hyatt wrote:Chris Whittington wrote:BB+ wrote: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?)
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.
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.
Computer programs are not works of fiction full of creative freedom. On the contrary, computer programs are specifically written to provide certain functionality. [...]
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.
However, participants do deserve to know exactly what is expected of them before they enter such an event.
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++.
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.
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.
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...
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.
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...
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.
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.
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.
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...
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.
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