Many people, even some lawyers, don't understand the GPL. :/ It elicits this kind of knee-jerk reaction in people.

Let me provide another viewpoint: many people don't understand the GPL, and any criticism of it elicits a knee-jerk reaction.

I've been in discussions about problems with the GPL in several companies already. The real problem is not (as most people tend to think) the requirement to provide source code and the rights to modify and redistribute it. The problem is the patent claim landmine that is considered to be dangerous by many lawyers (see GPLv2 Section 7, LGPLv2 Section 11). I don't want to go into excessive detail here, but in brief: the danger is that you might have to immediately stop redistributing the software if you become aware of a patent that would restrict the rights provided by the GPL.

A library project which is under GPLv2 or GPLv3 gets immediately rejected in many (most?) commercial settings. Note that I'm not judging here — just stating a fact. We ourselves reject a lot of interesting options because of licenses and I know most other companies do so as well.

Now, LightTable is not a library project, but I can imagine how companies would like to bundle it, or bundle a modified version of it. The moment you "redistribute" it, the GPL applies, and if you build a business on this software, that business might have to suddenly fold some day because of patents.

Please don't respond along the lines of "you might get a patent lawsuit anyway". Yes, you might, but then it's a lawsuit, which you can defend against.

Please understand that the license change is a really big deal for some people.

> any criticism of it elicits a knee-jerk reaction.

While this also may be true, I'm quite familiar with the patent issue. And I am not even really criticizing Light Table for this decision, just expressing a tinge of sadness that yet another project has switched to a non-viral license.

> Please understand that the license change is a really big deal for some people.

Yup, I'm one of them.

Does that mean that companies are happy to work with GPLv1 code? If so, I'm surprised more projects don't use it.

You are definitely correct that some of the aversion is a knee jerk reaction and misunderstanding, but that aside, the MIT license is very end user friendly, more understood than the GPL, and more permissive to the end user, plus we kept hearing from folks that that's what they wanted, so we switched.

BSD is _developer_ friendly, not end-user friendly. In this case, your end users are developers, though...

The GPL sacrifices developer freedoms for end-user freedoms. I don't think it's any inherently more or less free. But then you get into discussions of what 'freedom' means...

I have written a ton of software licensed as each, and the tide is certainly turning toward the BSD. It just bums me out.

It's not about end-user freedom at all. The GPL is there to establish the freedom of the code itself.

For the end-user it's irrelevant what license a product uses. They buy a polished, boxed product; they don't download source code, set up the code's build requirements and then compile it.

The only practical benefit of open source products for the end-user is that there may be forks of it which could have an impact on the price (although a product is more than just its source code, so they may not even be interchangeable). Or that someone could pick it up if the original developer abandons it. But these are theoretical long-term benefits, not immediate ones like those for developers or the code itself.

I'm not saying the GPL is bad. Just that people often misunderstand its motives. The GPL is about code in the same way PeTA is about animals. If the humans benefit directly from it, that's great, but the primary motivation is an ethical absolute: code should be free, locking it behind proprietary licenses is against its nature.

The GPL exists to ensure that code remains easily attainable and modifiable. These are huge end-user benefits.

GPL and BSD/MIT-style licenses are not equivalent in this regard, because code under BSD/MIT-style licenses is not obligated to be either easily attainable or modifiable. You can ship binaries and not release source code.

You can profit from GPL code. MySQL is perhaps the best example but there are others.

Keeping the source open is a big deal, because communities and projects can die otherwise. More than a few game mods, for example, have died because the developers closed the source to mitigate cheating, and then stopped developing the game altogether. Under the GPL, this could never happen.

I disagree. You're thinking of the end-user as unsophisticated, who treats the software as a black box, but I'd argue that the philosophy behind the GPL includes the end-user as someone who potentially wants to change the tools he works with.

This separation between "developer" and "end-user" is common, but by no means absolute; there are many examples of non-professional developers adjusting their own tools such as scientists, business analysts, financial advisers, etc.

Besides, the GPL also grants the right to share the binaries with other people, which is definitively something that every end-user does.

The free software philosophy is about giving freedom to people to modify and share code. Code is not a person, it does not need to be free or to be treated ethically for its own sake. The GPL is in no way like PETA.

I was very pleased that Light Table went against the current fad and adopted the GPL, so this turn of events is exceptionally disappointing. Editors/IDEs are particularly effective places to use copyleft, because it encourages the development of a free software ecosystem around them.

