Julia and (most?) Julia packages are developed under the MIT license, which is a very permissive one.
Is there any problem/concern (with Julia philosophy maybe, or any other restriction) to use a different license as GNU-GPL for a Julia package?
4 Likes
You can use GPL, it’s just a bad choice.
2 Likes
You can use GPL, it’s just a bad choice.
Not friendly to others. I won’t depend on a GPL package (because of the copy-left).
4 Likes
It is just a culture thing. Some open source communities are very GPL based (R for example) whereas Julia and Python are very MIT based. If you go against the grain you generally will make people grouchy but there is no legal / technical reason to not use what you want – but if you have the choice you will get more interest in Julia with MIT.
11 Likes
@gabrielgellner has it. This is all about culture, which should be apparent from the two previous replies (“just a bad choice” and “not friendly to others”). For what it’s worth, I am generally a fan of copyleft, but I’ve seen no reason to put my existing julia packages under anything but a permissive license.
6 Likes
FWIW, while I am fine with MIT, given that Julia is focused on scientific computing I don’t see a huge problem with GPL for packages used in science — the R community is doing fine it. But MIT is a good default too, and choosing a good default is important given how cumbersome it is to change the license later, especially if there are contributors.
2 Likes
Also, which GPL, v2 or v3? The distinction is important. [video: Linus on GPL v3, 10min]
1 Like
Thanks all for the answers and points of view.
Definitely, for a Julia package, @gabrielgellner’s comment needs to be taken into consideration.
@Tamas_Papp That would be GPLv2
I usually prefer LGPL3. The idea is of using a copy-left license is that no Mac OS is developed based on Linux and further development stays in the proprietary software rather than go back to helping the original one. Again, this is a safeguard which in many cases might not be needed due to norms rather than legal aspects. Sometimes even if a project is forked and takes a different license due to the similarities development trickles down to the original. MIT is a universal donor while LGPL3 is a receiver of other GPL and MIT. In a fertile environment MIT would be ideal, but risk-adverse people might opt for LGPL/GPL.
Adding to the discussion, the ISC license is a cleaner (and equivalent) version of the MIT license. I use it in my packages and I am pretty happy with it:
3 Likes
I find Richard Stallman persuasive. While I don’t live up to his ideals, I at least prefer the GPL.
Sure, MIT is more permissive, but that doesn’t equate to more free – the freedoms copyleft denies are those to rob others of theirs.
In a perfect world we wouldn’t need GPL, but in a perfect world the two would be equivalent anyway.
3 Likes
I also think that the GPL has the right ideal, but the implementation of runs into some difficulties. Ignoring various controversies of GPLv3, even GPLv2 is hard to interpret in practice (see the discussions about linking and libraries). It is understandable that some companies are cautious and would rather avoid GPL-licensed software, even if some interpretations would allow them to use it without problems.
1 Like
Keep in mind that the license you put on Github is only a public facing license. Privately you can also distribute your software with other licenses to specific individuals, if someone asks you for it.
For example, there is the case where someone gave permission for IBM to “use the software for evil”
http://dev.hasenj.org/post/3272592502/ibm-and-its-minions
However, for the Julia package ecosystem, MIT is generally preferred.
2 Likes
Just wanted to point out that many questions around the legal (and cultural) implications of license choice are addressed rather well at https://choosealicense.com . (Disclaimer: that page was created by GitHub, but they’ve accepted community contributions and do a decent job of staying factual and not trying to advocate for one position or another.)
EDIT: Also, the one license not yet mentioned here that attempts to strike a balance between Copy-Left freedoms and MIT-style permissibility is the Mozilla Public License v2.0
4 Likes
Here’s what I wrote on a Hacker News post about Light Table’s licence some years 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.
Since most Julia libraries are very much infrastructure and not products, the technical pain of maintaining a fork of an active project seems more than sufficient to prevent proprietary forks. Unless you think that someone would be able to sell a modified version of an open source library by itself, there’s no real need to use GPL and a permissive license like MIT, ISC or BSD should (imo) be preferred.
20 Likes