Hacker News Reader

I quite agree here, but to go a step further here:

Lots of people express this fear that BSD-licensing of components will lead to a world where all the big proprietary software just locks everything down. But if you actually work with large software, you end up finding out that it's actually a lot of work to maintain your own fork, and so you start pushing to get more things upstreamed. Because, after all, if your code is private, it's your task to fix it if somebody breaks it, but if it's upstreamed, it's their task to do it.

An interesting datapoint is LLVM/Clang, where, yes, lots of companies have their own proprietary forks of Clang. But for the most part, those companies still upstream gobs of stuff: most of the biggest contributors to the project are the people with the proprietary forks. Furthermore, as I understand it, basically everybody relying on EDG has, or is in the process of, worked to move off of it into Clang. Which, if EDG dies, means that the permissively-license Clang has done more to kill off proprietary compilers than copyleft-licensed GCC has.

The best defense against proprietary software is to make it too expensive for proprietary software to compete, and using a permissive license means you can trick the companies making proprietary software into helping you do that.

> An interesting datapoint is LLVM/Clang

It's also an example of the GPL not preventing corporations from building (and releasing under a more permissive license) non-GPL software.

Before Apple built Clang, they made a GCC plugin[0] which dumped the AST from the GCC frontend, and fed it into the LLVM backend. Sure, they published the source of their GCC modifications under the GPL, but that was nothing compared to the entirely novel backend, which was released under a far more permissive license.

Meanwhile, Stallman handcuffed GNU projects like Emacs for years[1] by refusing to expose GCC's AST in an effort to prevent something like this from happening.

[0]https://dragonegg.llvm.org

[1]https://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00...

> Before Apple built Clang, they made a GCC plugin[0] which dumped the AST from the GCC frontend, and fed it into the LLVM backend.

But they didn't! Dragonegg is a GCC plugin, which didn't exist when work started on Clang--GCC plugins date to GCC 4.5, released in 2010, which is the same year that Clang became self-hosting.

The timeline is rather like this: LLVM originally relied on a hacked-up version of gcc 4.2 called llvm-gcc to create LLVM IR from source code. When GCC added support for plugins, there was the attempt to move that frontend to a more reliable framework, and that was Dragonegg. As far as I'm aware, Apple never contributed to the Dragonegg project itself. Dragonegg didn't last that long; by 2014, the project was completely dead. And for most of its life, the biggest interest in Dragonegg was to have some modicum of support for Fortran.

> Meanwhile, Stallman handcuffed GNU projects like Emacs for years[1] by refusing to expose GCC's AST in an effort to prevent something like this from happening.

By the time of that message, RMS's worst nightmare had come true with Dragonegg... only for Dragonegg to have already died due to a lack of demand for it.

You're right, I got Dragonegg mixed up with llvm-gcc. But my point stands – the GPL was completely ineffective at preventing someone from using it to bootstrap a new compiler infrastructure under a more permissive license.

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.

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.

What he said:

> the GPL has led to fairly noticeable increase in the amount of proprietary software in the world

What he did:

> opening up our core source code was never an option.

It's companies that decide that open sourcing their software is 'never an option'–even the LZO compression part of it–that lead to a 'noticeable increase in the amount of proprietary software in the world'. They are just using the GPL bogeyman as a thin excuse for their own decisions.

His insinuation that if you just MIT your code so that big tech companies can use it, and if they end up needing help with it they might even hire you, seems super sleazy and borderline exploitive especially in the current job market.

Yes there exists now more proprietary software but you wanted to create proprietary software with it anyway so this kind of is what parent was talking about that some people don't want.

Partly related. Would you have paid if the project had offered a paid non GPL licence?

We (engineers) actually wanted to for another GPL’d project! But because they didn’t have a CLA, the lawyers wouldn’t sign off on it — they decided that the main/current maintainer didn’t have the rights to relicense it for us.

We probably would’ve for LZO too; not sure why that fell through.

> because they didn’t have a CLA, the lawyers wouldn’t sign off on it — they decided that the main/current maintainer didn’t have the rights to relicense it for us.

How would the legal argument be any different for MIT/etc. licensed software in that case? Would the lawyers sign off on using MIT-licensed software without a CLA? Wouldn't they make the argument that the provenance of the software and therefore its licensing is not solid? Seems like the only thing that matters is who has the right to offer a license to the software, not what the license is.

They just wanted the CLA to support the (paid) relicensing.

I think the reasoning (as it was explained to me) was that when people made their original contributions, they were agreeing to the license at that time (in this case GPL, but for other projects MIT). But the other contributors never agreed that the main maintainer could relicense their contributions for a fee.

The upshot was that we went with an in-house fully-proprietary alternative. More expensive, probably lower quality.

I've seen this personally. Google does not allow GPL code to imported into the massive monorepo. If I needed a library and the only good OSS option was GPL, I'd write it from scratch instead. I'd also usually not open source those things if this wasn't part of an already open source project, because it wasn't worth the effort.