Ideas versus Implementations
-
- Posts: 616
- Joined: Thu May 19, 2011 1:35 am
Re: Ideas versus Implementations
You see no moral difference between offering public praise and public condemnation?
I submit that you do not have much to worry about in offering praise, but a good deal to worry about in offering condemnation.
I suggest that Fabian's ideas, such as LMR are widely copied.
Including by members of the panel.
Did Vas do more than they did or do it in a worse way?
Perhaps, but I think it takes an expert in software law to know it.
Look at what we have come to now. It is petty bickering and accusations of wrongdoing.
I think it is the competitive nature that is at fault. Too bad people can' simply share ideas like they ought to.
All of this is neither here nor there and I do not know if Vas is guilty or innocent.
I do know this:
I do not like the process used to defame him.
I submit that you do not have much to worry about in offering praise, but a good deal to worry about in offering condemnation.
I suggest that Fabian's ideas, such as LMR are widely copied.
Including by members of the panel.
Did Vas do more than they did or do it in a worse way?
Perhaps, but I think it takes an expert in software law to know it.
Look at what we have come to now. It is petty bickering and accusations of wrongdoing.
I think it is the competitive nature that is at fault. Too bad people can' simply share ideas like they ought to.
All of this is neither here nor there and I do not know if Vas is guilty or innocent.
I do know this:
I do not like the process used to defame him.
-
- Posts: 1242
- Joined: Thu Jun 10, 2010 2:13 am
- Real Name: Bob Hyatt (Robert M. Hyatt)
- Location: University of Alabama at Birmingham
- Contact:
Re: Ideas versus Implementations
User923005 wrote:You see no moral difference between offering public praise and public condemnation?
I submit that you do not have much to worry about in offering praise, but a good deal to worry about in offering condemnation.
I suggest that Fabian's ideas, such as LMR are widely copied.
Including by members of the panel.
Did Vas do more than they did or do it in a worse way?
Perhaps, but I think it takes an expert in software law to know it.
Look at what we have come to now. It is petty bickering and accusations of wrongdoing.
I think it is the competitive nature that is at fault. Too bad people can' simply share ideas like they ought to.
All of this is neither here nor there and I do not know if Vas is guilty or innocent.
I do know this:
I do not like the process used to defame him.
I don't see where anyone has ever had issues with sharing ideas in computer chess. Why do you think the ICGA journal exists? But there is a difference between copying an idea where you write your own code and make the idea mesh into your search or evaluation, as opposed to just copying and modifying to make it work/fit.
-
- Posts: 616
- Joined: Thu May 19, 2011 1:35 am
Re: Ideas versus Implementations
I certainly agree that there is a difference between copying ideas and copying implementations.
And I agree that there is a difference between fair use and license violation.
But I do not think this issue is as cut and dried as some others do. I also think that the penalty was way, way over the top -- especially announcing to popular publications that Vas was a cheater.
My biggest problem is with the process itself (even more than the finding).
Though I do not think that the panel believes they acted improperly, the very construction of the panel makes it look bad, even if it really wasn't.
I am not in the Vas is innocent camp. I am not in the Vas is guilty camp. I am in the "I do not like the process and the penalty was too harsh" camp.
And I agree that there is a difference between fair use and license violation.
But I do not think this issue is as cut and dried as some others do. I also think that the penalty was way, way over the top -- especially announcing to popular publications that Vas was a cheater.
My biggest problem is with the process itself (even more than the finding).
Though I do not think that the panel believes they acted improperly, the very construction of the panel makes it look bad, even if it really wasn't.
I am not in the Vas is innocent camp. I am not in the Vas is guilty camp. I am in the "I do not like the process and the penalty was too harsh" camp.
Re: Ideas versus Implementations
From the point of view of copyright I would say these are still concepts / ideas / algorithms. You can (and do) phrase them in terms of chess pieces and ranks, not in terms of any concrete board representation. The way you express them in natural language is probably protected, but I am free to express them in my own words in natural language (or in source code). (Maybe this is helpful: do you consider that your precise natural language descriptions of the various evaluation features are protected by the copyright on Fruit and/or Rybka?)BB+ wrote:For instance, I consider something sufficiently broad like "rook on 7th (and 6th/8th)" to be the "concept", and then look at the specific ways that engines express this. As I note in my rebuttal: But even the example given by Riis fails his purpose: some engines give a rook on 7th bonus all the time; some only do so when the opponent's king is on the 8th or an enemy pawn is on the 7th; some add a bonus for doubled 7th rooks (perhaps depending on whether they mutually guard each other), some for a rook and queen both on the 7th; some have a similar bonus for a rook on the 8th (or even 6th), some don't (see §2.3.5 of EVAL_COMP).
It is true that some of these concepts are more specific than what you find discussed in chess books, but that doesn't imply that they cross the boundary between idea and expression. For example, to explain the concept of alphabetical sorting to a person there is no need to explain bubble sort or quicksort or any other such sorting algorithm, but these algorithms still are uncopyrightable.
I accept that the same rules apply, however the facts to which they apply are not the same and that is why the outcome can be different. Computer programs are not works of fiction full of creative freedom. On the contrary, computer programs are specifically written to provide certain functionality. At the level of the source code, there is still quite a bit of freedom, but you don't need to go much above that to be completely ruled by the functionality that the program is supposed to implement. (Going slightly above the level of the source should still be possible though, since also the object code is normally protected.)I think we diverge at Point Zero. I start from the fact (good or not) that computer programs are protected as literary works. Thus the "primary purpose" of copyright on computer programs is exactly the same as for literary works.The primary purpose of copyright on software is to protect the source code and object code. Everything going further than that might be "nice to have" for whoever profits from the added protection, but it is not essential for the proper functioning of copyright on software. [...] What is important is that copyright protects the final outcome: the code.
It could be argued (and it has been argued in the past) that computer programs are in fact too determined by their uncopyrightable functionality to be protected by copyright. However, the law has been amended both in the US and in Europe to make clear that their source code and object code is in fact protected (whether by way of legal fiction or not). So source code and object code are protected. Go one level above it, and most of it is quickly dictated by the functionality.
The Rorschach inkblots (which clearly are expressions!) indeed have a functional purpose, but one could argue that they, like source code, are not fully determined by this functional purpose. There is probably no "psychological formula" that generates them.I think your argument can similarly be applied to the Rorschach inkblots [they were created for a "functional" purpose, and not as an expression of HR's creative freedom]. Am I missing something?So as long as Fruit's combination of eval features was created for the purpose of having a good eval and not for expressing Fabien's creative freedom, copying it cannot infringe... (from a copyright point of view).
A bar code is completely determined by its functional purpose, so there is no copyright on a bar code.
Well, commercial programmers do not have to compete in ICGA events, so it is the ICGA that can set their own standard. However, participants do deserve to know exactly what is expected of them before they enter such an event. That does not sit well with discussions 5 years after the event on where the interpretation of the Rule "is going to".Hmm, I think one of the more recent arguments of Riis was (in essence) that Rule 2 should be taken to mean "original" in the copyright sense (at least for ex post facto application)... About a year ago, Chris Whittington (and maybe Alan Sassler) were arguing similarly regarding the standard in Rule #2. As it was becoming clear that "plagiarism" was going to the the interpretation (rather than copyright), they argued that surely a commercial programmer like VR should be judged by something closer to a copyright standard than some miasmic ivory-tower invention of the ICGA.Rule 2 doesn't say that it is copyright that matters, and it is obvious that even if copyright would allow precisely reproducing the functionality of an existing engine, Rule 2 still forbids two engines that make the exact same moves.
For the purpose of copyright, I would define a "derivative" as a work that shares a copyrighted expression with the original (and was not independently created).A related concern, of how to parse words "original" and "derive/derivative", has also been brought up (by Dalke, and MvK too I think with his code/entry distinction). Dalke went so far as to (in private correspondence) suggest that Levy in his interview deliberately intermixed the casual meaning of derivative with the legal definition (though he also seemed to suggest the latter was poorly-defined, and I must say the USC specification is not too illuminative).
Re: Ideas versus Implementations
As Letouzey put the Fruit issue: copy with different words if you like, similar to a translation. I find the Rybka re-expression of the Fruit expressions typically to fall rather close to translation in this sense. I'm also not sure what role the concrete board representation has? I would say it's like choosing what font to use when printing a file -- there is already suitable expression in the text itself.syzygy wrote:From the point of view of copyright I would say these are still concepts / ideas / algorithms. You can (and do) phrase them in terms of chess pieces and ranks, not in terms of any concrete board representation. The way you express them in natural language is probably protected, but I am free to express them in my own words in natural language (or in source code). (Maybe this is helpful: do you consider that your precise natural language descriptions of the various evaluation features are protected by the copyright on Fruit and/or Rybka?)
Also, there are collative aspects with the evaluation features. For instance, one can re-express Lincoln's "Four score and seven years ago" in many ways ("About 85 years previous to today"), without it being problematic. But if this occurs in the context of remolding his speech (one might continue "our ancestors founded upon this land a bold state in its infancy, with self-determination its battle cry and stamped with the Truth that men stand equal before Justice"), this can encroach copyright at a higher level of abstraction. Any individual evaluation feature might be excusable (as an idea or otherwise), but again to quote Letouzey, the Fruit situation was [n]ot just an extraction of a couple of ideas as is common, and normal.
Again I find this rather categorical. Many computer programs (such as video games) have aspects beyond the mere "functional", though I admit the most copyrightable aspects therein are often shunted out to audiovisual and/or user-experience considerations. For the Fruit/Rybka case, [it is generally admitted that] the desired functionality of the program was to play chess as well as possible (under certain constraints). The ICGA conclusion was that this desired functionality did not overdetermine the choice of evaluation features.Computer programs are not works of fiction full of creative freedom. On the contrary, computer programs are specifically written to provide certain functionality. [...]
If in doubt, ask. (See e.g. Point #10 for QMUL plagiarism). My experience has been that those who don't ask, generally have a reason for not doing so. In the Rajlich case, he was in Turin (the only WCCC he attended, it seems) in 2006, and could see what was going on with LION++.However, participants do deserve to know exactly what is expected of them before they enter such an event.
- Chris Whittington
- Posts: 437
- Joined: Wed Jun 09, 2010 6:25 pm
Re: Ideas versus Implementations
You simply place Vas and any other young programmer into a Catch 22 bind. Fruit and maybe other strong open sources essentially chose a sub list from your "47" possible evaluation features on the basis of most popular. Vas also chose most popular plus a few others. The LIST of eval features can't be copyrightable or protected for this reason else all programmers would be forced to choose a sub-optimal (based on crowd popularity) listing. The analogy with a Lincoln speech is nonsense, of course a speech which could be composed of any mix of 200,000 words is plagiarised/copied at the level you propose. Of course a chess evaluation function which would be composed from 47 (your number) of sub components where some sub components are both highly used/popular and vital to the functionality, is in no way comparable. One is a small subset of a huge list, the other a large subset of a small list where inclusion or not is pre-ordained.BB+ wrote:As Letouzey put the Fruit issue: copy with different words if you like, similar to a translation. I find the Rybka re-expression of the Fruit expressions typically to fall rather close to translation in this sense. I'm also not sure what role the concrete board representation has? I would say it's like choosing what font to use when printing a file -- there is already suitable expression in the text itself.syzygy wrote:From the point of view of copyright I would say these are still concepts / ideas / algorithms. You can (and do) phrase them in terms of chess pieces and ranks, not in terms of any concrete board representation. The way you express them in natural language is probably protected, but I am free to express them in my own words in natural language (or in source code). (Maybe this is helpful: do you consider that your precise natural language descriptions of the various evaluation features are protected by the copyright on Fruit and/or Rybka?)
Also, there are collative aspects with the evaluation features. For instance, one can re-express Lincoln's "Four score and seven years ago" in many ways ("About 85 years previous to today"), without it being problematic. But if this occurs in the context of remolding his speech (one might continue "our ancestors founded upon this land a bold state in its infancy, with self-determination its battle cry and stamped with the Truth that men stand equal before Justice"), this can encroach copyright at a higher level of abstraction. Any individual evaluation feature might be excusable (as an idea or otherwise), but again to quote Letouzey, the Fruit situation was [n]ot just an extraction of a couple of ideas as is common, and normal.
Again I find this rather categorical. Many computer programs (such as video games) have aspects beyond the mere "functional", though I admit the most copyrightable aspects therein are often shunted out to audiovisual and/or user-experience considerations. For the Fruit/Rybka case, [it is generally admitted that] the desired functionality of the program was to play chess as well as possible (under certain constraints). The ICGA conclusion was that this desired functionality did not overdetermine the choice of evaluation features.Computer programs are not works of fiction full of creative freedom. On the contrary, computer programs are specifically written to provide certain functionality. [...]
If in doubt, ask. (See e.g. Point #10 for QMUL plagiarism). My experience has been that those who don't ask, generally have a reason for not doing so. In the Rajlich case, he was in Turin (the only WCCC he attended, it seems) in 2006, and could see what was going on with LION++.However, participants do deserve to know exactly what is expected of them before they enter such an event.
You then Catch 22 the targeted culprit on the basis that any differences between implementations of sub-features (most of which are formulaic) are "translations". GUILTY! If it's the same, he copied. If it's different he translated and copied. Catch 22.
But, of course, as Sven Schule showed on talkchess with reference to mobility functions, the implementations are way more likely in fact to be original writes. The functionality appears similar because it is formulaic.
In summary: the function list is not free choice, nor is each individual implementation. Your COMPEVAL appears to imagine contrarily that subfunction choice is random, and implementation choice is wide. Both of your assumptions are false.
-
- Posts: 1242
- Joined: Thu Jun 10, 2010 2:13 am
- Real Name: Bob Hyatt (Robert M. Hyatt)
- Location: University of Alabama at Birmingham
- Contact:
Re: Ideas versus Implementations
By saying "fruit and others chose ..." you are essentially saying "all anyone can do is copy exactly what Fruit did/does." I don't buy that for a minute. Wonder why Rybka 4 eval is significantly different from Fruit if everyone has to follow Fruit? My program is much stronger than Fruit today, and I didn't find it necessary to do exactly the eval terms Fruit uses. Apparently we match about 25% or so according to Mark's comparison. That leaves a LOT of differences.Chris Whittington wrote:You simply place Vas and any other young programmer into a Catch 22 bind. Fruit and maybe other strong open sources essentially chose a sub list from your "47" possible evaluation features on the basis of most popular. Vas also chose most popular plus a few others. The LIST of eval features can't be copyrightable or protected for this reason else all programmers would be forced to choose a sub-optimal (based on crowd popularity) listing. The analogy with a Lincoln speech is nonsense, of course a speech which could be composed of any mix of 200,000 words is plagiarised/copied at the level you propose. Of course a chess evaluation function which would be composed from 47 (your number) of sub components where some sub components are both highly used/popular and vital to the functionality, is in no way comparable. One is a small subset of a huge list, the other a large subset of a small list where inclusion or not is pre-ordained.BB+ wrote:As Letouzey put the Fruit issue: copy with different words if you like, similar to a translation. I find the Rybka re-expression of the Fruit expressions typically to fall rather close to translation in this sense. I'm also not sure what role the concrete board representation has? I would say it's like choosing what font to use when printing a file -- there is already suitable expression in the text itself.syzygy wrote:From the point of view of copyright I would say these are still concepts / ideas / algorithms. You can (and do) phrase them in terms of chess pieces and ranks, not in terms of any concrete board representation. The way you express them in natural language is probably protected, but I am free to express them in my own words in natural language (or in source code). (Maybe this is helpful: do you consider that your precise natural language descriptions of the various evaluation features are protected by the copyright on Fruit and/or Rybka?)
Also, there are collative aspects with the evaluation features. For instance, one can re-express Lincoln's "Four score and seven years ago" in many ways ("About 85 years previous to today"), without it being problematic. But if this occurs in the context of remolding his speech (one might continue "our ancestors founded upon this land a bold state in its infancy, with self-determination its battle cry and stamped with the Truth that men stand equal before Justice"), this can encroach copyright at a higher level of abstraction. Any individual evaluation feature might be excusable (as an idea or otherwise), but again to quote Letouzey, the Fruit situation was [n]ot just an extraction of a couple of ideas as is common, and normal.
Again I find this rather categorical. Many computer programs (such as video games) have aspects beyond the mere "functional", though I admit the most copyrightable aspects therein are often shunted out to audiovisual and/or user-experience considerations. For the Fruit/Rybka case, [it is generally admitted that] the desired functionality of the program was to play chess as well as possible (under certain constraints). The ICGA conclusion was that this desired functionality did not overdetermine the choice of evaluation features.Computer programs are not works of fiction full of creative freedom. On the contrary, computer programs are specifically written to provide certain functionality. [...]
If in doubt, ask. (See e.g. Point #10 for QMUL plagiarism). My experience has been that those who don't ask, generally have a reason for not doing so. In the Rajlich case, he was in Turin (the only WCCC he attended, it seems) in 2006, and could see what was going on with LION++.However, participants do deserve to know exactly what is expected of them before they enter such an event.
We are not talking about one using the same evaluation "terms". That's not a problem. Everyone does some sort of eval for the usual chess knowledge concepts from weak pawns, to centralization, to you-name it. It is about the specific implementation details that we found a problem. Many do things like weak pawns, or passed pawns, to be sure. But they do NOT do them in lock-step sequences of tests that match as exactly as one can match considering bitboard vs mailbox...
Nope. There is a difference. If you look at WHAT is tested, and WHAT is done as a result of each test, two programs do not naturally match very well. Except for Fruit/Rybka of course...
You then Catch 22 the targeted culprit on the basis that any differences between implementations of sub-features (most of which are formulaic) are "translations". GUILTY! If it's the same, he copied. If it's different he translated and copied. Catch 22.
And if that was the only similarity, one would go "ho hum" and move on. But there are LOTS of ways to do mobility. Fruit and Rybka chose exactly the same one. Ditto for other things that are given in the ICGA report. Find another program that shows that level of similarity to Fruit.
But, of course, as Sven Schule showed on talkchess with reference to mobility functions, the implementations are way more likely in fact to be original writes. The functionality appears similar because it is formulaic.
Actually, both are dead accurate, for reasons already given. For a single idea, there is, by definition, an infinite number of ways to implement that idea. There are a significant number of GOOD ways to implement most ideas. What's the probability that two programmers keep choosing the same answer, over and over? Very small indeed...
In summary: the function list is not free choice, nor is each individual implementation. Your COMPEVAL appears to imagine contrarily that subfunction choice is random, and implementation choice is wide. Both of your assumptions are false.
Re: Ideas versus Implementations
Let's stick what Fabien still believes, Vas took the Fruit source code (everything) made changes and called it his own.BB+ wrote: Any individual evaluation feature might be excusable (as an idea or otherwise), but again to quote Letouzey, the Fruit situation was [n]ot just an extraction of a couple of ideas as is common, and normal.
Re: Ideas versus Implementations
That did not happen. King-safety, Mobility, Pawn eval are the 3 dominant EVAL terms that for 90% decides the performance of the whole EVAL. And like it or not, all 3 are different. Shall I list those differences, or does the statement suffice? Other fundamental differences 1) Fruit evaluates in 2 steps, Rybka in one step, 2) Fruit has only one evaluation table (for King Safety), Rybka 1.0 has many. Together and so far 21 differences between Fruit's and Rybka's EVAL and I am sure I find more if I start to look again.hyatt wrote:Actually, both are dead accurate, for reasons already given. For a single idea, there is, by definition, an infinite number of ways to implement that idea. There are a significant number of GOOD ways to implement most ideas. What's the probability that two programmers keep choosing the same answer, over and over? Very small indeed...
That's not your: "What's the probability that two programmers keep choosing the same answer, over and over? "
Not in the widest vista.
- Chris Whittington
- Posts: 437
- Joined: Wed Jun 09, 2010 6:25 pm
Re: Ideas versus Implementations
I append the crowd sourced popularity list of features below. The first six terms were chosen by all programmers. The second four by all programmers except one, the first thirty terms are each chosen by over half of all programmers. Typical programmer choice was most terms from the most popular grouping and a few from the rest.hyatt wrote:By saying "fruit and others chose ..." you are essentially saying "all anyone can do is copy exactly what Fruit did/does." I don't buy that for a minute. Wonder why Rybka 4 eval is significantly different from Fruit if everyone has to follow Fruit? My program is much stronger than Fruit today, and I didn't find it necessary to do exactly the eval terms Fruit uses. Apparently we match about 25% or so according to Mark's comparison. That leaves a LOT of differences.Chris Whittington wrote:You simply place Vas and any other young programmer into a Catch 22 bind. Fruit and maybe other strong open sources essentially chose a sub list from your "47" possible evaluation features on the basis of most popular. Vas also chose most popular plus a few others. The LIST of eval features can't be copyrightable or protected for this reason else all programmers would be forced to choose a sub-optimal (based on crowd popularity) listing. The analogy with a Lincoln speech is nonsense, of course a speech which could be composed of any mix of 200,000 words is plagiarised/copied at the level you propose. Of course a chess evaluation function which would be composed from 47 (your number) of sub components where some sub components are both highly used/popular and vital to the functionality, is in no way comparable. One is a small subset of a huge list, the other a large subset of a small list where inclusion or not is pre-ordained.BB+ wrote:As Letouzey put the Fruit issue: copy with different words if you like, similar to a translation. I find the Rybka re-expression of the Fruit expressions typically to fall rather close to translation in this sense. I'm also not sure what role the concrete board representation has? I would say it's like choosing what font to use when printing a file -- there is already suitable expression in the text itself.syzygy wrote:From the point of view of copyright I would say these are still concepts / ideas / algorithms. You can (and do) phrase them in terms of chess pieces and ranks, not in terms of any concrete board representation. The way you express them in natural language is probably protected, but I am free to express them in my own words in natural language (or in source code). (Maybe this is helpful: do you consider that your precise natural language descriptions of the various evaluation features are protected by the copyright on Fruit and/or Rybka?)
Also, there are collative aspects with the evaluation features. For instance, one can re-express Lincoln's "Four score and seven years ago" in many ways ("About 85 years previous to today"), without it being problematic. But if this occurs in the context of remolding his speech (one might continue "our ancestors founded upon this land a bold state in its infancy, with self-determination its battle cry and stamped with the Truth that men stand equal before Justice"), this can encroach copyright at a higher level of abstraction. Any individual evaluation feature might be excusable (as an idea or otherwise), but again to quote Letouzey, the Fruit situation was [n]ot just an extraction of a couple of ideas as is common, and normal.
Again I find this rather categorical. Many computer programs (such as video games) have aspects beyond the mere "functional", though I admit the most copyrightable aspects therein are often shunted out to audiovisual and/or user-experience considerations. For the Fruit/Rybka case, [it is generally admitted that] the desired functionality of the program was to play chess as well as possible (under certain constraints). The ICGA conclusion was that this desired functionality did not overdetermine the choice of evaluation features.Computer programs are not works of fiction full of creative freedom. On the contrary, computer programs are specifically written to provide certain functionality. [...]
If in doubt, ask. (See e.g. Point #10 for QMUL plagiarism). My experience has been that those who don't ask, generally have a reason for not doing so. In the Rajlich case, he was in Turin (the only WCCC he attended, it seems) in 2006, and could see what was going on with LION++.However, participants do deserve to know exactly what is expected of them before they enter such an event.
We are not talking about one using the same evaluation "terms". That's not a problem. Everyone does some sort of eval for the usual chess knowledge concepts from weak pawns, to centralization, to you-name it. It is about the specific implementation details that we found a problem. Many do things like weak pawns, or passed pawns, to be sure. But they do NOT do them in lock-step sequences of tests that match as exactly as one can match considering bitboard vs mailbox...
Nope. There is a difference. If you look at WHAT is tested, and WHAT is done as a result of each test, two programs do not naturally match very well. Except for Fruit/Rybka of course...
You then Catch 22 the targeted culprit on the basis that any differences between implementations of sub-features (most of which are formulaic) are "translations". GUILTY! If it's the same, he copied. If it's different he translated and copied. Catch 22.
And if that was the only similarity, one would go "ho hum" and move on. But there are LOTS of ways to do mobility. Fruit and Rybka chose exactly the same one. Ditto for other things that are given in the ICGA report. Find another program that shows that level of similarity to Fruit.
But, of course, as Sven Schule showed on talkchess with reference to mobility functions, the implementations are way more likely in fact to be original writes. The functionality appears similar because it is formulaic.
Actually, both are dead accurate, for reasons already given. For a single idea, there is, by definition, an infinite number of ways to implement that idea. There are a significant number of GOOD ways to implement most ideas. What's the probability that two programmers keep choosing the same answer, over and over? Very small indeed...
In summary: the function list is not free choice, nor is each individual implementation. Your COMPEVAL appears to imagine contrarily that subfunction choice is random, and implementation choice is wide. Both of your assumptions are false.
I assert that the list of terms and the usage of a particular set of terms is NOT copyrightable. Anybody is free to choose the most popular terms, for example, and construct an evaluation based on it, if that list clashes, whole or in part with another program, that is a) quite likely and b) perfectly acceptable. Comparisons to "chapter headings in books", or "words in poems" or "Lincoln Speeches" or "list of 100 best chess games" are irrelevent, simply because in the latter cases the choice is a small list of components from a huge list of possibles. Our chess evaluation function consists of a relatively long list from a very small total set, where the choice is made on grounds of functionality and efficiency. Essentially the chess evaluation function list does not contain creative choice in a copyright sense.
I also assert that the question of proof of copy or not comes down ONLY to the quality of the comparison for each and every term. It does NOT come to the choice of terms (the list) since these are not free choice. Mark Watkins has made a start on comparison quality in the paper EVALCOMP, the next step is to take a look at his method and figures and determine where he has gone wrong.
Crowd sourced sub-function popularity data (from 23 programs/programmers)
First column is count who chose that feature, second column is percentage who chose it, 1.00 = 100%
Note that design choices already made (bitboard, keep it simple, etc) will further focus choice on particular functions. For example, bitboard programmers will be more inclined than mailboxers to include mobilities because of computational cheapness, etc.
23 1.00 Rooks on 7th
23 1.00 Doubled pawns
23 1.00 Isolated pawns
23 1.00 Passer initial bonus
23 1.00 Rook open file
23 1.00 King shelter by pawns
22 0.96 Bishop mobility
22 0.96 Bishop pair
22 0.96 Backward pawns
22 0.96 Rook semi open file
21 0.91 Passer, free runner
21 0.91 King danger from pieces, method
21 0.91 Draw recognition
20 0.87 King danger, when to use
19 0.83 Unstoppable passer, races
19 0.83 King danger, relative to attackers
18 0.78 Passer, king involvement
18 0.78 Rook mobility
18 0.78 Game phase
17 0.74 Material imbalance
17 0.74 Trapped bishops
16 0.70 Lazy eval
16 0.70 Castling bonus
15 0.65 Knight mobility
15 0.65 Candidate passed pawn
15 0.65 Opposite Bishop ending
14 0.61 Knight outposts
13 0.57 Special endgame code
13 0.57 Blocked rooks
12 0.52 General development
11 0.48 Blocked centre pawns, bishops
11 0.48 Queen mobility
11 0.48 Pawn duos
10 0.43 King pawn storm
10 0.43 Queen 7th rank
10 0.43 Pawn centre
9 0.39 Tempo
9 0.39 Bad bishops
9 0.39 Early development Queen
7 0.30 Bishop knight in ending
7 0.30 Knight trapped
6 0.26 Hung pieces, pins
4 0.17 Pawn immobility
4 0.17 Bishop outposts
3 0.13 Pawn guards
2 0.09 Pawn strcuture drawishness
1 0.04 Pawn outpost