The bit about google employees willing to step up and work on the project is kind of disgusting: The company is too cheap to fund the project with money, but don't worry, they've got an endless supply of eager developers looking to 'pad their résumé' and deny you all the reward and satisfaction of what you built. It almost reads like a threat "work for free or we'll fork it and take it away from you". Wow

It was very influential for me too. Here's another one, also from Zed Shaw:

https://web.archive.org/web/20120620103603/http://zedshaw.co...

> Why I (A/L)GPL

> Open source to open source, corporation to corporation.

> If you do open source, you’re my hero and I support you.

> If you’re a corporation, let’s talk business.

> I want people to appreciate the work I’ve done and the value of what I’ve made.

> Not pass on by waving “sucker” as they drive their fancy cars.

The main problem is that you need to have contributors sign a copyright assignment/CLA, otherwise their code is going to be AGPL only and you cannot license it commercially.

Or you don't have any contributors, which is the base case, I guess.

> Did I get it right?

I think so.

> 1- Is this solution useful for subscription-based contract too?

If you mean SaaS, then maybe. I emailed Stallman about the ethics of the SaaS case and he said it's a net good.

You might want to think about whether the license actually gives you leverage in that case though. You might find that the corporations are perfectly willing to host a service using your AGPLv3 software. That's within their rights.

You only gain leverage if they want to create a proprietary version of your software.

> 2- Does it make a difference if the product is a app, library or hardware device?

Absolutely. The GPL has very specific wording with regards to linking and distribution which trigger license conditions. You should read the full license for a better understanding.

Hardware is a completely different matter, I won't even pretend to know anything about how licensing works in that case.

Remember, I'm not a lawyer. I'm just a hobbyist free software developer who's also trying his best to understand all this and make the best possible decision.

Let them maintain it. We can take their permissive code and add it to our AGPLv3 projects literally no questions asked, we just have to replicate the copyright notice and license file. Meanwhile they can't take our copyleft code without also copylefting any improvements they distribute. And with AGPLv3, network use is distribution.

Why throw out numbers when we all know you haven't actually measured that it's >80%?

In any case, the tooling around XML (DTDs, XPath, XSLT, etc.) is the reason to use it. I would go so far as to say the (supposed) >80% not using those features shouldn't have used XML in the first place.

The solution is simple: don't have XML files that are many gigabytes in size.

Yep, another case of XKCD 2347, unfortunately.

> its not clear why, say, Chrome or Firefox wouldn't want to take over XSLT/libxml2 development

Very few people actually like XSLT, presumably including the Chrome and Firefox devs. I know XSLT has its share of supporters and that's fine. I'm not here to argue to merits of XSLT – or lack thereof – but we need to be honest about this. They are the proverbial Black Metal fans; everyone else just thinks it's bloody noise.

In addition, many people have grown towards the idea that importing these large C libraries for little used features is just not a good idea in the first place. And that makes libxml and libxslt a dead end. The entire business with XSLT was kicked off by a bunch of security bugs.

Finally, I think a decent case can be made to slim down the "web platform" a bit. If you want XSLT you can still "bring it yourself", but does every browser need to implement it to be "standards compliant"? Seems like a bad trade-off to me. It's a win for newer browsers like Servo or Ladybird if they don't need to worry about XSLT.

So in short, it's not just a problem of "adding some more people to libxml", although obviously that is a problem.

They don’t want to because they don’t see any bright future for the technology even if it’s better maintained. XML/XSLT isn’t trendy anymore, nobody is building new apps on it. It is never going to win market share from react - it’s too baroque and dated.

> or you can't use it commercially or for safety-critical things

The license for libxml2 (like the license for almost any kind of open source software) already states "THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT." I don't see how you can put the responsibility even more on the integrator/seller than that. It literally states the devs don't even guarantee it works correctly.

Safety critical fields like aviation already have strict requirements. Usually there's very few software dependencies used in those projects.

Expanding that to more fields would be interesting, but difficult and expensive across the board. Particularly any sort of requirements like that generally incur significant regulatory and certification overhead.

However, if it was done similar to PCISS as an industry forum it might work better. Especially if certain fields like anything connecting with the electric grid we're required to use certified software.

More or less, though the CRA is pretty minimal: it has a few basic requirements and hobby/unpaid open source software is not covered. A company integrating open source software is essentially responsible for covering those requirements themselves.

Read your Microsoft licensing agreement. If you don't have one, read the EULA for OEM windows. The warranty, fitness for purpose and damages exclusion is not as extensive as what the grandparent cited, but it basically boils down to "as limited as legally possible, and the most damages you will get is your license fee back". You also won't get a binding requirements document anyways, so you don't even really know what the software microsoft sells you is fit for. At any point in time, there could be some knowledgebase article saying something like "oh, and btw, don't do this because it breaks", so per their warranty agreement you signed they are free from any responsibility simply by documenting the problem.

Really safety-critical stuff like ASIL-D, ISO26262, IEC61508 (and tons of other magic numbers) isn't something you can buy from microsoft. At best, you can sometimes get a reseller to sign something a little more binding, but with tons of restrictions that basically boil down to "use the microsoft stuff for the readout gauges, but the critical control part goes somewhere else".

Thanks for the info; I read the news but did not remember the name of the person.

*liblzma

No I had a hard time understanding as I was not aware of the person in question, no sarcasm.

All Internet comments are to be assumed sarcastic until proven otherwise. Bombcar’s law.