In #2, almost every open source project i can think that implement someone else's API are copying declarations verbatim :(

Really? What lines? Copied from where?

I think you misread it (so i updated the original comment).

I meant that open source projects that reuse API declarations or parts aren't typing them themselves, they are copying those API declarations verbatim from somewhere.

Ray's point what if they didn't copy, it may not be an issue, but they all do copy.

Here's a related but not exact example of what typically happens that i actually happened to have open in another window:

https://github.com/andreacimino/gql4j/blob/master/src/main/j...

Notice the comments. These are taken, verbatim, directly from the definitions in Google's GQL reference.

Because it's a parser, there are no declarations, only a grammar implementation (which, BTW, would also fall under this precedent).

However, you'll see the same thing in open source projects that do API implementations as well.

I wonder if you could clean-room most of this.

Person A reads the declarations and writes down what they do, without mentioning any function names or argument names.

  "This function returns the index of a character in a string."

Person B takes person A's work and writes

    int findIndexOf(String s, char c);

A team then writes all the functions to do what Person B wrote up.

Now, at this point, what you have is something functionally the same as Java's String object. Do this for all classes. Call this bundle something like AlterJava. (Or YerksDiddy if you really worry about the name.)

Then someone writes a tool that translates Java into AlterJava. It's an easy thing to put into the compiler chain.

I'm skeptical of these "just hop through this hoop and you aren't breaking the law" ideas when other people make them, so feel free to tell me I'm missing something.

EDIT minor edits

I was thinking of exactly this, and I'd love to hear an explanation of why it wouldn't work. I think Oracle's win here is pretty "thin" in that regard. You could attack the translation tool, but it's just a directory mapping Java names to AlterJava names. What those Java names happen to be called are, under Feist Publications v. Rural Telephone Service Co., uncopyrightable facts.

The hardest part in any clean room implementation is finding people with no prior knowledge of the source to make the clone.

Is it that hard to find people who haven't looked at the Java source code?

> I wonder if you could clean-room most of this. ...

This was much discussed in the early days of the PC; if memory serves, it's basically the approach that was taken by the first successful cloner of the IBM PC BIOS [1].

[1] http://en.wikipedia.org/wiki/Phoenix_Technologies#Cloning_th.... Also http://www.linuxinsider.com/story/33839.html

Leaving aside that GQL is a language, and thus not copyrightable according to this decision, this is licensed use! (AFAICT, GQL is Apache licensed). Google intentionally chose not to comply with the OpenJDK license, and claimed that the APIs aren't copyrightable, and therefore not covered by the license anyway.

Do you have examples of FOSS projects copying code while not abiding by the license?

Again, I really think you're taking this out of proportion. This decision does not affect you if your implementing an API in accordance with the license.

Some people keep saying that this decision is bad for FOSS, but they can't come up with examples of FOSS that will be affected (there are probably a few projects, but nothing that will shake up the industry).

"Leaving aside that GQL is a language, and thus not copyrightable according to this decision,"

Citation needed?

"AFAICT, GQL is Apache licensed"

This page (https://developers.google.com/appengine/docs/python/datastor...) is not Apache Licensed.

It's "Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 3.0 License,"

Given they haven't complied with the license (no citation, no attribution), calling this a "licensed use" is quite a stretch. It's actually pretty clearly not a licensed use.

"This decision does not affect you if your implementing an API in accordance with the license."

Which open source projects rarely do ...

Really, do you think the TOS of most of these websites or software allow you to make your own implementations? Are most of them who do get "licenses" being careful about actually following license requirements?

Every major open-source project complies, or tries to comply with licenses. Tiny projects don't matter because no one will sue them (and no one uses them anyway). Even if a completely imaginary scenario takes place, all they'll need to do to comply is add attribution, or something in the same vein. There's no earthquake coming.

As to copyrighting a language:

The appeals court makes a clear distinction between the Java programming language (i.e., the commands/keywords that are free for everyone to use) and the APIs, and finds that only three of the Java APIs in question are basically part of the Java language, but "Google could have written its own API packages using the Java languages", which, as the opinion notes, "Google chose not to do".

http://www.fosspatents.com/2014/05/oracle-wins-android-java-...

First, bullshit. Here's one on the front page right now: https://github.com/simon-weber/Unofficial-Google-Music-API

Do you think this is a licensed API? Your "nobody will sue tiny projects" thought is contravened by history.

Here's one: http://en.wikipedia.org/wiki/Jacobsen_v._Katzer

We'll strongly disagree as to where this decision will lead. Thankfully, I know i'm not the only one worried.

Also, fosspatents is not a legal decision, nor did you actually cite anything that backs up your claim: Your claim was the decision says the language was not copyrightable. It says no such thing. What it says is "It is undisputed that the Java programming language is open and free for anyone to use."

This is because it was licensed, not because it is uncopyrightable.

That project doesn't clone an API. It uses one. It might be violating TOS, but not copyright.

I didn't know about the Katzer case, but I still see no danger to the FOSS community and ecosystem by the new ruling. All it would do is require developers to clearly specify the license for their APIs. Cloning of proprietary APIs is most certainly not a cornerstone of FOSS today (unless, that is, Linux is in actual danger, in which case I'll change my position).

