LWN: Comments on "Fair use or "first excuse"? Oracle v. Google goes to the jury (ars technica)"

RMS on Copyrightability of APIs

steffen780 — Fri, 18 May 2012 01:30:08 +0000

> and would make your software subtly incompatible, license-wise, with other software using the true GPL license.

How do I put this.. please read the GPL. Any restriction beyond the GPL itself is voided, you cannot just place additional restrictions on it. Look at, for example, GPLd software in the Apple jailstore - it's illegal. Of course, by definition, the copyright owner cannot break the license (or if she can, it is entirely irrelevant as she cannot sue herself for infringement..), so the owner can put her software in the Apple store anyways.

RMS on Copyrightability of APIs

ekj — Fri, 04 May 2012 07:57:47 +0000

Indeed. I can walk into a shop here in Norway and say: "I would like to purchase a copy of [some-software]", they'll fetch a copy, and tell me the price. I pay, get the copy and leave.

You'd have to be insane to consider what just happened to be something different from a purchase. I stated point blank that I want to purchase, I was told the price, I paid and got the goods. Notice that you can do this directly from the software-vendor in many cases. "Buy" they say in their webshops.

They do -not- say "Get a license to use this software under certain restrictive terms", for example on Adobse own page: "Buy photoshop", "Buy lightroom". They claim you can buy it, they take your money, they give you the software.

To then come a week later when I want to install the thing, and claim that infact that was all just a joke, and I didn't infact buy a copy of photoshop, but instead merely a license, that should get laughed right out of court.

If they don't want to sell copies of photoshop, they should stop advertising photoshop as for sale.

To add insult to injury, the EULA is invariably in a foreign language that I may not even be able to read, and even if I was, it references laws that are not relevant in my jurisdiction and courts that have no jurisdiction here.

RMS on Copyrightability of APIs

dlang — Wed, 02 May 2012 17:53:06 +0000

for what it's worth, there was just a decision in the EU clearly stating that APIs and programming languages (as opposed to implementations of the languages) cannot be copyrighted.

http://web.archive.org/web/20200208061421/http://www.groklaw.net:80/article.php?story=20120502083035371

RMS on Copyrightability of APIs

steffen780 — Wed, 02 May 2012 16:29:15 +0000

> Copyright protection only applies to the act of making copies. Using something or modifying something does not require a copyright license, and there's no such thing as useright or modifyright protection.

Totally wrong. From Wiki: "Copyright is a legal concept, enacted by most governments, giving the creator of an original work exclusive rights to it, usually for a limited time. Generally, it is "the right to copy", but also gives the copyright holder the right to be credited for the work, to determine who may adapt the work to other forms, who may perform the work, who may financially benefit from it, and other related rights."

Copyright is badly named, but it is NOT merely about copying. I'd love to know where that idea comes from as it seems to be propping up more often recently.

> The fact that most software companies believe that "end-user license agreements" are legally enforceable is something the FSF disagrees with.

Yes, but that is not because copyright is only about copying. That is because the restrictions are so extreme and because the user is only given access to the license after purchase, when they need to be told about the conditions before purchase for them to apply (under any sane legal doctrine at least, your jurisdiction and/or judge may disagree). There might be further reasons for their view.

RMS on Copyrightability of APIs

Los__D — Wed, 02 May 2012 10:42:23 +0000

GPLv3:
"2. Basic Permissions.

All rights granted under this License are granted for the term of copyright on the Program, and are irrevocable provided the stated conditions are met. This License explicitly affirms your unlimited permission to run the unmodified Program."

GPLv2:
"Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted."

Fair use or "first excuse"? Oracle v. Google goes to the jury (ars technica)

rdale — Wed, 02 May 2012 09:16:03 +0000

But because the rejection isn't final, Oracle's still going to be allowed to present it in court.

Oracle asked the judge to allow the patent to be included in the trail, but the judge rejected their request as the trial had already started. From Groklaw:

Update: 5: Dan Levine has now tweeted that the judge has said no to Oracle's request. And he has indeed: "Oracle will be required to stand by its word and live with the dismissal with prejudice."

