Crafty accused of copying Fruit PST

[Dirt]

I agree with you fully that formulars are not copyrightable, and i add
that reversed engineered ideas,formulas are a matter of interpretation, opinion.
It is not possible to give 100% centainty that what someone interprets is inteded to be the point.

Even if an individual formula isn't copyrightable, if you use 100 formulas and 99 are the same as in another program, that probably is a violation.

[rbarreira]

As a result, you have provided zero convincing arguments but almost 100% attempts of changing the topic, or not wanting to understand. That is annoying and disappointing.

^ Actually it is quite normal from what I've seen...

[Sven]

I agree with you fully that formulars are not copyrightable, and i add
that reversed engineered ideas,formulas are a matter of interpretation, opinion.
It is not possible to give 100% centainty that what someone interprets is inteded to be the point.

Even if an individual formula isn't copyrightable, if you use 100 formulas and 99 are the same as in another program, that probably is a violation.

If it were as you say, then where would be the borderline? At 50? 10? 90? Why is using one non-copyrightable item no violation but using N+1 non-copyrightable items a copyright violation for some N?

Sounds wrong to me.

Sven

[marcelk]

Sub term 2 = "king support of passer"
Formula = "multiply distance of king to square in front of the pawn by a constant bonus; use different constants for friendly and enemy king"

NOTE: The above formula is from Fruit 2.1. I just found that Mark Watkins missed that Fruit does _not_ use a rank-based bonus constant in this case, despite Rybka, when he wrote in EVAL_COMP.pdf on page 33:

Fruit 2.1, Rybka 1.0 Beta, and Rybka 2.3.2a give a rank-based bonus/penalty (with 10-30-60-100 scaling) times the distance of the square in front of the pawn to the respective kings.

Fruit 2.1, eval.cpp:

Code: Select all

// king-distance bonus

delta -= pawn_att_dist(sq,KING_POS(board,att),att) * AttackerDistance;
delta += pawn_def_dist(sq,KING_POS(board,def),att) * DefenderDistance;

That is a bit insincere, because immediately below the lines you quote the calculated delta gets folded into quad() which does what Mark states... (that is, scale with 10-30-60-100)

Code: Select all

         // endgame scoring

         eg[att] += min;
         if (delta > 0) eg[att] += quad(0,delta,rank);

Are these formulas protected by copyright? I say "no".

Sven

Formulas might not be. Collections of formulas can be protected by copyright.

But mind that ICGA rule #2 doesn't talk about copyright and that consequently Rybka was not judged on that aspect, so the point is somewhat moot.

[Sven]

Sub term 2 = "king support of passer"
Formula = "multiply distance of king to square in front of the pawn by a constant bonus; use different constants for friendly and enemy king"

NOTE: The above formula is from Fruit 2.1. I just found that Mark Watkins missed that Fruit does _not_ use a rank-based bonus constant in this case, despite Rybka, when he wrote in EVAL_COMP.pdf on page 33:

Fruit 2.1, Rybka 1.0 Beta, and Rybka 2.3.2a give a rank-based bonus/penalty (with 10-30-60-100 scaling) times the distance of the square in front of the pawn to the respective kings.

Fruit 2.1, eval.cpp:

Code: Select all

// king-distance bonus

delta -= pawn_att_dist(sq,KING_POS(board,att),att) * AttackerDistance;
delta += pawn_def_dist(sq,KING_POS(board,def),att) * DefenderDistance;

That is a bit insincere, because immediately below the lines you quote the calculated delta gets folded into quad() which does what Mark states... (that is, scale with 10-30-60-100)

Code: Select all

         // endgame scoring

         eg[att] += min;
         if (delta > 0) eg[att] += quad(0,delta,rank);

That is correct, I'm sorry, I missed that point. You are absolutely right! So my NOTE above is wrong.

Are these formulas protected by copyright? I say "no".

Formulas might not be. Collections of formulas can be protected by copyright.

But mind that ICGA rule #2 doesn't talk about copyright and that consequently Rybka was not judged on that aspect, so the point is somewhat moot.

