split 3 from Zach technical thread

[tiger]

Gerd,

Thank you for your interest. This kind of posts are what we need: calm, objective observations.

UCI 'go' parser seems the strongest point so far.

It is certainly strong evidence. Unfortunately nobody seems to take it as "evidence".

Looks like a plausible order to me - except probably Setjmp
Of course you need to generate moves before ordering them
Does 150 have the same semantics in Fruit and Rybka 1.0 beta, e.g. centipawns?

Yes, at this point, the semantics are the same. It is a plausible order, i.e. it makes sense, but it is just rare to have the exact same order. The most important points here IMO are the setjmp, the limit depth, and the lookup hash move. Not many engines do a hash probe before starting with iterative deepening.

Might be quite common as well - since you always fetch both game stages simultaneously. In assembly it could be an array of structs as well.

Yes, these things might be "typical". But very few engines use them. I am merely trying to accumulate such low level similarities. As of yet, I haven't found any such similarities with any other engine I am aware of.

This is interesting, but might be considered as taking ideas rather than code.

While I see this point, we have to keep in mind that Rybka was already a 2000 engine before Fruit. I would expect it to already have hash tables, piece square tables, etc. So it's either a coincidence that such similarities exist, or Vas rewrote many fundamental aspects of his engine after Fruit came out.

I think the next one is quite common as well. I also use WK=1, WQ=2, BK=4, BQ=8 and used to use the stack that much and have separate make_null, undo_null. Why is CastleHash[oldflags] ^ CastleHash[newflags] more natural?

I would think that would be obvious. Take two situations, from the beginning of the game. Castling status is 1111b. Now white can lose its castling rights in two ways, moving its king or both its rooks. Which would happen like this:

King move:
hashkey ^= CastleHash[1111 ^ 0011 = 1100];

Rook moves:
hashkey ^= CastleHash[1111 ^ 0111 = 1000];
hashkey ^= CastleHash[1111 ^ 1011 = 0100];

Both of these must result in the same hashkey, which means that CastleHash[1100] == CastleHash[1000] ^ CastleHash[0100]. So you can't simply fill CastleHash with random numbers, you have to create 4 hashkeys at first (for each of 1, 2, 4, 8), and then make CastleHash[abcd] = CastleHash[a000] ^ CastleHash[0b00] ^ ..., with of course CastleHash[0] = 0.

And then of course when reading a fen, you must initialize the hashkey with hashkey ^= CastleHash[1111 ^ flags].

Zach,

I won't comment on the UCI go parser, this is the sort of coding I had done for me by support programmers and its outside the engine and I don't really understand it. I'm looking for a proof that exists within engine code, not UCI, I understand some people may take issue, but to show one engine is a clone of another surely requires *engine* code correspondence, no?

Your use of the word "clone" is incorrect in the context of this discussion and could lead to severe misinterpretation.

We are talking about a possible breach of the GPL, the license under which the author of Fruit has published his work. This license explicitely forbids any derived work from Fruit 2.1 to be published as closed source. Such a derived work should be published under the GPL license. It is the will of the original author.

As far as the engine stuff goes, I'm inclined to agree with Gerd and Uri(?) that this material shown so far can well be use of ideas.

I also take issue with the comment:

"But very few engines use them. I am merely trying to accumulate such low level similarities. As of yet, I haven't found any such similarities with any other engine I am aware of."

There are a lot of engines around. Many written before the days of public source, and many which have not revealed their source. Both you and Bob and anyone else know a subset of engines only. As case setjmp() shows. "Few engines use them" or "engine I am aware of" can sound plausible but is ultimately not scientific and can't be used in a logical proof.

On a positive note .... yesterday saw some heated and emotional and slightly wild and personal material - this does not help the discussion forward. It also saw quite a bit of code hieroglyphics posted, so its difficult to know where to start. Would it be possible that you generate some corresponding identical Fruit/Rybka engine code fragment in a strongest case version. ie the one you believe you could base your case on and which is most difficult to refute? Both sides can then concentrate their expert firepower onto this one case. If the anti side can't shoot your example down, then maybe Vas could be asked to comment?

Such side-by-side comparison has been posted (thanks to Norman). Here:

http://pagesperso-orange.fr/ct_chess/Fr ... rt_go.html



// Christophe

[chrisw]

Gerd,

Thank you for your interest. This kind of posts are what we need: calm, objective observations.

UCI 'go' parser seems the strongest point so far.

It is certainly strong evidence. Unfortunately nobody seems to take it as "evidence".

