Do patches need to be open source?

Discussion of anything and everything relating to chess playing software and machines.

Moderators: hgm, Rebel, chrisw

Milos
Posts: 4190
Joined: Wed Nov 25, 2009 1:47 am

Re: Do patches need to be open source?

Post by Milos »

mroh wrote:
Milos wrote: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...
You see, but that's a chicken and egg problem, how can glibc be LGPL when it is calling a proprietary function?
mroh
Posts: 29
Joined: Thu Nov 02, 2017 6:51 am
Location: Germany

Re: Do patches need to be open source?

Post by mroh »

Milos wrote: You see, but that's a chicken and egg problem, how can glibc be LGPL when it is calling a proprietary function?
No, thats why its LGPL, and it seems logical for me:
You can link against LGPL code (w/o releasing code), so why shouldn't the LGPL code call a binary?
User avatar
hgm
Posts: 27787
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: Do patches need to be open source?

Post by hgm »

I am pretty sure the GPL covers linking to a dynamic library. If not it would be completely meaningless. The 'kernel32.dll problem' is addressed by a requirement that the stuff you link to is easily obtainable. That requirement is fulfilled if it is open source AND the building tools are easily obtainable. (It would also be a GPL violation to link to an object file produced from a 'open source' in a language you designed yourself, which is only of use to anyone if they buy your closed-source compiler for it.) OR when the binary is commonly available to people for other reasons than running the patched software (even if this requires buyig it for a reasonable price). Kernel32.dll falls in the latter category: it is a default component of Windows, and people that need to call it from a GPL'ed code will always already have it. So you are allowed to add calls to kernel32.dll to GPL'ed software without the requirement to publish the source code of kernel32.dll (which would of course be a violation of MicroSoft copyrights even if you could obtain it).

Similarly, if you write a patch that would require MSVC as a building tool, this would not require you to provide the source code of MSVC, or make the binary of it available for free. People developing software for windows can reasonably be expected to have that.

The LGPL is not there to allow the thus-licenced software to call closed-source stuff, but works in the other direction: closed-source sofware is allowed to call LGPL libraries.
User avatar
phhnguyen
Posts: 1434
Joined: Wed Apr 21, 2010 4:58 am
Location: Australia
Full name: Nguyen Hong Pham

Re: Do patches need to be open source?

Post by phhnguyen »

I think there are two legal ways (but you may need to consult a layer first ;) ) :

1) Write your patches as UCI/xboard adapters to connect with a chess engine

2) Create a new branch of for that chess engine in which you add some code as a special gate to connect an extra program / lib. Your hidden code will be written as an extra program / lib for that gate. You may submit the new branch (not the program/lib) or fork all code to your own repository + new branch.

The best you contribute for open source communities. If you have really good reasons you may go ahead and contribute back later.

As an open source developer I am OK myself for any fair use of my code.
Dann Corbit
Posts: 12537
Joined: Wed Mar 08, 2006 8:57 pm
Location: Redmond, WA USA

Re: Do patches need to be open source?

Post by Dann Corbit »

Why try to circumvent right and wrong?

If you want to use a public project, then follow the public project rules.

If you want to release the code, then follow the rules.

You can always keep your binary for yourself and you did not break any rules.

We can live without it.

You might be able to figure out an end around. And you might find a legal way to distribute your changes to the masses. Some will praise you for that if it happens, but you will become a huge stink to others.
Taking ideas is not a vice, it is a virtue. We have another word for this. It is called learning.
But sharing ideas is an even greater virtue. We have another word for this. It is called teaching.
User avatar
velmarin
Posts: 1600
Joined: Mon Feb 21, 2011 9:48 am

Re: Do patches need to be open source?

Post by velmarin »

There's an example like this, as far as I know.
I always find it strange, even though I suppose I had private agreements.

It's Buzz from Pradu Kanman.
http://www.pradu.us/old/Nov27_2008/Buzz/

