Hacker News Reader

The moment someone mention dynamic linking and GPL is the point where one need to think about the law rather than computer technology. Dynamic linking does not exist in the definition of derivative work, and the legal concept is only used by the FSF as a public guideline on where to draw the line (and thus when they will enforce the license).

What you will have to ask is, what will a non-technical judge think is one work with different labeled parts, or two separated works that are interacting. Questions like "If I remove one, do I still have a something that make sense to call a work?", "how was it created and what was the intention of the creator", "how would a end-user perceive the result", and in many jurisdictions, "what is the industry standard" (judges has shown a tendency to avoid decision which would cause disruption in the market).

> let's say a company decides to make a proprietary fork of a GPL software application

If they intentionally trying to go against the wishes of the author, its likely infringing the license regardless if you use technology X or technology Y.

The 'wishes of the author' are not spelled out in clear terms in the GPL, that's the issue. For example, if I create a music production application, and use SoX to create audio spectrograms, what level of integration with SoX is permitted for a proprietary application? Stealing the code and putting it in your own codebase would obviously be a big no-no, but what if you used Sox in the form of a .dll/.so? The GPL code wouldn't be compiled alongside proprietary code, but it would be required for a non-core feature of the application to function.

This is the type of vagueness that a future GPL revision should seek to address, by refining what is meant by 'dynamic linking'.

Going through the questions above, the first answer seems clearly on the side of being a separate work, but the second one brings us to a big question: Is the SoX integration the only method for creating audio spectrograms, and is it a feature being presented as a part of the application? Is there maybe emails by the developers that talk about the feature as part of the application, or is there emails showing that the application is only being made compatible with SoX? What is included in advertisements, and are customers of the proprietary application perceiving the application as one work being compatible with SoX?

Law is never certain, but I suspect the answer to the thought experiment is that the application is creating a derivative work. It could however be that the application is only providing compatibility with SoX, among many other similar programs installed on customers machine, in which case it might be fair use or maybe not a derivative work at all. It depends on the details.

A similar thought experiment is to ask why no large company has tried to challenge the guideline of dynamic linking as line in the sand regarding derivative work. How rare would it be that a company want to include non-core optional features in their proprietary products that need to be dynamically linked rather than using inter-process communication, and they want to go to court about it?

No; that's the purpose of the LGPL. See this link and the section below it:

https://www.gnu.org/licenses/gpl-faq.en.html#SystemLibraryEx...

Yes, LGPL makes this clearer, but that doesn't address the broad range of interpretation in the GPL.

Consider that the purpose of using the GPL is to ensure that the users of software have the right to examine and change the software. It also ensures that those rights cannot be removed.

That would be the "broad range of interpretation".

If that is NOT compatible with your goals, do not use the GPL. Also, do not include any software using the GPL. For example, embedded systems using BusyBox.

However, adopting the GPL (and those user rights) should give you an advantage -- code that works and provides a time to market advantage.

> "If that is NOT compatible with your goals, do not use the GPL. Also, do not include any software using the GPL. For example, embedded systems using BusyBox.

However, adopting the GPL (and those user rights) should give you an advantage -- code that works and provides a time to market advantage."

In its current state, I have no intention to use the GPL for anything, even though I agree with the principals behind it (of ensuring that the code for free/libre software stays accessible to the public).

If you'd be happy to see GPL-style licences become less popular/relevant, by all means ignore the issues people have with them, but if you'd rather see their popularity grow then perhaps it's worth discussing further, especially as the main complaint is over the licence clarity, not something that has to undermine the goals of the FSF.

> If you'd be happy to see GPL-style licences become less popular/relevant, by all means ignore the issues people have with them.

If compromising the core principles that make the GPL and copyleft software special is what's necessary to get people to use it, then we've already lost.

I honestly don't see any lack of clarity in the license unless you're actively trying to find a way to make proprietary software that utilizes GPL components. The courts might not agree with Stallman about the word derivative but the spirit of the license is clear and simple. If someone releases their work under the GPL and you use it in yours, then the combined work must be Free Software.

I'm not talking specifically on the dynamic linking issue. My point is that the GPL cannot force you to publish your source code, but if you break the terms you can lose the license to distribute GPL code that isn't yours.

As regards your example, I don't think the GPLv3 permits that, so if a company tries to circumvent the GPL using that approach, it would probably lose the rights to distribute the GPL software application.