> This policy will probably make some downstream users nervous, but maybe it encourages them to contribute a little more.
This is an understated but brilliant framing. Oh I know they won't contribute, users will continue to apply pressure through issue threads saying that their clueless security teams are breathing down their necks. But at least you'd hope this gives pause.
The linked issue is worth a read, it's a shame the burden that corporate leeches like apple and google have placed on him. To them this project is simply free labour they have assumed they are entitled to and by extension are subject to their individual security theatrics.
I'd note that the only thing Apple, Google and MS are said to have done is to use the software.
The bug has no actual example of them making demands, "leeching" or acting entitled.
The security issues would be security issues just the same even if the library was only used by Linux desktops. (And if the library is unfit for use in other operating systems like the author suggests, feels like it probably is equally unfit for use in Gnome.)
polotics
It's high-time for a "reasonable compensation" clause in hobbyists' open-source software licenses I think.
Something to the effect of: "if you're using my labour of love to make millions, gimme one of these millions..."
ThrowawayR2
Yes, it's called "becoming proprietary software" because what are you going to do to get that oh so reasonable compensation? Create your own billing department and manage tax payments on your revenue? Hire a legal team to create and enforce your license? Sic the BSA (apparently they still exist after all these years!) to threaten to audit organizations who aren't paying? Fend off lawsuits from users, competitors, and patent trolls? (Once you start collecting money, other people inevitably want a piece of it.)
watwut
You can make such license, there is no issue with that. You just cant call it "MIT License" after that.
pabs3
That probably wouldn't meet the Open Source Definition.
I’d also like to see a license which prohibits any for-profit use. A don’t charge others for something you got for free license.
pabs3
There are lots of those, CC-NC to start with.
illiac786
The compensation should be in code not in money…
altairprime
Uncompensated use for unshared reward is, by definition, leeching. The BBS use of the term referred to leeching in the context your upload/download ratio, the torrent use in the context of your seeded/downloaded ratio.
ratio = (contributions - demands) : earnings
If you contribute nothing, demand nothing, and earn nothing, carry on. “Nothing” is loosely defined as “near enough to zero in the context of a specific project”.
If you contribute nothing, demand nothing, and earn (DL) a million dollars using it somehow, you’re a leecher. Your U/D ratio is 0.0. That should be an uncomfortable realization. One way to cope with that is to raise your ratio to 0.1. If you make a million dollars of revenue using libcurl, how much are you allocating to donate back?
If you contribute nothing and demand security fixes, then you’re not a leecher — you’re a parasite, because your demands exceed your contributions; your sign bit is still negative even if your ratio is 0.0 or NaN. It has been zero days since this workplace had a maintainer injury due to parasitic behavior.
Leechers are demoralizing when the revenue earned would let the author quit their day job to do more fun work instead. Parasites leave a trail of damaged and dead projects in their wake. libxml2’s maintainer made a policy change that cuts off the food supply for parasites; good. They’ll still burnout someday due to the untreated morale damage being done by the billionaire leechers, though.
If an author accepts contributions and you feel like a leecher, do something about it. If they do not accept contributions (including money) or if the anccepted contributions are incompatible (their code is in COBOL and you only know Rust, they only offer “donate bitcoin”, you’re a broke student funding school with your project) then maybe write them a thank you letter? and revisit this if your or their circumstances change someday.
As a former open source maintainer, I don’t mind it when people leech. That’s chill. Go for it. I don’t have a tip jar because I don’t expect a tip. But I mind when people DL a million dollars of revenue using my work and have a UL:DL ratio of 0.0 with me.
Corporations, formally do not care whether users are hobbyists, leechers, or parasites. Maintainers do. The OSI continues to reject as Open Source any licenses attempting to stop the morale impact of millionaire leechers and the time and effort drained by parasites.
Which is more important to the future of open source: the right to be a leecher or a parasite, or the maintainers that they feed upon?
jsnell
> If you contribute nothing and demand security fixes, then you’re not a leecher — you’re a parasite, because your demands exceed your contributions;
There's the "demand" word again. Who is that demanded something from the maintainer, and where? I saw no indication in the original bug of any demands from big tech companies.
(Just the act reporting a security issue is not a demand. A verifiable bug is a bug whether it was reported or not, and reporting one is a contribution.)
When the demand part of your torrent-inspired equation is zero, how is it leeching? It's just zero, no matter what the earnings are.
That doesn't look like Google, Apple or Microsoft though? It's some random guy.
altairprime
On the spectrum of grey areas from “request” to “demand”, we not only have to evaluate the literal words typed but also the context and expectations of open source. As the libxml2 maintainer indicates, they are no longer willing to participate in security bug secrecy and priority. In hindsight, those expectations that most take for granted as necessary must have demanded considerable time and energy from them. They could have said no at any time, but not as easily as turning down a feature request. For asocial-leaning maintainers (hi!) saying no to security processes is no more difficult than refusing any other request — but for the vast majority of maintainers, it will take an effort of courage and will to refuse the ‘demands’ — the social pressures, the contexts and expectations — of security’s best practices, reporting processes, and priority overrides. (Elsethread, the individual making demands in an issue is also a case of ‘demand’ rather than ‘request’, that isn’t much in the in-between grey area at all.)
Psychologically, it hits different when a leecher — someone whose uploads are not greater than some minimum threshold — begins demanding something; what they receive then is not just a free copy of the maintainer’s work to profit from, but also the specialized work of the maintainer to satisfy or reject their request. The cumulative impact of dealing with parasites is distinct from the demotivating effect of profitable leechers who silently download their work and never say anything at all?(and also from the motivating effect of seeing millions of people benefiting from leeching — adoption is often a significant reward). Torrenting has no language for this difference, as in torrenting there is no such problem; so I did some research and chose ‘parasite’ here. I recognize that, scientifically, the animal ‘leech’ tends to be viewed as ‘parasitic’; but there’s a clear difference in connotations, as a torrent leecher is not viewed with – does not view themselves with — the same disgust and loathing as parasites are.
I think a lot of people, when they see an open source project that somehow fits into their current challenges, read it as the person realising the project saying “I alone now own this entire problem space” and so that GitHub repo is now just an extension of your jira board.
ndiddy
I feel bad for the libxml2 maintainer. The project was originally intended for parsing GNOME configuration files, but then a bunch of corporations started using it to parse untrusted data with much higher stakes. I hope that both the decision not to prioritize security issues and the new notice in the README saying it's foolish to use the project to parse untrusted data will encourage corporate users to either switch to a different project or do more to improve its security than dumping security reports onto an unpaid maintainer.
I will say that all of the comments saying that open source licenses should change to formally prohibit this behavior are a bit naive. Ever since the Open Source Initiative was founded in the late 90s, its express purpose has been to boost the adoption of free (now "open source") software by pitching it to corporations as a way to cut costs. This means that they'll never approve a license that requires certain users to contribute to the project, monetarily or otherwise. Of course anyone's allowed to license their project any way they see fit, but they'll have to call it something other than open source and accept the limited distribution and userbase they'll see as a result.
wavemode
> Of course anyone's allowed to license their project any way they see fit, but they'll have to call it something other than open source and accept the limited distribution and userbase they'll see as a result.
This doesn't require abandoning open source. The GPL and AGPL serve precisely the purpose of preventing open-source software from being exploited for closed-source purposes.
Obviously hindsight is 20/20, so this doesn't help maintainers who have already chosen a permissive license and don't want to rugpull their users. But to say solving this problem requires adopting a non-open-source license is not correct.
Another option is dual-licensing - GPL/AGPL for all, or a permissive license that can be purchased for a fee.
ndiddy
I was specifically talking about the people saying that the corporate users should be required by the license to provide compensation or assistance to the project. You're right that licensing as GPLv3 or AGPL generally limits corporate use of open source, and that selling license exemptions is a good way to let everybody win (although it means you'll have to either not accept contributions or make all your contributors sign a CLA).
CaptainFever
Personally, the distinction I draw isn't between corporations and cooperation as per the article ("they make money" is kind of an arbitrary difference IMO), but just that in general maintainers have no obligation to do any sort of work for free.
So like, regardless of the user of the software, one should understand that there really is no warranty, or promise of quality or support from FOSS.
If one (whether it be Debian or Apple) needs a feature, bug fix, or security fix, one can ask for it, but don't expect anything.
The best way is to do it themselves, and share their code if they wish to or are obligated to under the GPL. Or commission a programmer or the maintainer to do it. Or buy a support contract from the maintainer. Or encourage it by doing micropatronage and voting for it.
anewhnaccount2
I think this is correct and projects like DuckDB are doing a food job at supporting both halves by triaging issues also based on the identity and affiliation of the author (no anonymous issues) and converting them into supporters https://duckdblabs.com/community_support_policy/
This passive approach of libxml2 where the software remains community only is just fine and totally fair, but corporate users can pay up if there's a clear offering. What they actually get doesn't need to be much, but if it does need to be clear. Of course this does change the project into hybrid community/corperate open source but there can be a spectrum there where a lot of time and resources is carved out for the community approach and the corperate sponsors are given just enough to keep them happy. In a way some more corperate focussed Linux distributions are also an example of a hybrid approach really given the two worlds are very much linked.
captn3m0
I don’t see affiliation/no-anon-issues on the DuckDB link, do you have a better link?
KingMob
The current attitudes and licenses of FOSS, while good in many ways, have also enabled a ton of exploitation and free-riding, and people need to acknowledge that.
Nobody should be giving Bezos free work.
ItCouldBeWorse
Especially when Bezos uses that free work,to sabotage the free eco-system wherever he can. Building moats and garden walls, embracing, extending and extincting.
And you can tell by the way they move, they do not want to hurt each other- a cartel of toe-owners. Otherwise, what happened to gaming with the steam-deck, could have happened with linux to the desktop world years ago. Especially now, where the owner describing his intent, transfers to scripting glue code.
GardenLetter27
> Nobody should be giving Bezos free work.
Just use the GPLv3 or AGPL, problem solved.
pabs3
The GPLv3 or AGPL still result in free work for corporations, and are easy to comply with for corporations, without paying a cent to maintainers, so do not solve the problem.
ThunderSizzle
Does it really? Licensing only means as much as the enforcement that follows infringement, and good luck forcing Amazon to lose on a case like that.
KingMob
Uhhh, neither of those forces Amazon to pay you for your efforts if they use your library.
I think you pattern-matched to a different argument.
altairprime
The crowning achievement of FOSS is in convincing maintainers to accept exploitation as beneficial.
The FOSS era can be distinguished from the BSD/MIT era preceding it by its dedicated promotion of libertarianism in all shared source code conversations, which celebrates (quite defensively!) the resulting exploitation and free-riding as beneficial. While this is often presented as a natural outcome of BSD/MIT licensing, that FOSS viewpoint hinges on assumption-by-framing of exploitation without compensation as being morally neutral or positive. That framed assumption is false: the “scientists publish their work to each other” social climate that preceded it was openly hostile to entities who profited from work without ‘uploading’ via publication back to the community in return. Thus, the innovative social bargain of the GPL: you receive legal certainty that improvements to your source code will be shared back to you; then, FOSS advocacy uses adoption of the GPL as proof that exploitation without compensation is beneficial.
pabs3
The GPL requires sharing forward, not sharing back.
KingMob
Yes, that's the problem.
pabs3
No, its the solution to the world wanting to reduce software freedom.
aaron695(dead)
[dead]
notarobot123
At this point, why shouldn't the licences change?
Sharing the result of collaborative efforts liberally makes sense. Wanting to be able to modify software and redistribute modifications makes sense. Allowing software to evolve in a broader eco-system makes sense.
What isn't seeming to make sense is how OSS software is used commercially and the way that skews the culture and priorities of open source projects. What purpose does the lack of commercial restrictions serve?
No restrictions on commercial use at all seems naive (and perhaps plain ideological) at this point. I used to think that things were too embedded to change but it does feel like a major shift is fermenting and has been for a while.
Arainach
There's always a tradeoff in use or contribution. If a project is under a more restrictive license the odds of individuals or companies contributing (or for certain licenses even using) drops radically.
If your intent is just "I wrote this thing, sharing the code" license as restrictively as you'd like. If your intent is "I want to build (and/or get others to help build) a bigger thing", restrictions scare folks off.
It's trivial for me to get approval from my employer to do almost anything in almost any MIT-licensed codebase; we use and contribute to a number of GPLv2 codebases. However GPLv3 is a very rigid line in the sand that I do not expect to ever change.
pabs3
What is it about GPLv3 that causes a line in the sand?
The source distribution, modification and reinstallation requirements are pretty much identical, at least according to the main folks doing Linux kernel GPL enforcement for the last decades.
The patent clauses are significant, and for any product which interacts with DRM the DRM clauses are a showstopper.
NoGravitas
The Peer Production License and its relatives are pretty good generally. The problem is always license compatibility. One of the benefits of Open Source licensing being kind of standardized has been composability. There's been a pretty clear gradient of "restrictiveness" of licenses, so when you mix software together, you just have to use the most restrictive license of your dependencies (or one that is more restrictive). Copyfarleft licenses are a good thing, but they make the restrictiveness dimension diverge in different ways, so you can't necessarily mix them with each other, or with the GPL (say).
phendrenad2
> You might not want to leave Debian (which is fundamentally people) in the lurch over a security issue, but if a corporation shows up with a security issue, well, you tap the sign.
I think that many people have done this, and all of them were deposed and replaced with someone who would "play ball" (I.E., work for free). Go ahead, keep an eye on Libxml2, we'll either see this reversed, or we'll see libxml3 promoted from all angles and libxml2 decried as "deprecated".
Note that if that happens, it doesn't mean libxml2 is actually bad, it just means that it no longer fits the needs of the corporate overlords, and they need YOU to believe that it's no longer good so you won't waste their time with support requests.
_vere
It's also notable that these companies often dont respect the terms of foss software at all.
Anyone worth their salt can tell you that training your LLM on gpl3 code would make it a derivative product, as it is able to reproduce large parts of that code. LLMs that are currently earning Google, Facebook, Openai, etc, billions, while they obviously dont make "their" products available under gpl3.
GardenLetter27
I don't mind them training on GPL code, but I wish they had to at least publish their model weights (and maybe also training and inference code, etc.) - same for the other issues re. using copyrighted media in training.
_vere
Its not really about if you mind, they create derivative works in direct violation of the gpl.
karmakaze
> They're not in open source as a cooperative venture, they are using it to make money
> Existing open source licenses, practices, and culture don't draw this distinction
I disagree for the most part. Corporations avoid copyleft licenses like the plague. It's the term open-source that includes 'free beer' licensed software that created this confusion.
NoGravitas
Lots of companies will draw the line in different places. Some will accept GPLv2 but not GPLv3. Some will accept GPLv3 but not AGPLv3.
burnt-resistor
Google and Meta have policies against using any AGPL code anywhere.
pabs3
I wonder why, it is not like it is hard to comply with.
burnt-resistor
Legal absolutism and intransigency, and maybe some ideological retribution. ¯\_(ツ)_/¯ I paid my dues in MAANG. Business culturally, control seemed all-important. They seemed to want source they could use without giving a dime to maintainers, if they so chose. Some support was given, but not enough and not uniformly.
This is an understated but brilliant framing. Oh I know they won't contribute, users will continue to apply pressure through issue threads saying that their clueless security teams are breathing down their necks. But at least you'd hope this gives pause.
The linked issue is worth a read, it's a shame the burden that corporate leeches like apple and google have placed on him. To them this project is simply free labour they have assumed they are entitled to and by extension are subject to their individual security theatrics.
https://gitlab.gnome.org/GNOME/libxml2/-/issues/913
The bug has no actual example of them making demands, "leeching" or acting entitled.
The security issues would be security issues just the same even if the library was only used by Linux desktops. (And if the library is unfit for use in other operating systems like the author suggests, feels like it probably is equally unfit for use in Gnome.)
https://opensourcedefinition.org/
ratio = (contributions - demands) : earnings
If you contribute nothing, demand nothing, and earn nothing, carry on. “Nothing” is loosely defined as “near enough to zero in the context of a specific project”.
If you contribute nothing, demand nothing, and earn (DL) a million dollars using it somehow, you’re a leecher. Your U/D ratio is 0.0. That should be an uncomfortable realization. One way to cope with that is to raise your ratio to 0.1. If you make a million dollars of revenue using libcurl, how much are you allocating to donate back?
If you contribute nothing and demand security fixes, then you’re not a leecher — you’re a parasite, because your demands exceed your contributions; your sign bit is still negative even if your ratio is 0.0 or NaN. It has been zero days since this workplace had a maintainer injury due to parasitic behavior.
Leechers are demoralizing when the revenue earned would let the author quit their day job to do more fun work instead. Parasites leave a trail of damaged and dead projects in their wake. libxml2’s maintainer made a policy change that cuts off the food supply for parasites; good. They’ll still burnout someday due to the untreated morale damage being done by the billionaire leechers, though.
If an author accepts contributions and you feel like a leecher, do something about it. If they do not accept contributions (including money) or if the anccepted contributions are incompatible (their code is in COBOL and you only know Rust, they only offer “donate bitcoin”, you’re a broke student funding school with your project) then maybe write them a thank you letter? and revisit this if your or their circumstances change someday.
As a former open source maintainer, I don’t mind it when people leech. That’s chill. Go for it. I don’t have a tip jar because I don’t expect a tip. But I mind when people DL a million dollars of revenue using my work and have a UL:DL ratio of 0.0 with me.
Corporations, formally do not care whether users are hobbyists, leechers, or parasites. Maintainers do. The OSI continues to reject as Open Source any licenses attempting to stop the morale impact of millionaire leechers and the time and effort drained by parasites.
Which is more important to the future of open source: the right to be a leecher or a parasite, or the maintainers that they feed upon?
There's the "demand" word again. Who is that demanded something from the maintainer, and where? I saw no indication in the original bug of any demands from big tech companies.
(Just the act reporting a security issue is not a demand. A verifiable bug is a bug whether it was reported or not, and reporting one is a contribution.)
When the demand part of your torrent-inspired equation is zero, how is it leeching? It's just zero, no matter what the earnings are.
https://gitlab.gnome.org/GNOME/libxml2/-/issues/905#note_243...
Psychologically, it hits different when a leecher — someone whose uploads are not greater than some minimum threshold — begins demanding something; what they receive then is not just a free copy of the maintainer’s work to profit from, but also the specialized work of the maintainer to satisfy or reject their request. The cumulative impact of dealing with parasites is distinct from the demotivating effect of profitable leechers who silently download their work and never say anything at all?(and also from the motivating effect of seeing millions of people benefiting from leeching — adoption is often a significant reward). Torrenting has no language for this difference, as in torrenting there is no such problem; so I did some research and chose ‘parasite’ here. I recognize that, scientifically, the animal ‘leech’ tends to be viewed as ‘parasitic’; but there’s a clear difference in connotations, as a torrent leecher is not viewed with – does not view themselves with — the same disgust and loathing as parasites are.
I will say that all of the comments saying that open source licenses should change to formally prohibit this behavior are a bit naive. Ever since the Open Source Initiative was founded in the late 90s, its express purpose has been to boost the adoption of free (now "open source") software by pitching it to corporations as a way to cut costs. This means that they'll never approve a license that requires certain users to contribute to the project, monetarily or otherwise. Of course anyone's allowed to license their project any way they see fit, but they'll have to call it something other than open source and accept the limited distribution and userbase they'll see as a result.
This doesn't require abandoning open source. The GPL and AGPL serve precisely the purpose of preventing open-source software from being exploited for closed-source purposes.
Obviously hindsight is 20/20, so this doesn't help maintainers who have already chosen a permissive license and don't want to rugpull their users. But to say solving this problem requires adopting a non-open-source license is not correct.
Another option is dual-licensing - GPL/AGPL for all, or a permissive license that can be purchased for a fee.
So like, regardless of the user of the software, one should understand that there really is no warranty, or promise of quality or support from FOSS.
If one (whether it be Debian or Apple) needs a feature, bug fix, or security fix, one can ask for it, but don't expect anything.
The best way is to do it themselves, and share their code if they wish to or are obligated to under the GPL. Or commission a programmer or the maintainer to do it. Or buy a support contract from the maintainer. Or encourage it by doing micropatronage and voting for it.
This passive approach of libxml2 where the software remains community only is just fine and totally fair, but corporate users can pay up if there's a clear offering. What they actually get doesn't need to be much, but if it does need to be clear. Of course this does change the project into hybrid community/corperate open source but there can be a spectrum there where a lot of time and resources is carved out for the community approach and the corperate sponsors are given just enough to keep them happy. In a way some more corperate focussed Linux distributions are also an example of a hybrid approach really given the two worlds are very much linked.
Nobody should be giving Bezos free work.
And you can tell by the way they move, they do not want to hurt each other- a cartel of toe-owners. Otherwise, what happened to gaming with the steam-deck, could have happened with linux to the desktop world years ago. Especially now, where the owner describing his intent, transfers to scripting glue code.
Just use the GPLv3 or AGPL, problem solved.
I think you pattern-matched to a different argument.
The FOSS era can be distinguished from the BSD/MIT era preceding it by its dedicated promotion of libertarianism in all shared source code conversations, which celebrates (quite defensively!) the resulting exploitation and free-riding as beneficial. While this is often presented as a natural outcome of BSD/MIT licensing, that FOSS viewpoint hinges on assumption-by-framing of exploitation without compensation as being morally neutral or positive. That framed assumption is false: the “scientists publish their work to each other” social climate that preceded it was openly hostile to entities who profited from work without ‘uploading’ via publication back to the community in return. Thus, the innovative social bargain of the GPL: you receive legal certainty that improvements to your source code will be shared back to you; then, FOSS advocacy uses adoption of the GPL as proof that exploitation without compensation is beneficial.
Sharing the result of collaborative efforts liberally makes sense. Wanting to be able to modify software and redistribute modifications makes sense. Allowing software to evolve in a broader eco-system makes sense.
What isn't seeming to make sense is how OSS software is used commercially and the way that skews the culture and priorities of open source projects. What purpose does the lack of commercial restrictions serve?
No restrictions on commercial use at all seems naive (and perhaps plain ideological) at this point. I used to think that things were too embedded to change but it does feel like a major shift is fermenting and has been for a while.
If your intent is just "I wrote this thing, sharing the code" license as restrictively as you'd like. If your intent is "I want to build (and/or get others to help build) a bigger thing", restrictions scare folks off.
It's trivial for me to get approval from my employer to do almost anything in almost any MIT-licensed codebase; we use and contribute to a number of GPLv2 codebases. However GPLv3 is a very rigid line in the sand that I do not expect to ever change.
The source distribution, modification and reinstallation requirements are pretty much identical, at least according to the main folks doing Linux kernel GPL enforcement for the last decades.
https://sfconservancy.org/blog/2021/mar/25/install-gplv2/ https://sfconservancy.org/blog/2021/jul/23/tivoization-and-t... https://events19.linuxfoundation.org/wp-content/uploads/2017...
I think that many people have done this, and all of them were deposed and replaced with someone who would "play ball" (I.E., work for free). Go ahead, keep an eye on Libxml2, we'll either see this reversed, or we'll see libxml3 promoted from all angles and libxml2 decried as "deprecated".
Note that if that happens, it doesn't mean libxml2 is actually bad, it just means that it no longer fits the needs of the corporate overlords, and they need YOU to believe that it's no longer good so you won't waste their time with support requests.
> Existing open source licenses, practices, and culture don't draw this distinction
I disagree for the most part. Corporations avoid copyleft licenses like the plague. It's the term open-source that includes 'free beer' licensed software that created this confusion.