GPLv2 licensing is a big issue, consider relicensing to BSD

[boegel]

After the PyHPC workshop at Supercomputing'2012, I was approached by Lauren Johnson from Enthought who informed me that the current GPLv2 license of EasyBuild is a big issue for companies. It will basically puts them of of looking at, let alone using, EasyBuild. Enthought licenses its open source products as BSD because of this.

This was backed by two guys from industry, as well as Andy Terrel (TACC). Although a dual licensing approach towards companies (e.g., having a separate BSD licensed version available) would help, i can get quite complicated.

Not only is it an issue for industry, but also for most Python hackers. In the Python community, all tools are released under a BSD license.

Several companies involved in HPC showed interest in EasyBuild, so this is an important issue.

We should consider relicensing EasyBuild under a BSD-style license to increase the likelihood of building out a community around EasyBuild...

Discuss!

[JensTimmerman]

Bsd license gives companies the ability to take EasyBuild and use it in their products without having to open up their changes, This does not help us forward as a community.

The Linux kernel uses gplv2, and I see a lot of companies having no trouble at all using that...

[boegel]

@JensTimmerman That's all very true, but if companies won't even take a look at EasyBuild because of GPL, then we won't be getting contributions for sure. With BSD, at least we give them no reason to just ignore it because of the licensing. I brought up this point during the discussion as well, and was told that companies that take a BSD licensed product and extend it usually contribute back instead of keeping it for themselves. In the end, they win as well, e.g. the community maintains what they've contributed or even builds on top of that. It's rare that companies just earn money on the back of a BSD licensed open source tool, or at least so I was told...

So, the community would benefit from relicensing to BSD.

[aterrel]

Hello,

Chipping in here because Kenneth asked me too. I don't really care to enter a long religious dialog over licensing your product but rather want to give some pros and cons of the basic licensing strategies.

TL;DR: While GPL does allow you to dual license, in practice BSD is a more community friendly license since everyone can use/improve the code.

Disclaimer: IANAL, you should consult a lawyer to get a definitive answer.

GPL: GPL provides your tools to the GPL community. It enforces anyone who wants to use your tools in code or other derived ways to join that community. In my experience, this is a major impediment for adoption in vendor solutions aside from companies that sell things like consulting around open source tools.

LGPL provides your tools to a larger community but makes sure changes and forks remain accessible to you. In practice this license is a good compromise if you are really worried about companies using your work without paying you.

BSD-like licenses provide your tools open to the widest community. In practice this results in a wider adoption and contributions from vendors much quicker than the (L)GPL routes. For example, all the core Python tools are BSD, PETSc is MIT-like and has lots of contributions from vendors. If your goal is to become a defacto standard for installing the Python and Scientific Computing stack, I would really recommend this license. The major downside to BSD is if you do have aspirations for monetization, they will no longer come from commercialization since you can't dual license.

Almost every community I have been a part of has made a lot of heat about this issue and it usually comes down to specific goals of the devs. Personally I always use BSD, its just less work to defend and I can always give it out, I've certainly seen good devs burned by universities and companies canceling the open license and basically taking all the work you have done. With BSD, this is very difficult to do.

Here is the discussion on Sympy: https://groups.google.com/d/topic/sympy/ta3dk57gyAM/discussion You can go to many other places on the web to find this discussion, and I encourage you to do so!

-- Andy

[piojo-zz]

Miguel de Icaza on StackOverflow:

The Apache license has some extra benefits over the BSD or MIT X11 license-style licenses. The Apache 2.0 licenses contain a patent grant, which means that at least the authors of the code are giving you any rights that you need for the authors' patents that happen to be in the code that you are using.

Considering how things are going now in the US, some US users may appreciate that patent grant.

Only the framework may merit a more restrictive license, but no more restrictive than LGPL. Or it will scare away commercial contributors.

[fgeorgatos]

Hi folks,

All your comments are valid, just a few more details to add.

since I had to do this kind of license research recently for some Uni.Lu business, here are some highlights from past emails; make your own judgements but, simply don't miss the judicium about Green Open Source Licenses, visible at Appendix F of the GEANT's IPR policy: http://www.geant.net/About_GEANT/Intellectual_Property/Pages/home.aspx GEANT needs to collaborate globally and exchange code with many many parties.

