split 3 from Zach technical thread

[Dirt]

As far as your "prove" the GPL is quite clear. It has been stated and restated over and over. Once code is GPL'ed, it is GPL. If you copy and rewrite, so long as you have one line of the original GPL code, your code is considered GPL as well...

This is subtly wrong. A derived program is infringing if it is released under a non-GPL license. Subsequently releasing the work under the GPL doesn't erase the prior infringement, although the copyright holder may settle for that. Contrariwise, while the infringer may be forced to cease distribution and pay damages, he normally cannot be forced to GPL his own code.

[LarsA]

This is an interesting question which I've also been searching for info on. I haven't found any conclusive answer, but the following article has some info from the FOSS side:

http://arstechnica.com/news.ars/post/20 ... mmies.html

which discusses (and links to) this:

http://www.softwarefreedom.org/resource ... guide.html

After reading this and a few other articles I sense that in general the FSF are after bigger fish than a one man team, and will always prefer to settle things outside the legal system. If indeed the FSF would find rybka 1 beta to be an infringement, their goal will be to either make it compliant, i.e. have the sources shipped with the binaries, or have it removed from the market. Since the software is already removed from the market, what remains is to convince the copyright holder that the violation is corrected in releases currently on the market (R2.2n and R3), either by removal of GPL licensed code or by release of the source.

As a side note, it seems the FSF prefers to settle things quietly, and that most of the infringemets are solved without any publicity. Maybe the FSF has already seen the code in question?

[bob]

As far as your "prove" the GPL is quite clear. It has been stated and restated over and over. Once code is GPL'ed, it is GPL. If you copy and rewrite, so long as you have one line of the original GPL code, your code is considered GPL as well...

I don't see any ambiguity at all, this has been tested in the courts multiple times, and each time the GPL has prevailed...

Exactly this has been subject of my research today. Given that you, Bob, obviously have current and substantial knowledge about how courts decide in such cases, can you give any reference/link where I can read how a court draws the borderline between "software Y is a derivative work based on X" and "it is not"?

Not accurately and off the top of my head. Blackberry had a major problem with software. The unix between Novell, AT&T, etc. Cisco routing software had some sort of copyright issue. It has been a pretty common issue in computing, and has evolved as patent/copyright decisions have changed over the years.

My point is that I would like to learn more about the "GPL reality" regarding derivative works, something that goes beyond what's written down on GNU pages like this one I found today:

http://www.gnu.org/licenses/gpl-faq.html

Currently there are different opinions in our forum about whether "trivial", or "non-AI", or "less interesting" parts of source code are subject of GPL protection, too. This should be clarified first, without speculating too much.

I googled and found a partially interesting article about GPL topics on the Novell pages: http://www.novell.com/coolsolutions/feature/1532.html
There I read:

US copyright law stipulates that a work will only be considered an infringing derivative work if it is substantially similar to the copyrighted work, and if the copyright holder did not authorize the derivative. Courts generally consider a work a derivative if it contains a substantial amount of material from a preexisting work.[...]The courts have not, however, done much to relate this concept of derivatives to software law,

and further down he writes about linking with libraries and such. This tells me that, [Edit: at least in the U.S., and] at least at the time of writing that article (2004), exact rules to tell whether some software is infringing derivative work or not don't seem to be commonly available yet but the basic principle shall be: "substantially similar, substantially copied, and not authorized by copyright holder".

Does anyone know more on this? I admit, it's just a google hit but it does look relevant for me.

Returning to our chess engines and their "copied lines", one of my major problems when thinking about GPL protection is that the concept of a "line" of C/C++ code is quite vague. I think it requires some additional specification, either written or "commonly agreed". I'd like to have a closer look at it, perhaps so that all of us will know better what could really be "GPL protected" and what is probably not, if such a difference exists (IMO it does, but that's another point).

Consider the following examples of "lines", each starting after the meta tag "LINE <lineNumber>: ". To each of these I want to assign some degree of relevance that tells me how strong the copying of that line might indicate a derivative work, from my personal point of view. Of course I know that in many cases the context is more important than the single line but some members of this forum repeatedly referred to lines so I want to stay at this low level first.

Code: Select all

LINE 1:    // UCI options

LINE 2: int i;

