Ideas versus Implementations

Code, algorithms, languages, construction...
BB+
Posts: 1484
Joined: Thu Jun 10, 2010 4:26 am

Ideas versus Implementations

Post by BB+ » Tue Aug 16, 2011 8:04 pm

One of the more peculiar arguments I have seen is that one can phrase everything in computer chess in terms of "ideas" (or maybe "concepts"), which are not copyrightable, and then "idea" determines the implementation, thus copyright does not apply, and so forth. Somewhat like the sophomoric proposal that "Data is not copyrightable, but everything is (or can be expressed as) data, ergo..."

To wit, if an "idea" determines an implementation, it is sufficiently specific for it no longer to classified as an "idea", at least not in the generic sense. Copyright lawyers talk about "levels of abstraction" and whatnot, and part of this is to remove any such chicanery. I think the phrase "expression-level similarity" is the term of choice here. [I did not even mention here that the choice of what ideas (even abstract ones) to use/combine also constitutes creative expression]. I can refer again to Brinson's work on separating copyrightable expression from unprotected ideas in computer programs.

Here would be an analogue. I have the "idea" of starting a book It was the best of times, it was the worst of times, [...] Lo and behold!, there's but one "implementation" of this "idea". Then I have the "idea" of continuing: it was the age of wisdom, it was the age of foolishness, [...] Contrast this to the idea of starting a book with a number of contrasting statements. Copyright law is not mocked as such, though for some reason, inserting computers into the picture tends to obscure many issues. Algorithms with a specified input/output can be merely "functional", but often there is a creative aspect as well.

User avatar
Chris Whittington
Posts: 437
Joined: Wed Jun 09, 2010 6:25 pm

Re: Ideas versus Implementations

Post by Chris Whittington » Wed Aug 17, 2011 10:53 am

BB+ wrote: To wit, if an "idea" determines an implementation, it is sufficiently specific for it no longer to classified as an "idea", at least not in the generic sense.
Ridiculous irrelevant nonsense. If an "idea" determines the implementation then you SHOULD have removed the section from consideration from the comparison stage by FILTERING it out at the filtration stage.

Something you did not do, even once, in all your EVAL document process.

hyatt
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

Post by hyatt » Wed Aug 17, 2011 2:37 pm

What nonsense.

How about some examples from Fruit that illustrate an "idea" that has just one implementation? While waiting on some examples from you, I'll pick one for starters.

How about the simplest concept of all, material?

Do you:

(1) sum material at the top of eval?

(2) incrementally update material in Make/Unmake?

(3) add material value for each piece to your PST so that you collect material as you collect PST values?

(4) use a material table that adjusts the final score depending on a hashed material signature?

(5) use a function that considers material imbalances and adjusts the raw material score that is incrementally updated?

This "idea forces the implementation" is a real crock in almost all cases. BTW, each of the above is used in at least one existing program, and there are other approaches as well, before you start to scream "fantasy, get real" or whatever...

Part of the fun of designing and then writing a chess program is choosing the implementation approach for a specific feature. I could simply list mobility and describe how many _different_ ways I/We have implemented it in Crafty before settling on what we do today. Which might not be what we are doing next year.

If it were this easy, one should be able to write a specification and feed it into a program that automatically produces "the only way to do this in source code." The idea is a crock.

BB+
Posts: 1484
Joined: Thu Jun 10, 2010 4:26 am

Re: Ideas versus Implementations

Post by BB+ » Wed Aug 17, 2011 8:23 pm

Just to remind us what filtration is:
Filtration

The second step is to remove from consideration aspects of the program which are not legally protectable by copyright. The analysis is done at each level of abstraction identified in the previous step. The court identifies three factors to consider during this step: elements dictated by efficiency, elements dictated by external factors, and elements taken from the public domain.[6][2]

The court explains that elements dictated by efficiency are removed from consideration based on the merger doctrine which states that a form of expression that is incidental to the idea can not be protected by copyright. In computer programs, concerns for efficiency may limit the possible ways to achieve a particular function, making a particular expression necessary to achieving the idea. In this case, the expression is not protected by copyright.[7]

Eliminating elements dictated by external factors is an application of the scènes à faire doctrine to computer programs. The doctrine holds that elements necessary for, or standard to, expression in some particular theme can not be protected by copyright.[8] Elements dictated by external factors may include hardware specifications, interoperability and compatibility requirements, design standards, demands of the market being served, and standard programming techniques.[9]

Finally, material that exists in the public domain can not be copyrighted and is also removed from the analysis.[2]
So there are 3 filtering considerations: elements dictated by efficiency, elements dictated by external factors, and elements taken from the public domain.
Chris Whittington wrote:Ridiculous irrelevant nonsense. If an "idea" determines the implementation then you SHOULD have removed the section from consideration from the comparison stage by FILTERING it out at the filtration stage.

Something you did not do, even once, in all your EVAL document process.
One example of filtering (in EVAL) for elements dictated by efficiency was the disregard of the process used to compute the knowledge (bitboards, piece scans, ...), which indeed was one reason why EVAL_COMP worked at the abstraction level that it did.