I don't think we should restrict this discussion to the one aspect "what is/was relevant for the ICGA decision". But even if we do, I do not see that difference. Rule #2 includes basically this:

Programming teams whose code is derived from or including game-playing code written by others must name all other authors, or the source of such code, in their submission details.

and thereby refers to code only, not to "originality of concepts". The term "code is derived from or including game-playing code written by others" is not really far away from the "licensing/copyright" topic. I don't know who brought up that claim the ICGA would require more than that. I consider it simply as not true.

Sven

[Dirt]

I agree with you fully that formulars are not copyrightable, and i add
that reversed engineered ideas,formulas are a matter of interpretation, opinion.
It is not possible to give 100% centainty that what someone interprets is inteded to be the point.

Even if an individual formula isn't copyrightable, if you use 100 formulas and 99 are the same as in another program, that probably is a violation.

If it were as you say, then where would be the borderline? At 50? 10? 90? Why is using one non-copyrightable item no violation but using N+1 non-copyrightable items a copyright violation for some N?

Sounds wrong to me.

Sven

It's a matter of whether there is any reasonable chance of you coming up with the idea on you own. The same formula might happen, but all of them the same implies copying. The precise number is what courts are for, but it is usually pretty obvious.

[marcelk]

But mind that ICGA rule #2 doesn't talk about copyright and that consequently Rybka was not judged on that aspect, so the point is somewhat moot.

I don't think we should restrict this discussion to the one aspect "what is/was relevant for the ICGA decision".

Agreed. But it is an important distinction to make. The panel's charter was restricted to the ICGA rules and specifically #2. It is my opinion that the copyright question is a lot more difficult to answer and that the panel wouldn't be qualified for it. Luckily they weren't asked to do so.

But even if we do, I do not see that difference. Rule #2 includes basically this:

Programming teams whose code is derived from or including game-playing code written by others must name all other authors, or the source of such code, in their submission details.

and thereby refers to code only, not to "originality of concepts". The term "code is derived from or including game-playing code written by others" is not really far away from the "licensing/copyright" topic. I don't know who brought up that claim the ICGA would require more than that. I consider it simply as not true.

Sven

There are many differences between copyright and rule #2. They have overlap but one is not the subset of another and therefore the differences matter a lot.

Code can be understood at many abstraction levels that can each have copyrightable elements. Exactly like the plot of a story still falls under copyright even if many of the details such as names, setting and language are changed. See Hollywood.

At one abstraction level translating from ASCII to EBDIC makes a program different. At another each chess program is like any other chess program.
The abstraction levels that are relevant here are the ones that the ICGA members intend with their rule set, not the ones that other people guess that are intended. There is for example a very elaborate article titled "Interpretation of the rules", published in an older ICGA Journal, that discusses this rule in more detail. And there are prior rulings that give the wording a meaning in the context of ICGA events.

One big difference is that copyright law (in the USA at least) allows derived works to become free of copyright claims by the original author once sufficient changes have been made to it, even if fragments of the original work remain. In the ICGA rules this is clearly not the case. For example DB was seen as a derivative of Belle, whereas their transistor level designs ("code") are nothing alike at all. Under copyright law this would likely not be considered a conflict, but for the ICGA it was. Important is that all this was properly explained by the DB team and approved by the Belle designers so there was no problem entering it in the tournaments.

For Rybka the individual concepts were not the problem. The problem was including the entire set of evaluation elements as a starting point and not disclosing that this was done, causing the TD to make an uninformed decision about whose entries to accept. I'm quite sure that if the construction method of Rybka had been disclosed upfront, Fabien would have been consulted and after consideration Rybka might have entered without further problems. The problem is that this information was withheld from the TD.

[Desperado]

Sub term 2 = "king support of passer"
Formula = "multiply distance of king to square in front of the pawn by a constant bonus; use different constants for friendly and enemy king"

NOTE: The above formula is from Fruit 2.1. I just found that Mark Watkins missed that Fruit does _not_ use a rank-based bonus constant in this case, despite Rybka, when he wrote in EVAL_COMP.pdf on page 33:

Fruit 2.1, Rybka 1.0 Beta, and Rybka 2.3.2a give a rank-based bonus/penalty (with 10-30-60-100 scaling) times the distance of the square in front of the pawn to the respective kings.

Fruit 2.1, eval.cpp:

Code: Select all

// king-distance bonus

delta -= pawn_att_dist(sq,KING_POS(board,att),att) * AttackerDistance;
delta += pawn_def_dist(sq,KING_POS(board,def),att) * DefenderDistance;

That is a bit insincere, because immediately below the lines you quote the calculated delta gets folded into quad() which does what Mark states... (that is, scale with 10-30-60-100)

Code: Select all

         // endgame scoring

         eg[att] += min;
         if (delta > 0) eg[att] += quad(0,delta,rank);

Are these formulas protected by copyright? I say "no".

Sven

Formulas might not be. Collections of formulas can be protected by copyright.

But mind that ICGA rule #2 doesn't talk about copyright and that consequently Rybka was not judged on that aspect, so the point is somewhat moot.

The _only_ thing which is moot now after 2 or 3 years of discussions is
_open source_ philosophy!

First:

I honor and thank the authors of open sources, in every area not only
chess programming. The reason is very simple, i learned a lot from these sources,
got inspiration and improved on the fly my programming skills.
That did not prevented me from reinvent some wheels!

But:

_IMHO_ every developer who decides unsolicited to public a source,
_should_ also forfeit any rights on the code. There will never exist a
license without lacks. Moreover it is a contradiction to open sth but want
to keep it (or some rights on it) for yourself at the same time.

so if you want to protect(as good as possible) your source:

* dont open it!

if you open your source:

* do it without restrictions!

It doesnt matter which expressions,values,sample of code are discussed.
Even if it is coded 1:1 there is room left for interpretation.
As long as opinions are possible there will no conclusion of what is right or wrong.
Now if we would be able to answer at this level what is right/wrong without
room for opinions, just based on rules and facts, the next level will open
the door for eternity, where no facts do exist and every discussion is
based on personal opinions: like where is the border of real wrong doing
concerning rules and facts and what is moral wrong doing.

i can also give you a bottle of wine, filled half with wine and ask
you: is it halfFilled/halfEmpty. Now, at least i will answer it is 100%
filled! Nobody defined filled with what. So my interpretation,assumtion
is wine and air.

Now the whole thing is a bottomless discussion which will never end,
until people accept opponents opinions and arguments, which does
not mean to go hand in hand with it. At least starting making definitions
woud be a good idea, so we can leave the area of interpretation step
by step. Definitions are the base of every discussion, and i miss them
now for 3 years.


Facts are:

- did Bob sth wrong ?
* 100% No (and was never intended by Miguel to point out as i understood!)

- is Bobs interpretation/opinion the only correct one ?
* of course a clear no, also. Alone that there is objectivly room for
discussion excludes the possibility.

- do i accept different interpretations/opinions ?
* yes, i do, as long as it works in both directions and argumention is factual.

- now after 3 years i entered the discussion. Why ?
* it is annoying to see people repeating themselves
over and over again, over many many years. Boring, too.
i dont see any productivity in all these discussion, so a goal of
all incoroparated people (who fight for there rights only)
should not be to change and evaluate the past,
but concentrate on future events. If everyone over the last
3 years would have worked on that and spent his time working on
a better open-source system, we may be able to avoid these
kind of discussion the next decade. What happend has happend.
What will happen depends on the community! Isnt there a demand
to reach such a goal, instead repeating themself the next years ?

It is sad, imo! Hopefully some of you will begin to accept different
opinions based on facts. Both side have good arguments. Thats the crux.
And start continuing ...

regards Michael

[marcelk]

_IMHO_ every developer who decides unsolicited to public a source,
_should_ also forfeit any rights on the code. There will never exist a
license without lacks. Moreover it is a contradiction to open sth but want
to keep it (or some rights on it) for yourself at the same time.

so if you want to protect(as good as possible) your source:

