Do patches need to be open source?

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

Moderators: hgm, Rebel, chrisw

syzygy
Posts: 5557
Joined: Tue Feb 28, 2012 11:56 pm

Re: Do patches need to be open source?

Post by syzygy »

velmarin wrote:
syzygy wrote:
velmarin wrote:That's not true, moreover, put something and immediately the opposite, they have gone to the literary world even.
I have not yet read anything that forbids not to do so, it is suggested, it is advised, ect.
If you are still asking about whether you can distribute an executable that contains GPL'd code without making available the full source code of that binary, then just read section 6 of the GPLv3:
6. Conveying Non-Source Forms.

You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways: (...)
Couldn't be much clearer, and this is certainly enforceable.
Sure, sure, it's not like that.
Pretty much all overwhelmed,


The zlib license has been approved by the Free Software Foundation (FSF) as a free software licence,[1] and by the Open Source Initiative (OSI) as an open source license.[2] It is compatible with the GNU General Public License.[1]

The license does not require source code to be made available if distributing binary code.[/code]
So? The zlib license is even less restrictive than the GPL.

This means that you can incorporate zlib code into a GPL program and release the thing under the GPL.

The same applies to my TB access code. It can be included in closed-source engines but also in Stockfish. Someone distributing Stockfish must also make available the SF source code including the TB code.
User avatar
velmarin
Posts: 1600
Joined: Mon Feb 21, 2011 9:48 am

Re: Do patches need to be open source?

Post by velmarin »

syzygy wrote: The same applies to my TB access code. It can be included in closed-source engines but also in Stockfish. Someone distributing Stockfish must also make available the SF source code including the TB code.
Not necessarily, your TB code could be in a dll or even a statically linked. lib.
There are already similar examples, Stockfish with TB lomonosov,
Comstock with TB Robbobasses and Stockfish with the TB gaviota.
syzygy
Posts: 5557
Joined: Tue Feb 28, 2012 11:56 pm

Re: Do patches need to be open source?

Post by syzygy »

velmarin wrote:
syzygy wrote:The same applies to my TB access code. It can be included in closed-source engines but also in Stockfish. Someone distributing Stockfish must also make available the SF source code including the TB code.
Not necessarily, your TB code could be in a dll or even a statically linked. lib.
There are already similar examples, Stockfish with TB lomonosov,
Comstock with TB Robbobasses and Stockfish with the TB gaviota.
You were asking about statically linked executables.
If my TB code is statically linked into a Stockfish executable (which it basically is), then that executable may only be distributed under the GPL (because Stockfish is GPL) and must then be accompanied by an offer to provide the full source for that executable under the GPL. The full source for that executable includes my TB code. But that's OK, since I allow everybody to distribute my TB code under the GPL or any other license they like.
User avatar
Ovyron
Posts: 4556
Joined: Tue Jul 03, 2007 4:30 am

Re: Do patches need to be open source?

Post by Ovyron »

syzygy wrote:
Ovyron wrote:This is circular reasoning.
But your reasoning is a non-starter to begin with, because there would not have been a constant stream of new developers contributing patches to SF had SF not been open source.
They would have, if Stockfish had a different Open Source Licence. GPL is just an option.

Note my claim is that Stockfish's development has been crippled by its licence, since people would have only contributed MORE by contributing closed source improvements that would have made it to the engine in the end.

The people contributing open source improvements wouldn't have diminished by a different licence, they would have increased by people looking at the behavior of closed source improvements and replicating it.

This is like DRM protection of software, the logic goes that if you stop people from pirating your software, people that would have pirated it would buy it instead. In practice, people that won't pay anything for software will not use it at all if no pirate version exists, people have decided to buy worthy sofware if the pirate version is useful to them (as their own unlimited version of "Trial version"), people have only known about some stuff because of their pirated distribution, and decided to buy (piracy working as free advertizement - those "DRM protection cracked before the project hit the stores!" news only increased sales). Any protection gets eventually broken (if it's worth it; The Sims 4's latest expansions have been so unpopular than nobody has cared to create pirate versions of them, so it turns out you can stop piracy by just releasing worthless software nobody cares to crack), and Rebel sales didn't decrease when its protecting mechanisms were removed.

The GPL works like that, and fears that a Licence with more freedom would have had less people producing open source patches is nonsensical.

And all of this is moot anyway, as Houdini proves. Before Ippolit, nobody thought anyone would go and disassemble an engine to release one of their own, because writing one from scratch and improving it to that level would have been easier (as engines like Andscacs or Fizbo later proved). But it happened and it was legal, and it was taken as a starting point to produce the next best thing behind Stockfish.

