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.
Order by: Score:
NOT APIs
by JAlexoid on Wed 2nd May 2012 23:28 UTC
JAlexoid
Member since:
2009-05-19

The fact is that they haven't said anything about APIs in code form.

It is only through the choice, sequence and combination of those words, figures or mathematical concepts that the author may express his creativity in an original manner and achieve a result, namely the user manual for the computer program, which is an intellectual creation (see, to that effect, Infopaq International, paragraph 45).


Point 67 of the ruling.
( http://curia.europa.eu/juris/document/document.jsf?text=&docid=1223... )


It's essentially equivalent to "Structure, Sequence and Organization" argument in Oracle vs Google.

Reply Score: 2

RE: NOT APIs
by dylansmrjones on Thu 3rd May 2012 00:29 UTC in reply to "NOT APIs"
dylansmrjones Member since:
2005-10-02

It only means the user manual containing the API is copyrightable; the API itself is not copyrightable. Only the total combination is. Method names, variables etc. are not copyrightable. Replace the code inside the methods and you are safe.

Reply Score: 3

RE: NOT APIs
by galvanash on Thu 3rd May 2012 01:18 UTC in reply to "NOT APIs"
galvanash Member since:
2006-01-25

The fact is that they haven't said anything about APIs in code form.


What is an "API in code form"? That doesn't make any sense... An API is by definition abstract - there is no such thing as an "API in code form".

You can document an API - but what you end up with is a description of it. You can write software that implements one of both "sides" of an API, but what you end up with is an implementation of it. In either case you can copyright your work, but in neither case is your work an API...

An API is an abstract idea. The expression of the idea can be copyrighted, but not the idea itself. And contrary to what many people are saying, there is US case law supporting this distinction (lots of it actually).

The difference between US law and this particular EU judgement is that under US law (unfortunately) a license can explicitly bar a party from expressing an API (or other idea) independently. This only applies if you actually agree to such a license of course. This EU decision explicitly nullifies such license clauses.

Reply Score: 2

RE[2]: NOT APIs
by henderson101 on Thu 3rd May 2012 14:22 UTC in reply to "RE: NOT APIs"
henderson101 Member since:
2006-05-30

"The fact is that they haven't said anything about APIs in code form.


What is an "API in code form"? That doesn't make any sense... An API is by definition abstract - there is no such thing as an "API in code form".
"

Yes there is... an API is a contract between a Provider and a Consumer. Just because you are used to seeing a C header file, don't be fooled in to believing that is the defacto API, in reality that is just a concrete implementation of an API specification.

CreateNewUser - a method to create a new user account. This recieves the user's name and personal details in a UserRef structure and returns a boolean result to indicate if the function was successful.

API in Pseudo code form:

method CreateNewUser:: receives: UserRef returns: boolean[success==true, failure==false]

You could then provide a model implementation of the API as a C header e.g.:

extern BOOL CreateNewUser(UserRef* userRef);

The actual API is the contract between two blocks of code. Otherwise, do you really think that because the Win32 API (as an example) can't be called directly from Assembler without using the original C headers? Do you believe that the Win32 API (and I'm totally using this as an example API) included in languages such as D or Delphi are just using C headers? No. If you look at a book like the Win32 programmer's reference guide (I forget the exact name, but it is multi volume), the API is detailed as a whole bunch of specifics. This is the API. The C is just one implementation of that API specification.

Reply Score: 3

RE: NOT APIs
by ndrw on Thu 3rd May 2012 02:04 UTC in reply to "NOT APIs"
ndrw Member since:
2009-06-30

Hmm.. does it mean that from now in Europe GPL==LGPL?

After all #including a header file, and then linking to a library at run-time, is just using an API.

Reply Score: 7

RE[2]: NOT APIs
by Alfman on Thu 3rd May 2012 02:55 UTC in reply to "RE: NOT APIs"
Alfman Member since:
2011-01-28

That's an incredibly insightful observation. If an API isn't copyrightable, and gets included into a project, then the project should not be considered derived from a copyrighted work.

I don't know how that will play out, however I'd like to bring up GPLv3 section 12:


"12. No Surrender of Others' Freedom.

If conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot convey a covered work so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not convey it at all. For example, if you agree to terms that obligate you to collect a royalty for further conveying from those to whom you convey the Program, the only way you could satisfy both those terms and this License would be to refrain entirely from conveying the Program."

So rather than reverting to LGPL, the GPL states the right to redistribute under the GPL is voided. But since APIs cannot be covered by copyright, what the GPL says is irreverent, so it would effectively loose it's "viral" property and become LGPL. On the other hand, the GPL's provision to void itself could be interpreted as applying to the complete work (API plus source code) instead of just individual header files in isolation.

Of course this would be for the case of dynamic linking, static linking would probably constitute a covered copy in any case because it's still pulling in actual code.

And so our little computer science drama unfolds...

Reply Score: 3

RE[3]: NOT APIs
by galvanash on Thu 3rd May 2012 03:13 UTC in reply to "RE[2]: NOT APIs"
galvanash Member since:
2006-01-25

That's an incredibly insightful observation. If an API isn't copyrightable, and gets included into a project, then the project should not be considered derived from a copyrighted work.


And how would you include an API in a project? I don't understand the angle your looking at this from. Writing down the specifics of an API (whether in documentation or in source code) doesn't include the API, it merely expresses it. An API is an idea - it is the expression of the idea that is copyrighted, not the idea itself.

To put it another way, you can copyright a program that expresses a totally original idea, but your copyright does not cover the idea, it only covers your implementation. Anyone is free to look at what your program does and create an independent implementation that does exactly the same thing. Remember, we are not taking about patents...

Also, I don't understand this GPL vs LGPL thing that was brought up. The difference between those two licenses rest solely on an explicit exception in the LGPL to allow linking without the license affecting the linked work. How does this decision apply to this? Neither the GPL or the LGPL have any clauses in them concerning reverse engineering or barring the other party from creating an independent implementation. Hell, reverse engineering is practically encouraged in the OSS world...

As an aside... This ruling, if made in US courts, could possibly cast doubt on parts of the DMCA anti-circumvention law. I don't think it would invalidate it, but it does seemingly conflict with it - at least in spirit.

Edited 2012-05-03 03:30 UTC

Reply Score: 4

RE[4]: NOT APIs
by Alfman on Thu 3rd May 2012 04:13 UTC in reply to "RE[3]: NOT APIs"
Alfman Member since:
2011-01-28

galvanash,

"And how would you include an API in a project? I don't understand the angle your looking at this from. Writing down the specifics of an API (whether in documentation or in source code) doesn't include the API, it merely expresses it."


You'd include the expression of an API, in your words. In programming terms that'd be tantamount to a list of structures and function prototypes.

Are you arguing that API's aren't copyrightable, but expressions of that API are? I guess you might say that but I honestly don't think that's what the EU court was saying. I think they want to exclude "expressions of APIs" from copyrightability because there's so little room for meaningful expression when expressing a compatible API.


"Also, I don't understand this GPL vs LGPL thing that was brought up."

It's probably nothing, but if function prototypes in header files that used to be covered under the GPL license are no longer being covered, then it could be possible to release proprietary programs that link to GPL libraries as is normally permitted only under the LGPL.

http://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL

Edited 2012-05-03 04:20 UTC

Reply Score: 2

RE[5]: NOT APIs
by galvanash on Thu 3rd May 2012 04:29 UTC in reply to "RE[4]: NOT APIs"
galvanash Member since:
2006-01-25

Are you arguing that API's aren't copyrightable, but expressions of that API are?


Yes, but I'm not really arguing it - that is exactly what the court decision stated. Did you read the decision?

"The Court recalls, first, that the Directive on the legal protection of computer programs extends copyright protection to the expression in any form of an intellectual creation of the author of a computer program. However, ideas and principles which underlie any element of a computer program, including those which underlie its interfaces, are not protected by copyright under that directive.
Thus, only the expression of those ideas and principles is protected by copyright."


"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."


In other words they are saying that you can't copyright an API because APIs are not expressions of an idea - they are ideas. The expression (the source code, the documentation, whatever) can be copyrighted - but that does not protect the idea itself (i.e. it's form and function).

Reply Score: 3

