Hacker News Reader

Comment by kevin_thibedeau | Hacker News Reader

The license on a linker shouldn't matter. It isn't injecting copyrighted code and there's already precedent for excepting trivial boilerplate in the GPL ecosystem so nothing in the generated binary should be affected by a copyleft license on the tooling. AGPL would only restrict deploying a privately modified linker via a network service which isn't a realistic scenario for a basic dev tool.

View on HN

While that is true, it requires a very specific understanding of both intellectual property law and the inner workings of development tooling that is pretty rare in practice. As such, companies are generally conservative in such decisions. Most organizations have a single list of licenses allowed for use rather than getting into specific use cases for specific licenses. These types of environments will generally limit uptake of copyleft tools.

All that said, I'm not convinced the licensing is the issue here (although I wish them the best). We are in a world that has grown accustom to free development tools and building a commercially viable business in tooling is incredibly difficult. I'm always amazed by how many developers I know who make a living by creating software yet are unwilling to pay for software themselves.

All of those companies have no issues using `ld` right? Binutils is GPL and has always been. Seems like a direct analogy.

Some companies completely ban AGPL usage https://opensource.google/documentation/reference/using/agpl...

AGPL and GPL are quite different beasts

> Most organizations have a single list of licenses allowed for use rather than getting into specific use cases for specific licenses.

Bullshit. Most organizations are absolutely fine with different ad-hoc licenses for various closed source software. Applying different standards to copyleft licenses is just due to FUD.

Ignoring the problem of convincing legal team that linker license doesn't affect it's output, there is the problem of including the linker in prepackaged toolchains - like the ones part of Visual Studio, Xcode, Android studio or embedded toolchains provided by hardware vendors. In some of those cases you might still get away with AGPL, but it will require putting in some effort to comply with license since in those cases the linker itself is redistributed. It's no secret that Apple is avoiding GPL as much as they can, with many of commandline tools they provide either being BSD versions or very old GPL2 versions.

> AGPL would only restrict deploying a privately modified linker via a network service which isn't a realistic scenario for a basic dev tool.

Interacting with linker over network service may sound weird, but it's not that uncommon. For example Unity offers Cloud build service for their engine which means indirectly interacting with Android and iOS toolchains. All major cloud providers are making solutions where the development tools and libraries are tightly integrated with their cloud service in attempts to make it harder migrating your project away from them. Regular CI/CD service providers are including the most popular development tools in their default environment, both to simplify the development process and also so that they can better cache them thus saving network costs and speeding up builds compared to each customer downloading the toolchain manually. There was also a period where multiple companies where pushing a remote dev environment as a solution to minimize the hassle of having each developer setup things locally thus improving onboarding speed, ensuring everyone is working in the same environment and also simplifying work for company wide IT management.

In many of those cases there might be 2 or even 3 companies repackaging and redistributing between the original software (linker) author and final user (programmer).

Even in the land of open source things aren't that simple. Not sure if it's still a thing but there was a period when FreeBSD was trying to remove GPL from it's base packages.

Third party CI builds aren't distributed to anyone. Even if the compiled binary was subject to GPL rules, the binary will almost never exit the CI server where it was built so copyleft protection won't be invoked.

You can use modified GPL code to your heart's content in a corporate setting. As all your coworkers are part of one legal entity, private use within the organization is not distribution per the terms of GPL. You have to distribute a binary to someone who can make a claim under the terms of the license before copyleft is activated. Furthermore, you only ever have to disclose source to someone with possession of a derived binary.

I was talking about the case where linker is the software and user is the developer performing linking. And MOLD was previously AGPL licensed, meaning that having access to binary isn't required, it's sufficient to interact with the software over network for copyleft to activate.

Let's imagine Google wanted to include Mold in Android sdk, and CI service company (like Travis or Github with their Actions) want to include Android SDK in their VM images. I would consider using of such CI service for building android app interacting with the linker software over network. Meaning everyone in the middle (Google and CI service) has to deal with license requirements.

The main purpose of using AGPL as the original license is to force companies that have a blanket-ban on AGPL to buy a commercial license or just buy the entire project, as told by the author.

https://gist.github.com/lleyton/9c0b75d065f37333ea9851b6cad1...

It did not workout, so they're switching to MIT.

Good luck convincing corporate lawyers that the license terms don't matter since we're just using it for linking. I don't know many (any?) that would risk it.

Reply on news.ycombinator.com