I guess not really “claiming” it, more like trying to understand how or if the fairly simple reading fails, yes I’m aware of the history. It’s clear that GPL or other copyleft is the way to go if you want to be sure to prevent proprietary forks.
All of which is somehow slightly off topic I guess (though very topic adjacent and I appreciate the discussion). Julia’s creators do not plan a proprietary fork, and good luck to anyone wanting to proprietary fork Julia without them.
The more important point about the lack of a CLA is that nobody can just yoink Julia’s source code away or change it to a license that would be incompatible with its current uses. For example, some open source models rely on free (A)GPL licensed code with paid non-GPL’ed licensing — that’s something that’s simply not possible here.
Nope. All you need to do is add some enhancements under a different license (e.g. AGPL).
For example, I can take Julia, make “Julia+” with my special GPL-licensed sauce, and then charge people for a non-GPL license to my work. (They don’t need a non-GPL license to the original Julia code — they already have that under MIT, so no relicensing or CLA is needed.)
Seriously, there have been decades of people making proprietary forks of BSD/MIT-licensed code written by other people. Speculation to the contrary makes no sense to me, and it would be a bad thing if Julia programmers mistakenly thought that the MIT license somehow protects them from this.
I think you’re missing his point, which (as I read it) is that if you receive a copy of Julia, and/or its source code today from the current repo no one can take it away from you tomorrow. (sorry that was supposed to be in reply to @stevengj
I never claimed that they could.
But @StefanKarpinski (and others) made a much stronger claim: that no one could make an enhanced “Julia+” version and sell it under a more restrictive license. This is simply false, and it is pernicious to spread this misconception.
That’s not what I said, though. Nobody can change the license of Julia’s current source code without getting the permission of all 1000 contributors. Yes, someone could add a new portion that’s not MIT, but the current MIT part remains MIT.
So what? The effect is the same:
The MIT license, and the lack of a CLA, provides zero legal protection against either of these possibilities.
Again, I’m not claiming that anyone can take the current Julia version away from you. The question is what happens with future versions, and I’m responding to false claims that future versions are somehow legally required to be MIT-licensed.
No, the effect is not the same. There’s a robust community here and even if there’s some company that comes out with a spectacular Julia+ that’s not MIT, they can’t suddenly change the terms of the existing codebase.
I’m not disagreeing with you, but for some reason you seem to be disagreeing with me. I was simply trying to add a bit of context about what the lack of a CLA actually does.
Yes, this is important. For example either a company or a person who wants to build some large code base to do something important would not like it if some day they suddenly couldn’t use Julia anymore. That is NOT the case. It’s possible they could not use the future alternative Julia+ but not possible to take today’s Julia away.
Sure, non-copyleft software still has some “social resistance” to proprietary forks, in that the community can always go back and fork the last MIT-licensed version. This is often effective!
e.g. it worked (eventually) for X11, though there were many years of widespread proprietary X forks on various Unices. And it is providing some relief toforthe fact that Anaconda Python is no longer free/open-source (they are now only free for non-commercial use), since many (but not all!) are switching to conda-forge. But it is not a panacea, e.g. Nvidia has a proprietary LLVM fork for their platform that there is no complete replacement for. If someone with enough resources (or the original developer!) makes a compelling enough fork, it can sometimes pose stiff competition for the original software.
(I think that would be hard to successfully fork in the case of Julia, but it can much more easily happen for smaller software packages.)
I’m not claiming that a successful proprietary fork of Julia is likely, even if Stefan joins the Sith! But claims that it is not possible are misinformation. It would be especially unfortunate if someone released code under an MIT license and thought erroneously, based on claims above, that this legally prohibited proprietary forks (or even just GPL forks!).
By the way, the lack of a CLA is completely irrelevant to this — the MIT license has no revocation/termination clause. So even if there is a sole copyright holder, they can’t take away rights to the original code from people who already received it.
(In contrast, the GPL does have a termination clause, but it’s contingent on you violating the GPL terms.)
Here’s a review written by lawyers of GPL termination and license revocation in general, which concludes
Whether as a matter of a straightforward contractual obligation, or as a matter of promissory estoppel, a contributor’s attempt to revoke a copyright license grant and then enforce their copyright against a user is highly unlikely to succeed.
Again, I want to emphasize I was only arguing against false claims that future versions of Julia must legally be MIT-licensed; I never said someone could take away the existing Julia versions.
Can someone explain the difference between a “proprietary fork of Julia” and a proprietary product that offers Julia with extra packages and IDE like JuliaPro?
My understanding is that it was not a fork — there was no attempt to add additional license restrictions to Julia itself, or to the installed packages, in JuliaPro — e.g. if you had JuliaPro, you could still extract all of the .jl files and they were still MIT-licensed (allowing you to modify/use/redistribute). But IIRC JuliaPro also included some add-ons like MKL that were under more restrictive licenses (e.g. MKL prohibits reverse engineering or disassembly).
But I’m not intimately familiar with the contents of JuliaPro, so if there’s something I’m missing I assume someone else will chime in.
JuliaPro was free, so not proprietary. It was a modified version of Julia that included an IDE and allowed connecting with JuliaTeam (a precursor to JuliaHub). I’ll add that maintaining even the minor modifications that allowed JuliaPro to connect to JuliaTeam for package installation was a major hassle.
I’m not sure which meaning of “free” you intend here – zero cost or unrestricted usage rights.
From JuliaComputing blog:
Finally, we now have a Pumas edition of JuliaPro, available from https://pumas.ai/products/pumas/download. This version of JuliaPro comes bundled with Pumas as well as other frequently used curated packages. Moreover, Pumas is compiled into the Julia system image, ensuring that load times for this package are significantly reduced.
What was the license on the Pumas edition of JuliaPro?
It was built without GPL libraries, which allowed shipping with MKL (with permission from Intel), which isn’t legal with the standard Julia distribution which includes a few GPL dependencies (these days I think only SuiteSparse?).
Both. It was available free of charge and includes the slightly modified source of Julia along with the same MIT license file that allows you to do what you want with it.
The JuliaPro part is the same: MIT-licensed. The Pumas part is proprietary. Even the GPL doesn’t apply to bundled software shipped together (and nothing in JuliaPro is GPL).
I see. Thanks for clarifying.
Did you edit this (because i remember to read a version number here)?
With an active license mathworks offers download from today R2021b to R11.1 (before 2006 mathworks didn’t have year numbers in versions). And i have seen more breaking changes (i.e. i needed to change code that was working in a previous version) in julia than in matlab - but let’s say i expect this from a language that’s still evolving (and the ecosystem).