Looks like a plausible order to me - except probably Setjmp
Of course you need to generate moves before ordering them
Does 150 have the same semantics in Fruit and Rybka 1.0 beta, e.g. centipawns?

Yes, at this point, the semantics are the same. It is a plausible order, i.e. it makes sense, but it is just rare to have the exact same order. The most important points here IMO are the setjmp, the limit depth, and the lookup hash move. Not many engines do a hash probe before starting with iterative deepening.

Might be quite common as well - since you always fetch both game stages simultaneously. In assembly it could be an array of structs as well.

Yes, these things might be "typical". But very few engines use them. I am merely trying to accumulate such low level similarities. As of yet, I haven't found any such similarities with any other engine I am aware of.

This is interesting, but might be considered as taking ideas rather than code.

While I see this point, we have to keep in mind that Rybka was already a 2000 engine before Fruit. I would expect it to already have hash tables, piece square tables, etc. So it's either a coincidence that such similarities exist, or Vas rewrote many fundamental aspects of his engine after Fruit came out.

I think the next one is quite common as well. I also use WK=1, WQ=2, BK=4, BQ=8 and used to use the stack that much and have separate make_null, undo_null. Why is CastleHash[oldflags] ^ CastleHash[newflags] more natural?

I would think that would be obvious. Take two situations, from the beginning of the game. Castling status is 1111b. Now white can lose its castling rights in two ways, moving its king or both its rooks. Which would happen like this:

King move:
hashkey ^= CastleHash[1111 ^ 0011 = 1100];

Rook moves:
hashkey ^= CastleHash[1111 ^ 0111 = 1000];
hashkey ^= CastleHash[1111 ^ 1011 = 0100];

Both of these must result in the same hashkey, which means that CastleHash[1100] == CastleHash[1000] ^ CastleHash[0100]. So you can't simply fill CastleHash with random numbers, you have to create 4 hashkeys at first (for each of 1, 2, 4, 8), and then make CastleHash[abcd] = CastleHash[a000] ^ CastleHash[0b00] ^ ..., with of course CastleHash[0] = 0.

And then of course when reading a fen, you must initialize the hashkey with hashkey ^= CastleHash[1111 ^ flags].

Zach,

I won't comment on the UCI go parser, this is the sort of coding I had done for me by support programmers and its outside the engine and I don't really understand it. I'm looking for a proof that exists within engine code, not UCI, I understand some people may take issue, but to show one engine is a clone of another surely requires *engine* code correspondence, no?

Your use of the word "clone" is incorrect in the context of this discussion and could lead to severe misinterpretation.

We are talking about a possible breach of the GPL, the license under which the author of Fruit has published his work. This license explicitely forbids any derived work from Fruit 2.1 to be published as closed source. Such a derived work should be published under the GPL license. It is the will of the original author.

As far as the engine stuff goes, I'm inclined to agree with Gerd and Uri(?) that this material shown so far can well be use of ideas.

I also take issue with the comment:

"But very few engines use them. I am merely trying to accumulate such low level similarities. As of yet, I haven't found any such similarities with any other engine I am aware of."

There are a lot of engines around. Many written before the days of public source, and many which have not revealed their source. Both you and Bob and anyone else know a subset of engines only. As case setjmp() shows. "Few engines use them" or "engine I am aware of" can sound plausible but is ultimately not scientific and can't be used in a logical proof.

On a positive note .... yesterday saw some heated and emotional and slightly wild and personal material - this does not help the discussion forward. It also saw quite a bit of code hieroglyphics posted, so its difficult to know where to start. Would it be possible that you generate some corresponding identical Fruit/Rybka engine code fragment in a strongest case version. ie the one you believe you could base your case on and which is most difficult to refute? Both sides can then concentrate their expert firepower onto this one case. If the anti side can't shoot your example down, then maybe Vas could be asked to comment?

Such side-by-side comparison has been posted (thanks to Norman). Here:

http://pagesperso-orange.fr/ct_chess/Fr ... rt_go.html

// Christophe

As has been already stated many times, the GPL is indeed a matter for the original author or whoever he passed ownership of the licence to. It's nothing to do with you.

The side by side comparison is of code where parameters are passed from the user interfae to the engine, the UCI side of things. Every program has to have this, many programs do it similarly or the same, it seems to me very unlikely that code is covered by the GPL because it likely to be in general use anyway. A known sort routine in the UCI won't be covered by the GPL, will it? For example.