I don't think 'shipped' has been clearly defined in court. Let say you extend it in-house, contractors move in, and you let them install the modified development environment on their laptops. Do you have to give them your changes upon request, licensed under the GPL?

Also, if you make a web-based product based on this, and a customer insists on hosting it in its cloud (many do because they do not want to, or in practice aren't allowed to, let their data out of their systems), can you sell it?

In both cases, did your patents just get free for all to use?

The moment you let in GPL code, you either give up having non-GPL code in your company, or you have to start spending time keeping the GPL and non-GPL code apart. If you do the latter, it also affects your flexibility.

Hmmmm.... I don't think these answers are ambiguous. I certainly have never read anything which suggests that your text editor influences what you can deliver.

You should already be tracking the licenses of the code you use. The BSD and MIT licenses both require attribution to the original copyright holders.

Personally, I will not contribute to something that's GPLed unless it's really important project - the Linux kernel for example. I know a lot of other developers that think the same.

Why?

The GPL is a vehicle of the Free Software ideology. Not every open source contributor is fully committed to that ideology.

The general argument in favour of the GPL and similar restrictive licenses is that it's not possible to extend GPL code without distributing your extensions under the same license (where the exact definition of "distribution" and "extension" is the main difference between LGPL, GPL and AGPL). It's largely about "us" (the Open Source community) vs "them" (the corporations, who historically don't contribute to open source).

In practice there is a vast body of open source code licensed under permissive licenses like MIT, BSD or Apache already and companies are releasing their open source projects under these licenses all the time. Even without the GPL, open source is here to stay.

On the other hand many companies now dual-license their projects under the GPL and a commercial proprietary license, with the GPL version being often intended as a "demo" to advertise the often very expensive but non-viral proprietary license (see Sencha for a perfect example of this approach). The ability of other GPL projects to make use of these projects under the GPL license is more of a side-effect (and free advertising) than an altruistic intention.

I think this has to do with the general shift in how we think about copyright today. Restrictive ("Copyleft") open source licenses subvert copyright to create a shared commons (which everybody can use but nobody can own). Permissive open source licenses abandon most of the copyright by just limiting it to an attribution policy and some basic cover-your-ass legalese (thus creating something everybody can use and own).

In most cases, if I've written some open source code I would rather see someone exploit it for profit than see someone prevented from using it because they can't meet the license terms. I don't claim to speak for anyone else but that is the logic.

Yeah, I totally agree with you on that front. The GPL (especially version 3) really stifles the ability for others to use your code. I license everything BSD so that what I do can help others. Plus the GPL is HUGE and I can't be bothered to read it all. I know, though, that I don't agree with the viral licensing shit that it does and have read those parts.

I support your idea, start a school of philosophy on this? Crowdsourced capitalism?

That sounds like a lot of work, and I'm sure a lot of folks have expressed or at least agree with the sentiment. But I'll consider writing about it in more detail.

Yeah, I did not get that either. I also do not understand why the GPLv3 would necessitate a contributor agreement, but MIT would not. I always thought those agreements were necessary so that one institution has copyright and can change the license without getting approval from every author. That applies to any free license, doesn't it? Anyway, I think they just wanted to change to MIT before new authors commit without an CA, after which they cannot change it so easily.

The decisions were largely separate.

The goal of having a CA was to leave us the option of selling commercial plugins in the future. We no longer plan to do that so we got rid of it.

Separately, we kept hearing that the GPL is a hurdle to adoption at some companies so we switched to MIT.

Were these concerns over Light Table for internal use by these companies? If so, then that sounds a lot like ignorant fear-mongering, either by counsel or execs playing armchair IP lawyer. I understand resolving the "sales objection"; it's just disappointing to see these licensing misconceptions persisting.

We were hearing concerns that the CA was worded in our favor and was one-way, in that people could contribute and we could take their work and commercialize it down the road without open sourcing it.

Did you consider alternatives, like for example, Mozilla Public License version 2 ? It is a file based copy-left license that is compatible with GPL.

Why not adopt the Eclipse Public License (EPL), which is the license used for Clojure/Script and the majority of open source Clojure libraries?

http://opensource.org/licenses/EPL-1.0

The EPL is incompatible with GPL, so you lose another group.

That makes sense, but then it begs the question of why Light Table was originally distributed under the GPL, i.e. since it's built from EPL'd software... and the GPL is incompatible with the EPL, as you say.

Does Light Table's new MIT license insulate developers from EPL-GPL compatibility concerns that might arise from the EPL'd pieces (Clojure/Script, et al.) used to build it?

A compiler or similar tool doesn't generally affect the license of its output (some of them explicitly disclaim that), just as a text editor doesn't affect the copyright of a novel written in it. The GPL is much more widely popular than the EPL, and now that it contains comparable patent language it is probably a better license to use (when the EPL was first written it was primarily to address patent issues that the GPLv2 didn't cover). I would hope that projects that are using the EPL would now migrate towards the GPL where possible - strong copyleft licenses are inherently impossible to combine, so it's best if the community can standardize on just one.

The MIT license is compatible with almost everything - it's really very minimal, comparable to a 2-clause BSD-style license. There is no problem combining MIT licensed components with EPL licensed components, or with GPLed components. (Of course there is still a problem if you want to combine with both at the same time)

If you don't want to support commercial plugins, then those companies have no legitimate usecase that would require avoiding the GPL.

No, they didnt plan to sell commercial plugins, other people still could.

The viral patent grant in gplv3 is very scary to companies that that hold a lot of patents. This seems to be a decent overview: http://www.internationallawoffice.com/newsletters/detail.asp...

A CA isn't really necessary for GPL code as such, but changing license without one is a massive pain, so you essentially commit to GPL and its restrictions forever if you don't have have one. This has caused problems for other projects (I think KDE is an example).

Obviously this also means we can't move from MIT now either, but it wouldn't really make sense to, since you can't practically add restrictions to already published code. (Strictly speaking I think you could still use LT under the GPL if you wanted).

The GPL makes a contributor agreement necessary if the original developer wants to distribute a version that does not comply with the GPL. With the MIT license, the original developer can distribute a proprietary version without a CA.

People rightly or wrongly don't feel comfortable modifying GPL code. And don't see any benefits to GPL. That seems pretty straightforward to me.

Why would people not feel comfortable modifying GPL code? The entire goal of the license is to allow people to make and distribute modified versions.

Because you're required to participate in some sort of re-distribution activity that is unrelated to your primary goal.

That isn't true. All the GPL requires is that if you distribute a modified version of something licensed under it, you must also make your modifications available to users under the same terms. If you don't distribute your modified version, the license doesn't apply to you at all.

From the perspective of someone contributing code to an open source project, there is no difference between a MIT-licensed or GPL-licensed project -- your contributions are covered under the same license as the project as a whole.

OP specifically cited companies that were wary of the license requirements with respect to code modifications. Not sure how it can get much clearer. The licenses are not even similar.

I just don't see where "comfort" comes into it, unless it refers to people wanting to release proprietary modified versions or extensions. If that's the case, "please change your license, because I would like to distribute proprietary derivations of your software" is a different argument than "Please change your license, because I do not feel comfortable modifying GPL code". The latter makes it sound like GPL code has copyleft cooties that jump out of the code and onto developers.

Yes, that's exactly the baggage that GPL carries.

Companies might WANT to ship it, enhance it, sell proprietary plugins for it, etc.

That's exactly why I've started to use the GPL for my OSS projects. If someone is going to make money off of modifying and redistributing my code, then I want them to pay me, either in code or dollars. I don't open source my projects so other people can get paid first. You wanna get paid off of my sweat, you have to chip in.

I know, I was surprised as well. And if there are legitimate issues, isn't this exactly the dual-licensing opportunity that open source projects dream of?

Firstly, dual-licensing requires that all contributors sign a CA, which is enough of a annoyance that many minor fixes just don't get contributed at all.

Secondly, Mike Innes (http://junolab.org/) is one of the big contributors to Light Table and has told us that many of the commercial users of Julia are uncomfortable with GPL code and that changing to MIT would help adoption.

The common thing these days is to include your CA in your pull request the first time you contribute by adding your own name to a list of contributors as a means of signature, then all future contributions are considered assigned. If that is too much of an annoyance to contribute to a project, then perhaps the contribution isn't that important and won't be missed.

And what does that even mean, "uncomfortable with the GPL"? I have this picture in my head of developers programming with GCC, sweat dripping from their brow, looking over their shoulders for Richard Stallman to come and steal their laptops out from under them. Using GPL software does not have any impact on the work you do. It's only modifying GPL software and distributing those modifications that matters.

Many large companies won't touch it if it's GPL.

That depends on what you mean by touch. If by touch you mean modify the code, then you may be right. But if by touch you mean use, you are wrong.