Hacker News Reader

Comment by PaulDavisThe1st | Hacker News Reader

So, the company wants us to trust them - trust that they will not take advantage off the BSDL to do things the GPL would prohibit them from doing. And we're supposed to trust them because doing so means that there would be more "hands on deck" (e.g. working on the now-canonical LZO compression library that everyone uses because it is BSDL).

Sorry, trust has been broken too often in these scenarios, and the benefits of lots more people working on the same library are not entirely clear.

I understand that many companies don't want to be a part of the pool of software licensed under the GPL - that is their right. But don't try to spin this "if only BSDL was the common one, there'd be a much bigger utilization of a different pool of software". That might even be true, but it would come with the caveat that tivoization would always be an option, which for some of us is something more significant.

View on HN

It's not about trust, it's about the fact that 10% of something, or even the chance of 10% of something, is better than guaranteed 100% of nothing. You're not being taken advantage of if someone uses a BSD license the way it's supposed to be used.

If I put two choices in front of someone, the binary option of copyleft vs proprietary and they'll always go proprietary, or I give them something permissive and there's at least the chance they contribute back, the second option is strictly better. It's sort of the equivalent of having a wealth tax that raises no revenue, I'd rather have you here contribute something than move abroad and get nothing, even if the benefit is more indirect

It's not 100% of nothing. If the choice is proprietary because they legally can't freeload off FOSS due to it being GPL, the company in question still needs to pay a developer to write the alternative. That's still a positive, and nothing lost. Permissive licenses just grant to freedom to freeload, nothing more.

I don’t think it would’ve in our case, at least. I actually quite like our OSS policy: basically, we don’t want to be in the business of maintaining forks, so all changes should try to get upstreamed if at all possible. It‘s good client service as well: when our clients ask about the libraries we use, we’d much rather be able to tell them “the latest public version” than “here’s our fork”.

We also want to engage with and donate to the projects we use, mostly out of risk management: if they go unmaintained that’s bad for us.

If you truly want to upstream changes to libraries then I don’t see why lgpl code isn’t a choice for you. Use it in your proprietary code if you want, no changes no foul. If you make changes you just need to upstream or make the source available.

> If you truly want to upstream changes to libraries then I don’t see why lgpl code isn’t a choice for you.

Read LGPL a little more carefully. LGPL requires you to use it in a particular manner that lets any user swap out your version for their version, which basically means you're only allowed to dynamically link it as a shared library. Even if you make no changes to the library!

> that lets any user swap out your version for their version, which basically means you're only allowed to dynamically link it as a shared library

I had thought that the dynamic linking requirement was the only option according to the licence, but apparently not. According to 6.a. of v2 and 4.d.0. of v3 of the LGPL, it would be enough to give the user access to the source/object code of the main application and the compilation scripts under non-open-source terms, so that they can recompile and statically link it against their own version of the library.

I think the wealth tax analogy is fantastic because some people genuinely hate rich people so much that they’d rather they left the country.

Reply on news.ycombinator.com