4 ms·

> You might be thinking, “Wait a minute, isn’t WarpStream just another corporation? Why should I spend my time contributing to their project if they can just ta

by teeray 2y ago

> You might be thinking, “Wait a minute, isn’t WarpStream just another corporation? Why should I spend my time contributing to their project if they can just take my contributions at any time and commercialize them?”. Bento is 100% MIT licensed and will stay that way forever. It would be interesting if there was a “no takebacks” enhancement to popular open-source licenses. Maybe the license could only change with a supermajority quorum of contributors.

xyzzy_plugh 2y ago
You do this by explicitly not having a CLA and by attributing the underlying copyright to the collective authors. Then even a supermajority is effectively unable to relicense.
- csande17 2y ago
  This only really works if the contributions were made under a copyleft license like GPL. With MIT, it's perfectly allowed to rugpull like this so long as you bury the original copyright line/disclaimer/etc somewhere in your app's equivalent of chrome://credits.
  - Gormo 2y ago
    No, with MIT, you are only releasing your subsequent modifications/derivative works under a new license. You can't retroactively change the license to anything that is already MIT.
- jen20 2y ago
  This doesn’t help if almost all of the contributions come from a single corporation, and now come with a different license attached. As forks prove, license changes typically affect future contributions, not previous ones.
  - csande17 2y ago
    I'm really hoping this string of "open source project goes proprietary" news stories are helping people see the value of licenses like the GPL, which do prevent you from releasing future contributions under a different license unless you own the copyright to 100% of the original code.
    - jen20 2y ago
      Indeed: if remaining open is valued, people should be looking for licenses that prevent it, not ownership by a foundation or similar. That realistically means the GPL. Unfortunately that cuts to the root cause of the problem, which is not valuing freedom as in speech, but instead only freedom as in beer (or, in the case of a lot of software, free as in mattress).
josephcsible 2y ago
The Linux kernel is already like that. The two requirements for it are (1) that the license is copyleft rather than permissive, and (2) that the project accepts significant external contributions without requiring a CLA that gives the upstream authors extra rights.
Gormo 2y ago
"No takebacks" is already inherent to the nature of all FOSS licenses. No one, not even a "supermajority quorum", can retroactively change the license to code they don't own the copyright to, and each contributor retains ownership of the copyright to whatever code they've written, individuall. The only exception to this is when corporate-backed projects sometimes insist that contributors assign copyright before accepting their contributions -- not sure if that's what's going on here, though. What does happen with MIT or BSD projects is that since these licenses are not "viral" (in the sense that they do not require modifications or derivative works to be released under the same license), and because contributors do own the copyright to their own code, anyone can take an MIT/BSD project, and modify it or build their own work on top of it, then release their own version under a different license applicable to their work. But that doesn't retroactively change the license for anything that was already BSD/MIT, it just produces a new work that mixes BSD/MIT-licensed code that was already out there with new code that is under a different license. So no one can ever "take back" anything that already existed: they can only control their own subsequent work built on top of it.

by teeray 2y ago

xyzzy_plugh 2y ago

You do this by explicitly not having a CLA and by attributing the underlying copyright to the collective authors. Then even a supermajority is effectively unable to relicense.

csande17 2y ago
This only really works if the contributions were made under a copyleft license like GPL. With MIT, it's perfectly allowed to rugpull like this so long as you bury the original copyright line/disclaimer/etc somewhere in your app's equivalent of chrome://credits.
- Gormo 2y ago
  No, with MIT, you are only releasing your subsequent modifications/derivative works under a new license. You can't retroactively change the license to anything that is already MIT.
jen20 2y ago
This doesn’t help if almost all of the contributions come from a single corporation, and now come with a different license attached. As forks prove, license changes typically affect future contributions, not previous ones.
- csande17 2y ago
  I'm really hoping this string of "open source project goes proprietary" news stories are helping people see the value of licenses like the GPL, which do prevent you from releasing future contributions under a different license unless you own the copyright to 100% of the original code.
  - jen20 2y ago
    Indeed: if remaining open is valued, people should be looking for licenses that prevent it, not ownership by a foundation or similar. That realistically means the GPL. Unfortunately that cuts to the root cause of the problem, which is not valuing freedom as in speech, but instead only freedom as in beer (or, in the case of a lot of software, free as in mattress).

josephcsible 2y ago

The Linux kernel is already like that. The two requirements for it are (1) that the license is copyleft rather than permissive, and (2) that the project accepts significant external contributions without requiring a CLA that gives the upstream authors extra rights.

Gormo 2y ago

"No takebacks" is already inherent to the nature of all FOSS licenses. No one, not even a "supermajority quorum", can retroactively change the license to code they don't own the copyright to, and each contributor retains ownership of the copyright to whatever code they've written, individuall. The only exception to this is when corporate-backed projects sometimes insist that contributors assign copyright before accepting their contributions -- not sure if that's what's going on here, though. What does happen with MIT or BSD projects is that since these licenses are not "viral" (in the sense that they do not require modifications or derivative works to be released under the same license), and because contributors do own the copyright to their own code, anyone can take an MIT/BSD project, and modify it or build their own work on top of it, then release their own version under a different license applicable to their work. But that doesn't retroactively change the license for anything that was already BSD/MIT, it just produces a new work that mixes BSD/MIT-licensed code that was already out there with new code that is under a different license. So no one can ever "take back" anything that already existed: they can only control their own subsequent work built on top of it.