They legally have to ask every contributor. The exception/loophole used by big companies (but also FSF for example) is that every contributor had to sign a CLA where they legally reassign ownership of their code to the project owner.
> If you believe in software freedoms, then there will never be any reason to need to relicense, nor would you want to.
The Tivo-ization process of the 90s shows that while this might be frequently true, it isn’t without exception. From a practical standpoint, continuing to provide for user freedom would have been best accomplished (personal opinion) if many projects had been able to move to a more AGPL style license.
Yeah, the entire security posture of Android would be massively different if Linux could have been relicensed away from GPL 2.0 to a license that says "you have to give users a way to compile your code and install it". Now the community can fix old phones without security updates.
> For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.
My amateur understanding is that the major kernel copyright holders are essentially comfortable with Tivoization and aren't looking to rock the boat with a lawsuit.
What if there was an extreme license that simply said you have to share it upon request from anyone, even private versions? Ignoring whether that's annoying or whether it's enforceable, would that be non-free?
I've seen an argument that the particular way the AGPL is worded makes it non-free, which seems pretty plausible, but I don't think that's an argument against "a more AGPL style license".
Most of the world is developing closed-source software.
When you publish an open-source project, people are going to assume you want your project to be open source. This often provides an enormous boost to the project, as people are way more willing to contribute to a collaborative community project than just donating time to some for-profit company.
I am totally fine with companies making proprietary for-profit software, but don't leech off the open-source community by pretending to be something you are not. I am at a point where I assume any company-backed project with a CLA is going to do a bait-and-switch as soon as that becomes the more profitable option. Remember kids: corporations are not your friend.
Isn't this very topic, the relicensing of ZeroMQ, a proof that there is a need and desire to relicense by an organization that believes in software freedom?
People constantly make this comparison, but it's stupid, the Linux kernel's DCO is just a CLA by a slightly different name and slightly different signatory procedure; giving it a slightly different acronym doesn't make it something else. The very fact it's mandatory makes the exact opposite case, that the world's most popular free software project sees it as important. Putting a Signed-off-by is literally a legal statement that you have the right to yield the given changes to the project, and that you affirm the right for them to be redistributed. This is exactly what most CLAs do; most don't assign or transfer ownership or copyright in any way because it isn't necessary.
Ironically, despite all the (unequivocally 100% wrong) yammering about this topic on places like this forum, many of the bigger "evil" companies like Meta and Google don't require transfer of copyright to contribute to their FOSS projects, while places like the FSF do require it so they can relicense under potential future FSF licenses e.g. a practically stronger version of the GPL 3's "or later versions" clause. And there are even more agreements like the FSFe's FSA that can stipulate exactly a fixed set of licenses that might be used in the future, as a sort of middleground.
The one time I was asked about signing a CLA, it wanted to me guarantee patent indemnification as well forever. Not only is this inadvisable, there was no way the legal counsel of my employer would permit that.
Seen this quite a few times as well, but we’ve managed to strike the indemnification clause from various third party CLAs by putting our legal teams in touch.
This is why there should be an easier way to auto-sign CLAs or better yet, programmatically declare that all my contributions are CC0/public-domain so nobody has to contact me to find out that my code doesn't come with strings attached
As the author of the changes, I thought you can license them however you wish. What you're contributing is basically a diff, I don't think that counts as a derivative work as you wrote all the content. If you distributed your change with the original repo that sounds more like a derivative work to me.
what you're describing would make end-running the GPL absurdly easy. Vendors would just distribute vanilla Linux source code and in another file distribute their not-a-derivative patches under their own proprietary license.
Patches are obviously a derivative work. No one spontaneously describes deleting several lines of code & then replacing it with other lines of code.
My understanding is that that would be legal. The problem for those companies is they can't build and distribute a Linux kernel that contains those patches, because then that is a derivative work. So in practice they have to release their changes under the GPL as it's not feasible to ask users to compile their own kernel with their custom patches.
Yes, most also require confirming that you're allowed to make contributions. That's because most tech companies make you sign "everything you do on a clock is ours" documents, CLA here meant to protect from your employee claiming your contribution is actually weren't yours to make.
CLA’s don’t fully transfer ownership (hence the L) and don’t unilaterally allow changing the software license. Though that does of course depend on the nature of each CLA since there’s no singular contract associated.
A CTA (transfer vs license) does allow unilateral license changes after the fact.
Ironically, a CLA backed by a nonprofit like the FSF is probably one of the few ways to do it properly. At least they are guaranteed to act in the interest of the community.
The other "loophole" is not to relicense, but instead for a corporation to make their own future contributions with a different license. This doesn't work too well from GPL-like licenses, but is fine for file-based copyleft.
People contacted were people who made major modifications, not every single contributor. And yeah, if the contributor don't agree to the new license, you can either don't do the license change, or remove the code they wrote as they don't agree to the new license.
Sometimes companies who do "FOSS" make you sign some sort of agreement that they own the code you produce and you won't have any say about re-licensing, so maybe the projects you're thinking about have done that?
IANAL, but if the license isn’t materially compatible (which perhaps is the case for LGPL and MPL, I don’t know MPL enough to say), I would imagine this is the only legal way to do it. When I contribute to a project, I release my code on the agreed upon license. You can’t change that without my permission.
Yes very common. I’ve helped some projects relicense in the past (because the original developer didn’t actually understand the license they chose) and it’s arduous having to contact each individual (and sometimes companies) to relicense.
You can do license changes without that however as long as:
1. You license per file in the repository. This can be quite arduous but many projects will move the old licensed stuff into a sub project to make that easier to grok.
2. Your new license is compatible with the old license.
Yeah. This is how Squeak changed the license from SqueakL to Apache and MIT. That code has a lot of history, so it was a pretty big effort, but worth it in the end.
I feel like I've heard of many larger companies doing relicenses on their open source without this kind of effort.