RE[6]: NOT APIs
by Alfman on Thu 3rd May 2012 05:38 UTC in reply to "RE[5]: NOT APIs"
Alfman Member since:
2011-01-28

galvanash,

I only read the article, in particular:

"The EU's highest court rejected these arguments. Computer code itself can be copyrighted, but functional characteristics—such as data formats and function names—cannot be."

This clearly describes a header file which contains no code as being non-copyrightable, but perhaps the article was misleading.


I thank you for the citations.

However I'm finding the "ideas & principals" argument to be somewhat contradictory with the conclusions.

Strongly typed languages like java store the entire class definition in binary form (java reverse compilers can recreate the source files almost line for line). Thus, the API is fully expressed in the binary. The binary expression of a compatible function/class prototype will very likely need to be identical to the binary expression of the original function/class prototype. So would the court still claim that an API is not copyrightable under those circumstances even when the language mandates the expression of such an API to be recorded the same way each time it is expressed as a binary?


To be honest, I preferred the article's stronger interpretation of explicit non-copyrightability where function names and prototypes were simply excluded from copyright without regards to how they are expressed.

Edited 2012-05-03 05:42 UTC

Reply Score: 2

RE[7]: NOT APIs
by galvanash on Thu 3rd May 2012 06:26 UTC in reply to "RE[6]: NOT APIs"
galvanash Member since:
2006-01-25

This clearly describes a header file which contains no code as being non-copyrightable, but perhaps the article was misleading.


I think it just boils down to how you acquire the header file to be honest. Let's say you write a header file for a library containing no functional inline code, nothing but interface declarations and constants. You then slap copyright on it.

If I copy the file and use it I would be violating the copyright. However, since the contents of the file are simply non expressive facts (and you cannot copyright facts) you could argue that copyright doesn't apply. This has always been the case, this ruling doesn't really change anything.

Or you could, instead of copying the code, simply instrument the library directly to discover its interface and then write a header that works the same way. The result would be the same, a functionally identical header, but clearly in the 2nd case you did not "copy" anything.

I think the EU ruling primarily applies to this scenario - i.e. recreating an interface (API) without having actually seen the copyrighted work (the implementation). It isn't new ground - reverse engineering was always legal (if done right) - it just strengthens existing law with another precedent. I think the only thing "new" is the part about not allowing licenses to bar reverse engineering.

However I'm finding the "ideas & principals" argument to be somewhat contradictory with the conclusions.

Strongly typed languages like java store the entire class definition in binary form (java reverse compilers can recreate the source files almost line for line). Thus, the API is fully expressed in the binary. The binary expression of a compatible function/class prototype will very likely need to be identical to the binary expression of the original function/class prototype. So would the court still claim that an API is not copyrightable under those circumstances even when the language mandates the expression of such an API to be recorded the same way each time it is expressed as a binary?


The ruling states you are allowed to instrument and observe a piece of software in order to determine its functional workings, and that those aspects of the work are not covered under copyright. If you did so and documented its interface and behavior and then created an independent implementation you would not be violating copyright, because the copyright doesn't cover the interface or behavior.

Reply Score: 3

RE[5]: NOT APIs
by dylansmrjones on Thu 3rd May 2012 09:38 UTC in reply to "RE[4]: NOT APIs"
dylansmrjones Member since:
2005-10-02

Are you arguing that API's aren't copyrightable, but expressions of that API are?"


That's exactly what the court did, and I'm surprised it was even necessary. Laws in EU are quite simple and awfully clear in this regard. An API is not copyrightable, but the implementation of the API is.

Or put differently: You can create headerfiles with the same names and with the same name for methods and variables, but the code must be different, since the code (the total combination) is copyrightable.

Reply Score: 5

RE[4]: NOT APIs
by Slambert666 on Thu 3rd May 2012 04:23 UTC in reply to "RE[3]: NOT APIs"
Slambert666 Member since:
2008-10-30

Also, I don't understand this GPL vs LGPL thing that was brought up. The difference between those two licenses rest solely on an explicit exception in the LGPL to allow linking without the license affecting the linked work. How does this decision apply to this? Neither the GPL or the LGPL have any clauses in them concerning reverse engineering or barring the other party from creating an independent implementation. Hell, reverse engineering is practically encouraged in the OSS world...


