8 ms·
"Permissive" licenses like MIT and BSD literally permit you do more things with the software. In particular, it is not legal to combine GPL software with GPL-in
by StefanKarpinski 13y ago
"Permissive" licenses like MIT and BSD literally permit you do more things with the software. In particular, it is not legal to combine GPL software with GPL-incompatible software (e.g. anything proprietary) and redistribute the result. This is why we cannot distribute a version of Julia pre-built with Intel's MKL even though we have MKL developer licenses that were generously donated by Intel. The fact that we use some GPL libraries makes the combination illegal to distribute. With permissive licenses like MIT and BSD, that isn't a problem.
In terms of choosing a license for an open source project, I think you should choose the most permissive license that will sufficiently encourage people not to make proprietary forks. The GPL was designed on the premise that it would be necessary to legally force people to contribute changes back, but the success of so many projects with MIT and BSD licenses shows this often isn't necessary. I think the choice depends on how "infrastructurey" or "producty" the project is. For projects like libraries, compilers or programming languages, it turns out that proprietary forks don't happen because of simple economics. Why would anyone pay for a forked proprietary version of a library when the original open source project is available? And if no one wants to directly pay for a forked version of some library, why would any company bother maintaining a fork when they can just contribute their improvements back and let the open source community maintain them for free?
With a self-contained product like Light Table, on the other hand, there's a very real danger that some company could come along, fork the code base, make a bunch of improvements and start selling their version. Using a viral open source license like the GPL makes this illegal, ensuring that only the original author can sell forks of the product.
tl;dr – GPLv3 is a great choice of license for Light Table because it is a product, but it's overkill for most open source projects which provide much lower level functionality.
- StefanKarpinski 13y agoI was pondering what the key psychological difference between "product" and "infrastructure" is – why are people willing to pay for one and not for the other? I'm not sure, but I think that for products polish is paramount, whereas for infrastructure, maintainability is paramount. Proprietary software is a nightmare for installation, deployability and maintenance, whereas open source is great. This is why open source has won the hearts and minds of people who build and deploy websites and other computing systems everywhere while companies producing polished products still rule the desktop.
- zmb_ 13y ago> The GPL was designed on the premise that it would be necessary to legally force people to contribute changes back This is the rationale Linus gives for using GPL: Wanting to let people use your stuff while requiring them to give you access to any modifications. However, Richard Stallman (who wrote the GPL) has been very explicit that it is not the premise behind the license and that he disagrees with Linus on that point. The premise behind GPL is to promote freedom[1]. In short, to ensure that the user always has complete control over the software they run. GPL ensures these freedoms, while permissive licenses that allow distribution of derivative binaries without sources do not. [1] https://www.gnu.org/philosophy/free-sw.html https://www.gnu.org/philosophy/free-sw.html
- StefanKarpinski 13y agoThe argument that software that you're not allowed to use in certain ways is somehow more free just doesn't pass the sniff test for me. RMS's rationale is very much an "ends justify the means" argument: it takes away immediate freedoms to promote freedom at large. My point is that for many kinds of software the means of imposing legal restrictions simply isn't necessary to achieve the same ends – the freedom of the software maintains itself just fine for technical rather than legal reasons.
- tracker1 13y agoGPL ensures that your fork's users get the same freedom to use the software that you get from the original/base... If you don't like the license, don't use it. There are plenty of people that don't use any commercial software if they can avoid it.
- dragonwriter 13y ago> GPL ensures that your fork's users get the same freedom to use the software that you get from the original/base... That phrasing presumes that the existence of a fork is not determined by the license terms. GPL guarantees that the would-be users of a fork that would have been made by someone not interested in (or able to, because of conflicting requirements necessary to actually produce the fork in question) providing Free software on the particular terms in the version of the GPL used by the particular upstream provider on which the putative fork would depend get nothing at all.
- cjo 13y agoGreat post! For those interested, GNU's Lesser General Public License (LGPL) was created to address these concerns.
- eropple 13y agoIt's not a particularly good one unless a static linking exception is included (dylibs on OS X are a pain for no serious benefit, it's not viable at all on Android or iOS).
- StefanKarpinski 13y agoLGPL is just fine in this regard – you can ship with and link against an LGPL library together with proprietary libraries because the combined result need not be under the LGPL. Whether you link dynamically or statically is irrelevant from a legal perspective.
- cstejerean 13y agoExcept that's not actually true. See, the point of the LGPL is not just that the user has access to the source, but that the user can modify the source and run it. Dynamic linking allows the user this freedom. Static linking generally does not, so unless you provide a way for users to delink your binary then you have to distribute the entire binary as LGPL.
- revasm 13y agoThe parent poster is talking about static linking against a third-party LGPL library, not your own library. In such a case, failing to provide the complete source code, or the original compilation dependencies (.o, .a, .so) and the build chain, is very much against the LGPL. (Edit: I can't seem to quote the LGPL section 4, so here is a link to it: https://www.gnu.org/licenses/lgpl.html#section4 https://www.gnu.org/licenses/lgpl.html#section4) There is a massive reluctance in the QT community over this currently -- people want to distribute single-binary applications, and they are told to be careful about doing it.
- jakobe 13y ago> ensuring that only the original author can sell forks of the product I consider this the absolutely worst reason to use the GPL. Quite a few companies (large companies like MySQL/now Oracle or small ones like Macromates) require contributors to sign an agreement that allows the company to distribute the code under a different, proprietary license. Doesn't this circumvent everything the GPL stands for? If I contribute to such a project, what guarantee do I have that the owner doesn't just distribute the software, including my contributions, under a proprietary license and stops making improvements public?
- andyroid 13y agoYou don't. And that's why people stop contributing to such projects and forks are created (see MariaDB). But that's not really a fault of the GPL. You could require contributors to agree to whatever you want regardless of the license you choose. Contributing to proprietary software (often as a result of an employment) sure comes with requirements other than the code itself.
- StefanKarpinski 13y agoI didn't mean to imply that it was a good thing that the original author could sell forks but rather that it was better that only the original author(s) could. This is one of the reasons I'm not fond of CLAs (contributor license agreements) and why Julia doesn't have one – the code belongs to the whoever wrote it and we can't relicense their contributions any more than they can relicense ours.
- jordigh 13y ago>> ensuring that only the original author can sell forks of the product > I consider this the absolutely worst reason to use the GPL. I think rms is right here. Selling exceptions is a good thing. It's certainly no worse than selling proprietary forks of non-copyleft free software: http://www.gnu.org/philosophy/selling-exceptions.html http://www.gnu.org/philosophy/selling-exceptions.html Why would it be ok to take non-copyleft software like clang and make proprietary forks with it, but not ok to sell exceptions in order to fund copyleft software? EDIT: As an Octave developer, I greatly respect how FFTW's copyleft is used, for example. Matlab buys a license exception to use FFTW. Octave gets FFTW under the terms of the GPLv3, just like Octave itself, which we in turn contribute back to everyone else. Matlab and Octave are both using the exact same library for Fourier tranforms. I like this model. Everyone is paying one way or another, no freeloaders, just lots of freedom.
- barbs 13y agoJust to clarify - it's not illegal to sell GPL'd code, so long as you provide the source with the binary. In fact, this is exactly what happened with Dosbox Turbo (https://play.google.com/store/apps/details?id=com.fishstix.dosbox https://play.google.com/store/apps/details?id=com.fishstix.d...). Dosbox is licensed under GPL, but here it's still being sold on Google Play. The author, fishstix, will send you the source if you've paid for the binary. This is completely legal. https://sites.google.com/site/dosboxturbo/gpl https://sites.google.com/site/dosboxturbo/gpl There were a couple of good discussions on this on SlashDot and VOGONS: http://yro.slashdot.org/story/12/12/09/1721200/ask-slashdot-where-do-you-draw-the-line-on-gpl-v2-derived-works-and-fees http://yro.slashdot.org/story/12/12/09/1721200/ask-slashdot-... http://www.vogons.org/viewtopic.php?t=34107 http://www.vogons.org/viewtopic.php?t=34107
- ivanca 13y agoWhat happens if your software haves 2 binaries that talk to each other and one of them contains the GPL'd code; can I just give the code for that one or do I have to release the source of both?
- barbs 13y agoIt's a bit of a grey area, but the FAQ states that so long as they're kept separate, and they communicate "at arms length", they should be ok: https://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem https://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySy... http://programmers.stackexchange.com/questions/110380/call-gpl-software-from-non-gpl-software http://programmers.stackexchange.com/questions/110380/call-g... Disclaimer: IANAL
- belorn 13y agoSooner or later, laws will get interpreted by a judge/jury. You question is equal to asking at what point a work should be considered a derivative work. The answer is sadly quite blurry, and country specific. US law say something like: "A “derivative work” is a work based upon one or more preexisting works, such as ... abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted." What would a judge say about two separate programs that talk to each other? A lot of people and companies has their opinion about it, but there is not much of case law in existence. All one can say is that the GPL author does not consider IPC level of communication to trigger a derivative work.
- camperman 13y ago| Using a viral open source license like the GPL A common misconception. Copyright law is viral.
- fulafel 13y ago> For projects like libraries, compilers or programming languages, it turns out that proprietary forks don't happen because of simple economics. Apple's/NeXT's compilers were a high profile counterexample for many years.