I appreciate the effort collating announcements, but the comparison to “rug pulls” is wrong and entitled.
Existing releases aren’t suddenly being turned from open to restricted. If there was any forward-looking promise from the project stewards, it wasn’t free lunch forever, but that users would be able to cook for themselves. I’ve yet to read about a project that changes its going-forward license policy and doesn’t tell outside contributors, so as to keep drawing contributions.
IMO, when you accept outside contributions, a forward-looking promise is strongly implied. If you change the license so that people who’ve contributed to make the whole of the product better no longer have the same rights to the better whole that they had to the old versions, that feels very much like a rug pull to me.
You might argue that I could avoid that by refusing to consent to a CLA. I’d agree, and argue that these rug pulls are evidence that CLAs are not just things that “keep the lawyers happy” (as another commenter said) but are things that should actively inform contributors as to risks that might reduce the future value of their contributions.
If you change the license so that people who’ve contributed to make the whole of the product better no longer have the same rights to the better whole that they had to the old versions, that feels very much like a rug pull to me.
Contributors have the same rights to improve or even fork releases made under the prior license. The delta between the last release under the old license and the first release under the new license is a bunch of new work by the steward’s contributors. There wasn’t any promise that any further work would be licensed consistently, or even that there would be future work.
You might argue that I could avoid that by refusing to consent to a CLA.
I wouldn’t, because use of a CLA isn’t necessary or sufficient for the kinds of policy changes we’re discussing. Any steward of a project under a permissive license without any particular terms for taking contributions by others can start releasing new work under different terms at any time, just as anyone else can fork under their own terms of choice.
No common license terms for source code shared and developed that I’m aware of—permissive, copyleft, or restricted—include any promise by anyone to do additional work in the future or license it a particular way. Certain uses of copyleft terms without special terms for licensing contributions from others can limit choice of license terms in practice, but still don’t obligate anyone to keep contributing. Companies offering work under these licenses aren’t any more obligated to perpetual user servitude than solo hackers putting out projects on their own.
Contributors have the same rights to improve or even fork releases made under the prior license. The delta between the last release under the old license and the first release under the new license is a bunch of new work by the steward’s contributors. There wasn’t any promise that any further work would be licensed consistently, or even that there would be future work.
Of course this is accurate, at least as far as the text of the license goes. But I would argue that it’s far from the whole story, socially, which is a big part of the math for me when I decide whether and how much sweat-equity I’m willing to contribute to a project. And that’s what I was getting at. When I write code for a project, my behavior is more than a simple transaction. I’m choosing to participate as a member of a community, and there are certain social norms that accompany that. I’m astute enough to read and understand the texts of licenses, so I often understand that there wasn’t a promise in a legal sense. But there can be a social understanding that goes beyond the text of the license, and that can create expectations just as much as a license text can, even if those are (much!) less likely to be enforced by a court. They still convey how a party intends to behave even if they don’t make that intent legally binding. And a party who conveys a misimpression based on these norms will eventually find itself wanting for collaborators if that becomes commonly recognized.
On those lines, when I choose to contribute to a project, I do generally understand that the project will continue to release future versions under terms that are very similar to the versions I gave code to. Project maintainers can, of course, violate that, if the license of the code I’m patching permits them to, but contributors and potential contributors will often notice this and react accordingly.
My point isn’t legal. Two sides talking past each other, or making assumptions that don’t turn out to be shared, happens all the time. They’re communication problems, basic people business problems, long before and more often than they become legal problems.
You can’t choose to unilaterally impose “community” on projects you don’t steward, or a particular definition of what community means, just by showing up with patches. You can’t impose your version of what goes without saying, by calling it “social norms” or “defaults” or anything else.
Nor can projects impose their “crowdsource” fantasies of infinite, competent, totally unpaid contribution on you. They decide what they offer, in the form of the projects they lead and their policies. You can take them or leave them, as you pointed out.
I’ve seen developers, especially idealistic Free Software people, decline to take up projects because of licensing policies. I’ve also seen developers consciously and energetically contribute to projects they know a for-profit company is actively dual licensing. I’ve seen developers assign IP in patches to proprietary software delivered in source form strictly under NDA, just to scratch a nagging itch in a tool their employer pays for.
I agree that many especially younger and more idealistic developers might feel a pang of loss when projects they contribute to announce going-forward license changes they don’t like. Better if the party went on their way forever, on someone else’s dime, as Linux, its distros, and a relatively tiny cohort of famous and important peer projects do. But outside those rarefied few, companies moving the work they fund to more restrictive terms has happened for a long time. Any disappointment based on informed expectations has to square with all that history.
I’d strongly encourage developers looking to contribute to projects to research the licensing policies and business models behind them before jumping in, especially if they’re not going to be paid. I’d strongly support GitHub issues or other public calls to project stewards to clarify where they haven’t, just as I’d encourage stewards to ask frank questions about motivation and funding of “outside” contributors appearing with unsolicited patches.
It’s never worth hashing out everything that might go wrong, but it’s also way too easy to self-deceive about alignment in silence, on either side. On major points, airing it out up front can be a whole lot better than retroactive recriminations about who knew or meant what where nothing was said. Many fewer lawyers would be needed in this world if more followed this free advice.
You can’t choose to unilaterally impose “community” on projects you don’t steward, or a particular definition of what community means, just by showing up with patches. You can’t impose your version of what goes without saying, by calling it “social norms” or “defaults” or anything else.
Absolutely not. But I need to make some assessment of what the community is like and what social norms are in place before investing time and labor in a non-trivial patch. For trivial patch-sets, I can’t be bothered. I will totally drive by and send those. But for adding something major, where I need to invest real time learning the codebase and figuring out how to make my contribution fit well, it’s not just technical and not just legal. There’s a fit issue that extends past both dimensions. I don’t believe a copyright license can be expressive enough to convey it.
For right or for wrong, when I contribute to an MIT-licensed project, I am expecting the future version that includes my contribution and is better because of my contribution to be licensed under similar terms. Same when I contribute to a GPL-licensed project. And I recognize that this is not an expectation that’s enforced by license or by contract, generally, but the expectation is formed based on my assessment of the project owner’s practices.
I’ve seen developers, especially idealistic Free Software people, decline to take up projects because of licensing policies. I’ve also seen developers consciously and energetically contribute to projects they know a for-profit company is actively dual licensing. I’ve seen developers assign IP in patches to proprietary software delivered in source form strictly under NDA, just to scratch a nagging itch in a tool their employer pays for.
I am not an especially idealistic Free Software person, but I have personally done all of these things.
I agree that many especially younger and more idealistic developers might feel a pang of loss when projects they contribute to announce going-forward license changes they don’t like. Better if the party went on their way forever, on someone else’s dime, as Linux, its distros, and a relatively tiny cohort of famous and important peer projects do. But outside those rarefied few, companies moving the work they fund to more restrictive terms has happened for a long time. Any disappointment based on informed expectations has to square with all that history.
I’m neither younger nor more idealistic, and I’m also not clairvoyant. We need to make educated guesses about where to apply efforts, particularly when the return on those efforts comes in the form of something social like free software. Sometimes those expectations get violated, and that’s because I didn’t inform myself properly up front. But it’s not “entitled” to have made my best guess at those, be wrong, and express disappointment at being wrong.
Edit to add:
I’d strongly support GitHub issues or other public calls to project stewards to clarify where they haven’t
Of course. But a lot of these changes get made quite a bit above the pay grade of people who respond to GitHub issues, mailing list posts, etc., and opening an issue or posting to a mailing list to inquire about business model and plans for future license changes can be both perceived as off-topic in a technical forum and as an inquiry about business concerns that the employers of the people answering those issues/posts are unwilling to discuss in public.
You might argue that I could avoid that by refusing to consent to a CLA. I’d agree, and argue that these rug pulls are evidence that CLAs are not just things that “keep the lawyers happy” (as another commenter said) but are things that should actively inform contributors as to risks that might reduce the future value of their contributions.
I avoid making contributions to projects with CLAs for this reason. I want future contributors to have to “pay it backwards” as I have “paid it forward.”
Creator here. This is great criticism; I don’t think I’ve landed on the best terminology yet. I’ve tried to avoid the term “rug-pull” elsewhere on the site for these reasons, but kept it on the home page because the term is frequently used elsewhere. I’ll keep working on terminology.
I think you’re right about releases having licenses, not projects. But a project is more than just a release, especially from the contributor side. A project is also a point of collaboration and community. When a license change occurs, it can really disrupt the community of contributors. Writing code for an open-source project feels different from contributing to a non-open-source one.
Drew DeVault wrote a great piece about CLAs a couple years back and is now running redict as a fork of Redis.
The most descriptive, neutral name for this I’ve seen is “licensing policy change”. But that’s not widely used.
The neutral term I see used most is “relicensing”, the one you picked up on. The problem with that term is ambiguity. I see a lot of posts on social media falling into that trap, confusing going-forward license changes as retroactive changes to past releases. I’ve also seen some people who know better encouraging confusion because they want to punish companies.
I’ve occasionally heard “license fork”, which makes sense to me conceptually. I tend to avoid it only because I see it leaning into the various rhetorical battles along the lines of “We’re not the fork. You are!” I think those battles are natural and healthy, so long as they’re fought on who has contributed more and will have the better project going forward. I don’t think it should be the case that any side—the steward, prior outside contributors, any new group pulled together to keep contributing under the old license—gets presumed to be the best. It should be about the software.
Drew’s is a well known voice on CLAs, but I’d encourage you to read others, as well. You might not know, from his blog alone, that there are and have been CLAs that limit what licenses and kinds of licenses stewards can release contributed work under—putting into explicit legal terms the deal some activists wish were implied.
Personally, I’d add that very, very often, the relationship between “outside” contributor and project steward isn’t equal, and justly should not be. Commercial project stewards tend to drive development. Many have had the experience of a highly opinionated guy with a patch showing up and demanding a fundamental licensing policy change for a PR, claiming it will unlock a deluge of “community” contributions that simply never materialize for the vast majority of even GPL-licensed, locked-open projects.
Maybe I should try to coin a new term. Rug-pull sounds too entitled and the others are lackluster.
CLAs that limit what licenses and kinds of licenses stewards can release contributed work under
I don’t think I’ve come across one of those, but that would be very good to include. Do you remember off-hand which projects had those? I’m intentionally measuring CLAs that require copyright and/or patent grants, because those make it easier for a company to relicense external contributions. A CLA without those seems less risky. There’s some really complicated stuff like Qt that have pretty novel approaches.
If I may suggest one more lens: Do project contributors have the same rights as the project originator?
It’s much easier to swallow a license change from someone who is a peer with the same rights as you, but it’s more painful if it comes from someone with a position of power over others.
I would argue that permissive licenses without a CLA create an environment where everyone is the most equal. Anyone can fork off with the same rights, even if they decide to use a different license moving forward. On the other hand, copyleft with CLA creates a strong imbalance where the source project owner has special rights to relicense that contributors do not share in.
I would argue that permissive licenses without a CLA create an environment where everyone is the most equal. Anyone can fork off with the same rights, even if they decide to use a different license moving forward. On the other hand, copyleft with CLA creates a strong imbalance where the source project owner has special rights to relicense that contributors do not share in.
This matches my analysis. As a general matter, I only contribute to a “copyleft with CLA” project if there’s significant benefit to me getting to use the project with my patch included AND strong desire not to maintain a fork plus a distribution mechanism for that fork.
My bar for CLAs is high in general, though, and it’d be unusual for me to consider accepting one without being financially staked in to the project or otherwise associated with the business behind it.
They just seem to be rating whether the org behind the project is individual, not-for-profit, or for-profit, and evaluating whether the org requires a CLA, DCO, or no agreement at all before accepting contributions.
Those with for-profit orgs and CLAs are deemed high risk for relicensing. Those with not-for-profit orgs and DCO are mid. Those with individuals and no agreement are low.
Maybe it’s more subtle than that, but I’ve not been able to spot more nuance so far.
(Creator here) The mild rating reflects the use of the Apache 2 license, which isn’t a copyleft license. It’s pretty easy to take Apache 2 licensed software and build a non-open-source fork. The Apache Foundation would be fully compliant with the Apache 2 license if they released future versions of HTTPd under a non-open-source license.
The reason HTTPd feels like it’s at lower risk is due to the reputation of the Apache Foundation. Reputation is hard to measure objectively, so I haven’t been factoring it in to the ratings. I’ve considered reducing all risk ratings for non-profits, but there’s examples of non-profits that have relicensed software, so that alone isn’t a clear signal.
It also feels like it’s at lower risk because it’s been offered under the same license by the same not-for-profit since the 1990s.
I won’t dispute that longevity is hard to measure/rate for the kind of ratings you’re doing, but it certainly figures into my mental “risk math” when I’m deciding whether or not to contribute.
I strongly agree. It seems about as likely to be relicensed as ghostscript.
I didn’t mean to suggest that I thought these ratings were correct; I was just saying what seems to be behind them as far as I can tell. The httpd one, specifically, made me think the ratings were not good as soon as I saw it.
I don’t think requiring copyright and patent grant should be the only thing immediately elevating a project as “high relicensing risk”, it’s mostly just there to keep the lawyers happy. As far as I know, MS has never relicensed anything open to something more restrictive (if they have, it’s obscure enough for me to have never heard of). You mostly see companies doing that because they sell one single software package and either want to be profitable or just to sell the whole company, which MS isn’t going to do. It feels like a pretty naive way to gauge risk that hasn’t taken actual real-world examples and reasoning for relicensing into account. In fact, I’d go as far as to argue a cloud company has the least possible incentive to relicense, especially because it would mean alienating their developer base, which would directly affect their cloud clientele. As an example, I think Amazon directly forked Redis to keep it open source, didn’t they?
(Creator here) Part of the challenge of building a project like this is convincing others that the ratings are objective and don’t represent personal bias. I’ve picked a couple measurable factors like “CLA requires copyright grant” which can be verified by linking to the relevant CLA. Drew DeVault’s post has a great explanation of the problem. To me (in my subjective opinion) a company demanding developers grant them the ability to relicense your contributed code is a pretty big red flag that they may exercise that right.
I think the factors you mention (history of relicensing, dependence on a single product, alienation of developers) are more subjective and can change over time. A good counter-example may be CICERO. It was changed to a non-open-source license but its a project by a non-profit, it’s not the sole product of the organization.
One of the main reasons I created the project was to promote developer discussion about open source licensing, so I’m happy that we’re engaging in discussion here.
Indeed. The big risk for things like VS Code are the non-open bits of the open core model. All of the dev container infrastructure (which is one of the big advantages of VS Code) come from the remote extension and are not part of the open source release. There’s a much bigger risk that other important features will be developed as proprietary extensions than there is of MS relicensing the core.
With Linux distros now shipping (proprietary) NVIDIA drivers and (CDDL) OpenZFS, the same risk applies to Linux.
After validation from the fellow comments, I now feel confident in asserting that this website is nothing more than an expression of the owner’s bias against corporations (and the deluded fear of companies abusing permissive licenses, which doesn’t happen anywhere near as often as FOSS advocates rave about). Now, having a bias against companies isn’t the most taboo form of bias one can have, but it’s still false information. This website is probably as reliable as your crazy uncle telling you they’re putting nanobots in the water.
I appreciate the effort collating announcements, but the comparison to “rug pulls” is wrong and entitled.
Existing releases aren’t suddenly being turned from open to restricted. If there was any forward-looking promise from the project stewards, it wasn’t free lunch forever, but that users would be able to cook for themselves. I’ve yet to read about a project that changes its going-forward license policy and doesn’t tell outside contributors, so as to keep drawing contributions.
Projects don’t have licenses. Releases do.
IMO, when you accept outside contributions, a forward-looking promise is strongly implied. If you change the license so that people who’ve contributed to make the whole of the product better no longer have the same rights to the better whole that they had to the old versions, that feels very much like a rug pull to me.
You might argue that I could avoid that by refusing to consent to a CLA. I’d agree, and argue that these rug pulls are evidence that CLAs are not just things that “keep the lawyers happy” (as another commenter said) but are things that should actively inform contributors as to risks that might reduce the future value of their contributions.
Contributors have the same rights to improve or even fork releases made under the prior license. The delta between the last release under the old license and the first release under the new license is a bunch of new work by the steward’s contributors. There wasn’t any promise that any further work would be licensed consistently, or even that there would be future work.
I wouldn’t, because use of a CLA isn’t necessary or sufficient for the kinds of policy changes we’re discussing. Any steward of a project under a permissive license without any particular terms for taking contributions by others can start releasing new work under different terms at any time, just as anyone else can fork under their own terms of choice.
No common license terms for source code shared and developed that I’m aware of—permissive, copyleft, or restricted—include any promise by anyone to do additional work in the future or license it a particular way. Certain uses of copyleft terms without special terms for licensing contributions from others can limit choice of license terms in practice, but still don’t obligate anyone to keep contributing. Companies offering work under these licenses aren’t any more obligated to perpetual user servitude than solo hackers putting out projects on their own.
Of course this is accurate, at least as far as the text of the license goes. But I would argue that it’s far from the whole story, socially, which is a big part of the math for me when I decide whether and how much sweat-equity I’m willing to contribute to a project. And that’s what I was getting at. When I write code for a project, my behavior is more than a simple transaction. I’m choosing to participate as a member of a community, and there are certain social norms that accompany that. I’m astute enough to read and understand the texts of licenses, so I often understand that there wasn’t a promise in a legal sense. But there can be a social understanding that goes beyond the text of the license, and that can create expectations just as much as a license text can, even if those are (much!) less likely to be enforced by a court. They still convey how a party intends to behave even if they don’t make that intent legally binding. And a party who conveys a misimpression based on these norms will eventually find itself wanting for collaborators if that becomes commonly recognized.
On those lines, when I choose to contribute to a project, I do generally understand that the project will continue to release future versions under terms that are very similar to the versions I gave code to. Project maintainers can, of course, violate that, if the license of the code I’m patching permits them to, but contributors and potential contributors will often notice this and react accordingly.
My point isn’t legal. Two sides talking past each other, or making assumptions that don’t turn out to be shared, happens all the time. They’re communication problems, basic people business problems, long before and more often than they become legal problems.
You can’t choose to unilaterally impose “community” on projects you don’t steward, or a particular definition of what community means, just by showing up with patches. You can’t impose your version of what goes without saying, by calling it “social norms” or “defaults” or anything else.
Nor can projects impose their “crowdsource” fantasies of infinite, competent, totally unpaid contribution on you. They decide what they offer, in the form of the projects they lead and their policies. You can take them or leave them, as you pointed out.
I’ve seen developers, especially idealistic Free Software people, decline to take up projects because of licensing policies. I’ve also seen developers consciously and energetically contribute to projects they know a for-profit company is actively dual licensing. I’ve seen developers assign IP in patches to proprietary software delivered in source form strictly under NDA, just to scratch a nagging itch in a tool their employer pays for.
I agree that many especially younger and more idealistic developers might feel a pang of loss when projects they contribute to announce going-forward license changes they don’t like. Better if the party went on their way forever, on someone else’s dime, as Linux, its distros, and a relatively tiny cohort of famous and important peer projects do. But outside those rarefied few, companies moving the work they fund to more restrictive terms has happened for a long time. Any disappointment based on informed expectations has to square with all that history.
I’d strongly encourage developers looking to contribute to projects to research the licensing policies and business models behind them before jumping in, especially if they’re not going to be paid. I’d strongly support GitHub issues or other public calls to project stewards to clarify where they haven’t, just as I’d encourage stewards to ask frank questions about motivation and funding of “outside” contributors appearing with unsolicited patches.
It’s never worth hashing out everything that might go wrong, but it’s also way too easy to self-deceive about alignment in silence, on either side. On major points, airing it out up front can be a whole lot better than retroactive recriminations about who knew or meant what where nothing was said. Many fewer lawyers would be needed in this world if more followed this free advice.
Absolutely not. But I need to make some assessment of what the community is like and what social norms are in place before investing time and labor in a non-trivial patch. For trivial patch-sets, I can’t be bothered. I will totally drive by and send those. But for adding something major, where I need to invest real time learning the codebase and figuring out how to make my contribution fit well, it’s not just technical and not just legal. There’s a fit issue that extends past both dimensions. I don’t believe a copyright license can be expressive enough to convey it.
For right or for wrong, when I contribute to an MIT-licensed project, I am expecting the future version that includes my contribution and is better because of my contribution to be licensed under similar terms. Same when I contribute to a GPL-licensed project. And I recognize that this is not an expectation that’s enforced by license or by contract, generally, but the expectation is formed based on my assessment of the project owner’s practices.
I am not an especially idealistic Free Software person, but I have personally done all of these things.
I’m neither younger nor more idealistic, and I’m also not clairvoyant. We need to make educated guesses about where to apply efforts, particularly when the return on those efforts comes in the form of something social like free software. Sometimes those expectations get violated, and that’s because I didn’t inform myself properly up front. But it’s not “entitled” to have made my best guess at those, be wrong, and express disappointment at being wrong.
Edit to add:
Of course. But a lot of these changes get made quite a bit above the pay grade of people who respond to GitHub issues, mailing list posts, etc., and opening an issue or posting to a mailing list to inquire about business model and plans for future license changes can be both perceived as off-topic in a technical forum and as an inquiry about business concerns that the employers of the people answering those issues/posts are unwilling to discuss in public.
I avoid making contributions to projects with CLAs for this reason. I want future contributors to have to “pay it backwards” as I have “paid it forward.”
Creator here. This is great criticism; I don’t think I’ve landed on the best terminology yet. I’ve tried to avoid the term “rug-pull” elsewhere on the site for these reasons, but kept it on the home page because the term is frequently used elsewhere. I’ll keep working on terminology.
I think you’re right about releases having licenses, not projects. But a project is more than just a release, especially from the contributor side. A project is also a point of collaboration and community. When a license change occurs, it can really disrupt the community of contributors. Writing code for an open-source project feels different from contributing to a non-open-source one.
Drew DeVault wrote a great piece about CLAs a couple years back and is now running redict as a fork of Redis.
The most descriptive, neutral name for this I’ve seen is “licensing policy change”. But that’s not widely used.
The neutral term I see used most is “relicensing”, the one you picked up on. The problem with that term is ambiguity. I see a lot of posts on social media falling into that trap, confusing going-forward license changes as retroactive changes to past releases. I’ve also seen some people who know better encouraging confusion because they want to punish companies.
I’ve occasionally heard “license fork”, which makes sense to me conceptually. I tend to avoid it only because I see it leaning into the various rhetorical battles along the lines of “We’re not the fork. You are!” I think those battles are natural and healthy, so long as they’re fought on who has contributed more and will have the better project going forward. I don’t think it should be the case that any side—the steward, prior outside contributors, any new group pulled together to keep contributing under the old license—gets presumed to be the best. It should be about the software.
Drew’s is a well known voice on CLAs, but I’d encourage you to read others, as well. You might not know, from his blog alone, that there are and have been CLAs that limit what licenses and kinds of licenses stewards can release contributed work under—putting into explicit legal terms the deal some activists wish were implied.
Personally, I’d add that very, very often, the relationship between “outside” contributor and project steward isn’t equal, and justly should not be. Commercial project stewards tend to drive development. Many have had the experience of a highly opinionated guy with a patch showing up and demanding a fundamental licensing policy change for a PR, claiming it will unlock a deluge of “community” contributions that simply never materialize for the vast majority of even GPL-licensed, locked-open projects.
Maybe I should try to coin a new term. Rug-pull sounds too entitled and the others are lackluster.
I don’t think I’ve come across one of those, but that would be very good to include. Do you remember off-hand which projects had those? I’m intentionally measuring CLAs that require copyright and/or patent grants, because those make it easier for a company to relicense external contributions. A CLA without those seems less risky. There’s some really complicated stuff like Qt that have pretty novel approaches.
If I may suggest one more lens: Do project contributors have the same rights as the project originator?
It’s much easier to swallow a license change from someone who is a peer with the same rights as you, but it’s more painful if it comes from someone with a position of power over others.
I would argue that permissive licenses without a CLA create an environment where everyone is the most equal. Anyone can fork off with the same rights, even if they decide to use a different license moving forward. On the other hand, copyleft with CLA creates a strong imbalance where the source project owner has special rights to relicense that contributors do not share in.
This matches my analysis. As a general matter, I only contribute to a “copyleft with CLA” project if there’s significant benefit to me getting to use the project with my patch included AND strong desire not to maintain a fork plus a distribution mechanism for that fork.
My bar for CLAs is high in general, though, and it’d be unusual for me to consider accepting one without being financially staked in to the project or otherwise associated with the business behind it.
Is there any substance to these assessments?
They just seem to be rating whether the org behind the project is individual, not-for-profit, or for-profit, and evaluating whether the org requires a CLA, DCO, or no agreement at all before accepting contributions.
Those with for-profit orgs and CLAs are deemed high risk for relicensing. Those with not-for-profit orgs and DCO are mid. Those with individuals and no agreement are low.
Maybe it’s more subtle than that, but I’ve not been able to spot more nuance so far.
Claiming that Apache HTTPd is mildly likely to be relicensed sounds just plain weird to me.
(Creator here) The mild rating reflects the use of the Apache 2 license, which isn’t a copyleft license. It’s pretty easy to take Apache 2 licensed software and build a non-open-source fork. The Apache Foundation would be fully compliant with the Apache 2 license if they released future versions of HTTPd under a non-open-source license.
The reason HTTPd feels like it’s at lower risk is due to the reputation of the Apache Foundation. Reputation is hard to measure objectively, so I haven’t been factoring it in to the ratings. I’ve considered reducing all risk ratings for non-profits, but there’s examples of non-profits that have relicensed software, so that alone isn’t a clear signal.
It also feels like it’s at lower risk because it’s been offered under the same license by the same not-for-profit since the 1990s.
I won’t dispute that longevity is hard to measure/rate for the kind of ratings you’re doing, but it certainly figures into my mental “risk math” when I’m deciding whether or not to contribute.
It’s more likely that HTTPd is dead within 10 years than being relicensed (apart from a potential Apache-3.0).
I strongly agree. It seems about as likely to be relicensed as ghostscript.
I didn’t mean to suggest that I thought these ratings were correct; I was just saying what seems to be behind them as far as I can tell. The httpd one, specifically, made me think the ratings were not good as soon as I saw it.
yeah that one stuck out as obviously wrong
It seems to be a consideration of :
A project with a CLA can be arbitrarily relicensed anytime.
A project with a permissive license can be switch to a non-open-source license (non retroactively).
I don’t think requiring copyright and patent grant should be the only thing immediately elevating a project as “high relicensing risk”, it’s mostly just there to keep the lawyers happy. As far as I know, MS has never relicensed anything open to something more restrictive (if they have, it’s obscure enough for me to have never heard of). You mostly see companies doing that because they sell one single software package and either want to be profitable or just to sell the whole company, which MS isn’t going to do. It feels like a pretty naive way to gauge risk that hasn’t taken actual real-world examples and reasoning for relicensing into account. In fact, I’d go as far as to argue a cloud company has the least possible incentive to relicense, especially because it would mean alienating their developer base, which would directly affect their cloud clientele. As an example, I think Amazon directly forked Redis to keep it open source, didn’t they?
(Creator here) Part of the challenge of building a project like this is convincing others that the ratings are objective and don’t represent personal bias. I’ve picked a couple measurable factors like “CLA requires copyright grant” which can be verified by linking to the relevant CLA. Drew DeVault’s post has a great explanation of the problem. To me (in my subjective opinion) a company demanding developers grant them the ability to relicense your contributed code is a pretty big red flag that they may exercise that right.
I think the factors you mention (history of relicensing, dependence on a single product, alienation of developers) are more subjective and can change over time. A good counter-example may be CICERO. It was changed to a non-open-source license but its a project by a non-profit, it’s not the sole product of the organization.
One of the main reasons I created the project was to promote developer discussion about open source licensing, so I’m happy that we’re engaging in discussion here.
Indeed. The big risk for things like VS Code are the non-open bits of the open core model. All of the dev container infrastructure (which is one of the big advantages of VS Code) come from the remote extension and are not part of the open source release. There’s a much bigger risk that other important features will be developed as proprietary extensions than there is of MS relicensing the core.
With Linux distros now shipping (proprietary) NVIDIA drivers and (CDDL) OpenZFS, the same risk applies to Linux.
Apparently all projects using the MIT license belong on this list? It’s gonna be a big list…
The “high risk” category requires a “license agreement”.
But yes, all permissives licenses (MIT, BSD, Apache) are “mild risk”.
After validation from the fellow comments, I now feel confident in asserting that this website is nothing more than an expression of the owner’s bias against corporations (and the deluded fear of companies abusing permissive licenses, which doesn’t happen anywhere near as often as FOSS advocates rave about). Now, having a bias against companies isn’t the most taboo form of bias one can have, but it’s still false information. This website is probably as reliable as your crazy uncle telling you they’re putting nanobots in the water.
(Creator) I think there’s room to add many more projects, especially popular projects, but at some point there’s diminishing returns.
TIL Wordpress is available under the GPLv2