Functionality of programs not protected by copyright

[syzygy]

In addition, according to the Court, there is no copyright infringement where, as in the present case, the lawful acquirer of the licence did not have access to the source code of the computer program but merely studied, observed and tested that program in order to reproduce its functionality in a second program.

The idea here being that what can be copied in this way is only functionality, and functionality is not copyrightable. So such copying is not "copying" in the sense of copyright law. By chance you could end up with identical source code, but the copyrightable elements in that code have then been independently created.

If you did have access to source code, common copyrightable elements in the source code cannot be so easily explained away by the argument of independent creation of the copyrighted elements.

For Rybka/Fruit, it seems to me the main contention is what ideas/principles (and "element") means in #30-31

The decision makes clear that everything that is part of the functionality of the program is not copyrightable:

40 As the Advocate General states in point 57 of his Opinion, to accept that the functionality of a computer program can be protected by copyright would amount to making it possible to monopolise ideas, to the detriment of technological progress and industrial development.

41 Moreover, point 3.7 of the explanatory memorandum to the Proposal for Directive 91/250 [COM (88) 816] states that the main advantage of protecting computer programs by copyright is that such protection covers only the individual expression of the work and thus leaves other authors the desired latitude to create similar or even identical programs provided that they refrain from copying.

So similarity in expression has to be looked for below the level of the functionality. You have to look for similarity in source code and structure of source code, abstracting away all similarity in functionality.