If the API itself isn't copyrightable is the "use" of the API then copyrightable?
GPL says yes it is copyrightable and this affects other works that links to it.
However if the use of the API is not copyrightable then the difference between GPL and LGPL cease to exist.
It also raises the question of when are you modifying a work and when are you using an API, it all becomes very muddy.

Reply Score: 2

RE[5]: NOT APIs
by galvanash on Thu 3rd May 2012 04:38 UTC in reply to "RE[4]: NOT APIs"
galvanash Member since:
2006-01-25

I think your off on a wild tangent. No offense meant, I just don't see any correlation between this ruling and the GPL/LGPL at all. Its simple:

1. The GPL/LGPL are licenses based purely in copyright law.
2. You cannot copyright an idea, only expressions of idea.
3. An API is an idea.

Thus the GPL/LGPL simply do not apply to APIs... They apply to the code you wrote, not the idea (API) being expressed. The linking clause (the distinction between the two licenses) has nothing to do with APIs or ideas - it is about what constitutes a derived work. The way linking is implemented is a function of the language you choose to use - it has nothing at all to do with your code or what it expresses.

If the API itself isn't copyrightable is the "use" of the API then copyrightable?
GPL says yes it is copyrightable and this affects other works that links to it.


No. You are linking to an implementation, not an API - it is the implementation that affects the other works that link to it. The GPL doesn't cover the arrangement of interfaces in a library (i.e. it's API) - it only covers the underlying source code and its binary representation when run.

If someone writes a 100% compatible independent implementation without using any of the source code from the GPL version they are free to license it however they see fit - they did not violate the copyright of the GPL code and thus are not affected by it.

Edited 2012-05-03 04:47 UTC

Reply Score: 8

RE[6]: NOT APIs
by Alfman on Thu 3rd May 2012 06:08 UTC in reply to "RE[5]: NOT APIs"
Alfman Member since:
2011-01-28

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.

Reply Score: 2

RE[7]: NOT APIs
by galvanash on Thu 3rd May 2012 06:36 UTC in reply to "RE[6]: NOT APIs"
galvanash Member since:
2006-01-25

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.

Reply Score: 2

RE[6]: NOT APIs
by Slambert666 on Fri 4th May 2012 03:02 UTC in reply to "RE[5]: NOT APIs"
Slambert666 Member since:
2008-10-30

The GPL doesn't cover the arrangement of interfaces in a library (i.e. it's API) - it only covers the underlying source code and its binary representation when run.


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?

Reply Score: 1

RE[7]: NOT APIs
by galvanash on Fri 4th May 2012 04:14 UTC in reply to "RE[6]: NOT APIs"
galvanash Member since:
2006-01-25

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 Score: 3

RE[7]: NOT APIs
by nutt on Fri 4th May 2012 12:41 UTC in reply to "RE[6]: NOT APIs"
nutt Member since:
2011-06-22

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.


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.

Reply Score: 2

RE[3]: NOT APIs
by cfgr on Thu 3rd May 2012 03:37 UTC in reply to "RE[2]: NOT APIs"
cfgr Member since:
2009-07-18

Indeed. I have always wondered how that was enforceable.

import xmllib
...
document.getElementsByTagName("div")

I'm sure there are several implementations of such an xmllib with the same API, and the exact implementation/licence depends on the library you are using at runtime. How can library A then demand that your software must be GPL'd? Even when it is the only library, the developer doesn't necessarily use and definitely doesn't distribute the code. The end-user is the one doing the puzzling.

In fact, I recall that the FSF did not consider including header files as derivative works[1]. In dynamic languages such as python, you don't even include anything before distributing it. This difference between GPL and LGPL has always been a bit fuzzy to me. Perhaps this is why many prefer to avoid the GPL nowadays.

[1] http://lkml.indiana.edu/hypermail/linux/kernel/0301.1/0362.html

The discussion is quite interesting to follow while keeping this court ruling about API's in mind.

Edited 2012-05-03 03:43 UTC

Reply Score: 1