One example of filtering elements dictated by external factors could be the non-discussion of the numeric values (for the most part), as often they can be dictated by considerations of maximising strength [or with some engines, perhaps fitting a pre-conceived notion of play of some GM] via a more mechanical process.

One example of filtering from public domain [or sufficiently common knowledge] was material scoring (1/3/3/5/9, or 100/325/325/500/975) was not included, though this would indeed seem to be an evaluation term.

I would say that if an "idea" is so precise as to determine the implementation, the idea is overly specified, and one should recede to a higher level of abstraction.

For instance, it is well-established that the moves of an individual chess game are not copyrightable. Yet a "creatively constructed" group of games is (e.g., what I think are the 100 best games of all time) is indeed copyrightable [the allowable overlap between any two such sets being dependent upon the context]. OTOH, a "noncreative" collection of games (all games from 2011 with both players over 2500 ELO) is again not copyrightable. One could have a collection specified by "All IM/GM games played in Germany from 2003-5 where a knight is sacrificed between moves 15-20, then White eventually queens his b-pawn, but Black gains a draw by perpetual check in the end" -- here the "creative content" is in making such a verbose specification, after which the collection of games therein is determined.

But I get the feeling that I wasting my time trying to explain (my understanding of) copyright law, as you seem to oppose its conclusions on philosophical grounds, at least for computer programming.

hyatt
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

Post by hyatt » Wed Aug 17, 2011 8:37 pm

That is the root of the problem. If you want to venture into "copyright chicanery" we define a chess program as a function, as I mentioned, and clearly a function can't be copyrighted. Except that a chess engine is not a function. It is an incredibly complex fusion of ideas, and their implementations/expressions.

On CCC Sune is trying to reduce individual evaluation terms to become a "formula" where the formula is

"if (pawn is weak) add big penalty". That is way too abstract. Defining "is a pawn weak?" is not a simple functional expression, it can be quite complex. "big penalty" can be a dynamic thing such as I have done in the past, sort of "if there is one weak pawn, add a penalty" "If there are two weak pawns, add a penalty that is > 2x bigger." "if there are 3 weak pawns, I can't defend them all and one will be lost, so add an enormous penalty."

That doesn't feel like a function/formula to me. 1.5 sentences, could be a hundred lines of code that could be written in many different ways depending on how you want to define "weak pawn". Could be just isolated. Or isolated on open file with rooks present. Or backward. Or backward on open file with rooks present. Or both isolated or backward. Or artificially isolated. Etc. That is not a formula and the code is certainly copyrightable...

syzygy
Posts: 148
Joined: Sun Oct 16, 2011 4:21 pm

Re: Ideas versus Implementations

Post by syzygy » Mon Apr 02, 2012 11:27 pm

BB+ wrote:To wit, if an "idea" determines an implementation, it is sufficiently specific for it no longer to classified as an "idea", at least not in the generic sense.
It is the other way around: if an idea can only be expressed in one way, then that expression (being fully determined by the idea) is not protected by copyright. The same holds when an idea can only be expressed in a few ways. This is also why purely factual accounts (e.g. a shopping list) are not protected by copyright: they are fully determined by the facts, and facts are unprotected.
Here would be an analogue. I have the "idea" of starting a book It was the best of times, it was the worst of times, [...] Lo and behold!, there's but one "implementation" of this "idea".
Your example is not an "idea", because it contains an expression: "It was the best of times, it was the worst of times." Why is this an expression? Because it is a literary work.

It might help to realise that whenever you give an example of an idea by typing it out, you actually give an expression of that idea in natural language, a literary work. That expression is in fact copyrighted (unless there are only a few basic ways to express it). The abstract thought behind the expression (i.e. the idea) remains free to be reused.

Your "idea" of a book is not (only) an idea. You can't abstract your expression of this idea without losing the expression "it was the best of times, it was the worst of times".
Algorithms with a specified input/output can be merely "functional", but often there is a creative aspect as well.
Well, video games can be copyrighted works in themselves. An independent re-implementation of pacman (even with some changes here and there in the graphics) will infringe the copyright on pacman. But chess engines implement the game of chess, which is free of copyright.

Saying that one can have a copyright on a particular way of evaluation a position seems akin to saying that Kasparov can have a copyright on his playing style.

To me, it seems simpler/better to explicitly abandon the copyright angle when discussing rule 2.

syzygy
Posts: 148
Joined: Sun Oct 16, 2011 4:21 pm

Re: Ideas versus Implementations

Post by syzygy » Tue Apr 03, 2012 12:09 am