* dont open it!

if you open your source:

* do it without restrictions!

It doesnt matter which expressions,values,sample of code are discussed.
Even if it is coded 1:1 there is room left for interpretation.
As long as opinions are possible there will no conclusion of what is right or wrong.
Now if we would be able to answer at this level what is right/wrong without
room for opinions, just based on rules and facts, the next level will open
the door for eternity, where no facts do exist and every discussion is
based on personal opinions: like where is the border of real wrong doing
concerning rules and facts and what is moral wrong doing.

I tend to agree with you. At first (before the Vas interview that is) I was not in agreement with the severity of the penalty. Yes the rules were breached, but by a program that brought a lot of innovation to the table. That could have been a signal to reflect and reconsider the rules themselves. However the given sanction firmly closes that road for the ICGA...

In an alternative universe derivatives would be welcomed without restriction. If you release your code, you might face an improved version of your program in a competition. Let it be. Chess programs are going to converge more and progress is going to be harder, so we must find ways to deal with detecting smaller strength differences between increasingly similar programs anyway. I see no reason people have to write move generators from scratch if they wish to contribute to computer chess progress. It is hard enough as it is already, there is a lot of talent out there but this 100% original thing is a big threshold for many people.

One of the justifications for the phrasing of rule #2 is a 1970s argument that derivatives would have a disproportionate chance of winning a limited rounds tournament. Well, that is a solvable problem with automated play and modern statistics as demonstrated on the Internet rating lists. It is a computer chess tournament, not a human chess tournament, so you can play as many games as you need to establish a desired likelihood of superiority of the champion.

The ICGA definitely missed an opportunity here to reform (or choose not to do so but I doubt this was a consideration).

[bob]

I get the point. But what you are saying is occurring way too late. You are saying "OK, I have an idea, I have designed it, I have flow-charted the code, so now there is only one way to write it."

But if you stop above the level of what is commonly called the architectural design (or detailed design) then your statement makes no sense. Because at that level, you have decided on what you are going to do, and what you want to test to pull this off, but you have not gotten to the how. Which means there are many possible choices.

This would apply to most any evaluation term. Because even good chess books generally don't define an evaluation concept at a level low enough to let us convert it to code directly.

I agree, once you have an architectural design, your hands are pretty much tied. But just deciding to evaluate some concept like a weak pawn, or more specifically a backward/isolated pawn, most definitely does _not_ tie your hands as to how it will / can be implemented.

Simple idea: I want to implement "square of the king" where if a passed pawn is inside the square of the enemy king, it can't run in and promote, while if it is outside the square of the king, it can. Well known idea. Now how to implement it? Two different approaches, one for bitboard, one for mailbox. But you are not done, because there are another few wrinkles to deal with. What about the case where both sides have a passed pawn that can't be caught? But one queens with check? A wrinkle. How to implement this detail? Several choices. Another wrinkle, once you get to the detailed design stage. Are you certain that if the pawn is in the square of the king, the king can reach it? Worst case is king is on a diagonal that is the only way to catch the pawn. What if there is a friendly pawn on the diagonal? King is blocked and can't catch it even though it is technically in the square of the king. What if there is an enemy pawn on that diagonal? Ah, you can capture it and continue chasing and catching the pawn. But what if the pawn is defended? Shoot. Blocked again.

That single piece of code has a ton of different implementations. Your hand is not tied until the very end.

Yes, for a simple term, like "is this rook on an open file?" You might just have one way to answer that. With bitboards, an AND with the right mask will do the trick. With mailbox, you can scan the file to see if there are any pawns on it. Or you can do as we did in Cray Blitz and update a set of file flags to identify which files are open/closed, when we Make/Unmake moves, which saves time. So maybe rook on open file is not so "forced"?

And this goes on and on, somethings done in eval, some done in make/unmake, and some have even counted mobility in the move generator. So saying that once you decide on an idea, you are stuck as to how to implement it doesn't make a lot of sense to me... In fact, we often add new ideas in Crafty "quick and dirty" for testing. If the results look promising, I go back and rewrite "fast and clean" which should make the results even better. And it is not uncommon to later find a better way to implement that idea that is even faster. Or more accurate. Or both.