Can you prove that UCI handling code segment is covered?

If you're not going to provide any engine code correspondences, can you at least reduce the damage done to Vas and his business and his program by making the unequivocal statement:

"I, Christophe Theron, absolutely reject any implication that the engine AI code of Rybka is anything other than Vas own work".

[tiger]

Gerd,

Thank you for your interest. This kind of posts are what we need: calm, objective observations.

UCI 'go' parser seems the strongest point so far.

It is certainly strong evidence. Unfortunately nobody seems to take it as "evidence".

Looks like a plausible order to me - except probably Setjmp
Of course you need to generate moves before ordering them
Does 150 have the same semantics in Fruit and Rybka 1.0 beta, e.g. centipawns?

Yes, at this point, the semantics are the same. It is a plausible order, i.e. it makes sense, but it is just rare to have the exact same order. The most important points here IMO are the setjmp, the limit depth, and the lookup hash move. Not many engines do a hash probe before starting with iterative deepening.

Might be quite common as well - since you always fetch both game stages simultaneously. In assembly it could be an array of structs as well.

Yes, these things might be "typical". But very few engines use them. I am merely trying to accumulate such low level similarities. As of yet, I haven't found any such similarities with any other engine I am aware of.

This is interesting, but might be considered as taking ideas rather than code.

While I see this point, we have to keep in mind that Rybka was already a 2000 engine before Fruit. I would expect it to already have hash tables, piece square tables, etc. So it's either a coincidence that such similarities exist, or Vas rewrote many fundamental aspects of his engine after Fruit came out.

I think the next one is quite common as well. I also use WK=1, WQ=2, BK=4, BQ=8 and used to use the stack that much and have separate make_null, undo_null. Why is CastleHash[oldflags] ^ CastleHash[newflags] more natural?

I would think that would be obvious. Take two situations, from the beginning of the game. Castling status is 1111b. Now white can lose its castling rights in two ways, moving its king or both its rooks. Which would happen like this:

King move:
hashkey ^= CastleHash[1111 ^ 0011 = 1100];

Rook moves:
hashkey ^= CastleHash[1111 ^ 0111 = 1000];
hashkey ^= CastleHash[1111 ^ 1011 = 0100];

Both of these must result in the same hashkey, which means that CastleHash[1100] == CastleHash[1000] ^ CastleHash[0100]. So you can't simply fill CastleHash with random numbers, you have to create 4 hashkeys at first (for each of 1, 2, 4, 8), and then make CastleHash[abcd] = CastleHash[a000] ^ CastleHash[0b00] ^ ..., with of course CastleHash[0] = 0.

And then of course when reading a fen, you must initialize the hashkey with hashkey ^= CastleHash[1111 ^ flags].

Zach,

I won't comment on the UCI go parser, this is the sort of coding I had done for me by support programmers and its outside the engine and I don't really understand it. I'm looking for a proof that exists within engine code, not UCI, I understand some people may take issue, but to show one engine is a clone of another surely requires *engine* code correspondence, no?

Your use of the word "clone" is incorrect in the context of this discussion and could lead to severe misinterpretation.

We are talking about a possible breach of the GPL, the license under which the author of Fruit has published his work. This license explicitely forbids any derived work from Fruit 2.1 to be published as closed source. Such a derived work should be published under the GPL license. It is the will of the original author.

As far as the engine stuff goes, I'm inclined to agree with Gerd and Uri(?) that this material shown so far can well be use of ideas.

I also take issue with the comment:

"But very few engines use them. I am merely trying to accumulate such low level similarities. As of yet, I haven't found any such similarities with any other engine I am aware of."

There are a lot of engines around. Many written before the days of public source, and many which have not revealed their source. Both you and Bob and anyone else know a subset of engines only. As case setjmp() shows. "Few engines use them" or "engine I am aware of" can sound plausible but is ultimately not scientific and can't be used in a logical proof.

On a positive note .... yesterday saw some heated and emotional and slightly wild and personal material - this does not help the discussion forward. It also saw quite a bit of code hieroglyphics posted, so its difficult to know where to start. Would it be possible that you generate some corresponding identical Fruit/Rybka engine code fragment in a strongest case version. ie the one you believe you could base your case on and which is most difficult to refute? Both sides can then concentrate their expert firepower onto this one case. If the anti side can't shoot your example down, then maybe Vas could be asked to comment?

Such side-by-side comparison has been posted (thanks to Norman). Here:

http://pagesperso-orange.fr/ct_chess/Fr ... rt_go.html