if the following is long for you, at least check the last 10 lines.

much of the information somebody would care for, is visible here:
http://en.wikipedia.org/wiki/Comparison_of_free_software_licenses#Approvals

The 3 licenses which tick all the boxes there are: MIT/ISC/BSD-modified
(did anyone say I wish to max-out compatibility and future options? yes!)

GPL is incomplete, if left alone; the proof for that is the existence of LGPL.
(I can hear FSF saying somewhere: ..."now we have two license standards"...)

MIT is my preference mostly because it is old enough (Xwindows, 1988) and
it has clear status in relation to the rest of the Open Source Software world,
which is, IMHO, what we all wish for code we want to contribute publicly:
http://en.wikipedia.org/wiki/MIT_license
And there are pretty plenty many people to care about its protection, too :-)

MIT/GPL should be equivalent to MIT; it is just "sugar" to say: "yes GPL guys"
and avoid the lengthy and distracting political discussions (*) and even
FSF paperwork like this one: http://www.gnu.org/licenses/why-assign.html

Here is some more elaborate discussion about MIT/GPL dual licensing matters:
http://stackoverflow.com/questions/3336161/mit-gpl-dual-license-in-commercial-software
btw. jQuery just switched from MIT/GPL to MIT! This happened during ~August.

(*)
Though there is merit in the political aspect of GPL, if I was to get *political*
I'd add in 1 tiny extra constraint: "you can't use this software in a smart bomb
or weapon targeting me or, my colleagues or, Uni.Lu or, our allies". Now, go figure!

and some more on the licensing saga:

Also the following bunch of people (big group) favored APLv2:
http://en.wikipedia.org/wiki/European_Grid_Infrastructure

So, I can now see the merits of Apache license (APLv2 to be specific):
Indeed, it has some clause of protection in relation to patent clauses.
In light of recent $$$ litigations, this is an interesting proposition.

That very one, though, is apparently a cause for incompatibility with GPLv2:
http://stackoverflow.com/questions/8373247/opensource-licenses-mit-vs-apache-license
ie. if a GPLv2 guy wants to use your APL2v2 code, he must then jump to GPLv3.
(as we are aware, GPLv2 is the most popular one in the OSS world, so far)

Thanks to archive.org, we can still find an old page with a comprehensive matrix:
http://web.archive.org/web/20090317083515/http://developer.kde.org/documentation/licensing/licenses_summary.html

and a little bit more, ok, finishing in this round:

APLv2 would be a no-go for easybuild contribs & any other project run around GPLv2!

To summarize what I understand, APLv2 gives better protection as regards patents
while MIT gives more latitude for mix-n-match in the OSS world.

ps.
Another interesting read reduces the number of licenses that matter to just 8,
avoid duals licensing, while suggesting to make a choice between APL and GPLv3 (!):
http://google-opensource.blogspot.com/2008/05/standing-against-license-proliferation.html
I think the reduction to 2 licenses is irrelevant for European academic institutions
though: it is only really meant to serve the save-your-butt-from-patents culture. 

But, the list of 8 can allow me to rewrite the combination graph in a readable way!

In fact, for the few that I care fondly about, here we go with some highlight rules:

MIT + anything -> MIT or, anything # MIT & BSD may be absorbed by "anything" license
BSD + anything -> BSD or, anything # 3-clause BSD gives a headache with advs.
GPLv2 + anything -> GPLv2 or, GPLv3 (or, any later version coming from FSF)
APLv2 + anything -> APLv2 or, GPLv3 or, anything that preserves its clauses.

And finally, an experimental site about merging OSS languages (!):
http://www.tldrlegal.com/compare?a=MIT+License&b=Apache+License+2.0+(Apache-2.0)

In short, the wise choices for anybody in european academia are MIT, BSD, APLv2. Dual licensed MIT/GPL, which I often use, is just like MIT or BSD, with extra sugar.

[itkovian]

