←back to thread

Libxml2's "no security embargoes" policy

(lwn.net)
277 points jwilk | 3 comments | 25 Jun 25 19:36 UTC | HN request time: 0.001s | source
Show context
kibwen ◴[25 Jun 25 22:01 UTC] No.44382195[source]▶
> Ariadne Conill, a long-time open-source contributor, observed that corporations using open source had responded with ""regulatory capture of the commons"" instead of contributing to the software they depend on.

I'm only half-joking when I say that one of the premier selling points of GPL over MIT in this day and age is that it explicitly deters these freeloading multibillion-dollar companies from depending on your software and making demands of your time.

replies(4): >>44382211 #>>44383593 #>>44385565 #>>44385638 #
spott ◴[26 Jun 25 02:03 UTC] No.44383593[source]▶
This makes an assumption that a bunch of companies are maintaining their own forks of MIT software with bug fixes and features and not giving it back.

I find that hard to believe.

replies(5): >>44383803 #>>44384019 #>>44385553 #>>44386007 #>>44386138 #
canyp ◴[26 Jun 25 02:47 UTC] No.44383803[source]▶
Not really. A company that does not bother contributing to a liberally-licensed project will 100% avoid GPL software like the plague. In either case, they won't contribute. In the latter case, they don't get to free-ride like a parasite.
replies(2): >>44384552 #>>44384660 #
ninjin ◴[26 Jun 25 05:54 UTC] No.44384552[source]▶
It is reasonable to assume that this is true. But an equally effective way other than making your license unpalatable to them, is just to say no and state clearly: "Patches or GTFO". Also, have a homepage to link with your (hefty?) consulting rates?

I have mentioned this in the past, but there was this weird shift in culture just after 2000 where increasingly open source projects were made to please their users, whether they were corporate or not, and "your project is your CV" became how their maintainers would view their projects. It does not have to be this way and we should (like it seems to be the case with libxml2) maybe try to fix this culture?

replies(1): >>44385597 #
1. tzs ◴[26 Jun 25 09:14 UTC] No.44385597[source]▶
> It is reasonable to assume that this is true. But an equally effective way other than making your license unpalatable to them, is just to say no and state clearly: "Patches or GTFO". Also, have a homepage to link with your (hefty?) consulting rates?

That's fine for feature requests, but the issue in the present case is bug reports.

replies(1): >>44386793 #
2. ninjin ◴[26 Jun 25 12:33 UTC] No.44386793[source]▶
I fail to see how that is different. Ultimately, you have released a piece of software into the wild with a clause stating: "The software is provided 'as is' and the author disclaims all warranties with regard to this software including all implied warranties of merchantability and fitness". Thus, it is purely cultural that somehow others and yourself expect you to cancel your family time on a Saturday night solely because an issue has been found in a piece of software you have given away for free. This "value add" is wearing people out and if we want this expectation to remain, maybe it is time for those profiting or those with a monopoly on violence to explore ways to support those that kindly provide free labour like this?
replies(1): >>44390051 #
3. tzs ◴[26 Jun 25 18:36 UTC] No.44390051[source]▶
> I fail to see how that is different.

A feature request is for something new. A bug report is reporting an error in the already released and distributed software. Here is why that is relevant.

> Ultimately, you have released a piece of software into the wild with a clause stating: "The software is provided 'as is' and the author disclaims all warranties with regard to this software including all implied warranties of merchantability and fitness".

When there is a bug in that released software the 'as is' is not the 'as is' that the developer intended. Probably 99% of free software developers would like to be informed about this, especially if it is software that they are continuing to develop and distribute.

> Thus, it is purely cultural that somehow others and yourself expect you to cancel your family time on a Saturday night solely because an issue has been found in a piece of software you have given away for free

Huh? If I report a bug on a Saturday night (to a free software project or a proprietary project) I expect that someone will look at the report during the normal hours when they look at bug reports and if they decide it is something that needs fixing the work will be scheduled the same way they schedule work to fix bugs that their own testing reveals.