OSNews

galvanash,

I understand what you are saying. But there is obviously more gray than you're implying.

In order to convey the precise ideas for an API, one must express the API, no exception.

When humans talk to one another, there's a great deal of room for expression. But when talking to a compiler, language constructs have a precise semantic purpose. In order to supply the idea of a compatible API structures & functions & classes to the compiler, it's necessarily going to take a form semantically resembling the original, this is an unavoidable part of creating a compatible API.

It seems the court claimed the ideas aren't copyrightable, which we already knew all along, but stopped short of saying whether expressions of those ideas were copyrightable when they produce exceedingly similar code to the original expression.

Fair enough. I just never really considered the notion of "exceeding similar" as far as the results go - it is the evidence of how you got there that will protect you in the end...

Even if the end result was 100% identical, if you can effectively demonstrate you did not copy anything it really doesn't matter. But I do see your point.

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.

If you only include the header files, but not actually link with the library (or load it as a plugin), then yes, that is ok. A common example of this is the Linux kernel headers. The Linux kernel is GPL, but including the kernel headers from a program does require that program to be GPL, as long as it just runs under the kernel rather than being linked into it.

This is intentional since the header files describe how to interact with the work, which is necessary for components which are not themselves part of the work.