RE[4]: NOT APIs
by galvanash on Thu 3rd May 2012 04:04 UTC in reply to "RE[3]: NOT APIs"
galvanash Member since:
2006-01-25

Indeed. I have always wondered how that was enforceable.


It depends. This is an admittedly grey area where different people have different opinions...

If you write a proprietary program that uses a GPL library and you distribute that library with your program you are definitely violating the GPL. However, even if you do NOT distribute the library, you are on very shaky ground unless there is a known, available version of the library with the same interface that is not GPL'd.

In effect the existence of a BSD, public domain, or LGPL version of the library insulates you from the GPL - as long as you do not distribute the version of the library covered by the GPL.

That's how I understand it at least.

Reply Score: 2

RE[5]: NOT APIs
by ndrw on Thu 3rd May 2012 04:20 UTC in reply to "RE[4]: NOT APIs"
ndrw Member since:
2009-06-30

"Indeed. I have always wondered how that was enforceable.


However, even if you do NOT distribute the library, you are on very shaky ground unless there is a known, available version of the library with the same interface that is not GPL'd.
"

That's where this ruling comes in. If I understand it correctly there is no gray area anymore.

Reply Score: 3

RE[6]: NOT APIs
by galvanash on Thu 3rd May 2012 05:01 UTC in reply to "RE[5]: NOT APIs"
galvanash Member since:
2006-01-25

That's where this ruling comes in. If I understand it correctly there is no gray area anymore.


I don't see how it affects it in any way, but I've already argued as much in other posts. Ill agree to disagree.

Reply Score: 2

MollyC
Member since:
2006-07-04

for any technology company or any company period at this point in time. The continent is generally in double-dip recession and multiple of its governments have collapsed recently, due to the continent implementing austerity measures during a recession (totally stupid, as even a first year economy student would know, but I guess political ideology ruled the day rather than sound economic theory). I don't get why Europe moved so far to the right when it comes to economics, but they're paying the price now.

Reply Score: 3

MollyC Member since:
2006-07-04

I forgot to add (something more pertinent to the story): I don't know that the inability to copyright APIs makes Europe more friendly for tech companies. I think the opposite claim could be as easily argued.

From personal experience, I worked as a programmer for 20 years (blissfully retired to hobbyist programmer status some years ago), and during all that time, neither I nor any of my coworkers ever had any desire whatsoever to clone anyone's API. But we did want to protect APIs that we ourselves created.

So I dont' know that many companies are interested in cloning others' APIs to begin with, so I don't know that they'd care much that Europe would allow such cloning. But I do know that many companies do want to protect the APIs that they themselves create. The inability to protect APIs that one creates might make Europe actually seem less friendly to tech companies (well, less friendly to creators; more friendly to freeloaders and those that lack the ability to create invent anything).

P.S.
I realize that the EU laws and court rulings are meant to foster healthy marketplace, but I can't help but notice that so much of the legal wrangling that goes on there (and elsewhere) involves American companies (and to a lesser extent, Asian ones). It's rare that a European company is involved. And that would seem to be because there are so few leading European software companies (depsite there being top-notch European programmers and top-notch European universities with great software degree programs (I worked with many great European programmers that had come to the US to find work)). Maybe that's because Europe's laws and rulings are not conducive to fostering world-leading software companies. Which would indicate that Europe is not "friendly" to such companies. And maybe allowing companies to freely rip off others work would only further such un-"friendly"-ness.

On the other hand (and somewhat contradictory to what I just wrote), Europe is the continent that bans products from the marketplace so as to cave to demands that parties pay 4 billion dollars per year for patents license fees, covering technology for which the typical patent fee is roughly 1.2 million times less than such demands. Seems Europe would allow folks to clone APIs, yet would defend 4 billion dollar patent license fees. Seems they want to be on both extremes. Which might be argued to result an un-"friendly" (as in "legally unpredictable") environment for tech companies.

Edited 2012-05-03 03:58 UTC

Reply Score: 2

dylansmrjones Member since:
2005-10-02

Blahblahblah

Reply Score: 3

ndrw Member since:
2009-06-30

EU is doing many things wrong but austerity, and keeping patents and copyright at bay aren't one of them. If anything, I wish it pushed harder.