I don't buy this "one way to write something" argument for anything but the simplest of chess-specific ideas...

For knight mobility, since you asked, I have done it in the following ways in Crafty over the years:

(1) I started with slate's attacks-from and attacks-to bitboards. I just extracted the attacks-from for the square the knight was on, which already had all the attack bit set, and popcnt'ed that and multiplied by a constant C.

(2) Later, I added a second table that contained the popcnt() values for all knight attacks on all squares. Now a table lookup and I get the answer without the popcnt() cost (back prior to the hardware popcnt instruction of course.

(3) Later I decided that mobility is not just about how many moves you have, but about which squares you are attacking (we do this today). We have a set of 4 weights. I AND away all bits but the center 4 squares, and multiply by the center square weight. I then AND away all bits but the next 'ring" and multiply the popcnt of that with that ring's weight. Repeated 4 times.

(4) early on, I removed squares from the mobility for pieces if the square was attacked by a piece. That was easy with the "attacks-to" bitboard from Slate's book chapter, where for any square, I can obtain a bitmap that shows all other squares that are attacking that square, both friend and foe. From that I can determine how many attacks by each side, and by which pieces. Lots of choices to play games here. Mobility to a square you attack less than the opponent is not very useful. Mobility to a square attacked by an enemy pawn is certainly not very useful.

Do I need to continue?

This is like saying that once you know you need to sort something, there is only one way to sort it. Not so fast. Bubble sort. Heap sort. Even an insertion/selection sort will work depending on the other details of how it is used...

I simply don't buy this "once you specify the idea, the implementation details become fixed." My experience is completely the opposite. I rarely see just one way to do anything. The trick is to see the "best way". Hopefully the first time you implement it, otherwise the second, or the third.

I am sure that you don't get the point yet, unless you prove that you have understood the meaning of the term "formula" in my post above.

I am tired to repeat these simple things over and over again. I did not ask for different ways to implement the same eval criterion but to implement a specific formula that has been chosen for that criterion.

Criterion = "knight mobility"
Formula = "count all pseudo-legal moves of the knight and multiply by a bonus"

And there we will _never_ agree. How do you (a) count all pseudo-legal moves"? pre-computed ala' Slate? Popcnt? Table lookup? is bonus a single value? an array of values? are the "pseudo-legal" moves reduced by removing certain types?

You want to reduce mobility to a single idea. Here's a better one I have proposed before. Define the chess engine as a formula F, given a position P, such that best-move = F(P) and now nothing is protected from copying, the entire chess engine is just a simple expression, correct?

Or, there are a _lot_ of ways to implement that chess engine. Just as there are a _lot_ of ways to implement a simple mobility evaluation. Again, the copyright case law and reviews refer to this as "chicanery" which is not flattering. It simply means "trickery with words to change the meaning / intent of the process."

Your approaches (3) and (4) do not implement that formula but a different one. And your approach (2) is nothing but an optimization attempt from past times which most people will no longer use today.

I use it. It is just as accurate as popcnt() and certainly faster.

Your obvious misunderstanding of the concept "formula" as I use it makes most of your post void.

The point is also that many evaluation formulas are that simple. Few are more complex than that, like formulas in the domains "king safety" or "passed pawns". But complex eval features like "passed pawns" are divided into simpler and smaller parts, and for each part you define a formula on the logical level which is simple enough to implement it.

Here is a complete and realistic example:

Eval criterion = "passed pawn"
Precondition: pawn has been found to be a passer

The following sub terms and the following calculation formulas are selected by the programmer:


Sub term 1 = "initial bonus"
Formula = "assign rank-based bonus, where lower distance to promotion square leads to higher bonus and vice versa"

I'll buy that as too simple to copyright, no argument.

Sub term 2 = "king support of passer"
Formula = "multiply distance of king to square in front of the pawn by a constant bonus; use different constants for friendly and enemy king"

Won't buy that because there are other things one might choose to add. And that would make my formula different from your formula and this conversation becomes moot.

NOTE: The above formula is from Fruit 2.1. I just found that Mark Watkins missed that Fruit does _not_ use a rank-based bonus constant in this case, despite Rybka, when he wrote in EVAL_COMP.pdf on page 33:

Fruit 2.1, Rybka 1.0 Beta, and Rybka 2.3.2a give a rank-based bonus/penalty (with 10-30-60-100 scaling) times the distance of the square in front of the pawn to the respective kings.

Fruit 2.1, eval.cpp:

Code: Select all

// king-distance bonus

delta -= pawn_att_dist(sq,KING_POS(board,att),att) * AttackerDistance;
delta += pawn_def_dist(sq,KING_POS(board,def),att) * DefenderDistance;

where "pawn_att_dist(pawn, king, colour)" and pawn_def_dist(...) both simply return "DISTANCE(king, pawn + PAWN_MOVE_INC(colour))".


Sub term 3 = "freedom of passer to advance"

Sub term 3.1 = "lack of any friendly piece on promotion path"
Formula = "assign rank-based bonus if condition is true"

Again, chicanery. How do you test for piece on promotion path? Compute at point of need? Compute incrementally in make/unmake?

Sub term 3.2 = "lack of any enemy piece on promotion path"
Formula = "assign rank-based bonus if condition is true"

Sub term 3.3 = "every square on promotion path is defended at least as much as it is attacked"
Formula = "assign rank-based bonus if condition is true"

Too complicated to even argue about. how do you measure whether each square is attacked more or defended more? Just raw attacks? SEE score? Do you keep up with that incrementally or compute at time of need? You can't ask complex questions and pretend there is just one and only one way to answer them. As you reach the above question, there are literally a dozen different things one might add. Each with varying cost that has to be considered vs the gain in accuracy.

Sub term 4 = "unstoppable passer"
Precondition: enemy has only the king left

Sub term 4.1 = "enemy king is outside the 'pawn square'"
Formula = "assign constant high bonus if the condition is true"

Same problem. Too many choices. Is there a critical path the king must traverse to stop the pawn? If so is the path blocked by own pieces which means the king loses the race, or is the path blocked by opponent pawns or king attacks which also means that king loses. Are there unstoppable pawns for both sides? Which queens first. How many moves faster? 2 or more and it is winning unless the other king is there to assist the other pawn in promoting. Does the winner queen with check giving it time to get back and stop the opponent's queener? Is the opponent's king close enough so that if it escapes check it is close enough to assist the pawn in promoting. What if the side that queens first is not a check, but the other side does queen with check? Is the king on the same diagonal with its newly created queen so that the checking queen x-rays the king and when it moves aside rips the new queen and wins? I have done all of those at various times in Crafty and Cray Blitz. You can't get away with calling that a "condition" that enables the use of a formula.

You are trying to abstract EVERYTHING far enough away so that there are just vague concepts that you then say can't be copyrighted. But that is NOT what copyright law says. What you are defining is NOT a formula. The precondition itself is copyrightable as it is not a formula. If there is more than one way to implement your "formula" it is also copyrightable. That's the point.

Sub term 4.2 = "friendly king suffficiently guards the passer"
Formula = "assign constant high bonus if this condition is true and condition 4.1 is false"

Similar to previous example and contains the same flaw in the argument.

NOTE: the choice of the formulas 4.1 and 4.2 includes the logical decision to ignore the level of advancement of unstoppable passers in case both sides have one. Taking this into account would mean to use a different formula, as in Rybka2.3.2a.

I agree that the implementation of terms 4.1 and 4.2 is relatively more complex and "non-intuitive" than all others mentioned here. But nevertheless you will not find copied code for these two in Rybka, it is only the formula that you may find.


Are these formulas protected by copyright? I say "no".

Sven

I would say "absolutely yes" using existing case law posted by Mark W previously... Because what you are calling conditions and formulas are actually significant blocks of code that can be implemented in many different ways, thus not giving up their "copyrightability" at all.