3 ms·

The GPL family of licenses certainly provides the strongest guarantees to the contributor. But let's consider a "weak" license like MIT. Here's the text to refr

The GPL family of licenses certainly provides the strongest guarantees to the contributor. But let's consider a "weak" license like MIT. Here's the text to refresh your memory: https://opensource.org/licenses/MIT https://opensource.org/licenses/MIT If you change the license, all of the original work must still be distributed under MIT and only the work done after the cutover can use a new license. The GPL differs in that the new work must also be licensed as GPL.

Klathmon 8y ago
If i'm reading you right, the implication is that if you sign a CLA for an MIT license codebase, they could retroactively close-source your code contributions? My understanding of MIT and other permissive licenses like it is that if I license that code under the MIT license, I can never "undo" that (for the code as it existed in that moment), even if I own all the copyright to a work myself. So a CLA cannot override the MIT license in that way either. The "without limitation" part of the MIT license guards against this doesn't it?
- Sir_Cmpwn 8y ago
  By assigning copyright to them, you give them the right to distribute your work under a different license. Yes, you can't take back the original license from the older code. But they could start distributing the code without respect to the original license. >The "without limitation" part of the MIT license guards against this doesn't it? Ah, but it reads "without limitation [...] subject to the following conditions"
  - Klathmon 8y ago
    Yes, but those conditions start and end at requiring attribution. MIT already allows sublicensing, so a CLA for an MIT project (assuming nothing else shady is going on) really only buys them the ability to change future licenses to something incompatible with MIT (would that be called superlicensing?), and possibly remove your attribution in future versions. That to me is philosophically what I want out of a permissive license, so I personally am fine with CLAs in those cases, however I can understand why some would be against that.
    - Sir_Cmpwn 8y ago
      >Yes, but those conditions start and end at requiring attribution. Read carefully: >copyright notice and this permission notice >MIT already allows sublicensing IANAL, but sublicensing can only impose additional clauses, it cannot roll back any grants or restrictions of the original license.
      - Klathmon 8y ago
        Sorry, that is what I meant by attribution (which is defined as the copyright and license in MIT). >IANAL, but sublicensing can only impose additional clauses, it cannot roll back any grants or restrictions of the original license. Yeah, so a CLA allows that to move to a "superlicense" kind of thing (still not sure if that word makes sense there), so they could rollback those grants or restrictions of the MIT license in the future, but they cannot do so for the past. Which, I'm okay with in a lot of cases, as that is what I philosophically want from a permissive license. However I can see how many would not be.
tomp 8y ago
The majority contributor(s) (i.e. those that are making you sign the CLA) can relicence their contributions, and keep your tiny contributions MIT licenced. Hopefully they can't relicence retroactivelly, so the previous version of the software stays available, but any following versions can be entirely closed source (but they keep your MIT licence notice).
lmm 8y ago
> If you change the license, all of the original work must still be distributed under MIT and only the work done after the cutover can use a new license. That's pretty meaningless given that there is no obligation to distribute the source code to the new version, or to provide any way that "substantial portions" that are used in the new version can be extracted and used separately from the new-license work. Meanwhile if you contribute to a currently-MIT-licensed project under a CLA, you have a copy of the current version under the MIT license and can continue to redistribute that indefinitely. So what practical difference does it make?

Klathmon 8y ago

If i'm reading you right, the implication is that if you sign a CLA for an MIT license codebase, they could retroactively close-source your code contributions? My understanding of MIT and other permissive licenses like it is that if I license that code under the MIT license, I can never "undo" that (for the code as it existed in that moment), even if I own all the copyright to a work myself. So a CLA cannot override the MIT license in that way either. The "without limitation" part of the MIT license guards against this doesn't it?

Sir_Cmpwn 8y ago
By assigning copyright to them, you give them the right to distribute your work under a different license. Yes, you can't take back the original license from the older code. But they could start distributing the code without respect to the original license. >The "without limitation" part of the MIT license guards against this doesn't it? Ah, but it reads "without limitation [...] subject to the following conditions"
- Klathmon 8y ago
  Yes, but those conditions start and end at requiring attribution. MIT already allows sublicensing, so a CLA for an MIT project (assuming nothing else shady is going on) really only buys them the ability to change future licenses to something incompatible with MIT (would that be called superlicensing?), and possibly remove your attribution in future versions. That to me is philosophically what I want out of a permissive license, so I personally am fine with CLAs in those cases, however I can understand why some would be against that.
  - Sir_Cmpwn 8y ago
    >Yes, but those conditions start and end at requiring attribution. Read carefully: >copyright notice and this permission notice >MIT already allows sublicensing IANAL, but sublicensing can only impose additional clauses, it cannot roll back any grants or restrictions of the original license.
    - Klathmon 8y ago
      Sorry, that is what I meant by attribution (which is defined as the copyright and license in MIT). >IANAL, but sublicensing can only impose additional clauses, it cannot roll back any grants or restrictions of the original license. Yeah, so a CLA allows that to move to a "superlicense" kind of thing (still not sure if that word makes sense there), so they could rollback those grants or restrictions of the MIT license in the future, but they cannot do so for the past. Which, I'm okay with in a lot of cases, as that is what I philosophically want from a permissive license. However I can see how many would not be.

tomp 8y ago

The majority contributor(s) (i.e. those that are making you sign the CLA) can relicence their contributions, and keep your tiny contributions MIT licenced. Hopefully they can't relicence retroactivelly, so the previous version of the software stays available, but any following versions can be entirely closed source (but they keep your MIT licence notice).

lmm 8y ago

> If you change the license, all of the original work must still be distributed under MIT and only the work done after the cutover can use a new license. That's pretty meaningless given that there is no obligation to distribute the source code to the new version, or to provide any way that "substantial portions" that are used in the new version can be extracted and used separately from the new-license work. Meanwhile if you contribute to a currently-MIT-licensed project under a CLA, you have a copy of the current version under the MIT license and can continue to redistribute that indefinitely. So what practical difference does it make?