http://web.archive.org/web/20140825110424/http://www.groklaw.net/articlebasic.php?story=20120425133552218

Fair use or "first excuse"? Oracle v. Google goes to the jury (ars technica)

drago01 — Wed, 02 May 2012 08:00:29 +0000

> But my point was simply that we still have weeks to go before we get a final decision on what happens with Android.

I'd say months ... I am pretty sure that whoever looses this will appeal the court decision so ...

RMS on Copyrightability of APIs

geofft — Wed, 02 May 2012 07:36:27 +0000

> Fascinating GPL loophole! How come the FSF let that happen?

Copyright protection only applies to the act of making copies. Using something or modifying something does not require a copyright license, and there's no such thing as useright or modifyright protection.

The fact that most software companies believe that "end-user license agreements" are legally enforceable is something the FSF disagrees with.

> In other words, you are basically saying the difference the LGPL and the GPL does not make any legal sense.

No, the difference between the LGPL and the GPL is something else entirely. It means that if I take an LGPL library and link it into / use it from a proprietary software application, and distribute the result, I am only obligated to redistribute the source of the library and my changes to it, not the entire application. If there's no distribution, neither the LGPL or GPL are relevant. If there is distribution, the difference is how much source has to be distributed.

RMS on Copyrightability of APIs

geofft — Wed, 02 May 2012 07:30:42 +0000

> Moreover, it's not clear if headers can even be copyrightable at all. They are merely statements of facts (about kernel's interface structure layout and numbers) and so in many jurisdictions can't even be put under the copyright.

That's not the position rms historically took in the early days of GPL compliance. Admittedly, in that example, I think rms won the argument by going "Do you really want commercial companies to be making the argument you're making", and the software author conceding "I think my software should be GPL'd for the sake of its its own future", rather than him believing the argument on the merits.

But rms definitely believes and argues, or believed and argued in October 1992, that using the readline API -- even if the software author provided an ABI-compatible "libnoreadline" -- was enough to make a software package subject to readline's licensing restrictions.

Of course, unlike with a kernel, the package in question and readline resided in the same address space, but I'm not sure that's a distinction that's legally significant.

RMS on Copyrightability of APIs

gmaxwell — Wed, 02 May 2012 06:45:52 +0000

Indeed, I was aware of this when I responded— and probably should have been more clear about that— but the lure of someone being wrong on the Internet was too strong for me. The followups appear to have confirmed my assumptions that people were confused about this, sadly.

RMS on Copyrightability of APIs

kevinm — Wed, 02 May 2012 06:42:22 +0000

This is a common bad argument. It's seductive because it's made out of true facts, but that doesn't prevent it from being wrong in most places where its applied.

You are correct, but in this case it isn't wrong - the scenario under discussion is when the GPLd library is not distributed by the author of the closed-source application. Only the closed-source application itself is distributed.

Fair use or "first excuse"? Oracle v. Google goes to the jury (ars technica)

xtifr — Wed, 02 May 2012 05:11:34 +0000

I believe it's actually two, although one has been tentatively rejected on re-exam by the PTO. But because the rejection isn't final, Oracle's still going to be allowed to present it in court. But my point was simply that we still have weeks to go before we get a final decision on what happens with Android.

RMS on Copyrightability of APIs

mjg59 — Wed, 02 May 2012 03:00:53 +0000

The early 80s were an era where it wasn't even entirely clear under US law that software was copyrightable. Franklin didn't attempt to demonstrate that they'd independently come up with equivalent code. They didn't attempt to demonstrate that the extent of their copying was to ensure compatibility and no more. They merely asserted that an independent implementation was impossible. Their defence was effectively "Yes, we did this, but we should be allowed to do this". It was worth a go at the time, but it's not really terribly surprising that it ended the way it did.

But that's not equivalent to copyright arguments over an API. Apple v. Franklin never really determined whether or not an API was copyrightable - it merely decided that object code *was* and that Franklin had directly copied Apple's object code. It's even indicated that third parties had produced compatible code without direct copying, but that Franklin had simply chosen not to.

