8 ms·

Completing Racket's relicensing effort

169 points by samth 7y ago

giancarlostoro 7y ago
>Did anyone say no? >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.
- ISL 7y ago
  > it baffles me why anyone would say no Because they preferred the original license?
  - sigzero 7y ago
    That is probably correct and within their rights to say no.
  - _ph_ 7y ago
    While it is absolutely right to insist on the original license, I find it also a bit surprising they rather have their contribution removed than allowing a more liberal license.
    - Tomte 7y ago
      To you it's more liberal, to others more exploitative. People get really upset about license changes, as Linus so nicely observed.
      - _ph_ 7y ago
        As I said, I fully agree that people have the right to deny the request.
    - progval 7y ago
      > I find it also a bit surprising they rather have their contribution removed than Maybe they considered that if enough people said no, then the relicensing would be cancelled.
- bootloop 7y ago
  Usually this comes down to individuals which refuse out of principle because the don't agree with the actions taken OR are not allowed to do it because of current or past contracts (with employers or similar).
- ocdtrekkie 7y ago
  Particularly if the contributions are trivial (which seems likely, since they removed/replaced the functionality in question already), trying to hold this over a project seems petty to me, and expresses the exact irritation I have with GPL. 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.
  - erikpukinskis 7y ago
    They didn’t pull anything back, the code is still publically available to anyone who wants to use it and share their contributions back to the community. 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.
    - amenod 7y ago
      Besides, the people contributed when it was GPL/LGPL. If it was MIT they might not have bothered.
      - erik_seaberg 7y ago
        This. You can choose any license if you pay me, but anything I write for free is GPL.
- INGELRII 7y ago
  MIT style licenses provide 'snapshot freedom'. The code is a collection of text files at one point of time. 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.
  - deleted 7y ago
    [deleted]
  - mumblemumble 7y ago
    > 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.
    - appleflaxen 7y ago
      you are building a straw-man version of an unworkable payment system. 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.
- jorams 7y ago
  > and the more important bits are still LGPL. Could you explain what you mean by this? It looks like the entirety of Racket is being relicensed.
  - em-bee 7y ago
    the old version of the code with the old license still exists. you may continue to use that. 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.
  - deleted 7y ago
    [deleted]
- belorn 7y ago
  I wonder what would happen if we went to companies who use MIT licensed code in proprietary software and asked if they believe in true freedom. How many would relicense their products to MIT. If they believe in freedom then they should not say no. 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.
  - archi42 7y ago
    Well, I enjoy about 80% of the work I do and would be quite content just doing that (even the 20% I don't like, since that's still necessary). And I believe in a multitude of freedoms. 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.
CalChris 7y ago
TL;DR 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.
- mumblemumble 7y ago
  > The first, dynamic linking exception, could maybe be patched up with some effort by FSF resulting in a new LGPL license. 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.
- pritambaral 7y ago
  > The first, dynamic linking exception, could maybe be patched up with some effort by FSF resulting in a new LGPL license. 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]. 1: https://www.cliki.net/LLGPL https://www.cliki.net/LLGPL
- phoe-krk 7y ago
  > 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. 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.
- 7y ago
dumbmatter 7y ago
Two people declined to re-license their contributions to Racket. We therefore removed their contributions and, where appropriate, replaced them with new code and/or documentation. 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/260347/ship-of-theseus-applied-to-gpl-can-i-relicense-my-program-if-i-replace-all-of https://softwareengineering.stackexchange.com/questions/2603...
- protomyth 7y ago
  remove code? certainly legal 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.
- _ph_ 7y ago
  If the new code is a clean reimplementation of the function of the old code, that is, not based in its source or principle of working on the old code (e.g. copy large parts of the logic from the original code), it should be quite fine. Porting an existing code to a new language isn't a clean reimplementation.
  - fourthark 7y ago
    Which is why, although it's a cool metaphor, it wasn't relevant to the linked SE question. A translation is not original work.
- xiaq 7y ago
  IANAL, but I think of the relicensing effort as conceptually equivalent to starting from scratch and asking everyone to re-contribute their code towards the new codebase, because these contributors never relinquished their copyright in the first place. For people who said no, you just leave out their contributions.
- chubot 7y ago
wtetzner 7y ago
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. I wonder if this simplifies the Racket-on-Chez effort in any way as well.
- samth 7y ago
  Racket CS works similarly to traditional Racket in this respect -- compiled libraries still contain the results of macro-expansion and inlining from their dependencies, and generated executables still bundle everything together in a way that's not easy to re-link. 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.
nwellnhof 7y ago
Why do projects dual-license under MIT and APLv2? All the additional clauses of the APLv2 like patent protection are useless if you also license under MIT.
- sigzero 7y ago
  > EITHER the Apache 2.0 License OR the MIT License Not simulatneously.
- JoshTriplett 7y ago
  Consumers of the project can use either MIT or Apache-2.0, which means the project is compatible with GPLv2 code. 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 https://opensource.org/licenses/BSDplusPatent license, which is just 2-clause BSD plus the Apache-2.0 patent grant.
  - Conan_Kudo 7y ago
    It's a pretty bad licensing arrangement, actually. I'm honestly surprised the Racket community didn't consider just adding a license exception to the LGPL. 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.
