Do patches need to be open source?

[Ovyron]

Suppose I implement some Learning Algorithm in Stockfish, but I don't want to open the source, because I want to keep my Algorithm secret.

Apparently, releasing the engine would be against the Licence Agreement.

So what if I release some other exe that when it's run, it patches Stockfish and makes it have learning?

Note this isn't very different from releasing a closed source Stockfish, because I'd be giving people the option of turning their Stockfishes into learning Stockfishes at home, so that they end up with a closed source Stockfish, just as if I gave them to them on the first place.

But doing it this way would be fine?

[hgm]

Seems to me lawyers could grow rich arguing over this...

[elcabesa]

I think that it's against GPL v3 licence, but I'm not a lawyer.

unless you do some modification for your purpose and use them at your home I think they must be opensource.

[Rodolfo Leoni]

Just my opinion. If your patch is a direct modification of SF code and it results in a modified SF binary, than it should be open source. But if you modify SF source and binary to launch an external application which handles all the learning stuff, then SF source (including the code lines for launching the application) should remain open source, but you can keep your external exe closed source.

Seems complicated to do....

[mroh]

So what if I release some other exe that when it's run, it patches Stockfish and makes it have learning?

I think this would be against GPL:

If you patch SF on the source level, its clear -> release your source.
If you "patch" SF on the binary level and it would have some kind of modules or dynamic linking functionality, I am not so sure (e.g. closed source linux kernel modules are legal...).
But as it doesn't have such a thing, I think, it would be against GPL to just change an object file... or so

Even for the other way around (building a shared lib from SF and link it to you bin), I think, you would need LGPL...

[Michael Sherwin]

If you add the ability to Stockfish to communicate through a pipe to your exe for example then start a fork of Stockfish where you release the source code of Stockfish but keep the source to your exe private.

Edit: The easiest way would be to write an adapter between a winboard protocol GUI and a modified Stockfish. You can keep your adapter code private.

[Milos]

If you patch SF on the source level, its clear -> release your source.
If you "patch" SF on the binary level and it would have some kind of modules or dynamic linking functionality, I am not so sure (e.g. closed source linux kernel modules are legal...).
But as it doesn't have such a thing, I think, it would be against GPL to just change an object file... or so

Even for the other way around (building a shared lib from SF and link it to you bin), I think, you would need LGPL...

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.
Why not simply build a shared lib and call its functions from SF?

[mroh]

or maybe implement some new uci commands in SF so that the communication can be bidirectional (in a slow way).
The values for the options might come from your prg via stdin...

[mroh]

Why not simply build a shared lib and call its functions from SF?

I am not the license guru, but I guess nothing in SF code calls kernel32.dll directly, something in the glibc (or so) would do this and that has a LGPL license...

I would guess, "hiding" source by only showing its interface is a too simple "crack" for the GPL, considering its age... but I dont know.

[MikeB]

Suppose I implement some Learning Algorithm in Stockfish, but I don't want to open the source, because I want to keep my Algorithm secret.
...

You do know the whole point of being open source is to share. Now I understand why somebody PM with a question about who you are - it went WAY over my head at the time this AM but I get it now.for sure Thank you Carl! lol