Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

Choosing a License for Research Software

By gavinb in Technology
Mon Mar 12, 2001 at 05:34:30 PM EST
Tags: Freedom (all tags)

Once again the debate over software licenses has flared up, this time focusing on the issue of which license is appropriate for software development funded by the government.

I am about to embark on postgraduate research, during which I will be writing a lot of code. I intend to GPL my code for a variety of reasons, and considering my scholarship is funded by the government, I figure it's a fair thing to do. What I want to know is, what others in a similar situation are doing?

The comments made by Jim Allchin have sparked yet another debate over licenses, but this time with a particular focus. Allchin now asserts that his comments were directed at the usage of the GNU General Public License (GPL) for government-funded software. Richard Stallman then wrote a very lucid and well-written response, providing some compelling arguments in favour of the GPL. Tim O'Reilly has now weighed in to the debate, trying to mediate on the issue. Tim has made some very salient and pragmatic points, and the debate is obviously far from over.

So, without entering into a flaming discussion on BSD vs GPL, I want to ask anyone who is writing code as a part of university or government-funded research: which license are you using, and most importantly, why?


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


Which license are you using for your university or government-funded software?
o GNU General Public License (GPL) 36%
o GNU Lesser Public License (LGPL) 4%
o BSD License 19%
o Artistic License 9%
o Apache Software License 0%
o Another OSI License 0%
o Proprietary 12%
o Other 17%

Votes: 41
Results | Other Polls

Related Links
o debate
o licenses
o comments
o GNU General Public License (GPL)
o response
o weighed in
o Also by gavinb

