Submitted by “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.
The fact is that they haven’t said anything about APIs in code form.
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.
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.
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.
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.
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.
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…
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
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
Yes, but I’m not really arguing it – that is exactly what the court decision stated. Did you read the decision?
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).
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^aEUR”such as data formats and function names^aEUR”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
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.
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.
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.
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.
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.
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
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.
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.
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.
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
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.
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.
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.
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
Blahblahblah
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.
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!
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?
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.
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).
*sigh*
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.
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
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.
Wow, ndrw really unleashed quite the debate here, it turns out I was right this would turn into quite the drama. Unfortunately I think the court left us with more questions than answers. Much of the problem is that the structures and function prototypes present in header files represent the idea of the API and are an expression of the API at the same time. There isn’t really any difference between the idea of a function prototype in our minds, and on screen. So which interpretation would the court have us use? That would have been helpful.
Assuming for a moment that structures & function prototypes are not copyrightable (because they’re directly representative of the ideas of them), then we might consider them to be a type of “copyright barrier”, where two different programs/DLLs can explicitly use the same structures & function prototypes without being legal derivatives. I think this would have huge implications for both proprietary and OSS licenses.
But the court was just too unclear, I think the issue needs to be kicked back in until they take a more assertive stance.
I don’t think the court knew what the hell it was doing. There’s a whole can of worms opened up, for no good purpose.
For example, take “template libraries”, where the “library” isn’t a staic or dynamic library file, but rather consists of a bunch of header files specifying (at times, very complex) templates. In such a case, the template library API is the same thing as the template library implementation. If one can’t copyright APIs, then one can’t copyright template library implementations. So, in effect, all template libraries (that are released to the public for developers to use) are now pulic domain, period. If one creates and releases a template library, the developer cannot specify any terms of use (GPL, LGPL, or otherwise) and must release it as public domain. Which makes no sense and serves no purpose.
Now, the only template libraries that I’ve ever used are the Microsoft ones (like ATL), which while having Microsoft copyright boilerplate statments, Microsoft likely wouldn’t care if they were public domain. But I can’t imagine that RMS or FSF would be pleased to see that it’s now impossible to write a GPL template library and that all existing GPL template libraries are now public domain by court order.
And template libraries is just one example. I can think of other examples where “You can’t copyright API” makes no sense and serves no purpose.
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.
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?
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!
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.
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.
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…