// Christophe

As has been already stated many times, the GPL is indeed a matter for the original author or whoever he passed ownership of the licence to. It's nothing to do with you.

I'm entitled, as anybody else, to gather evidence of GPL violation and pass the evidence to the Free Software Foundation, which is the copyright owner of Fruit 2.1.

The side by side comparison is of code where parameters are passed from the user interfae to the engine, the UCI side of things. Every program has to have this, many programs do it similarly or the same, it seems to me very unlikely that code is covered by the GPL because it likely to be in general use anyway. A known sort routine in the UCI won't be covered by the GPL, will it? For example.

Can you prove that UCI handling code segment is covered?

Naturally it is.

And the UCI interface part that has been shown participates in the engine's time management.

If you're not going to provide any engine code correspondences, can you at least reduce the damage done to Vas and his business and his program by making the unequivocal statement:

"I, Christophe Theron, absolutely reject any implication that the engine AI code of Rybka is anything other than Vas own work".

Unfortunately I cannot make such a statement. It is too risky.



// Christophe

[chrisw]

If you're not going to provide any engine code correspondences, can you at least reduce the damage done to Vas and his business and his program by making the unequivocal statement:

"I, Christophe Theron, absolutely reject any implication that the engine AI code of Rybka is anything other than Vas own work".

Unfortunately I cannot make such a statement. It is too risky.

// Christophe

It's the opposite of risky.

You provided zero engine AI evidence, UCI only.

Readers will draw their own conclusions.

[Enir]

If you're not going to provide any engine code correspondences, can you at least reduce the damage done to Vas and his business and his program by making the unequivocal statement:

"I, Christophe Theron, absolutely reject any implication that the engine AI code of Rybka is anything other than Vas own work".

Unfortunately I cannot make such a statement. It is too risky.

Being risky didn’t stop you from accusing Vas of plagiarism without hard proof, which you did not have.

Simultaneously accusing Vas of plagiarism, of unfairness for giving Rybka 2 for free, of obfuscating Rybka’s node count (something you did with Tiger), makes the whole thing not an angelical quest for fairness and truth, but just a campaign against Rybka and Vas.

[trojanfoe]

If you're not going to provide any engine code correspondences, can you at least reduce the damage done to Vas and his business and his program by making the unequivocal statement:

"I, Christophe Theron, absolutely reject any implication that the engine AI code of Rybka is anything other than Vas own work".

Unfortunately I cannot make such a statement. It is too risky.

// Christophe

It's the opposite of risky.

You provided zero engine AI evidence, UCI only.

Readers will draw their own conclusions.

Why have you decided that the GPL violation only covers core engine code and not other parts of the program? The GPL doesn't distinguish between the functionality of code and the level of coverage it's given; it's all covered. This seems normal.

[chrisw]

If you're not going to provide any engine code correspondences, can you at least reduce the damage done to Vas and his business and his program by making the unequivocal statement:

"I, Christophe Theron, absolutely reject any implication that the engine AI code of Rybka is anything other than Vas own work".

Unfortunately I cannot make such a statement. It is too risky.

// Christophe

It's the opposite of risky.

You provided zero engine AI evidence, UCI only.

Readers will draw their own conclusions.

Why have you decided that the GPL violation only covers core engine code and not other parts of the program? The GPL doesn't distinguish between the functionality of code and the level of coverage it's given; it's all covered. This seems normal.

I've not decided any such thing. The GPL covers what it says it covers.

[bob]

Gerd,

Thank you for your interest. This kind of posts are what we need: calm, objective observations.

UCI 'go' parser seems the strongest point so far.

It is certainly strong evidence. Unfortunately nobody seems to take it as "evidence".

Looks like a plausible order to me - except probably Setjmp
Of course you need to generate moves before ordering them
Does 150 have the same semantics in Fruit and Rybka 1.0 beta, e.g. centipawns?

Yes, at this point, the semantics are the same. It is a plausible order, i.e. it makes sense, but it is just rare to have the exact same order. The most important points here IMO are the setjmp, the limit depth, and the lookup hash move. Not many engines do a hash probe before starting with iterative deepening.

Might be quite common as well - since you always fetch both game stages simultaneously. In assembly it could be an array of structs as well.

Yes, these things might be "typical". But very few engines use them. I am merely trying to accumulate such low level similarities. As of yet, I haven't found any such similarities with any other engine I am aware of.

This is interesting, but might be considered as taking ideas rather than code.