So Stockfish's Licence doesn't matter as someone could just disassemble a Stockfish binary to have a strong source to improve at the top, make some closed source improvements that make it go ahead of Stockfish, close the engine, change the name, and sell it, and perhaps Chessbase will contact them to sell it on their GUI, and competitors will create some "Aquarium Electric Boogaloo" commercial thing that includes the thing, and what did the Licence do anyway? Slowing down this process because you can't use the code directly and have to go to the dissassembly way?

One just wonders what would have happened if Glarung had started as a Public Domain project.
Last edited by Ovyron on Sat Feb 24, 2018 7:09 pm, edited 1 time in total.
Your beliefs create your reality, so be careful what you wish for.
syzygy
Posts: 5557
Joined: Tue Feb 28, 2012 11:56 pm

Re: Do patches need to be open source?

Post by syzygy »

A bit of Googling shows that all lawyers (as opposed to programmers) who have looked into this matter essentially share my view.

One example: Andrew Katz, GPL - the Linking Debate
The Free Software Foundation is Richard Staffman's baby and the guardian of the GPL, in all its forms. The FSF FAQ states very simply that any software linking to a library, either statically or dynamically, which is covered by GPL2 must itself be released under GPL2.

Luckily, the FSF is not a judicial body, and the GPL will, ultimately, be subject to interpretation in the courts of the relevant jurisdiction. The FSF FAQ is not a legally binding document.

Does linking an application dynamically to a GPL library render that application subject to the GPL?

No. In spite of the FSF's comments in their FAQ, linking a piece of software to GPL code dynamically does not render that application subject to the GPL. There are several reasons for this:

1. It is the end-user at run-time, and not the programmer who causes the application to interface with the DLL. It follows that the programmer cannot be in breach of copyright, as he has not undertaken the act which would be an alleged breach of the GPL.

2. The alleged act of infringement could take place after the creation of the application has been completed.

3. The applications calls to DLL may be equally applicable to a number of different DLLs each with consistent APIs all of which are under separate copyright ownership and which may be subject to different licensing terms, and it is the user's choice which DLL they wish to use.

Note that none of this reasoning even requires looking at the wording of the GPL itself: it is a consequence of the fact that the GPL, as a software licence only purports to deal with acts which would otherwise be a breach of copyright. It is the end-user, and not the programmer, who is undertaking those acts, and therefore the GPL has no impact on the programmer in these circumstances. For completeness, and from the end-user's perspective, the end-user is merely running the program: an act which is not restricted in any way by the GPL.
And about static linking:
My view is that that the answer to the question "Does linking an application statically to a GPL library render that application subject to the GPL?" is a somewhat more hesitant 'no': the application is not a derivative work of the library and the application as a whole does not have to be licensed under the GPL. If you distribute the resultant application, it's clear that you will be distributing GPL code: namely those parts of the application derived from the library, and you'll have to comply with the GPL to the extent that it attaches to those parts of the code. However, I'd argue that what you are distributing is a collective work, and not a derivative work and all the relevant definitions in the GPL refer to a 'work based on the Program' which is defined (in the GPL) as a derivative work as determined by applicable copyright law. We are on slightly shakier ground here.
So the author argues that static linking does not create a derivative work but a collective work. Since the GPLv2 requires full source code only to be provided for derivative works, it does not require full source code for statically linked binaries. That is, if the author is right that static linking creates merely a collective work and not a derivative work.

The GPLv3 has probably fixed this problem with static linking by requiring source code for the "entire work". If you distribute an executable file that includes GPL code, it seems safe to say that the "entire work" is at least the whole executable file.
A "collective work" is a work, such as a periodical issue, anthology, or encyclopedia, in which a number of contributions, constituting separate and independent works in themselves, are assembled into a collective whole.

A "derivative work" is a work based upon one or more preexisting works, such as a translation, musical arrangement ... art reproduction, abridgement, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole,represent an original work of authorship, is a "derivative work."
syzygy
Posts: 5557
Joined: Tue Feb 28, 2012 11:56 pm

Re: Do patches need to be open source?

Post by syzygy »

Ovyron wrote:So Stockfish's Licence doesn't matter as someone could just disassemble a Stockfish binary to have a strong source to improve at the top, make some closed source improvements that make it go ahead of Stockfish, close the engine, change the name, and sell it, and perhaps Chessbase will contact them to sell it on their GUI, and competitors will create some "Aquarium Electric Boogaloo" commercial thing that includes the thing, and what did the Licence do anyway? Slowing down this process because you can't use the code directly and have to go to the dissassembly way?
You seem to have no understanding of programming.

It seems that in your alternative reality SF would have to be disassembled to do work on it. And you think that would not deter developers from contributing to SF.
User avatar
velmarin
Posts: 1600
Joined: Mon Feb 21, 2011 9:48 am