If you look at how Fruit calculates bishop mobility using four loops, the expression can be found in the four loops (of course too trivial to be copyrighted, but that's another point), not in the fact that it counts the number of attacked squares not occupied by friendly pieces. The latter is functionality.

[BB+]

For that case the judgment certainly leaves some room for interpretation of "with the aid of".

If you did have access to source code, common copyrightable elements in the source code cannot be so easily explained away by the argument of independent creation of the copyrighted elements.

I am also not sure what "with the aid of" means exactly. This goes someone beyond the traditional rubric, which was the two-fold: access and substantial similarity.

At any rate, here is a (partial) listing of things in Rybka 1.0 Beta which would not be likely to appear w/o the aid of the Fruit 2.1 source code.

[*] Redundancies in code -- a reimplementation of functionality should have no reason to replicate these. The principal two examples of this are the BadThreshold "flag" clearing, and the Delay clearing and double computation of (infinite || ponder) in the search wrapper. Multiplying time_limit_1 by 5 (or 5.0) is a third example.

[*] Ordering (and structuring) in code -- again a reimplementation purely at the level of functionality need not retain these. The examples here include: mixing of UCI and time management (almost all other programs, such as Rybka 1.6 from 2004, separate these), ordering of root search operations, ordering within piece-types in evaluation (e.g., for rooks, both Rybka/Fruit do: mobility, then (half-)open file with opposing king safety checked via abs(x)<=1 then abs(x)=0 a further subcase [rather than splitting into abs(x)=1 and abs(x)=0 cases], and finally 7th rank [again with subconditions checked in the same arbitrary order]), and the ordering(s) in the iterative deepening.

There are admittedly some examples where code ordering is not the same, but the above (a quite incomplete list) is probably already beyond what one would get from a probabilistic accounting. Or as Learned Hand put it: no plagiarist can excuse the wrong by showing how much of his work he did not pirate.

[*] Ordering/grouping of data structures: here examples include: SearchRoot, with particularly the 6 variables used in iterative deepening allocated the same -- note also that there is no reason to group all 6 of these together in the first place, and indeed other programs will often (say) split bad/last_value from easy/change [if they have corresponding such]; Searching/Infinite/Delay in protocol.cpp with again the 3 variables localised together in the same order, for no compelling reason; the grouping in SearchInfo, with jmp_buf, node checking, and last_time (here the Rybka structure starts with the jmp_buf, but then diverges slightly, as last_time is not a double); the hashing structure (entry_t), with Rybka merely swapping bytes 8-11 with 12-15...

I think the above should suffice to rebut a claim that Rybka 1.0 Beta merely replicated the "functionality" of Fruit 2.1. [The above (partial) listing was not of the most immediate relevance to the ICGA investigation, of course].

[BB+]

There is a difference though, namely the fact that Vas obviously did have access to Fruit's source code. [...] Personally I don't believe that just carefully looking at it (certainly in a case where the source code was meant to be looked at) makes a decisive difference.

I think you greatly under-rate the premise of access to source code here. Standard practise in clean-room implementations is to strictly segregate those who have seen the source code from those who are re-implementing. Under your schema, I really don't see why one would take such a measure? Things are even worse in (say) the music industry, where fear of unintentional infringement after exposure to a work is so great that unsolicited works are returned unopened.

It is also seems rather overbearing to me to say that one viewed the source code of a competing program, and yet only took "functionality" from it; unless the defendant can advance evidence toward such a claim (via clean-room or something), this seems like a schoolyard defense. In any event, substantial similarity should be the yardstick for this [see previous post for an enumeration]. Maybe VR should have said "I examined the Fruit functionality forwards and backwards and took many things..."

Your parenthetical comment is also worrisome to me; the source code was meant to be looked at provided certain conditions were met. Looking at the source code and then producing a substantially similar competing product "with the aid of" it would seem to necessitate GPL compliance. [Unless one holds a strict copy/paste notion of "copying", which copyright does not].

[BB+]

You can't write a program identical to Fruit without writing an evaluation function that gives identical results, i.e. that has all the same evaluation features.

The latter is incorrect, and I think it undermines your argument substantially. It is perfectly possible to replicate the functionality of the Fruit evaluation function w/o using the same evaluation features. For instance, one might split the knight mobility into forward/backward, and happen (at a certain stage of development of the engine) to have the same score for each. This would be counted as different for evaluation features. Or one could have have a bonus for RookOn7th and opponent's pawn on 7th, another for RookOn7th and opponent's king on 8th, and a third (which happens to subtract off the two) for RookOn7th and both conditions. To use your (bishop) mobility example, one could count all squares attacked as one feature, and then have a second feature to subtract off those occupied by a friendly piece.

I admit the above three are a bit contrived (though certainly within the realm of what an implementer might do -- forwards/backwards mobility might want to be counted separately at a future time, etc.). So to recall an example actually in Fruit/Rybka (see above), the rook evaluation uses adjacent-or-on files and then subcases to on-this-file, whereas one could just as well split this as adjacent-but-not-on files and on-this-file. The result would be identical, but the features would differ.

I might also add that the legality of producing an identical program can also be encumbered, e.g., if the output of said program is itself copyrightable. This could be an issue (say) with the extent that Fruit 2.1 was designed to play chess in a certain style (as opposed to mere strength).

[User923005]

There is a difference though, namely the fact that Vas obviously did have access to Fruit's source code. [...] Personally I don't believe that just carefully looking at it (certainly in a case where the source code was meant to be looked at) makes a decisive difference.

I think you greatly under-rate the premise of access to source code here. Standard practise in clean-room implementations is to strictly segregate those who have seen the source code from those who are re-implementing. Under your schema, I really don't see why one would take such a measure? Things are even worse in (say) the music industry, where fear of unintentional infringement after exposure to a work is so great that unsolicited works are returned unopened.

It is also seems rather overbearing to me to say that one viewed the source code of a competing program, and yet only took "functionality" from it; unless the defendant can advance evidence toward such a claim (via clean-room or something), this seems like a schoolyard defense. In any event, substantial similarity should be the yardstick for this [see previous post for an enumeration]. Maybe VR should have said "I examined the Fruit functionality forwards and backwards and took many things..."

Your parenthetical comment is also worrisome to me; the source code was meant to be looked at provided certain conditions were met. Looking at the source code and then producing a substantially similar competing product "with the aid of" it would seem to necessitate GPL compliance. [Unless one holds a strict copy/paste notion of "copying", which copyright does not].

If this means that reading a GPL program causes us to lose the ability to use the ideas contained in the program then the GPL license is the worst imaginable piece of garbage on earth and anyone who uses is would be a criminal in my view because they are stealing ideas from the general pool of knowledge and rendering them unusable.

My understanding of the GPL license was that the code was protected and not the ideas. If it is the other way around, then I think that using it is criminal (not legally, of course, but in my own strange mind it is).

[syzygy]

For that case the judgment certainly leaves some room for interpretation of "with the aid of".

If you did have access to source code, common copyrightable elements in the source code cannot be so easily explained away by the argument of independent creation of the copyrighted elements.

I am also not sure what "with the aid of" means exactly. This goes someone beyond the traditional rubric, which was the two-fold: access and substantial similarity.

I thought about this issue between my previous two posts. My conclusion is that "with the aid of" simply means that copyrightable elements were taken over (and thus "copied").

"With the aid of" obviously cannot mean that looking at e.g. Fruit's source will taint all code you write with functionality similar to that of Fruit. Only code you write that actually does have copyrighted elements in common with Fruit would be tainted (and then only if you in fact did take them from Fruit).

The copyrighted elements cannot be at the level of the functionality. Indeed, functionality can often easily be "copied" without having access to the source code, but the ECJ explicitly states that in such a case there cannot be infringement of the copyright on the computer program. So such "copying" of functionality is not copying in the sense of European copyright law.

Of course it can be argued that Rule 2 is not about copyright. But then what it is about exactly is not too clear.

At any rate, here is a (partial) listing of things in Rybka 1.0 Beta which would not be likely to appear w/o the aid of the Fruit 2.1 source code.

As you say, this listing was apparently not of much relevance to the panel (like the time management code, I suppose?).

Standard practise in clean-room implementations is to strictly segregate those who have seen the source code from those who are re-implementing. Under your schema, I really don't see why one would take such a measure?

Simple: in order to be on the safe side in case part of the new code is (by chance) identical to the original code. This can easily happen for simple routines.

It is also seems rather overbearing to me to say that one viewed the source code of a competing program, and yet only took "functionality" from it; unless the defendant can advance evidence toward such a claim (via clean-room or something), this seems like a schoolyard defense.

The defendant has no problems as long as the only common elements are at the functional level. Once there is sharing of source code (and thus copyrighted elements), he indeed will have a hard time defending himself.

Your parenthetical comment is also worrisome to me

"Worrisome" even. I simply meant it as User923005 took it.

The publication/availability of source code cannot increase the protection offered by the copyright on a computer program. This copyright does not cover the functionality, whether source code is available or not.

The latter is incorrect, and I think it undermines your argument substantially. (...) I admit the above three are a bit contrived (...)

I'm not going to play the semantic game.

[BB+]

Of course it can be argued that Rule 2 is not about copyright. But then what it is about exactly is not too clear.

I think the first point is almost obvious, while the second is much more obscure [and a different topic, perhaps]. Indeed, Mark Lefler twice reminded the Panel that the investigation was not about copyright per se:

Please keep in mind we are not trying to determine the legality of a program. We are trying to determine if the ICGA Tournament Rules were violated [...]

Reminder: THIS IS NOT A COPYRIGHT CASE. This is a case to determine if Rybka version(s) that competed in ICGA Tournaments are undeclared derivatives.

And the ICGA Journal editorial on the matter again made it clear that copyright was a different issue:

For example, in the Tournament Rule 2 as quoted in ICGA announcement “playing nearly all moves the same” is given as an example of a close derivative. I am not sure whether it would always be a derivative in copyright law meaning. Similar behaviour of programs might result from similarities of algorithms (and algorithms might constitute ideas underlying the programs), and not from similarities of source codes (copyright-protected expressions of ideas). Ideas are not protected by copyright.

Thus, it might be possible that a program is an original implementation of the same algorithm, and as a result programs
behave much in the same way. If the algorithm is only a non-copyrightable idea, the program's author does not breach
copyright, but she would still have to provide information required by Rule 2 and risk exclusion from the tournament. [...]

Nevertheless, ICGA does not have to stick to the balance struck in copyright law. Namely, it may require attribution and
refuse to accept programs even if non-copyrightable ideas are used, thus setting a higher standard for “originality” than the
one in copyright law. ICGA rules can go further than copyright because these two have different purposes.”

But then what it is about exactly is not too clear.

To understand what Rule #2 is about, one should (at least) review the LION++ decision. Knowing the back-history can also be useful. E.g., contra another thread, Rule #2 did not exist in 1989 (QUICKSTEP), or even in 1996 (Gunda). It seems to have come about later, for a number of reasons. For instance, there was a sense in the post-DB age that the main "scientific" goal of computer chess was passed, and subsequently sharing between programs was viewed (by some) to be less desirable than previously. Another was the increase in open-source programs (such as Crafty), and their consequent effect on "originality". In this same guise, it can also be seen as a measure against such copying as had previously occurred. As previously, it is my expectation that it should be VR's responsibility to query the ICGA concerning Rule #2 interpretation in a borderline case. The commentary of van den Herik regarding LION++ seems to run along the same lines, where he says (a bit arrogantly, I must say): For long-standing members of our community -- we assume -- the above the interpretation of the rules is clear.

My conclusion is that "with the aid of" simply means that copyrightable elements were taken over (and thus "copied").

I think we are agreement about this. My main point is that a court can often reasonably assume that more than functionality (similarly ideas) has been copied when access to the source code applies. For any given concrete question: "Is common element X simply functionality or more than that?"; or "Is common element Y more of an idea or is it expression?" -- the assumption works against he who has accessed the source code. Making source code available (as FL did with Fruit, under the GPL) shouldn't change this.

The above (partial) listing was not of the most immediate relevance to the ICGA investigation, of course.

As you say, this listing was apparently not of much relevance to the panel (like the time management code, I suppose?).

No, I said immediate relevance. Evaluation features were the primary issue discussed, but the fact that there were various less-chessic blobs/bits of Fruit in Rybka was at least noted, and probably in the back of the minds of many.

[syzygy]

My main point is that a court can often reasonably assume that more than functionality (similarly ideas) has been copied when access to the source code applies. For any given concrete question: "Is common element X simply functionality or more than that?"; or "Is common element Y more of an idea or is it expression?" -- the assumption works against he who has accessed the source code. Making source code available (as FL did with Fruit, under the GPL) shouldn't change this.

Whether a particular common element is functionality or expression is a question of law. The alleged infringer having had access to the source code if of no relevance to the answer to this question.

Access to source code does become important after it has been determined that the element is expression (and not dictated by functionality, etc.). In that case, the fact that the alleged infringer had access will certainly work against him.

The above (partial) listing was not of the most immediate relevance to the ICGA investigation, of course.

As you say, this listing was apparently not of much relevance to the panel (like the time management code, I suppose?).

No, I said immediate relevance. Evaluation features were the primary issue discussed, but the fact that there were various less-chessic blobs/bits of Fruit in Rybka was at least noted, and probably in the back of the minds of many.

And I think this is one of the problems. There was a lot of material, some of it relevant, some of it irrelevant, some of it erroneous. There appears not to be any final justification of the verdict that specifies exactly on what basis the decision was taken. There is no indication that the various voting panel members were at all in agreement on what was relevant.

The most common reaction to criticism against evidence I have seen (admittedly for 99% Bob's) goes like "who cares if we were wrong on this, there is still all the OTHER evidence". It is all so slippery.

[BB+]

Whether a particular common element is functionality or expression is a question of law.

At least in actual practise, such questions need not always be cut-and-dry, particularly when one is dealing only with the object code of the accused. The main issue here is that non-common elements are not always so apparent, which complementarily tends to exaggerate the ones that are common (and idiosyncratic). E.g., Program A might do something such as "x=(x+1)+x", while the Object Code B does a left-shift of x followed by an increment. Is this thus evidence of a particular common element that B did not copy A at the code level, but only at the level of functionality? I would argue "no", as it is just as likely to be the compiler as a source code difference in B. Also, many of the common elements are rather short and pithy in nature, so that any particular common element could easily be chance, but form a picture on the whole. So one needs to build up a statistical basis, which (as I say) can be obscured by how the compiler is thought to have intervened. One is left with: some elements that clearly exceed mere functionality, but which could be by chance; and others where it is not completely apparent exactly what is common.

To adduce a related example from the principals, Fruit 2.1 uses a "X>=Y+150" comparison for EasyThreshold and "X<=Y-50" for BadThreshold. Depending on what one believes about compilers, those seem to re-appear (and not as say "X-Y>=150" and "X+50<=Y") in Rybka. But as I say, it might be a compiler aspect. In the absence of (Rybka) source code, I think one has to tend to conclude that this is beyond functionality [though still perhaps chance], even though it is possible VR re-typed these comparisons in a different manner. If there were no access to the Fruit code, obviously one could not make such a conclusion.

Code: Select all

0x409615: mov    0x267449(%rip),%eax    # 0x670a64 (value of move 1)
0x40961b: add    $0x96,%eax             # EasyThreshold of 150 [as in Fruit]
0x409620: cmp    %eax,0x26743a(%rip)    # 0x670a60 (value of move 0)
0x409626: cmovae %esi,%ecx              # if move values differ by enough

Code: Select all

0x040b878: mov    0x260bca(%rip),%eax        # 0x66c448 last_value
0x040b87e: add    $0xffffffffffffffce,%eax  // -50
0x040b881: cmp    %eax,%ecx
0x040b883: jg     0x40b89c                  // opposite of <= 

[There's also the somewhat tangential question of whether "X-Y>=150" might be disliked on the grounds that data-dependency(?) would make it slightly slower, etc.].

There appears not to be any final justification of the verdict that specifies exactly on what basis the decision was taken.

In the absence of a defence (to the ICGA) from VR, this was unnecessary for the Board. With the alternative defense via the NH interview, the Riis report, etc., this does become a notable gaping omission [which is one reason why I wrote the RECAP, though that's my opinion, not the ICGA's or the Panel's]. The Panel members were not specifically directed to exposit any basis of their opinions, though some did so -- perhaps the best there is in this regard is the Report (the discussions of the Panel remain private).

[hyatt]

You can continue to spout all the nonsense you want. I have finished the Spring semester and have all Summer to continue to address this nonsense. The EU case was about someone taking a program, and running it. Feeding it input, and looking at the output. And then writing a program that will produce similar output for similar input. Nothing to do with RE. Nothing to do with comparing source to binary. Nothing to do with the ICGA investigation whatsoever. We did not claim that Vas had used the black-box approach to design and develop Rybka. We claimed he used Fruit for the basis. The ACTUAL implementation details from the Fruit source. The case you guys are hyperventilating over is 100% irrelevant to the ICGA investigation... Nowhere in the ICGA report or evidence do you see the term "copied functionality" or "identical functionality". We spent time looking at the actual implementations of eval terms in Fruit and Rybka, which is not "functional comparison" at all, as we were looking at specific semantics.

So let's get off the WRONG bandwagon again, since it is going nowhere that is relevant to the fruit/rybka case.

BTW in reading this, I apparently deleted the quoted material. My post was NOT directed at Mark, hopefully that is obvious...