Copyright reaches way too far and lasts too long. Anything relaxing the restrictions is good, even if it happens to turn GPL into LGPL.

BTW, if you're one of these economy students - please change the school. It is like a medical school teaching that defibrillator solves all the health problems.

Reply Score: 6

dylansmrjones Member since:
2005-10-02

It doesn't turn GPL into LGPL.

You obviously cannot grasp the difference between an abstract representation and the actual implementation.

*long stuff removed*

Read what Galvanash wrote, you carrot!

Reply Score: 2

Slambert666 Member since:
2008-10-30

Read what Galvanash wrote, you carrot!


Galvanash is misrepresenting the case, he basically says that the GPL never covered dynamic linking, and that is a radically different interpretation than for example the FSF has.

i.e. the problem in a nutshell:
1. if you cannot copyright the API, can you then copyright the files that express that API? and only that API? (ie. the header files).

2. If you cannot copyright either, then can I include only the header files from a GPL covered library in my non GPL (say BSD or proprietary licensed) project?

Reply Score: 2

dylansmrjones Member since:
2005-10-02

You are misrepresenting the posts of Galvanash. Galvanash hasn't stated that GPL never covered dynamic linking. At the very least link to a post where it is the case.

1) There is no actual code in a header file (.h) itself - it simply defines the API but does not actually express it (that would be a .c-file or .m-file for Objective C). So no, header files are not copyrightable. Neither in european countries, nor in USA (at least the courts have said so, so far). But the code which implements the API (.c, .m, .cmm, .pas, .bas). This leads to the answer for question #2.

2) No, not according to copyright law, nor the GPL licenses. Only including the header files makes no sense, and you would know that if you were a programmer. An include statement does not mean that you are putting the source file or the header file among your source files. It is a compiler statement, which means that the compiler during compilation of your source will link against the said file, creating a digital work which includes the copyrightable code implementing the methods described by the header file. So, the answer is a strong and resounding NO! - at least not without violating copyright.

There is one 'but'. When using interpreted languages you as a developer do not control what the binary representation of your digital work will link against since there is no binary until the source is a run by the end user. You can certainly distribute source code which is non-GPL'ed but links to GPL'ed source code. You just cannot distribute the resulting binary product. With interpreted languages (or some plug-in based applications) there is no such binary product to distribute and the GPL may fail to activate. There is nothing new in that.

Reply Score: 3

Slambert666 Member since:
2008-10-30

Do you even know what dynamic linking is?

There is no code from the library included in the final binary that is not in the header files (in almost all cases).

So are you saying that it is possible to dynamically link against GPL code?

Anyways GPL header files are normally full of copyright and license information, are you saying that GPL projects should remove this superfluous information since they are misrepresenting copyright and now breaking EU law by including it?

The obvious conclusion is of course that if an API is not copyrightable then it must be legally ok for a non GPL project to dynamically link against a GPL project, and on a side note, it must be legally ok to make linux kernel modules that are not GPL and distribute these (as non GPL code).

Reply Score: 2

dylansmrjones Member since:
2005-10-02

*sigh*

Reply Score: 3

cfgr Member since:
2009-07-18

2) No, not according to copyright law, nor the GPL licenses. Only including the header files makes no sense, and you would know that if you were a programmer.

Yes it makes sense. That's what all these -devel RPMs are for. They are not source RPMs, they just contain the header files so that you can include them.