I don't think this case covers anything relevant, other than indicating that courts are able to change the status quo. Before this and the Williams case, the assumption was that software might not be copyrightable. It's conceivable that Oracle might trigger a change in assumptions about whether APIs are copyrightable. We just have to hope not.

RMS on Copyrightability of APIs

wahern — Tue, 01 May 2012 22:56:17 +0000

One way to read the case is that the defendant tried to argue that the OS (as compiled into object code) was so simple that it did not possess the requisite creativity necessary for copyrightability. Remember, we're not talking about a modern, multi-million line kernel, but an extremely simple OS doing basic I/O in way almost entirely dictated by the hardware (i.e. dictated under the circumstances). The creativity involved here is arguably commensurate with that which goes into creating an API. The amount of code we're talking about here is substantially less than many header files today, and certainly far less than the Java API. If something lacks sufficient creativity than verbatim copying is of no matter. This is why Google and RMS argue that Google can basically copy kernel headers files verbatim, strip the GPL notice and, somewhat ironically, affix their own license.

In this case, that argument about simplicity and lack of creativity failed miserably. Our concepts of operating systems has changed considerably over the past 30+ years, so today the case on its face doesn't look like it's concerned with APIs per se. In any event, the questions and holdings of the case make it poorly suited to use in a brief in a real case. But because the question of copyrightability of APIs has received little actual attention in the courts, this case still stands out in the academic literature.

RMS on Copyrightability of APIs

zlynx — Tue, 01 May 2012 21:45:38 +0000

I think I found it.

US Copyright Act section 117 - http://www.bitlaw.com/source/17usc/117.html

"[...]it is not an infringement for the owner of a copy of a computer program to make or authorize the making of another copy or adaptation of that computer program provided:

(1)
that such a new copy or adaptation is created as an essential step in the utilization of the computer program in conjunction with a machine and that it is used in no other manner[...]"

RMS on Copyrightability of APIs

zlynx — Tue, 01 May 2012 21:37:41 +0000

Just to nitpick: people can copy many things without permission or a license agreement. In the US this is Fair Use. Other countries have other laws.

So, your point (a) may not apply.

Probably, if you copy it from an internet site. Probably not, if someone else writes it onto media and hands it to you.

In that second case, someone else made the copy. You are not bound by license by receiving the copy. And, you can copy it off the media onto your computer via Fair Use, and/or automatic permission to use media as intended. The intended use of a computer program is to run it on a computer, which involves required copying onto disk and into RAM. I'm not a lawyer and I don't have the case reference, but I am fairly sure that the copies required to make use of a computer program were decided to not require a license agreement.

RMS on Copyrightability of APIs

slashdot — Tue, 01 May 2012 21:25:57 +0000

That article says "Franklin admitted that it had copied Apple's software but argued that it would have been impractical to independently write its own versions of the software and maintain compatibility".

And "The Court of Appeals overturned the district court's ruling in Franklin by applying its holdings in Williams and going further to hold that operating systems were also copyrightable".

So unless those statement are false, it seems it was about the ability to copyright the OS implementation, not the API.

RMS on Copyrightability of APIs

wahern — Tue, 01 May 2012 21:12:25 +0000