Display: Sort:
Choosing a License for Research Software | 32 comments (31 topical, 1 editorial, 0 hidden)
I chose GPL (3.60 / 5) (#1)
by guppie on Mon Mar 12, 2001 at 09:16:52 AM EST

I licensed the code I wrote for my master thesis under the GPL, mostly for political reasons. (I want to support the free software movement in general, and specifically the FSF). I'd be delighted if some corporation had to GPL their product because they built it on my code.

This was possible because the copyright of the work done by students in my university are owned by the students themselves, and we can use any license we like.

What? The land of the free? Whoever told you that is your enemy.
-Zack de la Rocha
delighted (4.00 / 2) (#10)
by PresJPolk on Tue Mar 13, 2001 at 12:17:44 AM EST

Do you really think that a business is going to open code they otherwise would not, just to use your code?

It's far more likely that you'll have people turn away from reusing your code thanks to the GPL, even open source projects.

The more times people have to reinvent the wheel, the slower free software will expand and improve. Help the community, use the X or BSD license.

[ Parent ]
BSD,GPL. (3.50 / 2) (#11)
by sety on Tue Mar 13, 2001 at 01:28:48 AM EST

The more times people have to reinvent the wheel, the slower free software will expand and improve. Help the community, use the X or BSD license.
I'll bite......

Who are these people re-inventing the wheel? If I write some code and Cisco reads my paper and downloads my code and says "shit we can't use this in our product, it's under the GPL". Cisco then proceeds to reinvent the wheel and duplicates what I have already done.

So it would seem to me that free software isn't suffering, but Cisco is for being stuck-up and wasting there time.

Now if you mean "BSD vs. GPL", well that has already been argued at length here, /., etc.

[ Parent ]

BSD vs GPL (3.50 / 2) (#12)
by PresJPolk on Tue Mar 13, 2001 at 01:38:08 AM EST

I exactly mean BSD vs GPL.

I don't care if proprietary people have to reimplement. I only care if free software has to reimplement. I'd rather that the developers of KDE libraries, Apache, XFree, and other projects were able to reuse as much as they could, to get as much done as fast as possible.

[ Parent ]
BSD<_>GPL (3.00 / 2) (#14)
by sety on Tue Mar 13, 2001 at 01:55:38 AM EST

Would you be satisfied (in a differnt world) if all free software was under either the BSD or the GPL. Would that be good enough or would you have a strong opinion one way or another?

[ Parent ]
BSD (3.50 / 2) (#15)
by PresJPolk on Tue Mar 13, 2001 at 02:07:41 AM EST

Sure, if everyone in the world were using only one license, then it wouldn't matter which free license it would be.

However, Linux isn't going anywhere. Neither is BSD, Mozilla, or Apache. All are using different licenses.

I like X or BSD licenses, myself. The fact that nvidia has released closed XFree server drivers doesn't prevent me from using my open Matrox driver. The fact that Sun and Microsoft have used BSD code hasn't prevented many people from being very happy with Net/Free/OpenBSD.

So it'd just be nice if more people used more sharing licenses. The impending GPL v3 will show why.

[ Parent ]
Forcing open sourcing (3.00 / 1) (#16)
by guppie on Tue Mar 13, 2001 at 03:49:18 AM EST

Well, I admit that the closed source hardliners like M$ would rather reinvent the wheel than open sourcing a product, but not all companies are like that.

For example, in my current company, we built some nifty tool out of a open source package. The managers saw the value, and wondered if we could sell this. I (triumphantly) told them that since we had built this thing from GPL code, our product had to be GPL too. Had the package been licensed under BSD, our managers would have forced us to create a closed source product, for sure.

Regarding open source projects: I know the holy war scenario is a big risk. (But that can happen no matter which license you choose). But open source projects usually come to some compromise, so that the code can be used by the project that wants it. (Dual licensing _is_ possible.)

What? The land of the free? Whoever told you that is your enemy.
-Zack de la Rocha
[ Parent ]
Dual licensing _is_ possible? (3.00 / 1) (#17)
by PresJPolk on Tue Mar 13, 2001 at 04:38:05 AM EST

But if you re-use third party GPL code, then dual licensing becomes impossible, unless you get written permission from the copyright holders, and everyone else who sent relevant patches to the copyright holders (if it is a community-developed project).

That's why making it a true open license is best for the community as a whole, because it makes it easier to share, reuse, and improve code. The whole licensing issue disappears, so energies become spent more on actual development.

Witness the time that was wasted arguing about whether it was legal to restribute the GPL parts of KDE 1. More open licensing avoids that stuff from the start.

[ Parent ]
The License Wars (4.00 / 1) (#20)
by Per Abrahamsen on Tue Mar 13, 2001 at 05:52:21 AM EST

> Do you really think that a business is going to
> open code they otherwise would not, just to use
> your code?

It has happened. The reason we have free C++ and Objective C compilers today, is that NeXT and whoever funded Michael Thiemann wasn't allowed to make the front-ends proprietary.

> It's far more likely that you'll have people
> turn away from reusing your code thanks to the
> GPL, even open source projects.

It is hard to judge "likelihood" of things like that. My experience is that it is a very small fraction of the actual developers who care about the BSDL or GPL license wars, one way or another. They just use the same license as the related projects. Thos who pariticipate in the license wars or mostly people who don't code, plus a very small number of very vocal developers.

[ Parent ]
license wars (none / 0) (#21)
by PresJPolk on Tue Mar 13, 2001 at 06:50:00 AM EST

interesting note about the compilers. While I doubt we'd lack C++ compilers (I don't know about ObjC), I'd be interested to see some details about that.

Anyway, it's not just a matter of license wars. It's a matter of outright compatibility. If BSDs tried to use too much GPL software, they'd lose support. Some other licenses, like artistic, or the QPL, are completely GPL compatible according to the FSF.

It's in cases like those, where the GPL hurts free software, not just license zealots.

[ Parent ]
GPL compatibility (4.00 / 1) (#25)
by Per Abrahamsen on Tue Mar 13, 2001 at 08:14:45 AM EST

> interesting note about the compilers. While I doubt we'd lack C++ compilers
>(I don't know about ObjC), I'd be interested to see some details about that.

RMS post the stories from time to time, they might be on the FSF site. Basically, NeXT licensed a commercial Obj-C to C preprocessor in the beginning, and used gcc to compile the C. This was fine, but for some reason NeXT wanted to use a native gcc front-end. They did ask FSF if they could write their own closed front-end, and link to the free gcc front-end. FSF told them no, so instead they released their front-end under the GPL, and even signed it over to the FSF.

> If BSDs tried to use too much GPL software, they'd lose support.


> Some other licenses, like artistic, or the QPL, are completely
> GPL compatible according to the FSF.

I think you mean incompatible. And yes, this is IMAO the largest problem with the GPL. Luckily, most software under the QPL and AL are also dual licensed under the GPL, so the problem isn't that bad in practice.

A dual QPL/GPL license will be compatible with most free software, and very little non-free software.

[ Parent ]
Ownership of "Your" Code (4.28 / 7) (#2)
by MrAcheson on Mon Mar 12, 2001 at 09:44:56 AM EST

Depending upon your work and the nature of the contract you have as a graduate student and nature of your funding, you may not be the one who can make this decision. For instance everything I write is technically my research groups under the control of my advisor. However myself and my group is partially paid by a US Navy contract (not a grant) so the Navy has last say on what we can do and how we can publish it.

In short read the fine print, your ideas may not be your own and your software may not be your own to license.

These opinions do not represent those of the US Army, DoD, or US Government.

Funding as a two-edged sword (5.00 / 1) (#8)
by gavinb on Mon Mar 12, 2001 at 10:40:06 PM EST

...you may not be the one who can make this decision.

Yes, excellent point. I am very fortunate in that my university does not claim rights to my firstborn as well as any IP I may produce. They do however have a clause giving them the option of exercising a non-exclusive license to it.

Provided I can obtain independent funding (such as scholarships and grants), I can choose my own direction. The difficulty is when you accept funding from other parties. They will obviously want their pound of flesh, and probably wouldn't be too happy about their share of the code being "given away".

Is it worth getting the extra research budget, to give away some (or all!) of the control and IP?

[ ::gavinb ][ "You can lead a moron to knowledge, but you can't make him think." ]
[ Parent ]

Ownership may be a complex thing. (4.00 / 1) (#19)
by Ben Ritchie on Tue Mar 13, 2001 at 05:26:00 AM EST

In short read the fine print, your ideas may not be your own and your software may not be your own to license.

These things may be resolvable - or, at least, defined - if you just work within your department, or when you are all funded by a single body. In my experience, however, this is rare, and any fine print may be either nonexistent or not applicable to the real world. My PhD has involved work on N-body simulations of galaxy formation, using a code developed by half a dozen or so people, myself included, at several different institutions over a number of years. Given the tendency for people to move around in academia I would guess that a dozen universities in five countries (England, Scotland*, US, Canada and Germany) could, in theory, lay claim to parts of the code, as universities invariably claim some sort of rights to your work when you are employed by them. Members of the consortium have also been funded by a number of different bodies during the period in which the code was developed, and these may also make claims to own or share IP rights.

Now, everybody involved will have their own small print, and I could almost guarantee that it would be of no practical use if one or more organisation decided that there was something to be gained by exercising their supposed IP.

Our solution, as such, is simply to licence the code in the simplest way possible, allowing it to be freely downloaded and modified provided we are acknowledged in any publications resulting from the use of our work. That's it. Unenforceable, of course, but simple enough that it won't wake up anybody in administration who might get worked up about more complex licences that could be seen to undermine the universities 'right' to the code. We don't tell, they don't ask, and that's the path of least resistance in the (un)real world that is my bit of academia. Yes, it hasn't fixed anything, and I can see the flaws in what we have done quite clearly, but if I really worried too much about licencing I'd still be arguing about it. Sad but true.

Having said that, I'd be interested to know how anyone has solved our problems. Or if?



*These things are often interpreted differently under English and Scottish Law, so I'll count them as distinct, rather than the UK. IANAL, of course, or I'd know.

[ Parent ]

My experiences (3.83 / 6) (#3)
by BigStink on Mon Mar 12, 2001 at 10:09:18 AM EST

Firstly, a similar topic was covered in this Slashdot story recently, and some of the comments may give you some additional points of view. One concern that I had after reading the Slashdot story was that some institutions may not allow previously published work to be submitted as part of your thesis. My university doesn't have such a rule, but it's worthwhile to check before you release your code under any license. Releasing Free Software's a great thing to do, but it's probably not worth risking your chances of earning your PhD :) OTOH, I would certainly be in breach of my university's regulations if I were to release any code which they considered to have any commercial potential.

As for my own experiences, I've written a number of programs during my 3 years of postgraduate research, but haven't released any of them. The main reason for this is that my code is just too messy to be worthy of release to the outside world. Although at the outset of the project my code is tidy and well structured, good software design practice (commenting, abstraction, weak coupling, not writing the program within main(), etc) tends to get thrown out of the window as I hurriedly add functionality to my software to try to discover something new. Almost all of my software is designed to model obscure phenomena in electronic engineering, so is unlikely be of interest to the rest of the world anyway. I decided that the (huge!) effort needed to tidy the code up wasn't worthwhile, considering no-one else would benefit from it.

What I've been doing (3.66 / 6) (#5)
by RangerBob on Mon Mar 12, 2001 at 01:23:15 PM EST

I've been using the MPL for a lot for my research, but might go looking for something else soon. I originally picked it up since I don't like a lot of the GPL and don't fully agree with Stallman. I would caution you to at least put some license behind it and not just dump it into public domain. My agency has had a lot of problems with commercial companies wanting code from us and then using it in products. One company even went so far as to take code, compile it, and try to sell it back to us without changing anything! From what I've seen, this is a problem other federal agencies have had.

I'm starting to favor something like the BSD license because all I ever expect of someone that uses my code is that they credit where they got it from. I don't really care if they modify it and don't send me the changes, and I don't really care about viral licenses that want all of the code to be released in source form. I just think people should give a professional courtesy if they uses someone else's work as part of their project.

Why MPL? (none / 0) (#23)
by gavinb on Tue Mar 13, 2001 at 07:38:00 AM EST

From the MPL:
4. (...) Except to the extent prohibited by statute or regulation, such description must be sufficiently detailed for a recipient of ordinary skill to be able to understand it.
I just went and read the Mozilla Public License (MPL), and I was reminded why I chose not to pursue a legal career. It's a pity they don't apply the above principle to the license itself, so that a person of "ordinary skill" can grok it!

I am now very interested to know why you chose the MPL, over say the Artistic License? It is not apparent from skimming the MPL just what the spirit of the license is, and that is just as important as the letter of the law. I understand if you don't agree with RMS and choose not to go the way of the GPL, but why the MPL?

[ ::gavinb ][ "You can lead a moron to knowledge, but you can't make him think." ]
[ Parent ]

Well.. (4.00 / 1) (#26)
by RangerBob on Tue Mar 13, 2001 at 08:59:55 AM EST

Actually, at the time, I choose the MPL 1.0 mainly because I didn't agree with RMS and I was really peeved because people kept trying to claim my work as theirs. I had a deadline and picked it since it it didn't seem to have the same viral nature of the GPL. In hindsight, it was probably a bad choice, and will probably switch to another one soon.

Why do I want to switch? Well, mainly because I don't want to use an overly complicated and fairly anal license. I'm actually a bit tired of the licensing issues, and have so far kept the brunt of what I've done to myself (the code that I actually write these days is usually on my own time at home). I might reissue my older stuff under a new license if I can, especially since to date, no one's really been using my older code except internally.

I agree that most licenses are way too verbose for their own good. I think we should all make a PEL (Plain English License) :) I'll probably look at something like the BSD license since it mainly just wants someone to give credit when they use code.

[ Parent ]
Public Domain (3.00 / 5) (#6)
by WinPimp2K on Mon Mar 12, 2001 at 04:12:05 PM EST

I don't think gov't sponsored software should be "licensed" at all.
To take a look at just one piece of software that had an immense impact on PCs.. The humble dBase started out at NASA. Ashton-Tate got ahold of it and made something of it. They spawned competition. Eventually, at the height of the "look and feel" wars (by now Borland had dBase, Microsoft had Foxpro) an expert witness remarked that dBase grew out of PD NASA code. The judge revoked Borland's copyright - but reinstated it less than a week later.
link Ashton Tate would not have made so much of dBase without a copyright on what they brought to it. We'd still be playing with dot codes and have no real RDBMs to play with if the original NASA code had been GPL'd

Protect the Source, Luke! (2.00 / 1) (#7)
by gavinb on Mon Mar 12, 2001 at 10:22:15 PM EST

Don't you think releasing source code without a license is dangerous? I think in the US and in Oz, copyright is automatically vested in the author (or their employer) once written. You can still retain copyright and give the code away, without completely divesting yourself of any control over your work. What if some company takes your code, commercialises it and then turns around and sues you when you try to release your own shareware version?

I think it's necessary to protect one's creation, even if you use the most liberal license available. For example, using your own example, dBase could still have succeeded if NASA had released the code under the BSD License (for example).

And I don't think we would have been without a real RDBM (was dBase really relational anyway??) even if this hadn't happened -- something else would have filled the void.

[ ::gavinb ][ "You can lead a moron to knowledge, but you can't make him think." ]
[ Parent ]

BSD or Public Domain (3.33 / 3) (#9)
by PresJPolk on Tue Mar 13, 2001 at 12:12:34 AM EST

If your work done on the code is funded by the US Government (since you didn't specify which government I'm guessing here), you should use a license far less restrictive than the GPL. Use the BSD license, or just put the work in the public domain.

The US government has along tradition of keeping information unrestricted. You are allowed to take US government information, republish it, and not send a dime to anyone. To keep source code unrestricted would keep with this tradition.

Your work is being funded by taxpayers. Let those taxpayers use your code with all free software licenses. Even RMS says that the GPL is not compatible with all free software licenses, so why restrict yourself?

Yes, that means your work may be used in some closed work. But think hard. Would that bother you? And if so, why? Greed?

Anyone who doesn't want to share with the community won''t do it. They'll chose something else, or break the license. So do the free software community a favor and make your code compatible with all sorts of licenses. Richard Stallman may have good ideas, but he has ulterior motives. He's fighting a war. Sharing is second to that war against people who don't share. Avoid hurting other free projects and use an open license like X or BSD, or just public domain it.

Selling BSD (4.00 / 1) (#22)
by slaytanic killer on Tue Mar 13, 2001 at 06:50:22 AM EST

So, without entering into a flaming discussion on BSD vs GPL, I want to ask anyone who is writing code as a part of university or government-funded research: which license are you using, and most importantly, why?
This was the article's question, and I think that gavinb had foresight when asking it so specifically. This is not the best place to sell BSD. You likely have good points, though so would an equally-skilled GPL defender, but there really are better places for it.

[ Parent ]
Editorial: Narrow topic (none / 0) (#27)
by PresJPolk on Wed Mar 14, 2001 at 12:47:25 AM EST

This is a broad-based discussion site, and the discussion article as-stated was too narrow.

So, as a taxpayer funding a tiny portion of his research, and a regular kuro5hin reader, I've taken the liberty of expanding the discussion.

And given the huge discussion above, it's clear I'm not the only one who wishes to take that liberty.

[ Parent ]
Ok, then onto the flames (none / 0) (#29)
by slaytanic killer on Wed Mar 14, 2001 at 08:13:47 AM EST

There are 52 comments as I write this, and about 6 of them are pure license advocacy. I do not find the discussion too narrow. Most people are not programmers, but you've got quite a few programming articles on the FP and Columns. How well would it be received if someone said, "Well, you shouldn't even program in Perl cause of the dual-license." It may be inevitable, but it won't be well-received if someone tries dominating the discussion with that.

As a US citizen and someone who also funds gavinb's research, I am against the BSD, in favor for the GPL. Too often have companies tried co-opting a person's code, extending it so it's a little improved, then using their marketing machinery to sell it. Unlike other areas of research where the audience is expected to publish their results, these companies are happy to patent some minor "innovation" or "business practice" and lock it away. Under no circumstances do I want possible avenues of this research to be locked away in this manner.

If a company really wishes to "innovate" with proprietary knockoffs of your software, they can very well make their own codebase, or specially license using the exception provision of the GPL. And if our country can finally get its act together WRT IP laws, then I would be more accepting of BSD as a research license.

[ Parent ]
(minor note) (none / 0) (#30)
by slaytanic killer on Wed Mar 14, 2001 at 08:30:09 AM EST

K5 mangled the numbers; in reality there were 28 messages. But aside from one editorial comment, the main number of pure advocacy comments were written by one person, with the predictable defensive responses. I am curious what would happen if the log wasn't filled with highly-polarized sentiments from demanding taxpayers.

[ Parent ]
school owns all? (3.33 / 3) (#13)
by sety on Tue Mar 13, 2001 at 01:47:45 AM EST

At UofO the school owns everything you do. If I want to relaese something under a license I believe the dean has to sign off on it. In the case of the GPL they are unlikely to do this because it reduces the commerical value of the code. As the university takes 50% of the first 100K made and a larger chunk after that it is in there best interests to keep the commercial value as high as possible.

Others in my group have published all there source code in the appendix of there thesis, this is now in the public domain and I believe is a way of allowing themselves (and others?) to use the code in the future. Can anyone comment if this is a legal (correct) statement?

Code in a thesis (none / 0) (#18)
by PresJPolk on Tue Mar 13, 2001 at 04:48:12 AM EST

Well, publishing your work in an academic form doesn't disavow the copyright.

Does the university or other publisher own the copyright, or get an exclusive license, to your thesis? If not, then you can license the code in it however you want. If so, then you really can't do anything without their permission anyway.

[ Parent ]
Figure out what your goals are first. (4.00 / 2) (#24)
by Per Abrahamsen on Tue Mar 13, 2001 at 08:01:30 AM EST

Really. Your are releasing the code for a reason. The license you choose should be the license that best promote that goal. However, first make sure your understand the legal and practical concerns:

LEGAL: Obviously, you must be sure you actually own the code. Otherwise, you are not the one who can select the license. There is a good chance that your employer or sponsor own the code. Check it first.

PRACTICAL: Mixing licenses can be impractical, even if done right it means the concerned user will have more licenses to read and try to understand. So, unless your goals (see below) interfere, I suggest for practical reasons to use the same license as "related" software. I.e., a program for the KDE desktop should use the same license as KDE, a Perl library should use the same license as Perl, an X11 utility should use the X11 license, und so weider. Think about what software "community" your program will be part of, and choose the dominating license in that community. These practical concerns often override the "political" concerns listed below.


1. GET RICH: Maybe you hope to make money of the product, and want to use the free version for marketing and perhaps debugging. This is perfectly all right, lots of useful free software is developed like this, examples include Qt, Ghostscript, Cygwin and ReiserFS. The developers of all four have both free and non-free versions available. Here, you want a "copyleft" license that prevents others from undercutting you in the non-free market. GPL is used by Cygwin and ReiserFS, Qt uses a QPL/GPL dual license, and Ghostscript uses the "Alladin GPL" which is just short of being OSI certified, but old versions are available under the GPL.

QPL can be combined with most free software licenses but GPL, and GPL can only be combined with GPL, LGPL, and licenses close to PD.

SUGGESTION: Use a GPL / QPL dual license.

2. GET HELP: A good reason to release the source code, is that you hope to get bug fixes and other contributions, i.e. free developers. Here, you want a license that encourage people to share back, but also allows so many people as possible to use it. A copyleft like GPL or QPL will prevent developers of non-free software to use it, and PD-like license like BSDL or X11 will allow them to keep their improvements to themselves. The compromise here is one of the "library" licenses, LGPL and MPL. Both are designed to allow or even encourage use in non-free products, but keep your part of the code free in form of a library (LGPL) or file (MPL). Theoretically, developers can write improvements and bug fixes in different libraries or files to "get around" the license, but since the complete product can remain non-free, there is little reason to do that. MPL can't be used in GPL'ed projects, and LGPL have some practical problems that might make developers of non-free products avoid it.

SUGGESTION: Use a MPL / LGPL dual license.

3. IMPROVE THE STATE OF THE ART. You love technology, and want us to progress as fast as possible. You don't really care about politics, and think free vs. non-free isn't as important as quality. You want a license that encourage others to use it, no matter who they are. Better products, free or non-free, will create a better world. Choose a well known and trusted license with a minimum of restrictions.


4. YOU WANT TO HELP PROMOTE FREE SOFTWARE. You like the idea of free software much better than non-free software, and want your contribution to help make free software software beat non-free software on quality as well as price. Here, you want a copyleft license to delay having you improvements copied to non-free solutions.

SUGGESTION: Use a GPL / QPL dual license.

5. WANT YOUR SOFTWARE TO BE USED. You have written this software, and simply like to know that as many people as possible use it. Here, you want to encourage everybody to use it as part of their products, and don't want any restrictions in their way. Public Domain would be perfect, but the concept is not recognized everywhere, and some claim it will leave you vulnerable for a lawsuit. I suggest using a well-known license, written by top-grade lawyers, and trusted by everyone.


Addendum (3.00 / 1) (#32)
by slaytanic killer on Thu Mar 15, 2001 at 06:57:17 AM EST

One point if you wish to pursue the GPL: You may wish to give the ownership to the FSF. In this case, you probably won't be able to grant exceptions (if someone offers you $$$ for the ability to make their copy proprietary, you might regret this); but on the other hand, the FSF takes care of problems that may arise, such as having lawyers sending little cautionary notes to people who break the license, etc.

[ Parent ]
GPL for other reasons (4.50 / 2) (#28)
by RandomPeon on Wed Mar 14, 2001 at 04:35:56 AM EST

I think the GPL might be a valid option for government-funded software.

From an academic's standpoint, you'd want the code to remain open as much as possible - this might not happen with BSD, depending on the nature of your project, as previous posters have pointed out.

From a "I work for the taxpayers" standpoint, it seems that the GPL would allow the public to maintain permanent access to the project and its derivatives. The relatively widespread use of the GPL has prevented CS departments from looking like chemistry and pharmacy programs.

If you look at a chem, biochem, or pharmacy dept at any research university you will see that its research administration raises some unsettling questions. A lot of their research is immediately appropriated by corporate partners and patented. They've demonstrated that they can survive on corporate grants, so they can expect relatively little funding from the university - which means that corporate grants influence the nature of research far too much.

The Zy***(or whatever) lawsuit at my school is a good example - a corporation funded research on an AIDS drug and ceased funding of the project once they had enough data to finish the work internally. Needless to say, they patented the whole thing. Total value of taxpayer-ripoff: over $1 billion.

Could Intel cut off my advisor's large grant for "Binary Code Reoptimization for the IA-64" once the cost to complete the project internally was low enough and then convert it into payware? Not in this case, because everything is under the GPL.

The relatively widespread opposition to cozying up too closely to corporate interests in CS has prevented this kind of crap from being too widespread. Since many academics use the GPL or GPLed software in their projects, there is relatively little opportunity for research funding to be subject to these tactics. Your project may be a different story, there may be no funding issues or hostile parties waiting in the wings. But I think that a presumption towards the GPL prevents CS departments from becoming wholy owned subsidiaries of AOL-Netscape-TimeWarner or Microsoft-NBC or other giant corporations. Sure, you can be like chem folk and get plenty of money out them, but they expect to reap all the rewards.

Be *very* careful (4.50 / 2) (#31)
by drgerg on Wed Mar 14, 2001 at 10:41:06 AM EST

I'm going to totally avoid the philosophical points but I will bring up a couple of points of caution:
  1. As someone has already pointed out, many universities have restrictions on what you are allowed to do with your code. You probably signed something indicating that you are aware of and will abide with their policies. I'm guessing you don't really want to run afoul of these policies. Universities (particularly these days) have big legal departments.
  2. Be very sure that your advisor is aware of what you are doing and approves. Again, it's probably not a good idea to step on his/her toes.
Now that I've got those important things out of the way, I'll bring up a question: are you sure that you want to release something for other people to use? Let me justify that question.

During my Ph.D. work (I am a chemist), I wrote a package of software for doing quantum chemistry and visualizing the results. I did this because the existing academic code was difficult to use and/or less flexible than I wanted and/or a mess which had accumulated over the course of decades. Oh yeah, and I wanted to deeply understand the underlying chemistry.

After getting the package to v1.0, I decided to release it to the community as a whole. I checked with my advisor, who thought it was a good idea. We both got the university to agree that it was okay. So I released the code under a "Do whatever you want (except sell this) as long as you give me credit, and please cite this as follows if you use it in a publication" type of license. I chose this license because I didn't like how complicated the GPL was... I read through it over and over again and couldn't figure out what all meant. I was sure that I didn't want my code to get used in commercial products though. I believed in the FSF, I just couldn't understand what they said. :-)

Anyway, the package was pretty successful. Lots (a relative term) of people downloaded it and started using it. It was great! People were using my software! Woo hoo!

That was 1994.

Now, 7 years later, part of me wishes that I had never released the package or its updates. Why?

  • I still get support requests/questions in my email. I don't even use the damn thing anymore (and haven't for a couple of years), but I'm still responsible for it. Lots of those support requests are from people who obviously haven't even browsed through the manual. Answering the same question (which is answered in bold face in the @#$%@#$ manual) 150 times gets old fast.
  • It's amazing how difficult it is for otherwise intelligent people to actually do things like cite a program as the license requests that they do. I used to vanity surf Science Citation Index to see how many people were using the program. Those who did cite it would do so randomly (mis-spelling my name, getting the url wrong, etc), but lots of users didn't bother citing the program at all.
Whoa... this is getting close to turning into a rant. So I'm going to stop now. My big point here is that you should seriously think about why you are releasing the program and how willing you will be to support it for the next N years. Maybe that's not an issue in your field, so you won't have any problems.

I'll keep my fingers crossed.


Choosing a License for Research Software | 32 comments (31 topical, 1 editorial, 0 hidden)
Display: Sort:


All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!