4 ms·

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

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'.

belorn 10y ago
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?

belorn 10y ago

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?