By "software Interfaces" I meant APIs (it's just that with an old OS the API is mostly just entry points at fixed addresses). There are several other well known cases concerning copyrightability of GUI elements which is of no use discussing here.

RMS on Copyrightability of APIs

wahern — Tue, 01 May 2012 21:09:32 +0000

Here's the one I had in mind: Apple Computer, Inc. v. Franklin Computer Corp., 714 F. 2d 1240 (3rd Cir. 1983). http://scholar.google.com/scholar_case?case=1006320412569...

Wikipedia also has a description, http://en.wikipedia.org/wiki/Apple_Computer,_Inc._v._Fran....

But note that the description on that Wikipedia article has some biased opinion. In the first paragraph the editor conspicuously tries to pin the ruling to the facts of the case. E.g. when the editor says that the court opinion "cited the presence of some of the same embedded strings." That's the editor's spin. As taught in law school that case is often used to represent the idea that software interfaces are copyrightable. Of course, it represents whatever a court says it does; not what academics, scholars, and wikipedia editors say.

RMS on Copyrightability of APIs

dlang — Tue, 01 May 2012 18:41:13 +0000

> everal courts have ruled that APIs are copyrightable. I don't have my casebook handy but I believe there was an Apple case a few decades ago where this was affirmed at the appellate level.

Oracle was unable to produce any examples for the court, so I question this statement.

RMS on Copyrightability of APIs

wahern — Tue, 01 May 2012 18:15:43 +0000

Several courts have ruled that APIs are copyrightable. I don't have my casebook handy but I believe there was an Apple case a few decades ago where this was affirmed at the appellate level.

But by-and-large the copyrightability of APIs is still an open question, I believe.

I personally think APIs (and many, many other things) shouldn't be copyrightability. But my "beliefs" count for squat. And the problem in the FOSS community is that we hear a certain cadre of academics swear up and down that APIs aren't copyrightable, and we believe them because they're the only voices we hear.

Well, unfortunately, there are other voices. Rich voices. And those voices pay for conferences and retreats for judges and other policymakers. And though to our ears those voices sound weak and distant, that simply might say more about how far away from the legal mainstream our community is than it does about where the actual law is actually headed. Though, I tend to think most district courts aren't eager to join the party happening over in the patent circuit, and seem to be holding the line against strengthening of copyrights wrt IT.

Still, there's quite a long list of sharp turns the law has taken which surprised the vast majority of legal scholars.

RMS on Copyrightability of APIs

scientes — Tue, 01 May 2012 18:06:20 +0000

I'm sorry, you are right. In copyright the burden is on the accuser and copyright holder.

RMS on Copyrightability of APIs

csd — Tue, 01 May 2012 17:46:32 +0000

Here is article 4 of GPL:
"4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance."

So:
(a) copying has to be done in accordance with GPL - and copying a binary into your computer counts (be it from the internet from another medium).
(b) users only get to use the license as long as they are in "full compliance".

My interpretation of that is that you are only allowed to copy the gpl licensed library if you plan to use it in accordance with the gpl - and if you agree to copy a program which is in violation of the gpl when linked against a gpl licensed library, and your intent it to do exactly that, then you are not in full compliance as a user. Thus you loose your license. I.e. this is willfull infrigement on the part of the user if he/she plans to download a code that violates the license when linked against gpl code.
But I agree that the gpl is confusing on this part. I can see your argument too - the part that is a hold up for me is 'copy', which ultimately both sides are doing - the one publishing and the one receiving - as being the potential issue with your interpretation. We'll find out if this is ever tested in court. Cases that have been tested afaik only test the more obvious cases of releasing modified versions of gpl licensed code (busybox, kernel), I am not aware of any test of the linkage clauses of the gpl

RMS on Copyrightability of APIs

nybble41 — Tue, 01 May 2012 17:27:06 +0000

The requirement to provide source code only applies if you distribute the program. You don't even need to agree to the GPL merely to use the software, as the license itself clearly affirms. It's a distribution license, not an EULA. So your users are not in violation of the GPL, and inability to release the source isn't an issue, provided they don't attempt to distribute the combined work.

RMS on Copyrightability of APIs

csd — Tue, 01 May 2012 16:26:00 +0000

yes. But then your users are in violation of GPL. Makes lawbreakers of your app's userbase as they couldn't release the source if they wanted to.

RMS on Copyrightability of APIs

raven667 — Tue, 01 May 2012 16:07:54 +0000

That's hardly a loophole, that's totally intended and desired behavior. The goal of the GPL is that the programmer who maintains a particular thing has the access and the rights to fix and modify the whole of that thing, if a programmer writes their own (proprietary, internal-only) code they still have access and rights to the whole thing so that's a total GPL success. If they distribute the result of their work than the people they distribute to need to also have access and rights to the whole of the work which is why the GPLs sharing clauses are predicated on distribution.

RMS on Copyrightability of APIs

nybble41 — Tue, 01 May 2012 16:06:45 +0000

> In other words, you are basically saying the difference the LGPL and the GPL does not make any legal sense.

Copyright doesn't make legal sense to begin with, especially as applied to software. However, there is still a difference. In the case under discussion only the application is distributed, not the library. It would remain a problem to mix the two together, e.g. as part of a distribution. The application developer would have to distribute an incomplete version of the program, and probably couldn't even advise the user on where to find the GPL'd library to link against without risking "contributory infringement".

There have been GPL/LGPL implementation of proprietary library APIs before; e.g. lesstif vs. motif. Applications written against the motif API, but linked to the lesstif implementation, are not generally considered derivatives of the motif library. Another example would be applications written for ReactOS, a FL/OSS implementation of the Win32 APIs. Is it so surprising that the same principle could be applied to GPL/LGPL libraries?

RMS on Copyrightability of APIs

nybble41 — Tue, 01 May 2012 15:54:24 +0000

> APIs and their implementations (and their use) is full of bugs, and unless forced to programs generally don't get it right. This shows that programs are derivative by default.

No, it only shows that _if_ a program depends on the bugs in a particular implementation, rather than an API common to all implementation, then it might be derivative.

If this sort of dependency is as common as you say then it shouldn't be difficult to prove that the application is derivative of the library implementation rather than just the API--but you still need to prove it for each specific application and library, not just assume it to be true "by default".

RMS on Copyrightability of APIs

marcH — Tue, 01 May 2012 14:49:39 +0000

> There's limits to what EULA contracts can actually demand.

If the licence of a library is struck down in court as unreasonable, that surely makes no one able to use the library until a new licence is issued.

"Judge: since you missed your chance at a licence, sorry you just fell in the public domain". Uh?

Fair use or "first excuse"? Oracle v. Google goes to the jury (ars technica)

rdale — Tue, 01 May 2012 14:46:00 +0000

"Note that this isn't the whole case; this is just the copyright portion of the case. The patents are still to come."

The aren't multiple patents - as far as I know it is just a single patent at issue which is about initializing static arrays. That doesn't sound like it is innovative earth shattering stuff that Oracle deserves to get hundreds of millions of dollars for to me. So if Oracle lose the copyright part, it looks like their case has pretty much fizzled out.

RMS on Copyrightability of APIs

marcH — Tue, 01 May 2012 14:34:12 +0000

> Even if the user does choose to link a non-GPL application to a GPL library, without distributing the resulting derivative work, it is far from clear that doing so infringes on anyone's copyright.

Fascinating GPL loophole! How come the FSF let that happen?

More seriously: if your application has a hard dependency on the GPL library then it alone is a derivative work of the library. This is clearly the intent of the GPL.

In other words, you are basically saying the difference the LGPL and the GPL does not make any legal sense. I'd rather hear that from a few judges in a few different countries.

RMS on Copyrightability of APIs

nevets — Tue, 01 May 2012 13:59:33 +0000

The authors of the CPL don't get to "define what derivative works are", of course, but they have broad freedom to set whatever terms they like on the distribution of _their own code_

This isn't entirely true. In fact, I would argue that what you just suggested would be struck down in court, as it would most likely be declared as "unconscionable". You can't make a EULA state ownership of other things. Like everything in a 5ft radius. There's limits to what EULA contracts can actually demand.

Have a look at this wikipedia article.

RMS on Copyrightability of APIs

scientes — Tue, 01 May 2012 07:37:54 +0000

> Basically, it's the 'author is [almost] always right' principle.

It is not just a principle, its codified as estoppel. This is one reason why Alan Cox is so clear on this issue.

https://lkml.org/lkml/2012/4/20/487

RMS on Copyrightability of APIs

scientes — Tue, 01 May 2012 07:33:49 +0000

> To play Devil's Advocate for a bit: The _user_ is linking to the GPL library. The application only depends on the API.

In theory: yes. But in practice: Hell No.

APIs and their implementations (and their use) is full of bugs, and unless forced to programs generally don't get it right. This shows that programs are derivative by default. Full Stop. It takes a lot more convincing to show that an application is purely dependent on an API, rather than a bazillion bugs of the *implementation* that are not the API at all.

RMS on Copyrightability of APIs

Cyberax — Tue, 01 May 2012 07:21:15 +0000

>No they can't. 'Derivative work' is a legal term. It is defined by the court precedent and legislative law. You don't get to choose the definitions of this phrase.

You can _loosen_ it by declaring that you don't consider certain uses to be derivative works. Basically, it's the 'author is [almost] always right' principle.

RMS on Copyrightability of APIs

iabervon — Tue, 01 May 2012 04:49:36 +0000

It would actually be more like allowing someone to have a copyright on Klingon or Esperanto. APIs and constructed languages were at least created by a particular individual or organization, and have a certain amount of arbitrary choice. If there are a lot of fields and methods that aren't determined by any fixed scheme, that aspect could be copyrightable. If there are quirks of the API which are only necessary for interoperating with that particular implementation, those probably are copyrightable. In general, APIs should probably be copyrightable to the extent that they are poor APIs.

Fair use or "first excuse"? Oracle v. Google goes to the jury (ars technica)

xtifr — Tue, 01 May 2012 04:15:37 +0000

Note that this isn't the whole case; this is just the copyright portion of the case. The patents are still to come.

RMS on Copyrightability of APIs

drag — Tue, 01 May 2012 04:08:33 +0000

> When you are distributing a work you must abide by the license. Imagine some CrazyPublicLicense which says that any piece of software distributed within a 5ft radius is considered a derivative for the purpose of the license and must also be CPL licensed work.

No they can't. 'Derivative work' is a legal term. It is defined by the court precedent and legislative law. You don't get to choose the definitions of this phrase. While it's true you can agree to a EULA that places additional restrictions that go beyond the scope of copying/distributing, that is entirely besides the point.

I am guessing that that abusing 'derivative works' term would put the license in jeopardy of being declared invalid... which means that everybody loses their rights to copy the software except the original author.

Needless to say: the GPL limits itself to controlling your copy actions of the code and the copying actions of derivative works in the specific case of distribution.

In all actuality it is very likely that some cases linking GPL libraries by closed source software would be 100% legal (and distributing it), while in other cases linking would not be legal. Also it's very likely that some types of proprietary kernel modules would be legal and others would not. It just depends on the specific circumstances and what the judges decide it to be.

In fact that I am willing to bet that if you tried to claim that your GPL license version would prevent 100% of all use of APIs (or kernel modules, or whatever) by closed source software then that would be actually placing additional restrictions beyond what a true GPL license would have and would make your software subtly incompatible, license-wise, with other software using the true GPL license.

RMS on Copyrightability of APIs

gmaxwell — Tue, 01 May 2012 03:14:06 +0000

This is a common bad argument. It's seductive because it's made out of true facts, but that doesn't prevent it from being wrong in most places where its applied.

When you are distributing a work you must abide by the license. Imagine some CrazyPublicLicense which says that any piece of software distributed within a 5ft radius is considered a derivative for the purpose of the license and must also be CPL licensed work.

The authors of the CPL don't get to "define what derivative works are", of course, but they have broad freedom to set whatever terms they like on the distribution of _their own code_— including spatial-proximity-during-distribution, a requirement to only copy onto stone tables, or what have you. If you distribute non-CPL work along with CPL work in violation of the license you're infringing the copyright of the CPL work you're distributing.

If you aren't actually distributing (or otherwise engaging in activities which would be unlawful absent the license) the covered work, then indeed its terms don't apply— including its theories of what constitute a derivative for the purpose of the license. But this is a far more clear criteria than that generic argument "does not define what derivative works", which is prone to being applied when the covered work _is_ also being distributed.

RMS on Copyrightability of APIs

slashdot — Tue, 01 May 2012 02:53:21 +0000

Whether dynamic linking to a library creates a derived work is totally unrelated to whether APIs can be copyrighted.

In the latter case, both the application AND the library are newly written code, and only the API itself is from the original implementation.

Anyway, I don't see how a court could rule an API copyrightable.

It would be like allowing someone to have a copyright on the English language, and requiring everyone to pay royalties to speak or publish unless they switch to French or something else.