Re: Do patches need to be open source?

Post by velmarin »

What is clear to me is that in this world of chess programming," the trees don't let them see the forest".
Suppose an author decides to create a routine for a game, this creates a visual effect when called,
the name "impact", decides to save its code and makes a library called impact. lib, easy to run for example with a single routine.
Now to test it and make it known, he creates an open source game program under the GPL, he releases it with its statically linked. lib impact.
Of course include impact. lib in the final package
And you say it's not legal........
Uri Blass
Posts: 10268
Joined: Thu Mar 09, 2006 12:37 am
Location: Tel-Aviv Israel

Re: Do patches need to be open source?

Post by Uri Blass »

Ovyron wrote:
syzygy wrote:
Ovyron wrote:This is circular reasoning.
But your reasoning is a non-starter to begin with, because there would not have been a constant stream of new developers contributing patches to SF had SF not been open source.
They would have, if Stockfish had a different Open Source Licence. GPL is just an option.

Note my claim is that Stockfish's development has been crippled by its licence, since people would have only contributed MORE by contributing closed source improvements that would have made it to the engine in the end.

The people contributing open source improvements wouldn't have diminished by a different licence, they would have increased by people looking at the behavior of closed source improvements and replicating it.

This is like DRM protection of software, the logic goes that if you stop people from pirating your software, people that would have pirated it would buy it instead. In practice, people that won't pay anything for software will not use it at all if no pirate version exists, people have decided to buy worthy sofware if the pirate version is useful to them (as their own unlimited version of "Trial version"), people have only known about some stuff because of their pirated distribution, and decided to buy (piracy working as free advertizement - those "DRM protection cracked before the project hit the stores!" news only increased sales). Any protection gets eventually broken (if it's worth it; The Sims 4's latest expansions have been so unpopular than nobody has cared to create pirate versions of them, so it turns out you can stop piracy by just releasing worthless software nobody cares to crack), and Rebel sales didn't decrease when its protecting mechanisms were removed.

The GPL works like that, and fears that a Licence with more freedom would have had less people producing open source patches is nonsensical.

And all of this is moot anyway, as Houdini proves. Before Ippolit, nobody thought anyone would go and disassemble an engine to release one of their own, because writing one from scratch and improving it to that level would have been easier (as engines like Andscacs or Fizbo later proved). But it happened and it was legal, and it was taken as a starting point to produce the next best thing behind Stockfish.

So Stockfish's Licence doesn't matter as someone could just disassemble a Stockfish binary to have a strong source to improve at the top, make some closed source improvements that make it go ahead of Stockfish, close the engine, change the name, and sell it, and perhaps Chessbase will contact them to sell it on their GUI, and competitors will create some "Aquarium Electric Boogaloo" commercial thing that includes the thing, and what did the Licence do anyway? Slowing down this process because you can't use the code directly and have to go to the dissassembly way?

One just wonders what would have happened if Glarung had started as a Public Domain project.
I think that it could be possible to have something in the middle between GPL and Public domain project.

What about a Licence that allow you to close the source for a limited time.
It means that you can change the program and sell your changes but after 2 years you need to release the code as open source?

Note that I do not know if this type of license could be better for stockfish's improvement or worse.
User avatar
Ovyron
Posts: 4556
Joined: Tue Jul 03, 2007 4:30 am

Re: Do patches need to be open source?

Post by Ovyron »

Uri Blass wrote:What about a Licence that allow you to close the source for a limited time.
It means that you can change the program and sell your changes but after 2 years you need to release the code as open source?
I like the idea, though probably 2 years is a too short time frame, considering Rybka 4 was still selling relatively well 4 years after its release, I believe. And who knows if even people are still buying Rybka 3 for this day; Vas had planned to eventually make Rybka 3 and Rybka 4 freeware like he did with 2.3.2a and earlier versions. But it would be stupid if people is still buying the thing, right?
Your beliefs create your reality, so be careful what you wish for.
Fulvio
Posts: 395
Joined: Fri Aug 12, 2016 8:43 pm

Re: Do patches need to be open source?

Post by Fulvio »

syzygy wrote: One example: Andrew Katz, GPL - the Linking Debate
"My advice to clients who wish to release software under a licence of their choice (which may be another free or other source licence, and not just the
GPL) is as follows ...
link statically, avoid amending the library, remember to comply with the GPL for the library when you distribute the object code containing it, and buy a rabbit's foot"
https://lwn.net/Articles/548216/

the decision about whether or not a derivative work has been created can't be based on technical factors alone, but rather on factors such as the relationship between pieces of code. "Suppose I add an interface to a GPL-licensed program to implement new functionality in a shared library; then of course it is a derivative work [regardless of the type of linking]."