Linked by Thom Holwerda on Wed 2nd May 2012 22:32 UTC, submitted by PLan
Legal "The European Court of Justice ruled on Wednesday that application programming interfaces and other functional characteristics of computer software are not eligible for copyright protection. Users have the right to examine computer software in order to clone its functionality - and vendors cannot override these user rights with a license agreement, the court said." Bravo. A landmark ruling, for sure. If the US courts decide in favour of Oracle in the Google-Oracle case, Europe would instantly become an even friendlier place for technology companies.
Thread beginning with comment 516992
To view parent comment, click here.
To read all comments associated with this story, please click here.
by galvanash on Fri 4th May 2012 04:14 UTC in reply to "RE[6]: NOT APIs"
Member since:

So if I only include the header files from a GPL licensed library my code does not become GPL, because the copyright does not cover the header files, hmmmm.

I believe you will find that the FSF has a radically different interpretation of that specific issue, because that is exactly the purpose of the GPL, and the whole reason for the LGPL is that you cannot link to a GPL licensed library neither static or dynamic without being covered by the GPL itself. If you are telling the truth and not just lying in order to win the argument, then why does the LGPL even exist?

Three things...

First, a header file is NOT an API. It is an implementation (or more correctly documentation) of an API. Im not saying you can copy the header file from a GPL project, what I am saying is the arrangement of the interface that is expressed in the header file is not copyrightable. If you can determine the names of all a libraries methods, its parameters and return types, etc. WITHOUT actually using the header file (which in general isn't all that hard most of the time) you have not violated copyright. What you end up with at the end may be 100% identical, but you did not copy it. Since you did not copy it and your implementation was independent and derived purely form observing the running software - copyright does not apply.

Secondly, I think you will find (if you do a bit of googling) that quite a lot of people in the OSS world actually agree with me and have for quite a while. This is not a new argument.

Im not saying the FSF supports this viewpoint - Im not even saying that this viewpoint is right and theirs is wrong... What I AM saying is that it is a legitimate point of view that is supported by existing case law. It isn't a question of the terms of the license, it is a questions of what can or cannot be copyrighted. If you can't copyright something, then the GPL cannot be applied to it (since it is a copyright license).

Thirdly, about the LGPL not being necessary... I don't think people are understanding what I am getting at... If you link to a GPL'd library with non-GPL'd code with the intention, at runtime, to combine your code with said library - you are violating the GPL. By doing so you are demonstrating quite clearly the intent to combine with a GPL'd work. It doesn't matter one bit HOW you go about this - the fact that you reversed engineered the header has no bearing at all... You are violating the GPL because your code, at runtime, is being combined with a GPL'd work (which is explicitly not allowed by the terms of the license). This EU ruling doesn't affect things in any way.

What I have been struggling to get across (maybe not successfully) is that what the GPL cannot do is protect the API of the code. If you can determine (through observation) the API of a GPL'd work and you then independently create a compatible implementation you have not violated the GPL. This is a totally different scenario, because it does not in any way involve the implementation of the GPL'd work. You are not combining with it or using it in any way, you are simply recreating it.

It could be argued, that even if you copied the headers (assuming that they are non-expressive in nature) this would be the case. I don't want to make that argument too strongly, because frankly I think it would put me on shaky ground - but it is a valid point of view.

What I am most definitely NOT saying though is that you can do so as a way to get around the "linking" clause of the GPL in order to use a GPL'd library in your code (without honoring the license)... How you got the header is totally immaterial in that scenario - you are still linking to an actual implementation, and your code demonstrates the intent to do so. You are violating the GPL, plain and simple.

Reply Parent Score: 3

by Slambert666 on Fri 4th May 2012 10:53 in reply to "RE[7]: NOT APIs"
Slambert666 Member since:

you are violating the GPL

No I'm not. I'm just using the API.
API's are not copyrightable.
GPL is copyright.

Do you see the problem now?

Reply Parent Score: 2

by galvanash on Fri 4th May 2012 21:08 in reply to "RE[8]: NOT APIs"
galvanash Member since:

No I'm not. I'm just using the API.
API's are not copyrightable.
GPL is copyright.

Do you see the problem now?

I write some code. In the code I link to a GPL'd library. In order to do so I have to conform to its API (or it won't work). So in the end I have a program that uses a GPL'd library. There is no other known library that conforms to this API - it is unique to this particular GPL'd work.

I decide to release it without distributing the library myself - I leave it up to the user to acquire the library. I do not release my source code and I do not license my work under the GPL.

Have I violated the GPL? The FSF would say that because you obviously demonstrated intent to link to a GPL'd implementation you are creating a derived work and thus you are violating the GPL. Many others would say you are not. My only point is I don't see how the EU ruling affects this argument either way - it was never about whether APIs can be copyrighted, it is about what is considered a derivative work under copyright law. Two completely unrelated issues...

Again, what I was talking about is a completely different scenerio (i.e. creating a compatible but independent implementation) - there is no derived work because I never demonstrate any intent to combine with the original work.

Reply Parent Score: 3