Every time a company rug pulls a license, block the principals, on GitHub and elsewhere. If you build your product on the back of the commons, and then delete your product from those commons, you delete yourself from collaborating on the next generation of the commons. Trust matters.
companies happy to use v2 pro gratis (scorpion7)
Apache fork (frog4)
code share license (scorpion 6)
cloud hosting (scorpion 5)
we are here <- (frog3)
well-timed series B funding (scorpion4)
companies happy to use v1 pro gratis (scorpion3)
startup (scorpion2)
venture capital fund (scorpion)
well-meaning software developers (frog2)
401k (frog)
@jonoabroad@tpolecat@eed3si9n That's one of the essential differences between the "permissive" licenses (e.g., BSD, MIT, Apache) that most of us comfortably use at work, and the "copyleft" licenses (e.g., LGPL) that make your employers' legal team's sphincters clench.
Nobody can retroactively revoke the license, which is why forks come from HEAD~1. And also why some prominent forks are choosing LGPL, so it doesn't happen again.
@ross you can't change the license on code licensed under BSD or MIT, because there's nothing that allows you to. You can incorporate that code in proprietary projects, but that BSD/MIT portion of the project stays BSD/MIT. E.g, you can't take an APL2 project and make it GPL3, only the changes can be GPL3.
Also, all the license changes we're seeing are due to copyright assignments being required from contributors, and copyleft licenses wouldn't have helped.
as extra detail, as the copyright holder it's possible to change the license from X to Y in any way one wants. But that's the only situation where one can do that. That's why people shouldn't be signing away their copyright for their submitted changes, since the projects in that way accumulate more than a single copyright holder which makes it harder to change licenses, since they would need agreement from everyone that has copyright to do it.
Add comment