Completing Racket's relicensing effort
blog.racket-lang.org
blog.racket-lang.org
I made some small contributions to Racket's SSH library personally, and I was happy to consent to relicensing. I think most people who contribute docs/code to projects like this did it because it was something they needed implemented, so it would be counter-productive to ask for it to be removed, IMO.
Is that actually allowed by the GPL? I thought it was more like the "Ship of Theseus" - that even if you eventually replace all the original GPL code, the entire work remains GPLed. https://softwareengineering.stackexchange.com/questions/2603...
replace the code? I'm not sure how it would not be legal to write substitute code under a new license. If there is no remaining GPL code in a project, the project doesn't have to abide by the GPL. The "Ship of Theseus" example makes no sense in the context of copyrights.
The two declining authors don't have copyright on the new replacement code, because they didn't write it. So their choice of license can't possibly have any bearing on the license of the rest of the project.
A similar thing happened when the busybox maintainer forked the project to toybox.
busybox is a GPLv2 project (not LPGL), and so all his contributions were licensed as such. But he forked his own code to a Apache 2 License. He is able to do that because he owns the copyright. But of course he can't relicense code to which he doesn't own the copyright.
toybox isn't a derivative work of busybox in that sense. It's just a bunch of code that someone wrote (and automatically gets copyright for), and chose to license in a certain way.
Basically you get the copyright first, then you decide to license it. If it's clearer to think about, the authors could have started a new project called "Zacket" that's not a derivative work of Racket, as long as they own all the copyrights. But the name doesn't matter here, and they can keep using "Racket".
That's my understanding anyway.
But they influenced the shape of the code.
Imagine if Google loses their upcoming case with Oracle. Any rock thrown into the river will forever taint a codebase unless you can rewind before it was committed or the code is 100% leafy and isolable.
The GPL for Version 1 (example) would be presented if you checked it out and if you check out Version 2 it's now an Apache 2 license. The license in each case applies to the files in the VCS, a the GPL contains no special case for access to previous or future versions of the same file under it's license under the GPL license, neither does the Apache license and I doubt such a clause would hold water.
but you can take the 98%, and also relicense it under anything the copyright holders (=authors) agree to, and include an extra 2% so that it is a new work.
Start on a clean system. Put all of the correctly licensed source code there. Do not include any GPL/LGPL code
Now run make.
Nothing GPL or LGPL licensed touched your build or source code.
If you updated your Racket to the new version it would be under the new license.
>Two people declined to re-license their contributions to Racket.
Although it is entirely within their right, it baffles me why anyone would say no. At the end of the day, it's still open source, and the more important bits are still LGPL. I'm personally within that camp that prefers MIT licensed code. I don't think forced freedom is truly freedom (thinking of the GPL here).
Edit: I much rather have the right to allow others to copy over being forced to allow everyone to copy even if I rework an entire project.
Because they preferred the original license?
People get really upset about license changes, as Linus so nicely observed.
Maybe they considered that if enough people said no, then the relicensing would be cancelled.
These contributors "contributed", but then, maintained the ability to pull back those contributions when it suited them to do so, or were used as leverage to try and prevent a change supported by the majority.
I like permissive licenses because when I contributed open source code, it's meant to be a gift, not a gift with strings attached.
As a side note, I am also inclined to use more permissive licenses, to allow the widest possible use.
But your attitude of “anyone who uses the GPL is a jerk” is way too far.
The idea behind the GPL is to create an all-or-nothing pool of code. Inside the pool everything is free, but you must also share the work you do in the pool.
Outside of the pool you can use the pool, but you can’t distribute it to others without also sharing any changes you made.
It’s fine if you don’t like those terms. There are lots of reasons to not like them.
But to act like people who willingly contributed work to that pool are assholes because they want to protect the contract... I think you’re being unfair.
GPL license is additionally a share agreement. If the code is also an valuable asset that requires constant development, update and contributions to stay alive, GPL can help with that.
I would personally would prefer GPL-license under organization that can sell different licenses. If a company don't want to use GPL, they can buy commercial license and developers get money.
At first blush that idea makes sense, but the problem there is that we've already tried that, and it failed miserably.
I think that one fundamental problem that would need addressing is how to make it not a PITA to administer, and a hassle for everyone involved: Maintainers of small projects aren't necessarily looking to embark on a proper business enterprise, contributors don't necessarily want to have to digest the implications of the license, nobody wants to figure out how royalties for contributors would work - and with people potentially getting paid directly for the software, that's going to be a much thornier issue to negotiate than it is with the "closed source derivative works" thing that you get with permissive licenses - and licensees don't necessarily want to deal with an explosion of payments to manage.
I also suspect there's a sort of prisoner's dilemma from the business perspective. If we all share some permissively licensed open source projects, we can all come out ahead and achieve a very efficient pooling of development resources. If someone wants to go dual GPL/commercial, though, it may well be cheaper for me to implement my own version of the, say, 5% of some library that I actually need, than it is for me to pay a commercial license fee for the whole thing.
it would be totally doable for the project to say
1) we are GPL licensed
2) if you can't use GPL we will sell you a license for $X
3) all proceeds go to the project.
4) if you contribute, you give us the right to do this, and retain the funds that are generated.
Dual licensing really could be a silver bullet, but because nobody has done it well (for some reason people want to use MIT + commercial), nobody understands how powerful it could be.
kevsim put Qt as a counterexample and I objected that they're different beasts because Qt was developed mostly by Trolltech. Later it became more of an open project, but the dual licensing arrangement is older than that.
This is the spot where I see it becoming a sticking point. What is "the project"? For it to be an independent entity, you need to incorporate, which, at the very least, costs money, and is therefore a huge barrier to taking this route for a small project. And it's almost by definition a small project if it's in a position to be making this decision. And if it's not an independent entity, then "the project" is probably just a euphemism for one person's pocketbook. Maybe with some pinky swearing layered on top. In any case, you've also got an image problem, because a lot of people are going to be skittish about a GPL/commercial model after what happened with MySQL and some of the other open source projects that fell into Oracle's hands.
You could instead set up a legal entity that pools the resources of several projects, and let it be the commercial vendor. That might even, in a parallel universe, have been a plausible funding model for the FSF. But even there it's probably tricky, because you still need to have some way of deciding what to do with the surplus. Having once served on the board of a nonprofit, I can say that that's tricky at the best of times, and it's probably only worse if you're talking some sort of open source foundation, because open source community members tend to get along like cats in a sack.
Long story short: While I never said that something like this was unworkable, I do think that, given how badly it tended to work out when people were trying to figure out how to make it work a couple decades ago, it would seem to be much harder to get right than it initially seems.
A nice (maybe impossible or impractical) idea would be to sell commercial licenses with eventual future payments.
As in the commercial license states an estimated price and a clause saying that at any time (with some months of notice) the price will be set to somewhere up to the estimated price. If the project chooses an higher price then the licensee is free to not pay. This would also allow prospective licensee to estimate future expenses and the project to estimate eventual revenue.
Could you explain what you mean by this? It looks like the entirety of Racket is being relicensed.
the pieces of code that are unchanged in the new version therefore still can be accessed under the old license.
the safest way to do that though is by taking that code from the old version.
If just everyone would choose freedom and only use MIT then I too would be in the MIT camp. Sadly there are people who do not believe in freedom and would sue those that simply want to share with each other. As the song goes, not even 7 years old girls can be safe against the wrath of those who think culture and knowledge is an object to be owned. Against those people, and only against those people, I say we should not give the freedom for which they wish to deprive others. My work is reserved to those who believe in true freedom.
However, the people who built my house, produce my food and electricity don't feel that way, so I'm happy my employer doesn't license under MIT.
I wonder if this simplifies the Racket-on-Chez effort in any way as well.
It's more the other direction that's a benefit -- traditional Racket makes fundamental use of several pieces of LGPL software, such as GNU Lightning and libgmp, but Racket CS does not use them and Chez Scheme is Apache-licensed.
Why relicense?
... First, it is unclear how to apply the LGPL’s statement about dynamic linking to a language like Racket, where macro expansion can copy code from libraries to applications, and where applications are typically bundled with the Racket runtime and libraries. Second, some organizations unfortunately are unwilling to use software licensed under any variant of the GPL.
The first, dynamic linking exception, could maybe be patched up with some effort by FSF resulting in a new LGPL license. The second is more of a developers voting with their feet thing.
It could, but the LGPL is already a compromise on the FSF's stated goals, and I can't imagine they'd want to erode the LGPL's ability to encourage people to open source products that rely on open source software even further.
The Common Lisp world already has something like this, the "LLGPL"[1], but it's use is discouraged[1] because (among other reasons):
> 2. In 2004, the Free Software foundation affirmed that "the LGPL works as intended with all known programming languages" and that "LGPL contains no special provisions for inheritance, because none are needed." There is no need for the linking and inheritance provisions that are in the [LLGPL].
Linking exception, same as with GCC. Parts of GCC and GNU standard library make themselves into the produced binaries, but the license explicitly allows the resulting binaries to be licensed under any license the author wants.
Not simulatneously.
Contributors contribute their code granting permission to use under both licenses, which means they're granting the patent grant in Apache-2.0.
So, dual-licensing MIT/Apache-2.0 gives you a permissive license with a patent grant and GPLv2-compatibility.
That said, if you want a permissive license with a patent grant and GPLv2-compatibility, a simpler choice is the "BSD+Patent" https://opensource.org/licenses/BSDplusPatent license, which is just 2-clause BSD plus the Apache-2.0 patent grant.
Alternatively, ASL 2.0 with exceptions could have worked to make it compatible with the full assortment of GNU licenses. That's the strategy that CUPS and LLVM chose.
This weird MIT/ASL 2.0 thing (which clearly was stolen from Rust) is a completely asinine idea, because it forces a situation where it's impossible to verify a patent license grant to users and contributors.