Code: Select all

Here is the source code for some older version of Buzz released under GPL. It is intended to be an example program for new chess programmers. I might update it every now and then.
Download Opensource Buzz
In the downloaded version different definitions are read towards the version of Andrés Valverde that seems to give origin to Dirty

Code: Select all


#ifdef ANDRES_EVAL
//load Dll
//typedef int (__stdcall *importFunction)(int side, int alpha, int beta, int pieceList[2][16], int pieces[64], int color[64], int passed[2][8], int halfpassed[2][8], int doubled[2][8], int isolated[2][8], int backward[2][8]);
//typedef int (__stdcall *importFunction)(int side, int alpha, int beta, int pieceList[2][16], int pieces[64], int color[64]);
typedef int (__stdcall *importFunction)(int side, int alpha, int beta, int pieces[64], int color[64]);
typedef int (__stdcall *importInitFunction)(char* path, char* password, int cache_size);
importFunction dirtyeval=NULL;
importInitFunction InitDirtyDll=NULL;
ect, ect
There is we have the load of a DLL with part of the evaluation function.
Milos
Posts: 4190
Joined: Wed Nov 25, 2009 1:47 am

Re: Do patches need to be open source?

Post by Milos »

hgm wrote:OR when the binary is commonly available to people for other reasons than running the patched software (even if this requires buyig it for a reasonable price). Kernel32.dll falls in the latter category: it is a default component of Windows, and people that need to call it from a GPL'ed code will always already have it. So you are allowed to add calls to kernel32.dll to GPL'ed software without the requirement to publish the source code of kernel32.dll (which would of course be a violation of MicroSoft copyrights even if you could obtain it).
Well you can try to rationalize it as much as you like, but first you are wrong since that would mean cross-compiling is not allowed which is (so you compile it with calls to kernel32.dll but without actually having it), and second there is nothing in GPL regarding owning (or common availability of) a commercial binary (there is a part regarding system libraries as a part of OS but you don't have to own it for sure).
User avatar
Evert
Posts: 2929
Joined: Sat Jan 22, 2011 12:42 am
Location: NL

Re: Do patches need to be open source?

Post by Evert »

Ovyron wrote: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?
Doing it that way is reprehensible. You're not following the spirit of the license agreement, you're trying to wriggle out of it on a technicality. One that I'm pretty sure isn't going to fly.

Want to modify stockfish and keep the source closed? Fine, keep your program to yourself.
Want to release a program to the world and keep your code private? Fine, write your own engine.
It's really that simple.

Why do you want to keep your algorithm secret anyway? Most people who obsess over keeping their ideas/code secret don't actually have ideas/code that are worth keeping secret.
User avatar
hgm
Posts: 27787
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: Do patches need to be open source?

Post by hgm »

Milos wrote:Well you can try to rationalize it as much as you like, but first you are wrong since that would mean cross-compiling is not allowed
???

How the heck could you have concluded that from anything I wrote? :shock: You mistake 'must be commonly available' for 'the person releasing the code must have it'?
which is (so you compile it with calls to kernel32.dll but without actually having it), and second there is nothing in GPL regarding owning (or common availability of) a commercial binary (there is a part regarding system libraries as a part of OS but you don't have to own it for sure).
syzygy
Posts: 5557
Joined: Tue Feb 28, 2012 11:56 pm

Re: Do patches need to be open source?

Post by syzygy »

Ovyron wrote: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?
As long as your exe contains no Stockfish code, it cannot infringe the copyright on Stockfish and so the GPL does not apply.

But it seems to me the idea will not work very well. If your exe patches the Stockfish source code, any user of your exe will be free to distribute that source code including your changes.

So you would have to make an exe that patches a particular Stockfish compile. But that is practically impossible to do. (It may be possible if your learning code has almost no interaction with the SF search code, but then you could as well implement learning in the GUI instead.)