I'm pretty hard in favour of sticking with GPLv2. BSD allows a company to take what we have, add to it and ship it, without having to give back like ever. Besides, to the best of my knowledge, it is not we who can decide about it, the code is legally property of Ghent University. How about using LPGL?

From a /. post about this:

The bottom line is, the GPL is not anti-commercial or anti- capitalistic; it is only anti-proprietary. The BSD license, on the other hand, is very unrestrictive, and allows proprietary knockoffs

I would like to see other people use this tool, I would like to have to pay up to get improvements, if the other party can use the existing code base for free. If a company asks to use BSD, I am not sure there's no hidden intention.

Also, Python is released under PSF license, which is compatible with the GPL. It's a BSD derivative, but that does not mean we should use the same license. However, I am not against the BSD in itself. I just wonder if it's the best choice for this work.

[dagss]

I don't mean to butt in but was asked by Kenneth and Jens to provide my perspective.

The GPL was originally created to encourage more people opening up their codes (you can only use this cool GPL library if you make your code GPL too). I'm sure there's cases where that happens, but I think much more often the GPL stops people from using the software.

So if you want to maximize the userbase, and thereby patches back upstream and amount of open source code in the world overall, I think the answer is BSD, not GPL. People who want to contribute back do it anyways (after all you don't want to be stuck maintaining your own patches on top), whereas people who then "steal" the code wouldn't use it in the first place if it was GPL, so it's the same to you.

(Often there are of course other reasons for choosing GPL, such as "the FFTW3 solution": Make software GPL and provide a commercial offering in addition. I'm not commenting on that.)

More important to me, BSD simply allows you to stop worrying about copyright, vs. with the GPL you need to worry about it all the time (you probably can't legally distribute software that has a dependency on both FFTW3 and CUDA for instance, though IANAL).

Moving into the more "personal belief" domain: @itkovian says: What if one is bothered by somebody else monetizing your code? Myself I'm employed by a university that's funded by EU tax money, and funded for Hashdist by US tax money. Some of that money comes from the private sector. So if my research ends up indirectly contributing to the bottom-line of companies then that's great.

If I was a mathematician or statistician, companies would read my papers and make money off the ideas in them. That's one of the points of public funding of research; that it can provide infrastructure for the private sector. Perhaps analogously, scientists often cite "HTML is a CERN a spin-off" as an argument for public funding of research, but a lot of the value of internet today is that people monetize it. So I just don't see other people monetizing as a problem (I guess if I wasn't paid by taxpayer money then perhaps I'd feel differently).

If somebody (the suspects would be Enthought and Continuum) were to take Hashdist and "make money off it", that would mainly just make me happy because of the increased userbase.

[end personal beliefs]

On a more practical note, the GPL now stops me from being able to lift snippets I like here and there in EasyBuild into Hashdist, as I want Hashdist to be BSD.

[dagss]

I forgot my most important point: Even if you stay GPL now, you should make sure you have copyright from patches others contribute assigned to you so that you have a choice in switching to the BSD later.

Also: The scientific Python community desperately needs an open source software distribution that's cooperatively developed (the best ones now are EPD and Anaconda but since they are not free there's little incentive for everybody to rally around them and standardize, and e.g., when holding Python tutorials for scientists you can't just give them a link to a "standard" non-propriotary solution for getting all the software they need on their Windows, Max and Linux machines).

If EasyBuild wants to have a shot at becoming the standard scientific Python distribution then the BSD may make sense simple because of the strong BSD culture in that community. In that case it would in fact help if Enthought and Continuum etc. were able to take EasyBuild and rebrand it and extend it, so that they could gradually transition their existing users to EasyBuild to make everything more uniform (this is very hypothetical and I'm not associated with either of those companies).

Does the GPL really matter for a software distribution tool? I think what matters is the time spent by lawyers to figure out the answer to that question for every company, not so much the outcome of what the lawyers say. One of the selling points of the EPD is that it's all non-GPL, simply so that you don't need to spend time investigating exactly which parts are GPL and whether the usage is legal or not (which takes time figuring out even if the answer is that it is, at least if the only GPL part is the distribution tool).

[itkovian]

The main problem is that Ghent University may not be happy with a company making money off code that was (at least partially) developed during working hours by UGent employees. My main concern is also that companies need not contribute back. If they're smart, they will, but they might not. I'd rather have a non-company oriented community, where companies can use the code if they deem it useful, but where they cannot hijack it and provide a closed framework.

If the GPL does not matter, why should BSD? At this point, I doubt we grasp all the consequences of either license.

[boegel]

The fact that we'd have to convince UGent if we decide we want to relicense to BSD (or whatever) is true. But we'll have to agree first, before we can take that next step.

GPL matters because it's viral, I think. Companies stay away from it, because they don't want to risk infecting other stuff they have in closed form, which would force them to release source code for that stuff.

The easy way is just to stay away from GPL code. The sensible way would be to handle it case-by-case, and see whether 'infection' risk if present. But I guess they just don't want to spend time/money on figuring that out. Hence, companies (and other people) simply stay away from it.

BSD is no issue there, because it doesn't have the infection risk.

That's how I understood the whole issue, do correct me if I'm wrong.

I think we need to compose a list of pros/cons on GPL/BSD/licenseX to streamline this discussion. I'll try and look into that ASAP.

[fgeorgatos]

Hi to all there,

I think we need to compose a list of pros/cons on GPL/BSD/licenseX to streamline this discussion. I'll try and look into that ASAP.

OK, I reformulate some feedback in the form of criteria ;-) below:

* large science project green status

As regards the point of view of EU academia, much of the important information has been investigated here: http://www.geant.net/About_GEANT/Intellectual_Property/Pages/home.aspx In short, from its point of view, the only "Green" licenses are: MIT, BSD-3, APLv2. Let's remind that GÉANT is THE leading network of networks for academic entities, globally.

* IPR clarity and compatibility

If EasyBuild catches the attention of GÉANT, you are forced to pass from its IPR Co-ordinator's office. In my eyes, that's already a deficiency of a license (IANAL and why should YOU be one, after all?!). Furthermore, the existence of LGPL is food for thought...

* Fitness for academic entities

GPL can work greatly for individuals, on the condition that you are willing to donate your software to FSF. And in fact, it has done so greatly for the Linux kernel and so many other situations. That doesn't automatically imply it is great within a university: """FSF requires that each author of code incorporated in FSF-oriented projects provide a copyright assignment, and, where appropriate, a disclaimer of any work-for-hire ownership claims by the programmer's employer.""" [1] But, AFAIK, IANAL, our academic work-for-hire contracts ask for (non exclusive) code ownership by any Uni. The Green licenses can do that fine, while GPL is far more tricky business with a few side-effects.

* Freedom for further work

So, either you don't assign the copyright to FSF and you lose the strong benefits of GPL or, you do so and actually make your academic org liable against FSF, fi. if UGent creates a spin-off company to build upon EasyBuild services! Personally, I'd think of the latter as a success story for the Belgian or EU taxpayer. GPL limits Uni's freedom, I can't ever see that as proper course!

* Established academic spirit

Finally, let's think of the paper of the project, seen at SC'12 or, any other paper for that matter: Is that released under a BSDish or GPLish license context? Why not add a clause and an NDA to the paper, to fence the passers-by from free-riding on the great idea and monetizing the concept? :-P

ps. The next "free as in beer" round is mine ;-)

enjoy, Fotis

[1] http://www.gnu.org/licenses/why-assign.html

[certik]

I also originally released SymPy as GPL, thinking that's the best for a community, but was quickly convinced by the established Python community to use BSD, so it's been BSD for the last 5 years roughly and that's been the best licensing decision in terms of growing the community.

Given that your tool would (or rather could) be at the bottom of several other projects (like hashdist), it should definitely be BSD licensed, that would be my simple recommendation.

[itkovian]

Several of the above arguments do make sense.

OTOH, there are numerous companies that successfully use open source under the GPL (think of the hundreds of Drupal shops and it's leading service provider, Acquia (OTOH, that's about the only example I am familiar with, though there must be others) -- the latter raising VC capital in the order of $30 M). So I am not sure this would hinder any eventual spin-off service provider. Of course, such a service would need to offer above and beyond standard EasyBuild.

The paper copyright is, as always, transferred to the IEEE (in this case), though preprints can be made available for free.

[scopatz]

Hello All, I am also commenting because @boegel has asked me to. Most of my major arguments have been made by @aterrel, @dagss, and @certik. That is to say I am strongly in favor of relicencing to BSD. The only I have to add is as follows.

Fundamentally, this isn't a technical or legal or freedom issue. The code doesn't care how it is licenced or who uses it, the lawyers are going to fight it out in court anyways, and the freest licence out there is the WTFPL.

This is a marketing issue. BSD has name recognition as being company friendly AND free & open source. In my experiance, when trying to get companies to adopt open source solutions they do not blink when told that it is BSD. For most other licenses, they often think twice and typically walk away. This is doubly true if you are trying to sell them on the customizability of the project and what them to potentially contribute back. Small and medium sized ventures are particularly hesitant since they do not have the legal resources a larger outfit does.

Ultimately, corporate and/or government buy-in is important because it helps ensure the long term support and survival. So branding your code to make it attractive to others is important in a Darwinian sense :).

Furthermore, as @fgeorgatos says,

So, either you don't assign the copyright and you lose the benefits of GPL or, you do so and actually make your uni liable against FSF, eg. if UGent creates a spin-off company to build upon EasyBuild services! Personally, I'd think of the latter as a success story for the Belgian taxpayer. GPL limits Uni's freedom, I can't ever see that as proper!

I think it is very important that products funded by the government or publicly funded institutions be themselves for the benefit of the public that paid for them. If a licence is a barrier -- or perceived as a barrier -- to greater public value than it should be dropped in favor of something else.

Having been in the Python and other open source communities for a while now, I see moving to a BSD licence as only being beneficial to all possible affected parties.

[boegel]

Here's a nice story about how much work it can be to relicense a long-running project, i.e. VLC: http://lwn.net/Articles/525718/.

So, we should decide soon rather than later.

[fgeorgatos]

It seems that FSF has managed to dismay even more people recently: http://article.gmane.org/gmane.comp.lang.smalltalk.gnu.general/7873 # sed http://lwn.net/Articles/529558/ # gnutls

Furthermore, if code from an APLv2 project or contribution was to be incorporated, a GPLv2 codebase should be promoted to GPLv3, which reduces karma, as per Linus: http://en.wikipedia.org/wiki/Free_Software_Foundation#Criticism

[fgeorgatos]

Slightly off-topic, won't affect the outcome of this discussion; but interesting for license geeks nevertheless. Said earlier:

Though there is merit in the political aspect of GPL, if I was to get *political*
I'd add in 1 tiny extra constraint: "you can't use this software in a smart bomb
or weapon targeting me or, my colleagues or, Uni.Lu or, our allies". Now, go figure!

And sure enough: http://linux.slashdot.org/story/13/01/09/227231/worlds-first-linux-powered-rifle-announced So, yeah, GPL code can be turned against you in a number of ways...

[ajdecon]

FWIW, here's a perspective from a sysadmin inside the corporate world: When we contribute anything to open source, it goes through an IP review, but any contributions to GPL and other "copyleft" licensed projects get extra scrutiny and tend to take longer to get approval. There are a variety of reasons for that which I'm not particularly qualified to comment on (IANAL), but it seems to be a common experience at a lot of companies. Contributions to Apache- or BSD-licensed projects are also reviewed, but the process seems to move more quickly and smoothly.

Aside from my job, I use MIT/BSD for personal projects because it makes it a lot easier to share code in general, and because most of the projects I'm interested use those licenses.

[JensTimmerman]

We have decided to stick with GPL v2.

However, to make re-licensing in the future easy I propose this Contribution Agreement https://github.com/hpcugent/easybuild-framework/pull/587

This scan be followed up in https://github.com/hpcugent/easybuild-framework/issues/223

[fgeorgatos]

It would be better if we had this link last year, much of the yada yada in this issue is compactly presented here: http://choosealicense.com/licenses/ # contributed by Ken over #easybuild on irc.