LINE 3:     if (option_get_bool("OwnBook") && !SearchInput->infinite) {

LINE 4: 

LINE 5: void search() {

LINE 6:       init = true;

LINE 7:          printf("info string GetConsoleMode() failed, error=%d\n",error);

LINE 8:    return double(GetTickCount()) / 1000.0;

LINE 9:    } else {

LINE 10:          value = -full_search(board,-beta,-alpha,new_depth,height+1,new_pv,NodePV);

LINE 11:    0, 0, 128, 192, 224, 240, 248, 252, 254, 255, 256, 256 ,256, 256, 256, 256,

LINE 12:             for (to = from-17; capture=board->square[to], THROUGH(capture); to -= 17) mob += MobMove;

1 (comment): in most cases irrelevant, with few exceptions

2 (trivial declarations with frequently used names like "i"): irrelevant

3 (complex expression calling functions or using data structures that are quite specific for the program although not involving too much of its "secrets"): medium relevance

4 (empty lines or lines containing only spaces): irrelevant

5 (function definition using very common name within the program's domain): little relevance, one can have a function 'void search()' with an implementation completely different from the original

6 (simple assignment using very common variable name): same as 5, even closer to 2 since not very domain specific

7 (printing quite specific output): sometimes high relevance, might contribute to kind of a "fingerprint" of a program - although GPL protection of a program's output seems to be a very special separate topic

8 (math expression, also using system library function): low to medium relevance, depends on context, the '1000.0' may carry high relevance here

9 (only language keywords and the like): irrelevant

10 (function call with many parameters): may have high relevance, but in this case has only low or medium relevance for me since this function call is part of a widely known standard algorithm in our domain

11 (constants being part of array init code): high relevance, in this case even very high since it is KingAttackWeight[] and influences the eval and thus the engine's play

12 (accessing specific data structures in a very specific way): very high relevance, part of mobility evaluation


I could have written hundreds or thousands of examples but enough is enough.

Again my point: for me, lines of C/C++ source code have very different relevance to the decision about being derivative work. Whether courts would really consider that is something I would like to learn.

Any comments on this? (Sorry for this long post, I swear it is one of my last ones for today )

Sven

[bob]

As far as your "prove" the GPL is quite clear. It has been stated and restated over and over. Once code is GPL'ed, it is GPL. If you copy and rewrite, so long as you have one line of the original GPL code, your code is considered GPL as well...

I don't see any ambiguity at all, this has been tested in the courts multiple times, and each time the GPL has prevailed...

Exactly this has been subject of my research today. Given that you, Bob, obviously have current and substantial knowledge about how courts decide in such cases, can you give any reference/link where I can read how a court draws the borderline between "software Y is a derivative work based on X" and "it is not"?

Not accurately and off the top of my head. Blackberry had a major problem with software. The unix between Novell, AT&T, etc. Cisco routing software had some sort of copyright issue. It has been a pretty common issue in computing, and has evolved as patent/copyright decisions have changed over the years.

another:The first U.S. GPL-related lawsuit appears to be headed for a quick out-of-court settlement. Monsoon Multimedia admitted today that it had violated the GPLv2 (GNU General Public License version 2), and said it will release its modified BusyBox code in full compliance with the license. that was a year or so ago

and another: The Software Freedom Law Center (SFLC) has filed two more GPL infringement lawsuits on behalf of an open source software project. The second-ever GPL lawsuit alleges that Xterasys and High-Gain Antennas failed to honor "source-code transparency," in violation of Busybox's GPLv2 license.

My point is that I would like to learn more about the "GPL reality" regarding derivative works, something that goes beyond what's written down on GNU pages like this one I found today:

http://www.gnu.org/licenses/gpl-faq.html

Currently there are different opinions in our forum about whether "trivial", or "non-AI", or "less interesting" parts of source code are subject of GPL protection, too. This should be clarified first, without speculating too much.

I googled and found a partially interesting article about GPL topics on the Novell pages: http://www.novell.com/coolsolutions/feature/1532.html
There I read:

US copyright law stipulates that a work will only be considered an infringing derivative work if it is substantially similar to the copyrighted work, and if the copyright holder did not authorize the derivative. Courts generally consider a work a derivative if it contains a substantial amount of material from a preexisting work.[...]The courts have not, however, done much to relate this concept of derivatives to software law,

and further down he writes about linking with libraries and such. This tells me that, [Edit: at least in the U.S., and] at least at the time of writing that article (2004), exact rules to tell whether some software is infringing derivative work or not don't seem to be commonly available yet but the basic principle shall be: "substantially similar, substantially copied, and not authorized by copyright holder".

Does anyone know more on this? I admit, it's just a google hit but it does look relevant for me.

Returning to our chess engines and their "copied lines", one of my major problems when thinking about GPL protection is that the concept of a "line" of C/C++ code is quite vague. I think it requires some additional specification,

I don't think it has ever been stretched to a single line. "significant blocks" is the usual standard, and is vague enough to leave lots of room for discussion. But those are different issues dealing with copyright as opposed to the GPL which has a different angle about open-source.

either written or "commonly agreed". I'd like to have a closer look at it, perhaps so that all of us will know better what could really be "GPL protected" and what is probably not, if such a difference exists (IMO it does, but that's another point).

Consider the following examples of "lines", each starting after the meta tag "LINE <lineNumber>: ". To each of these I want to assign some degree of relevance that tells me how strong the copying of that line might indicate a derivative work, from my personal point of view. Of course I know that in many cases the context is more important than the single line but some members of this forum repeatedly referred to lines so I want to stay at this low level first.

Code: Select all

LINE 1:    // UCI options

LINE 2: int i;

LINE 3:     if (option_get_bool("OwnBook") && !SearchInput->infinite) {

LINE 4: 

LINE 5: void search() {

LINE 6:       init = true;

LINE 7:          printf("info string GetConsoleMode() failed, error=%d\n",error);

LINE 8:    return double(GetTickCount()) / 1000.0;

LINE 9:    } else {

LINE 10:          value = -full_search(board,-beta,-alpha,new_depth,height+1,new_pv,NodePV);

LINE 11:    0, 0, 128, 192, 224, 240, 248, 252, 254, 255, 256, 256 ,256, 256, 256, 256,

LINE 12:             for (to = from-17; capture=board->square[to], THROUGH(capture); to -= 17) mob += MobMove;

1 (comment): in most cases irrelevant, with few exceptions

2 (trivial declarations with frequently used names like "i"): irrelevant

3 (complex expression calling functions or using data structures that are quite specific for the program although not involving too much of its "secrets"): medium relevance

4 (empty lines or lines containing only spaces): irrelevant

5 (function definition using very common name within the program's domain): little relevance, one can have a function 'void search()' with an implementation completely different from the original

6 (simple assignment using very common variable name): same as 5, even closer to 2 since not very domain specific

7 (printing quite specific output): sometimes high relevance, might contribute to kind of a "fingerprint" of a program - although GPL protection of a program's output seems to be a very special separate topic

8 (math expression, also using system library function): low to medium relevance, depends on context, the '1000.0' may carry high relevance here

9 (only language keywords and the like): irrelevant

10 (function call with many parameters): may have high relevance, but in this case has only low or medium relevance for me since this function call is part of a widely known standard algorithm in our domain

11 (constants being part of array init code): high relevance, in this case even very high since it is KingAttackWeight[] and influences the eval and thus the engine's play

12 (accessing specific data structures in a very specific way): very high relevance, part of mobility evaluation


I could have written hundreds or thousands of examples but enough is enough.

Again my point: for me, lines of C/C++ source code have very different relevance to the decision about being derivative work. Whether courts would really consider that is something I would like to learn.

Any comments on this? (Sorry for this long post, I swear it is one of my last ones for today )

Sven

[Albert Silver]

This is an interesting question which I've also been searching for info on. I haven't found any conclusive answer, but the following article has some info from the FOSS side:

http://arstechnica.com/news.ars/post/20 ... mmies.html

which discusses (and links to) this:

http://www.softwarefreedom.org/resource ... guide.html

After reading this and a few other articles I sense that in general the FSF are after bigger fish than a one man team, and will always prefer to settle things outside the legal system. If indeed the FSF would find rybka 1 beta to be an infringement, their goal will be to either make it compliant, i.e. have the sources shipped with the binaries, or have it removed from the market. Since the software is already removed from the market, what remains is to convince the copyright holder that the violation is corrected in releases currently on the market (R2.2n and R3), either by removal of GPL licensed code or by release of the source.

As a side note, it seems the FSF prefers to settle things quietly, and that most of the infringemets are solved without any publicity. Maybe the FSF has already seen the code in question?

So whatever the conclusion of this, all that matters is whether Rybka 2.2n or Rybka 3 contain violations?

[LarsA]

This is an interesting question which I've also been searching for info on. I haven't found any conclusive answer, but the following article has some info from the FOSS side:

http://arstechnica.com/news.ars/post/20 ... mmies.html

which discusses (and links to) this:

http://www.softwarefreedom.org/resource ... guide.html

After reading this and a few other articles I sense that in general the FSF are after bigger fish than a one man team, and will always prefer to settle things outside the legal system. If indeed the FSF would find rybka 1 beta to be an infringement, their goal will be to either make it compliant, i.e. have the sources shipped with the binaries, or have it removed from the market. Since the software is already removed from the market, what remains is to convince the copyright holder that the violation is corrected in releases currently on the market (R2.2n and R3), either by removal of GPL licensed code or by release of the source.

As a side note, it seems the FSF prefers to settle things quietly, and that most of the infringemets are solved without any publicity. Maybe the FSF has already seen the code in question?

So whatever the conclusion of this, all that matters is whether Rybka 2.2n or Rybka 3 contain violations?

The way I understand how the FSF handles these cases, yes.

[LarsA]

This is an interesting question which I've also been searching for info on. I haven't found any conclusive answer, but the following article has some info from the FOSS side:

http://arstechnica.com/news.ars/post/20 ... mmies.html

which discusses (and links to) this:

http://www.softwarefreedom.org/resource ... guide.html

After reading this and a few other articles I sense that in general the FSF are after bigger fish than a one man team, and will always prefer to settle things outside the legal system. If indeed the FSF would find rybka 1 beta to be an infringement, their goal will be to either make it compliant, i.e. have the sources shipped with the binaries, or have it removed from the market. Since the software is already removed from the market, what remains is to convince the copyright holder that the violation is corrected in releases currently on the market (R2.2n and R3), either by removal of GPL licensed code or by release of the source.

As a side note, it seems the FSF prefers to settle things quietly, and that most of the infringemets are solved without any publicity. Maybe the FSF has already seen the code in question?

So whatever the conclusion of this, all that matters is whether Rybka 2.2n or Rybka 3 contain violations?

The way I understand how the FSF handles these cases, yes.

As can be expected, it seems that the FSF is only taking these cases to protect the integrity of the GPL. When compliance is restored, the case is closed as far as they are concerned.

Fabien could probably file his own law suit for damages, but I don't think he had any business model around the GPL'ed version of fruit, e.g. through a dual licensing scheme or support sales.

[Albert Silver]

This is an interesting question which I've also been searching for info on. I haven't found any conclusive answer, but the following article has some info from the FOSS side:

http://arstechnica.com/news.ars/post/20 ... mmies.html

which discusses (and links to) this:

http://www.softwarefreedom.org/resource ... guide.html

After reading this and a few other articles I sense that in general the FSF are after bigger fish than a one man team, and will always prefer to settle things outside the legal system. If indeed the FSF would find rybka 1 beta to be an infringement, their goal will be to either make it compliant, i.e. have the sources shipped with the binaries, or have it removed from the market. Since the software is already removed from the market, what remains is to convince the copyright holder that the violation is corrected in releases currently on the market (R2.2n and R3), either by removal of GPL licensed code or by release of the source.

So whatever the conclusion of this, all that matters is whether Rybka 2.2n or Rybka 3 contain violations?

The way I understand how the FSF handles these cases, yes.

Well, I guess we can expect Theron, Zach and co. to start disassembling Rybka 3 and posting that here now. After all, their mission to take down Vas won't amount to much if they don't.

Albert

[bnemias]

This is an interesting question which I've also been searching for info on. I haven't found any conclusive answer, but the following article has some info from the FOSS side:

http://arstechnica.com/news.ars/post/20 ... mmies.html

which discusses (and links to) this:

http://www.softwarefreedom.org/resource ... guide.html

After reading this and a few other articles I sense that in general the FSF are after bigger fish than a one man team, and will always prefer to settle things outside the legal system. If indeed the FSF would find rybka 1 beta to be an infringement, their goal will be to either make it compliant, i.e. have the sources shipped with the binaries, or have it removed from the market. Since the software is already removed from the market, what remains is to convince the copyright holder that the violation is corrected in releases currently on the market (R2.2n and R3), either by removal of GPL licensed code or by release of the source.

As a side note, it seems the FSF prefers to settle things quietly, and that most of the infringemets are solved without any publicity. Maybe the FSF has already seen the code in question?

Thanks for the groundwork here Lars. If there turns out to be any GPL violation, I imagine the following quote FTA is true:

The vast majority of GPL violations are the result of ignorance rather than willful infringement.

And so, either solution you mentioned above would suit me fine.

[BubbaTough]

Boy, not much meat in these threads.

Anyway, I personally find it minorly useful to distinguish whether "important" parts of the code (such as search / eval) of Rybka 1.0 vs. "unimportant" (such as input processing and string compares) are from fruit in part because of implications regarding other versions. If the only overlap between Rybka 1 and Fruit were things like string compare and input processing, it would be quite easy to believe that versions 2.0 + have no overlap as those parts would be easy to rewrite without harming performance. If other parts (say, the hash table, see function, move generation) were copied, I would expect they would be harder to replace without effecting performance and would be possibly passed on to future versions. This distinction is unimportant to those who just care about whether there was a GPL violation (probably more of an emotional issue to those that have made their code public than those of us who haven't [not sure why it seems so emotional to many without a codebase]).

Just out of curiosity, were there similar size ruckuses in the past regarding other programs? It is kind of depressing to think that if I found some amazing new algorithm that took my engine over the top that I would be reticent to make my engine public for fear of a string_equal() hunt finding something hidden somewhere in my code. Luckily, odds of me coming up with enough big breakthroughs to make this relevant is small (and hopefully the odds of someone finding something appearing to be a GPL violation is also small).

-Sam