Do patches need to be open source?

[Ras]

Why, not all the library functions SF uses are GPLed? When you compile SF for Windows linker links kernel32.dll. AFAIK kernel32.dll is proprietary.

See paragraph 1 of the GPL where the term "source code" is defined and contrasted to system libraries:

The "System Libraries" of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A "Major Component", in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.

The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries

[syzygy]

Taking advantage of this thread I would like to know your opinion of this hypothetical scene:
Houdini or Komodo (examples), have access to Syzygy, are closed source and do not show that part of the code either.
Let's say they decide to use the derived and named Fathom code that has been given a GPL.
How to do this, a closed code and what they would do, a link to the github and fixed.

In my view linking to a GPL'd Fathom library dynamically does not require the linking program to be GPL.

The FSF seems to have a different view: https://www.gnu.org/licenses/gpl-faq.ht ... braryIsGPL:

Yes, because the program actually links to the library. As such, the terms of the GPL apply to the entire combination. The software modules that link with the library may be under various GPL compatible licenses, but the work as a whole must be licensed under the GPL.

I think they're right if they are talking about a statically linked executable. But I doubt that the GPL forbids you from distributing a program that, when executed, happens to link to and call functions in a non-GPL library.

In principle a license could probably say "you can modify this code or include the code in another program and distribute the result, but not if that resulting program does X, Y or Z". Whether such conditions are valid might differ from country to country. But it seems the GPLv3 only forbids distributing ("conveying") the modified program if you do not license "the entire work, as a whole" under the GPLv3.

How should I understand that? What if my modified program does not yet compile? Does it then not qualify as "the entire work"? Would it be a GPL violation to publish the modified code on github?

If I implement some calls to an API, does the "entire work" then become the modified program plus any library that implements the API? What if there are GPL implementations of the API and non-GPL implementations? This is confusing!

I have confused myself here.

I was thinking of the case where the program is GPL and the library is non-GPL. In that case, there is an argument based on that "license the entire work" requirement that the library has to be GPL if the program is GPL. This argument exists, because if the program is GPL, you cannot help that the GPL is in play and you will have to obey it to avoid copyright violations. But the question is then still what the GPLv3 actually requires and whether this "entire work" concept makes any sense.

But your question was different! You are asking about a non-GPL program linking to a GPL library. This is much easier.

As long as the program does not contain any GPL code, the GPL does not come into play. It's as easy as that. There is no way to make a claim based on the GPL if there is no GPL code in the first place. (It only gets tricky once you start to distribute the non-GPL program together with the GPL library.)

[Ras]

And in fact it is 100% certain that if some code does not include any GPL code, the GPL is simply irrelevant to it.

True, you could distribute the closed library in itself. However, you could not distribute a modified Stockfish version that uses this library. The GPL is quite explicit here in that dynamic linking does not circumvent the GPL.

However, the user himself could of course modify Stockfish to use that library, provided that the user does not distribute the modified Stockfish version.

[syzygy]

So this is just complete nonsense:
https://www.gnu.org/licenses/gpl-faq.ht ... ernelLinux

Does distributing a nonfree driver meant to link with the kernel Linux violate the GPL?

Linux (the kernel in the GNU/Linux operating system) is distributed under GNU GPL version 2. Does distributing a nonfree driver meant to link with Linux violate the GPL?

Yes, this is a violation, because effectively this makes a larger combined work. The fact that the user is expected to put the pieces together does not really change anything.

Each contributor to Linux who holds copyright on a substantial part of the code can enforce the GPL and we encourage each of them to take action against those distributing nonfree Linux-drivers.

No, a nonfree driver meant to link with the Linux kernel cannot possibly violate the GPL unless the driver itself contains GPL code.

[Ras]

No, a nonfree driver meant to link with the Linux kernel cannot possibly violate the GPL unless the driver itself contains GPL code.

The driver in itself not, that is correct. But the resulting whole work can. That's why in Linux distros, you have a separate repo for tainted stuff so that it is the user himself who does the combination and not the distro maintainer.

[syzygy]

And in fact it is 100% certain that if some code does not include any GPL code, the GPL is simply irrelevant to it.

True, you could distribute the closed library in itself. However, you could not distribute a modified Stockfish version that uses this library. The GPL is quite explicit here in that dynamic linking does not circumvent the GPL.

However, the user himself could of course modify Stockfish to use that library, provided that the user does not distribute the modified Stockfish version.

But I think it's still fine. I see no reason why some library that maybe does not even exist or that may not be uniquely identifiable would somehow become part of "the entire work".

Maybe I have an advanced proprietary version of the library that I sell for good money and a toy version that I give away for free including the GPL'd source. Would the fact that the proprietary version exists suddenly change the "entire work" that has to be licensed under the GPL? What if that proprietary version is not even written by me but by someone else?

Say Stockfish is linking to GPL'd Fathom. Now someone releases a proprietary library that is somehow better but offers the same API. Stockfish can no longer be distributed unless that new library is GPL'd?

[syzygy]

No, a nonfree driver meant to link with the Linux kernel cannot possibly violate the GPL unless the driver itself contains GPL code.

The driver in itself not, that is correct. But the resulting whole work can. That's why in Linux distros, you have a separate repo for tainted stuff so that it is the user himself who does the combination and not the distro maintainer.

But the FSF's FAQ is clearly referring to the driver itself there.

The resulting whole work is indeed a different matter, but not a very clear-cut one.

I think in practice the Linux developers simply allow non-binary drivers, which they can do as copyright holders, so there is no problem. (I'm not entirely sure what the policy on this is.)

I think the tainting is done mostly for filtering out bug reports from systems running drivers that are outside the control of the kernel developers.

[Ras]

But I think it's still fine. I see no reason why some library that maybe does not even exist or that may not be uniquely identifiable would somehow become part of "the entire work".

Because it's dynamically linked AND shares data structures. This is exactly what the GPL defines, and that is part of the point of the GPL.

Maybe I have an advanced proprietary version of the library that I sell for good money and a toy version that I give away for free including the GPL'd source.

You can sell GPL'ed software, too.

Would the fact that the proprietary version exists suddenly change the "entire work" that has to be licensed under the GPL?

It doesn't change it. It has always been that way.

What if that proprietary version is not even written by me but by someone else?

Then he has the same problem. The point of the GPL is to prevent people from taking free SW, tacking proprietary stuff on top of it and making it non-free. Dynamic linking is not exempted under the GPL. Authors use the GPL to explicitely prevent that kind of circumventing. If they had wanted to allow that, they could have chosen e.g. BSD or MIT instead.

Stockfish can no longer be distributed unless that new library is GPL'd?

Stockfish can, of course, but the library designed to run with Stockfish can't. And if there is only the closed lib, then the modified Stockfish version can't be distributed either - except by the authors who can chose dual-licencing, of course.

[Ras]

But the FSF's FAQ is clearly referring to the driver itself there.

Yes, but the perspective is that the "whole work" is distributed, and that would be a complete Linux. Plus that the driver ABI of Linux is not stable, but for a certain kernel version, it exists.

[Ras]

However, the question is whether the "whole work" part of the GPL would uphold in court. Nobody will know until this actually happens.

While the GPL has been successfully tested in court many times, these were always clear cases where a binary was distributed that contained GPL'ed software, and where the source was withheld.