BB+ wrote:I would say that if an "idea" is so precise as to determine the implementation, the idea is overly specified, and one should recede to a higher level of abstraction.
I think the problem is you're trying to mold copyright into a tool that fits the intention of rule 2.

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 I'm trying to say is: the world does not end if copyright is simply not the tool for rule 2. Reading Bob's post above, I really do not understand why it is so important that copyright should protect all this "fun of designing". What is important is that copyright protects the final outcome: the code.
For instance, it is well-established that the moves of an individual chess game are not copyrightable. Yet a "creatively constructed" group of games is (e.g., what I think are the 100 best games of all time) is indeed copyrightable [the allowable overlap between any two such sets being dependent upon the context]. OTOH, a "noncreative" collection of games (all games from 2011 with both players over 2500 ELO) is again not copyrightable. One could have a collection specified by "All IM/GM games played in Germany from 2003-5 where a knight is sacrificed between moves 15-20, then White eventually queens his b-pawn, but Black gains a draw by perpetual check in the end" -- here the "creative content" is in making such a verbose specification, after which the collection of games therein is determined.
Funny, I recently gave this exampe of creative collections of chess games on talkchess while never having read this post. In other words, I agree with this.

Does the collection of evaluation features of a chess engine express the personal creative choices of its author? Or did the author only attempt to choose a collection that makes the evaluation function as strong as possible given the rules of chess?

I tend to the latter: creating a good evaluation function is a question of engineering, not of being an artist. Chess optimisation is not fundamentally different from efficiency optimisation.

That said, I will not dispute that there is at least something to be said for the former. However, even if that is the case, only a "large overlap" in evaluation features between Rybka and Fruit doesn't seem sufficient if there are also considerable differences (which I believe there are judging from what I have read, but I have not compared the two myself). There cannot be much doubt that in order to have a strong engine, many of the evaluation features are simply indispensable. The "chess efficiency requirement" dictating the use of those features cannot be ignored, even if it does leave room for actual creativity. It should be clear that the line becomes very very fuzzy... Even if it can be determined that Vas crossed it, can he really be blamed?

syzygy
Posts: 148
Joined: Sun Oct 16, 2011 4:21 pm

Re: Ideas versus Implementations

Post by syzygy » Tue Apr 03, 2012 12:18 am

Reading back my two posts, I notice a recurring theme:
syzygy wrote:Saying that one can have a copyright on a particular way of evaluation a position seems akin to saying that Kasparov can have a copyright on his playing style.
Kasparov has no such claim, since he plays to win, not to give expression to any free creativity not dictated by the rules of chess.
BB+ wrote:For instance, it is well-established that the moves of an individual chess game are not copyrightable.
Individual chess games are not protected by copyright, because the players played to win, not to give expression to any free creativity not dictated by the rules of chess.
Artificial games with a creative theme, e.g. somehow encoding an original poem, are of course protected by copyright.
syzygy wrote:I tend to the latter: creating a good evaluation function is a question of engineering, not of being an artist. Chess optimisation is not fundamentally different from efficiency optimisation.
Again the same theme.

syzygy
Posts: 148
Joined: Sun Oct 16, 2011 4:21 pm

Re: Ideas versus Implementations

Post by syzygy » Tue Apr 03, 2012 12:32 am

European copyright law is moving quite fast at the moment. Last month, the ECJ decided in case C-604/10:
Article 3(1) of Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases must be interpreted as meaning that a ‘database’ within the meaning of Article 1(2) of that directive is protected by the copyright laid down by that directive provided that the selection or arrangement of the data which it contains amounts to an original expression of the creative freedom of its author, which is a matter for the national court to determine.

As a consequence:

– the intellectual effort and skill of creating that data are not relevant in order to assess the eligibility of that database for protection by that right;

– it is irrelevant, for that purpose, whether or not the selection or arrangement of that data includes the addition of important significance to that data, and

– the significant labour and skill required for setting up that database cannot as such justify such a protection if they do not express any originality in the selection or arrangement of the data which that database contains.
Extremely relevant for the question of the extent to which copyright protects the functionality of a computer program is case C-406/10 to be decided on 2 May 2012. The opinion of the Advocate-General is already available and hints to a rather narrow scope of copyright protection. In particular, it does not apply to functionality or combinations of functionalities:
63. Let us return to the example of the computer program for the reservation of airline tickets. The structure of the program will define the program’s functionalities and describe the combination of those functionalities. The very function of the program, that is to say, to enable the user to obtain an airline ticket, will dictate that combination. It will have to enable the user to check whether the flight exists and, if so, on what date and at what time, whether there are any seats left, and so on. Whatever its nature and scope may be, it is my view that the functionality, or indeed the combination of several functionalities, continues to be comparable to an idea and cannot therefore be protected, as such, by copyright.

BB+
Posts: 1484
Joined: Thu Jun 10, 2010 4:26 am

Re: Ideas versus Implementations

Post by BB+ » Tue Apr 03, 2012 11:08 am

I am quite busy with many things right now (and haven't read "On Dalke" in some time), but I might note briefly a thought I had a few weeks ago, namely that just because a "process" or "procedure" is involved, this doesn't mean that other facets cannot be copyrightable. One example would be the Rorschach Test, which involves a fairly set-out procedure to carry it out, but the inkblots themselves were subject to copyright. Similarly, a 10-question medical self-assessment would have copyright on the specific questions asked. [I like the second example better, as notions of "public domain" or "common practise" in the medical field would more easily arise here].

Post Reply