Actually, it both uses one and clones one :)

"Cloning of proprietary APIs is most certainly not a cornerstone of FOSS today (unless, that is, Linux is in actual danger, in which case I'll change my position)."

I would disagree, but I can't say more, sadly.

Wouldn't this break Wine?

fosspatents is run by a (paid) Microsoft shill. He calls himself an IP pundit or something. Groklaw basically outed him before he owned up to being on Microsoft's payroll publicly.

He is loyal to his employer but his analysis and projections are often contradicted by facts.

> Google intentionally chose not to comply with the OpenJDK license, and claimed that the APIs aren't copyrightable

Perhaps Google didn't comply with OpenJDK license because it didn't exist when Google used Java Apache Harmony implementation.

> Open source projects that reuse API declarations or parts aren't typing them themselves.

And even if they were, if the originals were copyrightable, there's no copyright-relevant difference between "typing them themselves" and "copy and pasting", both are verbatim copying (and, even not doing a verbatim copy and merely doing a "derivative work" based on the existing API would be -- barring fair use or other explicit exception -- a violation of copyright if the API, as such, was copyrightable.)

The reason I bring up the difference between verbatim copying and "typing things in themselves" is because I think the Federal Circuit was myopic in how it applied the merger doctrine, and I think the District Court got it right. The merger doctrine basically says that an expression is not copyrightable if the expression is inextricably merged with the idea.

So I'm imagining a bunch of Java classes loaded into memory. They're objects, and they have methods, and those methods refer to methods in other objects. Creating this state of memory is functional, and definitely not protect-able. Now, the interface declarations, then, are just a description of this state of memory. A method has a particular name or a particular set of parameters but those are just a description of the functionality, and there is no other way to precisely describe that state of affairs. The closest analogue I can think of to an API is a phone book, and the names and addresses in a phone book are not copyrightable, although higher-level structure might be.

I think the court got stuck on the verbatim copying and that prevented them from seeing things this way.

Any API reimplementation is a verbatim copy of the original API.

Depending on the languages involved in both the original declaration and the implementation, its quite possible for an API reimplementation to include a derived work rather than a verbatim copy of the original API declaration (and obviously, it wouldn't be a reimplementation if it was just a verbatim copy of the original API implementation.)

Though both making verbatim copies and making derived works are exclusive rights of copyright owners so that doesn't really reduce the impact of API copyrightability on API reimplementations,

When I say API reimplementation is including the underlying functional code, not just the API headers.

And what is copied verbatim are just the headers

> And what is copied verbatim are just the headers

If you are using different languages that compile to a compatible target, or if you are using the same language that admits different literal declarations expressions that produce the same interface, it is possible to have an API reimplementation -- for the same target platform even -- that does not involve verbatim copying of even the headers/declarations.

It's possible in some languages, but it often involves serious messing around.

For example, in C, this would involve function name aliasing which is usually a compiler specific extension. This might give you name compatibility, but to get struct-level compatibility, you'd have to copy the exact layouts due to padding issues.

In C++ it's even harder, due to when vtables are emitted, etc.

My java knowledge is old (java 5), so i don't know if they made it possible.

Objective-C, I believe it would only be possible if you used the runtime reflection methods directly. I don't think you can easily do it with just headers (corrections welcome!) etc

I believe Java will look up methods etc by name (and signature) at runtime, so anything missing will just produce an exception when you try to use it.

Yes, but most open source projects I know implement APIs while complying with their license. Google chose not to.

If you're implementing an API, you don't need a license... (or at least you shouldn't). You are implementing something based upon given facts, which can't be copyrighted. Google thought that didn't need a license in the first place.

And that's the crux of this case... is an API copyrightable?

Well, doesn't it seem like the circuit court has answered this question in the affirmative?

Samba and Mono, just to name a few, are pretty big-name open source projects that implement APIs without consent of the creator of those APIs. And even the Linux kernel uses the same system call API as AT&T Unix...

Google used Apache Harmony, I suppose that they complied with its license.

closing braces?