anaphor 7y ago
It's not clear from the title I think, but this actually was a multi-year undertaking, "This has been a long process, beginning in 2017". 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.

169 points by samth 7y ago

>Did anyone say no? >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.

ISL 7y ago
> it baffles me why anyone would say no Because they preferred the original license?
- sigzero 7y ago
  That is probably correct and within their rights to say no.
- _ph_ 7y ago
  While it is absolutely right to insist on the original license, I find it also a bit surprising they rather have their contribution removed than allowing a more liberal license.
  - Tomte 7y ago
    To you it's more liberal, to others more exploitative. People get really upset about license changes, as Linus so nicely observed.
    - _ph_ 7y ago
      As I said, I fully agree that people have the right to deny the request.
  - progval 7y ago
    > I find it also a bit surprising they rather have their contribution removed than Maybe they considered that if enough people said no, then the relicensing would be cancelled.
bootloop 7y ago
Usually this comes down to individuals which refuse out of principle because the don't agree with the actions taken OR are not allowed to do it because of current or past contracts (with employers or similar).
ocdtrekkie 7y ago
Particularly if the contributions are trivial (which seems likely, since they removed/replaced the functionality in question already), trying to hold this over a project seems petty to me, and expresses the exact irritation I have with GPL. 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.
- erikpukinskis 7y ago
  They didn’t pull anything back, the code is still publically available to anyone who wants to use it and share their contributions back to the community. 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.
  - amenod 7y ago
    Besides, the people contributed when it was GPL/LGPL. If it was MIT they might not have bothered.
    - erik_seaberg 7y ago
      This. You can choose any license if you pay me, but anything I write for free is GPL.
INGELRII 7y ago
MIT style licenses provide 'snapshot freedom'. The code is a collection of text files at one point of time. 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.
- deleted 7y ago
  [deleted]
- mumblemumble 7y ago
  > 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.
  - appleflaxen 7y ago
    you are building a straw-man version of an unworkable payment system. 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.
jorams 7y ago
> and the more important bits are still LGPL. Could you explain what you mean by this? It looks like the entirety of Racket is being relicensed.
- em-bee 7y ago
  the old version of the code with the old license still exists. you may continue to use that. 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.
- deleted 7y ago
  [deleted]
belorn 7y ago
I wonder what would happen if we went to companies who use MIT licensed code in proprietary software and asked if they believe in true freedom. How many would relicense their products to MIT. If they believe in freedom then they should not say no. 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.
- archi42 7y ago
  Well, I enjoy about 80% of the work I do and would be quite content just doing that (even the 20% I don't like, since that's still necessary). And I believe in a multitude of freedoms. 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.

CalChris 7y ago

TL;DR 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.

mumblemumble 7y ago
> The first, dynamic linking exception, could maybe be patched up with some effort by FSF resulting in a new LGPL license. 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.
pritambaral 7y ago
> The first, dynamic linking exception, could maybe be patched up with some effort by FSF resulting in a new LGPL license. 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]. 1: https://www.cliki.net/LLGPL https://www.cliki.net/LLGPL
phoe-krk 7y ago
> 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. 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.
7y ago

dumbmatter 7y ago

Two people declined to re-license their contributions to Racket. We therefore removed their contributions and, where appropriate, replaced them with new code and/or documentation. 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/260347/ship-of-theseus-applied-to-gpl-can-i-relicense-my-program-if-i-replace-all-of https://softwareengineering.stackexchange.com/questions/2603...

protomyth 7y ago
remove code? certainly legal 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.
_ph_ 7y ago
If the new code is a clean reimplementation of the function of the old code, that is, not based in its source or principle of working on the old code (e.g. copy large parts of the logic from the original code), it should be quite fine. Porting an existing code to a new language isn't a clean reimplementation.
- fourthark 7y ago
  Which is why, although it's a cool metaphor, it wasn't relevant to the linked SE question. A translation is not original work.
xiaq 7y ago
IANAL, but I think of the relicensing effort as conceptually equivalent to starting from scratch and asking everyone to re-contribute their code towards the new codebase, because these contributors never relinquished their copyright in the first place. For people who said no, you just leave out their contributions.
chubot 7y ago

wtetzner 7y ago

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. I wonder if this simplifies the Racket-on-Chez effort in any way as well.

samth 7y ago
Racket CS works similarly to traditional Racket in this respect -- compiled libraries still contain the results of macro-expansion and inlining from their dependencies, and generated executables still bundle everything together in a way that's not easy to re-link. 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.

nwellnhof 7y ago

Why do projects dual-license under MIT and APLv2? All the additional clauses of the APLv2 like patent protection are useless if you also license under MIT.

sigzero 7y ago
> EITHER the Apache 2.0 License OR the MIT License Not simulatneously.
JoshTriplett 7y ago
Consumers of the project can use either MIT or Apache-2.0, which means the project is compatible with GPLv2 code. 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 https://opensource.org/licenses/BSDplusPatent license, which is just 2-clause BSD plus the Apache-2.0 patent grant.
- Conan_Kudo 7y ago
  It's a pretty bad licensing arrangement, actually. I'm honestly surprised the Racket community didn't consider just adding a license exception to the LGPL. 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.

anaphor 7y ago

It's not clear from the title I think, but this actually was a multi-year undertaking, "This has been a long process, beginning in 2017". 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.