When linking dynamically, you do not include any actual source code (unless it's in those headers), so you do not need to have the actual source code installed. All you do is building a lookup table with unresolved symbols that's used by the linker at startup time to find and load fitting external libraries. It's easy to intercept that process and make the linker load different libraries with the same API. A typical example is valgrind, which hijacks standard calls such as malloc and free to detect memory leaks, but you never include any valgrind headers nor code at any time.

There is one 'but'. When using interpreted languages you as a developer do not control what the binary representation of your digital work will link against since there is no binary until the source is a run by the end user.

Nor do you when you use dynamic linking. It's only when you build a static binary that you pull in all the code to have a standalone executable.

Edited 2012-05-04 17:03 UTC

Reply Score: 1

MollyC Member since:
2006-07-04

Yes, but what does the FSF say? Does dynamic linking to GPL code create a GPL "derived" work according to FSF?

Reply Score: 1

cfgr Member since:
2009-07-18

Yes, but what does the FSF say? Does dynamic linking to GPL code create a GPL "derived" work according to FSF?

What the FSF says is not really relevant. What matters is what the law says. As far as I can tell, this ruling points out that API's (i.e. things like names and signatures) are not copyrightable, only the actual implementation of that API is. Therefore it would be odd that you can end up with a derived work if you only use the API and do not include an actual implementation of that API (which is what dynamic linking does).

So from an engineering point of view, it would seem that when linking dynamically, you would be creating a derived work from something that is not copyrightable. I'm not a lawyer, but my guess is that this no longer makes it a derived work, in which case GPL would be equal to LGPL for dynamic linking (and interpreted languages), at least in the EU. It remains to be seen if that is the case in the USA as well.

Reply Score: 1

MollyC Member since:
2006-07-04

In C++, one can write the entire code for a library in .h files by implementing class methods directly in the class definition. .h files can also have stand alone inline functions, templates, and macros, all of which implement functionality rather than merely declare an interface to the functionality. Indeed, there are so-called "template libraries" where the "library" is just a bunch of .h files that implement templates, and there's no compiled binary at all. All of these things are actual implementation code, rather than just being function prototypes, and are indeed copyrightable. So it's wrong to declare that .h files are not copyrightable.

Beyond that, open any Win32 .h file, and you'll see "Microsoft copyright 2012" statement at the top (or something like that). Open a GPL .h file and you'll see the GPL boilerplate copyright info at the top. Even if the file only contains function prototypes. .h files have always been copyrightable.

Reply Score: 2

MollyC Member since:
2006-07-04

If implementing austerity during a recession or during a recovery from a recession is so great, why have multiple European governments collapsed due to it (I think Thom's own Holland is an example), why is Europe in doule dip recession (the US is not), and why are national debts actually increasing (for example, see the UK, where Cameron's austerity has led to an increase in national debt due to low tax revenue resulting from the double dip recession that austerity brought on).

Another question: Why are so many European countries simply doing whatever Germany tells them to do? Germany demands austerity, so the other countries do it. Who appointed Germany as economic steward of the EU?

Reply Score: 1

ephracis Member since:
2007-09-23

I guess the EMU did that. But yeah, Germany should shut up and stop being so afraid of a little inflation risk. Damn, we need a real firewall.

Besides, we outside the EMU are a bit more safe. My country, Sweden, has managed to keep afloat pretty good during these hard times. You forget that Europe is a whole bunch of countries, some working together, some not, some with a common currency, some not, and so on. We're all different.

Back on topic: yeah!

Reply Score: 2

ndrw Member since:
2009-06-30

Nah.. I was already replying to you, when I realized it simply doesn't make sense. You're obviously set in your opinions, and so am I. Everyone else: sorry for the off-topic.

So, just quickly reasserting my opinions:
- Austerity is a necessary evil (we shouldn't have inflated the economy in the first place).
- Austerity is still better that further inflating the credit bubble.
- I don't mind good ideas regardless of their origin (here: Germany).
- You're living in Greece in 2004, watching Olympic Games and thinking how this massive expenditure is going to push the country forward.

Reply Score: 4

Fair use
by kwan_e on Thu 3rd May 2012 11:46 UTC
kwan_e
Member since:
2007-02-18

Surely, header files should come under fair use provisions. You should be able to directly copy header files, no matter how the stuff the header file points to is copyrighted.

If nothing else, it would stop people from implementing APIs in header files...

This brings me to another idea - instead of fighting copyright, would we be better served by increasing the scope of fair use? It will either have the effect of giving people more power to cope with big business having more power; or big business will stop trying to extend copyright lest they become too fair.

Reply Score: 2

FSF doesn't matter
by kwan_e on Fri 4th May 2012 08:01 UTC
kwan_e
Member since:
2007-02-18

The opinion of the FSF on dynamic linking doesn't matter as much as a court's decision whether one instance of dynamic linking creates a derivative work and another one doesn't...

Reply Score: 2