Use the most radically copyleft and freedom preserving license you can. If the corporations want your software, you present a business solution: pay for special licensing conditions.
It's even blessed by Stallman. I emailed him to confirm. Unlike permissive licenses, only the original copyright holders get to benefit in this way. Others don't have this relicensing permission. The damage is contained.
I hope it works out for him. Watching beggar barons make billions off of free software that's being maintained for free is really hard to watch.
My friend sent me that article a few months ago. It _completely_ changed my approach to OSS contribution: from a 25yr MIT/BSD adherent to AGPL adherent in 30min.
The RedHat apparatchik at the top of the link is amazing. Attacking others from his secure position and celebrating more corporate influence:
"Good news is several Google and Apple engineers have volunteered to help with libxml2 and libxslt security issues, despite your effort to sabotage libxml2 users -- especially web browser users -- by disclosing all vulnerabilities immediately rather than allowing them the industry-standard 90 day disclosure deadline used by all other GNOME projects (#913 (closed)). They've posted a couple patches in the libxslt issue tracker already. I assume you're not satisfied with this, and are now trying to push them away. If that's your goal, you'll no doubt succeed pretty quickly."
RedHat often has a detrimental effect on open source, it is filled with bureaucrats and careerists.
Thanks Nick Wellnhofer for going AGPL. You are setting a great example!
This should be higher up and seems very relevant to understanding what's going on. Looks like the (former) maintainer does not actually want to abandon libxml2.
Because according to the Gitlab comment you've taken that excerpt from, companies are so allergic to the GPL that they will not only avoid using the GPL version of libxml2, no. They will maintain a MIT fork of libxml2 out of spite, even though they've been actively running away from their responsibility to do so.
If you think you need libxml2, think again. XML is a complex beast. Do you really need all those features? Maybe a much smaller, more easily maintained library would suit your needs while performing better at the same time!
For instance, consuming XML and creating it are two very different use cases. Zooming into consuming it, perhaps your input data has more guarantees than libxml2 assumes, such as the nonexistence of meta definition tags.
But different "yous" need different features, and so they get all glommed together into one big thing. So no one needs "all" of lbxml2/XML's features, each individual needs a different subset.
It's the same as the old joke about Microsoft Word: people only use 10% of Word's functionality, but the problem is each person uses a different 10%.
Of course this is an oversimplification, and there will no doubt be some sort of long tail, but it expresses the challenge well. I'd imagine the same is true for many other reasonably complex libraries, frameworks, or applications.
XML without DTDs is a very reasonable subset that eliminates significant complexity (no need for an HTTP client!) and security risks (no custom character entities that are infinitely recursive or read /etc/passwd!) and would probably still work for >80% of users.
I kinda want something which just treats XML as a dumb tree definition language... give me elements with attributes as string key/value pairs, and children as an array of elements. And have a serialiser in there as well, it shouldn't hurt.
Basically something behaves like your typical JSON parser and serialiser but for XML.
To my knowledge, this is what TinyXML2 does, and I've used TinyXML2 for this before to great effect.
That's what you call a DOM Parser - the problem with them is, as they serialize all the elements into objects, bigger XML files tend to eat up all of your RAM. And this is where SAX2 parsers come into play where you define tree based callbacks to process the data.
1. "This XML library is way bigger than what I need, I'll write something more minimal for my use case"
2. write a library for whatever minimal subset you need
3. crash report comes in, realise you missed off some feature x. Add support for some feature x.
4. Bob likes your library. So small, so elegant. He'd love to use it, if only you supported feature y, so you add support for feature y.
...
End result is x+1 big, complex XML libraries.
Obviously Im being a bit obtuse here because you might be able to guarantee some subset of it in whatever your specific circumstances are, but I think it's hard to do over a long period of time. If people think you're speaking XML then at some point they'll say "why don't we use this nice XML feature to add this new functionality".
XML is used in countless standards. You can't just not use it if you interact with the outside world. Every XML feature is still in the many XML libraries because someone has a need for it, even things like external entities.
Maybe you don't need libxml2 specifically (good luck finding an alternative to parse XML in C and other such languages though), but "I don't like the complex side of XML so let's pretend it doesn't exist" doesn't solve the problem most people pick libxml2 for. It's the de-facto standard because it supports everything you could possibly need.
Exactly. For example if you need to integrate SAML, you have to support a significant subset of several XML specs. It may be possible to write a SAML-only library that supports less, but it's not clear it would be any simpler.
It's common for both the producer of XML and the consumer of XML for any given application to be using a dramatically smaller subset of the standard. Well-engineered software is intentional about this and documents those limitations. Under these conditions it's perfectly valid to use a library that only supports this subset.
Furthermore, those subsets have natural "fault lines", influenced by the burden:utility ratio. This makes consumers and producers naturally coordinate on a subset. It's not like another commenter here said about everyone needing different features.
My argument is therefore that there is value in having different libraries for different subsets - with the smallest subset being much simpler than libxml2.
> <blink>Expat is UNDERSTAFFED and WITHOUT FUNDING.</blink>
> The following topics need additional skilled C developers to progress
> in a timely manner or at all (loosely ordered by descending priority):
Its a shame that xslt seems to be struggling so much at the moment. If xslt 3 support was fully implemented in libxml2 (and therefore xsltproc and browsers) then it would be by far the most sensible option for designing anything to do with getting text onto the web.
* XSLT is still the only native templating option for HTML pages that runs natively in the browser (but just now you are limited to XSLT v1.0 which as a number of drawbacks and limitations)
* XSLT/XML is still best at text markup. In particular interpolation. There is no simple way to represent marked up text in, say, JSON.
* Content federation (atom, rss) is still very dependent on XML.
Surely somebody somewhere has money to pay for a greybeard to fix XSLT for us? It seems far to fundamental to be left to wither on the vine.
Rather than struggling/withering, it's actively being killed. Efforts are underway to completely remove XSLT support from browsers, due to the poor state of libxml2 and a lack of any new maintainer stepping up.
Right, but AKAIK its _still_ being maintained on a voluntary basis. Thats nuts, and its not clear why, say, Chrome or Firefox wouldn't want to take over XSLT/libsml2 development, particularly if they won market share from stuff like React, and created a developer acquisition pipeline for their respective ecosystems.
I feel like it adds more weight to my feeling that we should have a software building code. When you have software that's critical infrastructure, with a nutso security policy like "no embargoes / 0day me bruh", we should have some regulations in place to require the software be maintained properly (that is to say, in a sane manner) or you can't use it commercially or for safety-critical things. Which would inevitably force commercial entities to pay for the maintenance so it could be done right.... which they should be doing already, the same way any company that builds safety-critical infrastructure has to pay to do it right.
If we want society to be safe, we have to make a law that enforces it. That's how that shit works.
(as an aside: holy shit, you're a prolific HN submitter, and all from different sources. where do you get it all?)
This made my brain go
"Oh no, not this again. Open source projects don't owe you..." etc etc.
> or you can't use it commercially or for safety-critical things
Oh. Yeah, okay, absolutely! For safety-critical, I would like to think the responsibility already lies with the integrator/seller, but making it explicitly so can't hurt.
Isn't this what the european Cyber Resilience Act (CRA) is about?
See https://orcwg.org/cra/ and the work of the Open Regulatory Compliance Working Group in general.
> When you have software that's critical infrastructure, with a nutso security policy like "no embargoes / 0day me bruh",
...you then should stop and re-evaluate your life choices: specifically, choosing this particular piece of software, which is known to have always been insecure, to be a critical part of your infrastructure.
People building "safety critical" systems already pay for a "secure" ecosystem. It's called Microsoft. We don't need regulations to have Microsoft exist. Do you think some random med tech startup is going to pay to have libxml2 maintained? They'll see the regulation and go "oh ok, Windows licenses it is".
It's not the "safety critical" software that needs this fixed, it's all software in general. There's a million software systems that have important privacy sensitive data or safety relevant processes that fly under the "safety critical" radar.
Nick Wellnhofer is stepping away from libxml2 after a decade of unpaid maintenance. He’s forking it under the AGPL, but that will probably scare off most corporate users.
Meanwhile libxml2 is still everywhere. Without someone with real backing, a core piece of infrastructure is about to go unmaintained.
Once again, the open-source funding problem is laid bare: the internet runs on the unpaid evenings of a few people until they burn out (add relevant reference from XKCD, obviously).
"Expected effort required to maintain implementation" should be an evaluation criteria when selecting technologies. Thousand page RFCs do not make sustainable standards in the long run. Most committee designed specs end up in this category. People are impressed by complexity but actively pursuing simplicity is what we should be doing.
With not enough time to develop an alternative and too many application ecosystems relying on this library, I think it's a matter of time before a large company forks the library to fix security issues with it now that they have no choice but to do the work themselves. At least until IBM and Google figure out a way to move away from this library.
Maybe my human interaction interfacing software has a glitch but I am having a hard time parsing this content. Do I detect a hint of sarcasm? Please add a '/s' at the end of your future posts to aid my very archaic and vintage brain matter.
Jia Tan was the alias of the hacker(s) who infiltrated xz to plant a backdoor. He/They were in the project for 2 years I believe, and so had "significant experience" "maintaining" open source software.
Readit News
This business model is known as selling exceptions to the GPL.
https://www.gnu.org/philosophy/selling-exceptions.html
Use the most radically copyleft and freedom preserving license you can. If the corporations want your software, you present a business solution: pay for special licensing conditions.
It's even blessed by Stallman. I emailed him to confirm. Unlike permissive licenses, only the original copyright holders get to benefit in this way. Others don't have this relicensing permission. The damage is contained.
I hope it works out for him. Watching beggar barons make billions off of free software that's being maintained for free is really hard to watch.
https://zedshaw.com/blog/2022-02-05-the-beggar-barons/
I personally like the slow and steady tide of understanding the value of GPL family of licenses.
- Licence as AGPL
- Mention that commercial use (without having to open source the derivative work) is available
Did I get it right?
1- Is this solution useful for subscription-based contract too?
2- Does it make a difference if the product is a app, library or hardware device?
"Good news is several Google and Apple engineers have volunteered to help with libxml2 and libxslt security issues, despite your effort to sabotage libxml2 users -- especially web browser users -- by disclosing all vulnerabilities immediately rather than allowing them the industry-standard 90 day disclosure deadline used by all other GNOME projects (#913 (closed)). They've posted a couple patches in the libxslt issue tracker already. I assume you're not satisfied with this, and are now trying to push them away. If that's your goal, you'll no doubt succeed pretty quickly."
RedHat often has a detrimental effect on open source, it is filled with bureaucrats and careerists.
Thanks Nick Wellnhofer for going AGPL. You are setting a great example!
Deleted Comment
Why wouldn't other FOSS projects like Gnome Web for example not use GPLv3 licensed software?
For instance, consuming XML and creating it are two very different use cases. Zooming into consuming it, perhaps your input data has more guarantees than libxml2 assumes, such as the nonexistence of meta definition tags.
"You" probably do not.
But different "yous" need different features, and so they get all glommed together into one big thing. So no one needs "all" of lbxml2/XML's features, each individual needs a different subset.
Of course this is an oversimplification, and there will no doubt be some sort of long tail, but it expresses the challenge well. I'd imagine the same is true for many other reasonably complex libraries, frameworks, or applications.
(I wrote such an XML parser a long time ago.)
Basically something behaves like your typical JSON parser and serialiser but for XML.
To my knowledge, this is what TinyXML2 does, and I've used TinyXML2 for this before to great effect.
1. "This XML library is way bigger than what I need, I'll write something more minimal for my use case"
2. write a library for whatever minimal subset you need
3. crash report comes in, realise you missed off some feature x. Add support for some feature x.
4. Bob likes your library. So small, so elegant. He'd love to use it, if only you supported feature y, so you add support for feature y.
...
End result is x+1 big, complex XML libraries.
Obviously Im being a bit obtuse here because you might be able to guarantee some subset of it in whatever your specific circumstances are, but I think it's hard to do over a long period of time. If people think you're speaking XML then at some point they'll say "why don't we use this nice XML feature to add this new functionality".
The former are blazingly fast. In real world they can parse instantly. So alternatives do exist for different use cases.
No. This is the first good expkanation for the library hell in linux those days.
Maybe you don't need libxml2 specifically (good luck finding an alternative to parse XML in C and other such languages though), but "I don't like the complex side of XML so let's pretend it doesn't exist" doesn't solve the problem most people pick libxml2 for. It's the de-facto standard because it supports everything you could possibly need.
Furthermore, those subsets have natural "fault lines", influenced by the burden:utility ratio. This makes consumers and producers naturally coordinate on a subset. It's not like another commenter here said about everyone needing different features.
My argument is therefore that there is value in having different libraries for different subsets - with the smallest subset being much simpler than libxml2.
> <blink>Expat is UNDERSTAFFED and WITHOUT FUNDING.</blink> > The following topics need additional skilled C developers to progress > in a timely manner or at all (loosely ordered by descending priority):
* XSLT is still the only native templating option for HTML pages that runs natively in the browser (but just now you are limited to XSLT v1.0 which as a number of drawbacks and limitations)
* XSLT/XML is still best at text markup. In particular interpolation. There is no simple way to represent marked up text in, say, JSON.
* Content federation (atom, rss) is still very dependent on XML.
Surely somebody somewhere has money to pay for a greybeard to fix XSLT for us? It seems far to fundamental to be left to wither on the vine.
I feel like it adds more weight to my feeling that we should have a software building code. When you have software that's critical infrastructure, with a nutso security policy like "no embargoes / 0day me bruh", we should have some regulations in place to require the software be maintained properly (that is to say, in a sane manner) or you can't use it commercially or for safety-critical things. Which would inevitably force commercial entities to pay for the maintenance so it could be done right.... which they should be doing already, the same way any company that builds safety-critical infrastructure has to pay to do it right.
If we want society to be safe, we have to make a law that enforces it. That's how that shit works.
(as an aside: holy shit, you're a prolific HN submitter, and all from different sources. where do you get it all?)
This made my brain go "Oh no, not this again. Open source projects don't owe you..." etc etc.
> or you can't use it commercially or for safety-critical things
Oh. Yeah, okay, absolutely! For safety-critical, I would like to think the responsibility already lies with the integrator/seller, but making it explicitly so can't hurt.
...you then should stop and re-evaluate your life choices: specifically, choosing this particular piece of software, which is known to have always been insecure, to be a critical part of your infrastructure.
It's not the "safety critical" software that needs this fixed, it's all software in general. There's a million software systems that have important privacy sensitive data or safety relevant processes that fly under the "safety critical" radar.
Meanwhile libxml2 is still everywhere. Without someone with real backing, a core piece of infrastructure is about to go unmaintained.
Once again, the open-source funding problem is laid bare: the internet runs on the unpaid evenings of a few people until they burn out (add relevant reference from XKCD, obviously).