While I see this point, we have to keep in mind that Rybka was already a 2000 engine before Fruit. I would expect it to already have hash tables, piece square tables, etc. So it's either a coincidence that such similarities exist, or Vas rewrote many fundamental aspects of his engine after Fruit came out.

I think the next one is quite common as well. I also use WK=1, WQ=2, BK=4, BQ=8 and used to use the stack that much and have separate make_null, undo_null. Why is CastleHash[oldflags] ^ CastleHash[newflags] more natural?

I would think that would be obvious. Take two situations, from the beginning of the game. Castling status is 1111b. Now white can lose its castling rights in two ways, moving its king or both its rooks. Which would happen like this:

King move:
hashkey ^= CastleHash[1111 ^ 0011 = 1100];

Rook moves:
hashkey ^= CastleHash[1111 ^ 0111 = 1000];
hashkey ^= CastleHash[1111 ^ 1011 = 0100];

Both of these must result in the same hashkey, which means that CastleHash[1100] == CastleHash[1000] ^ CastleHash[0100]. So you can't simply fill CastleHash with random numbers, you have to create 4 hashkeys at first (for each of 1, 2, 4, 8), and then make CastleHash[abcd] = CastleHash[a000] ^ CastleHash[0b00] ^ ..., with of course CastleHash[0] = 0.

And then of course when reading a fen, you must initialize the hashkey with hashkey ^= CastleHash[1111 ^ flags].

Zach,

I won't comment on the UCI go parser, this is the sort of coding I had done for me by support programmers and its outside the engine and I don't really understand it. I'm looking for a proof that exists within engine code, not UCI, I understand some people may take issue, but to show one engine is a clone of another surely requires *engine* code correspondence, no?

Your use of the word "clone" is incorrect in the context of this discussion and could lead to severe misinterpretation.

We are talking about a possible breach of the GPL, the license under which the author of Fruit has published his work. This license explicitely forbids any derived work from Fruit 2.1 to be published as closed source. Such a derived work should be published under the GPL license. It is the will of the original author.

As far as the engine stuff goes, I'm inclined to agree with Gerd and Uri(?) that this material shown so far can well be use of ideas.

I also take issue with the comment:

"But very few engines use them. I am merely trying to accumulate such low level similarities. As of yet, I haven't found any such similarities with any other engine I am aware of."

There are a lot of engines around. Many written before the days of public source, and many which have not revealed their source. Both you and Bob and anyone else know a subset of engines only. As case setjmp() shows. "Few engines use them" or "engine I am aware of" can sound plausible but is ultimately not scientific and can't be used in a logical proof.

On a positive note .... yesterday saw some heated and emotional and slightly wild and personal material - this does not help the discussion forward. It also saw quite a bit of code hieroglyphics posted, so its difficult to know where to start. Would it be possible that you generate some corresponding identical Fruit/Rybka engine code fragment in a strongest case version. ie the one you believe you could base your case on and which is most difficult to refute? Both sides can then concentrate their expert firepower onto this one case. If the anti side can't shoot your example down, then maybe Vas could be asked to comment?

Such side-by-side comparison has been posted (thanks to Norman). Here:

http://pagesperso-orange.fr/ct_chess/Fr ... rt_go.html

// Christophe

As has been already stated many times, the GPL is indeed a matter for the original author or whoever he passed ownership of the licence to. It's nothing to do with you.

The side by side comparison is of code where parameters are passed from the user interfae to the engine, the UCI side of things. Every program has to have this, many programs do it similarly or the same, it seems to me very unlikely that code is covered by the GPL because it likely to be in general use anyway. A known sort routine in the UCI won't be covered by the GPL, will it? For example.

Can you prove that UCI handling code segment is covered?

If you're not going to provide any engine code correspondences, can you at least reduce the damage done to Vas and his business and his program by making the unequivocal statement:

"I, Christophe Theron, absolutely reject any implication that the engine AI code of Rybka is anything other than Vas own work".

How can anyone make that statement when the current investigation has not been completed, when the Rybka team has remained silent, etc???

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...

[Sven]

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"?

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

[Sven]

Just a note to add: relevance should also be weighted somehow for code blocks, not just single lines, but it is simply not so easy to list some good examples so I did it only for single lines. Maybe someone else has a better idea?

E.g. the string_equal() vs. strcmp() case from a few days ago (yesterday?) would be a trivial example of a code block with very low relevance for me (standard programming stuff). I think the GPL definitely does not protect such functions.

Sven