Declaring Code Is Not Code, Says Larry Page (arstechnica.com)

Alphabet CEO Larry Page says his company never considered getting permission from Oracle for using the latter's Java APIs in Android. Page, who appeared in a federal court, said Java APIs are open and free, which warrants them or anyone to use it without explicit permission from Oracle. From an Ars Technica report (edited for clarity): "But you did copy the code and copy the structure, sequence, and organization of the APIs?" Oracle attorney Peter Bicks asked, raising his voice. "I don't agree with 'copy code,'" Page said. "For me, declaring code is not code," Page said. "Have you paid anything to Oracle for using that intellectual property?" Bicks asked. "When Sun established Java, they established it as an open source thing," Page said. "I believe the APIs we used were pretty open. No, we didn't pay for the free and open things." [...] "Was Google seeking a license for Java?" Google lawyer Robert Van Nest asked. "Yes, and a broader deal around other things, like branding and cooperation," Page said. "After discussions with Sun broke off, did you believe Google needed a license for APIs?" Van Nest asked. "No, I did not believe that," Page said. "It was established industry practice that the API and just the headers of those things could be taken and re-implemented. [It must be done] very carefully, not to use any existing implementation of those systems. That's been done many, many times. I think we acted responsibly and carefully around these intellectual property issues."

Comments

Giant problem

[NotInHere]

If APIs are copyrightable, this will be a huge problem for projects like Wine (which implements Microsoft APIs), and GNU/Linux (which implements Bell labs APIs).

Re:Giant problem

[LichtSpektren]

And also Microsoft. Remember that MS-DOS was a renaming of Seattle Computer Products' QDOS, which itself was an API clone of CP/M.

If the jury rules for Oracle, that means Microsoft will owe billions to the estate of Gary Kildall.

Re: Giant problem

[Anonymous Coward]

Wealth redistribution at last!!

Re:Giant problem

[segedunum]

Indeed so. Software is in a whole heap of trouble of APIs are copyrighted and you have to go to court to prove whatever laughable versions of fair use is in vogue this week.

Re:Giant problem

[Anonymous Coward]

Those two are good examples, but it would mean practically *all* clean-room reimplementations of any code would run afoul of copyright issues. It would undermine the whole principle if the API interface itself was copyrightable.

Re:Giant problem

[TWX]

That may largely depend on if man and later the estate did what was necessary to maintain copyright.

Re:Giant problem

[Anonymous Coward]

Not only clean room implementations. Anything that could be considered derivative would also be in a problematic situation.
It's not just that you wouldn't be able to write a replacement library if you don't like the way one is implemented. You wouldn't even be able to write a non-compatible library since the declarations would clearly be derivative.

Re:Giant problem

[StormReaver]

If the jury rules for Oracle, that means Microsoft will owe billions to the estate of Gary Kildall.

And IBM will be able to sue Oracle and Microsoft for billions, for Oracle's use of the SQL API .

Re:Giant problem

[LichtSpektren]

Go home Larry Ellison, you're drunk.

Re:Giant problem

[Anonymous Coward]

It would also mean that Oracle owes billions to SCO for redistributing Linux. If Oracle does win this then I hope that Google buys up the SCO copyrights and sues the hell out of Oracle in return.

Damn, what are you smoking? Because that has to literally be a pipe dream.

If SCO's claims were worth anything, SCO would have won with them.

PS - I own this wonderful bridge. It goes from Manhattan to Brooklyn. I'll let YOU have for much less than it's really worth! Just ONE MILLION DOLLARS!

Re:Giant problem

[LichtSpektren]

SCO doesn't own Unix. Novell (in turn owned by Attachmate) does.

Re:Giant problem

[dwye]

Alas, there is nothing to be done to maintain copyright. It lasts a half century after the creator's death, unless the creator or the rightful heir or heirs (and isn't THAT just a bunch of lawsuits in waiting?) explicitly places it in the Public Domain.

All so Mickey Mouse can never be abused by non-Disney artists/writers/whatever.

Re:Giant problem

[LichtSpektren]

Suppose the government made breathing ("oxygen infringement") illegal. Would you suffocate yourself to death in the name of justice?

Re:Giant problem

[peragrin]

Only after SCO sues IBM for trillions.

Oracles argument was used in SCO vs IBM and it was tossed there too. Headers are not copyright able.

Re:Giant problem

[phantomfive]

You're getting confused with trademark, which needs to be maintained; whereas copyright and patents do not.

Re:Giant problem

[phantomfive]

If APIs are copyrightable

APIs are copyrightable, at least in California.

this will be a huge problem for projects like Wine (which implements Microsoft APIs), and GNU/Linux (which implements Bell labs APIs).

No, Wine has a solid fair-use defense, because they exist only for the purpose of interoperability.
Google is struggling to make an interoperability defense because that was not the purpose of their copying.

Re:Giant problem

[a_n_d_e_r_s]

Linux implements Posix https://en.wikipedia.org/wiki/... which is an IEEE and ISO standard.

Re:Giant problem

[Anonymous Coward]

Trademarks need active maintenance. Copyright does not. It doesn't even need registering, although that can be useful since it gives a 3rd party witnessing proof of its existence at a point in time to use in a court case.

Re:Giant problem

[Sloppy]

Wait a minute... you wrote a .. a .. what did you call it? A "web browser?" And this web browser communicates with my website but you neglected to get a license?!?

Re:Giant problem

[cdrudge]

It's not quite that cut and dry. In general, it depends on when the work was first published and/or registered as well as where. There are all sorts of combinations that would need to be figured out based on a particular instance.

And current copyright is 70 years after an authors death or 95 to 120 years for corporate works depending if they were in a publication or not.

Re:Giant problem

[oh_my_080980980]

Except it was proven that SCO does not own Unix. Ownership was never passed to SCO.

Re:Giant problem

[segedunum]

Yep, you're going to see a ton of stuff coming out the woodwork. There is just simply too much money to be made here not to.

Re:Giant problem

[Anonymous Coward]

And current copyright is 70 years after an authors death or 95 to 120 years for corporate works depending if they were in a publication or not.

Assuming that Disney doesn't pressure legislators into amending the Mickey Mouse Perpetual Protection Act to extend copyright protection even further.

Re:Giant problem

[dwye]

First, we were discussing the copyright of the APIs for CP/M, not Sons of The Swordmaker (which was copyrighted the first time in a period where it could have gone into the PD if it hadn't been extended, which it was, so it still is). CP/M APIs are in the easy period (copyright lasts forever because Disney will keep persuading Congress to extend it whenever Steamboat Willie gets near leaving copyright).

Second, 70 years? Oh, GOD! It's WORSE than I remembered!!

Re:Giant problem

[cyriustek]

Organisations publish their APIs, because that want people to use them.

Sun was making a huge push on this in the early 2000s. IMO Larry Page is spot on with this.

Re:Giant problem

[phantomfive]

Headers are not copyright able.

That's definitely not true, it's even less true of header files than of APIs in general, because header files can have real, important code. The example that was raised on the LKML at the time of the SCO trials were things like htonl() ntohl() etc, because they are implemented as macros in the Linux source code, and they are really efficiently implemented. Obviously in C and C++ a lot of real source code can be implemented in header files.

Re:Giant problem

[fyngyrz]

Buying the license does not mean "using the software supplied with the license" ...unless you want it to. :)

Re:Giant problem

[roman_mir]

Well obviously APIs are copyrightable, pretty much any 'original' work is copyrightable. The real problem is that there is such a concept as government protected copyright (and patent) in the first place.

Government protected copyright and patent laws must be abolished.

Re:Giant problem

[macs4all]

And also Microsoft. Remember that MS-DOS was a renaming of Seattle Computer Products' QDOS, which itself was an API clone of CP/M. If the jury rules for Oracle, that means Microsoft will owe billions to the estate of Gary Kildall.

And that SCO will rise from the dead once again...

Re:Giant problem

[phantomfive]

That's true, Google has plenty of potential defenses.

Re:Giant problem

[gnupun]

Not only clean room implementations. Anything that could be considered derivative would also be in a problematic situation.

And? Do you have problem designing your own APIs instead of starting design with a competitors' APIs and modifying it? The world is full of copycats.

Re:Giant problem

[rochrist]

You ARE off your meds.

Re: Giant problem

[backslashdot]

It's silly to copyright APIs. Eventually we will run out of synonyms and it doesn't help the advancement of the sciences. Congress is only allowed to provide copyright and patents if it promote the arts or sciences. People seem to forget that.

From the constitution:
"To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries."

If a copyright is overbroad and detrimental to progress it shouldn't be allowed.

Re:Giant problem

[jbengt]

. . . pretty much any 'original' work is copyrightable.

No, at least that's not how it's supposed to be. Functionality is not copyrightable, only creative expression.

Re:Giant problem

[Solandri]

Not really. Software companies will all close shop in the U.S. and move their operations to countries where APIs are legally declared not copyrightable. All those companies hiring H1B programmers from India or outsourcing programming work to India? They'll move to India and if you're lucky they'll outsource some of their work to you in the U.S. Software development will continue on in the rest of the world as if nothing had happened. The U.S. will be relegated to a software backwater, as most of the software made and sold in the rest of the world cannot legally be distributed in the U.S.

That's the nature of the free market. It interprets stupidity as damage, and routes around it.

Re: Giant problem

[gnupun]

Don't Ford, Honda and Toyota reinvent their own wheels instead of borrowing designs from each other? Copying ends where private intellectual property begins.

Re:Giant problem

[roman_mir]

Ha, and what if you are absolutely wrong about it? I am against all copyright and patent government guarantees and I also profit from these protections. I consider these protections to be wrong.

Re:Giant problem

[mrchaotica]

The world is full of copycats.

Exactly. A ruling that APIs are copyrightable would set off a legal Armageddon. There'd be nothing left allowed to access the Internet except NSCA Mosaic running on Unix (including BSD derivatives, but not Linux) because the makers of those pieces of software would hold the copyright on TCP/IP and HTTP!

Re:Giant problem

[I4ko]

Next thing you know - UK suing US for copyright infringement on English language since US stopped paying their license fee with the Boston Tea Party.

Re: Giant problem

[unrtst]

Copying ends where private intellectual property begins.

Copying never ends?

Re: Giant problem

[gnupun]

Except the HTTP protocol is in the public domain, just like letters in the English alphabet.

Re:Giant problem

[gnupun]

Exactly. A ruling that APIs are copyrightable would set off a legal Armageddon.

People would steal less, hopefully. And atrocities like MS ripping off Java to create .net or Google making billions off a Java clone will somehow not be repeated.

the makers of those pieces of software would hold the copyright on TCP/IP and HTTP!

How? Those protocols are public domain. They belong to no one and everyone.

Re:Giant problem

[Amouth]

Oh, GOD! It's WORSE than I remembered!!

And it will continue to get worse every time Steamboat Willy gets close to falling into the public domain.

Just think of it as anything made during or after 1928.

Re:Giant problem

[gnupun]

Not really. Software companies will all close shop in the U.S. and move their operations to countries where APIs are legally declared not copyrightable.

What a whole lotta FUD. If you create a product by recreating a competitors' API (that is, you provide an alternate implementation to a competitors' API), you could get sued. How many companies create APIs that are used by the public? An extremely tiny portion.

There is no risk in using an API provided by a vendor (e.g., creating a Java program that uses the standard Java API).

Re:Giant problem

[Dcnjoe60]

If the jury rules for Oracle, that means Microsoft will owe billions to the estate of Gary Kildall.

And IBM will be able to sue Oracle and Microsoft for billions, for Oracle's use of the SQL API .

And anybody who built an IBM compatible computer using the what was formerly thought to be open APIs.

Re:Giant problem

[mattack2]

You do realize that would require a Constitutional Amendment, right?

Re:Giant problem

[Dcnjoe60]

Only after SCO sues IBM for trillions.

Oracles argument was used in SCO vs IBM and it was tossed there too. Headers are not copyright able.

Unlike that case, aren't they arguing that it is the APIs that are copyrightable? That's is quite a bit different. Of course, it would also mean every book teaching JAVA or any other language, for that matter, would not be infringing. I wonder if Oracle used any APIs of others when they developed their flagship product. They might owe AT&T, IBM and others a lot of money.

Re:Giant problem

[Dcnjoe60]

In which countries are APIs determined to be not copyrightable? As in, there has already been legal action or explicit laws passed to say so.
Due to all of the various IP treaties out there, almost anything copyrightable in one country is automatically granted equivalent protection in all other countries. If this is upheld in the US, expect the EU nations to follow suit soon after.

Most of the world can freely use various CODECS without encumbrance of copyright or patents, it is likely that in those same countries one could use APIs. It does not legal action to say something is not protected. It does, however, take legal action to say something is protected. Therefore, only in countries that define APIs as copyrightable would they be so.

Re: Giant problem

[Dcnjoe60]

This guys never heard of not reinventing the wheel.

The problem isn't reinventing the wheel. The problem is interfacing with existing equipment and software. Unless you are going to develop everything from the ground up, including the microcode in the processor, you are going to have to use somebody's API somewhere in the process. One cannot even boot a PC without having to interface with the BIOS or UEFI. Of course, one is free to go around those system calls, but then you need the APIs for the components the BIOS/UEFI talks to.

If APIs are copyrightable it doesn't take long before it is turtles all the way down.

Re:Giant problem

[budgenator]

I do believe patent do have a maintenance fee, or something that has to be repaid or the protection lapses

. The grant confers “the right to exclude others from making, using, offering for sale, or selling the invention throughout the United States or importing the invention into the United States” and its territories and possessions for which the term of the patent shall be generally 20 years from the date on which the application for the patent was filed in the United States or, if the application contains a specific reference to an earlier filed application under 35 U.S.C. 120, 121 or 365(c), from the date of the earliest such application was filed, and subject to the payment of maintenance fees as provided by law. General Information Concerning Patents, Maintenance Fees

If you have enough confidence in reputation and the utility of your product, you might acquire a patent to preclude someone else from interfering with your production, and then let it lapse.

Re:Giant problem

[anegg]

If the specification of a software interface as expressed in the manner precisely needed to make the interface operable in a given programming language is copyrightable, then wouldn't the specification of any interface as implemented in the manner to make the interface usable be copyrightable?

That could make it a copyright violation to use a non-Ford oil filter on your Ford engine, or non-OEM lightbulbs in your lighting fixture, or non-Keurig K-cups in your Keurig coffee maker unless the equipment manufacturer specifically allowed it.

Ok, so perhaps it can be claimed that software is different because it is expressed in a written form that makes its interfaces themselves specifically vulnerable to a copyright claim that can't be made against the actual interfaces of physical objects. If so, that specific vulnerability should probably be removed from copyright law unless there is a good reason for not removing it. Creating a "something" that can interface with another "somethingelse" should fundamentally be a protected act against claims from the creators of the "somethingelse", as long as the internal mechanism of the "something" doesn't steal intellectual property belonging to the creators of the "somethingelse", whether the objects are physical or virtual. The greater good lies in the interface itself being freely copy-able/re-usable by others.

Re:Giant problem

[budgenator]

I would argue that an API isn't copyrightable because it is simply a catalogue of facts not a creative work; it points to program locations and describes the interface; no more copyrightable than a telephone book.

Re: Giant problem

[ZeroWaiteState]

BS. That's precisely why it was done. It was done so existing Java third-party libraries (of which there are a huge amount) could be leveraged in Android applications without much rework needed. Google would not have had to even create Dalvik at all, had the JVM had the necessary efficiency to operate on memory and clock constrained mobile platforms. The problem is that Sun and later Oracle killed the golden goose with overly restrictive licensing. If they can go after Google for Dalvik, they can also sue Apache for making Tomcat, various open source byte-code optimizers, and virtually any competing database vendor which can run Java stored procedures. This lawsuit is why Java will never replace standardized languages like C, because the owner of the language has legally encumbered the technology to the point that it is a minefield. People have been warning about this for decades. What I'm surprised about isn't that it happened, but rather that it took this long.

Re: Giant problem

[jschultz410]

Considering API design a "mere collection of facts" is bonkers. It is one of the most, possibly the most, important elements of software design.

Re:Giant problem

[mrchaotica]

How? Those protocols are public domain. They belong to no one and everyone.

A protocol is nothing more than an API, "on the Internet."

Re:Giant problem

[budgenator]

They have to be a creative work to be copyrighted, an API is a catalogue, a list of facts, the programming equivalent to a phone book. In the game Trivial Pursuit, only the errors are copyrighted because the correct answers are fact, not creative works.

Re:Giant problem

[phantomfive]

It costs ~$5000 to apply for a patent (including lawyer fees). After that, there's no maintenance fee. It will lapse automatically after ~20 years, and there is nothing you can do to renew it.

Re: Giant problem

[phantomfive]

BS. That's precisely why it was done. It was done so existing Java third-party libraries (of which there are a huge amount) could be leveraged in Android applications without much rework needed.

What existing java libraries became popular on Android? I can't think of any, and I've never used any in my own programming (although I've used C libraries).

Re:Giant problem

[roman_mir]

Again, you are wrong on you idiotic statement 'you have not created anything'. I run a business, I own products and services that a number of clients are using, I built code for the last 20 years. I hold a patent, I also wrote a few articles, recorded some sounds, shot a million pictures, whatever. All those things have copyright protections.

My position is that it is wrong to have government guaranteeing any of these protections.

Re:Giant problem

[roman_mir]

Sure, so did slavery.

Re:Giant problem

[roman_mir]

a list of facts,

- sure, so is a photo or any picture and pictures are copyrightable.

The list of facts from wiki:

Based on reviewing this case history, the court noted that: ...the above summary of the development of the law reveals a trajectory in which enthusiasm for protection of "structure, sequence and organization" peaked in the 1980s, most notably in the Third Circuitâ(TM)s Whelan decision. That phrase has not been re-used by the Ninth Circuit since Johnson Controls in 1989, a decision affirming preliminary injunction. Since then, the trend of the copyright decisions has been more cautious. This trend has been driven by fidelity to Section 102(b) and recognition of the danger of conferring a monopoly by copyright over what Congress expressly warned should be conferred only by patent. This is not to say that infringement of the structure, sequence and organization is a dead letter. To the contrary, it is not a dead letter. It is to say that the Whelan approach has given way to the Computer Associates approach, including in our own circuit. See Sega Enters., Ltd. v. Accolade, Inc., 977 F.2d 1510, 1525 (9th Cir. 1992); Apple Computer, Inc. v. Microsoft Corp., 35 F.3d 1435, 1445 (9th Cir. 1994).[16]

Appeals court:

Oracle appealed to the Federal Circuit Court of Appeals, and Google filed a cross-appeal on the literal copying claim.[28][29] The hearing was held on December 4, 2013,[30][31] and the judgement was released on May 9, 2014. The appeals court reversed the district court on the central issue, holding that the "structure, sequence and organization" of an API was copyrightable. It also ruled for Oracle regarding the small amount of literal copying, holding that it was not de minimis. The case was remanded to the district court for reconsideration of the fair use defense.[6]

There is only one real problem in all of this and that is government protection of monopolies based on copyrights and patents. Government must not be helping anybody with anything, including people or businesses in their business models.

Re: Giant problem

[UnknowingFool]

Well it never got to that. Most of the claims by SCO were tossed out because they lacked specificity even after ordered by the judge to clearly spell out to the court what they were claiming. The rest were closed by the court after Novell was found to be the copyright owner of UNIX and thus SCO had no standing to sue.

Had it gone to trial, IBM certainly would have won on any detailed code comparisons as SCO did a completely shoddy job of code analysis. Among the things they claimed were that header files like "include studio.h" were copyrightable. They also claimed lines of code were similar when it was clear that there were not. They also lumped code that were not contiguous (in different libraries, separated by many lines) as the same as those found that were actually contiguous.

Re: Giant problem

[ZeroWaiteState]

Just because it's an ISO or IEEE standard doesn't mean you can legally implement it without obtaining licenses. The same thing also holds for many telcos standards.

Re: Giant problem

[ZeroWaiteState]

I'm not going to list the contents of maven central in a slashdot thread for you. By the way, the so-called Android API already bundles some third-party libraries (such as Apache HttpComponents) although you may not realize it.

Re: Giant problem

[phantomfive]

Most people don't use Maven for building Android apps, believe it or not. Most of the time people used Ant, believe it or not, because that's what Google advocated (I have no idea why). Later, they switched to Gradle (again, I have no idea why).

the so-called Android API already bundles some third-party libraries (such as Apache HttpComponents)

ok, that's a good point.

Re:Giant problem

[gnupun]

an API is a catalogue, a list of facts, the programming equivalent to a phone book.

Funny, there's only one phone book for any given city. However, for any given problem domain, there are dozens of different API sets, each concentrating on certain aspects and ignoring others -- similar to what designers do while designing something. So much about your theory about "a list of facts."

Populating a phone book with its content is a tedious, simple, boring job. However designing APIs is a difficult endeavor, requiring highly skilled architects. Even tiny defects in the design have a great impact for years or decades to come. Implementing these APIs is often done by programmers of much lower skill than the architects. And you fools still claim the implementation is of greater importance than the API?

Re:Giant problem

[angel'o'sphere]

TCP/IP and HTTP are protocols.
Not APIs.
They are basically on an even lower level of 'copyrightness' than APIs.

Think about a distress call via radio:
MAYDAY MAYDAY MAYDAY
This is pleasure yacht 'Odins Eye'.
My position is:
My hazard is:

I request immediate assistance.

OVER.

This is a protocol, not an API.

Re:Giant problem

[angel'o'sphere]

No, a protocol is far far far less than an API.

Or, depending if you have an API to support some internet protocol: it is a ruleset how to invoke functions/methods in which order on that API.

APIs and protocols are complete different things.

You can have endless APIs to support/implement one protocol.

But not plenty of protocols to implement/realize/support and API.

Re: Giant problem

[Time_Ngler]

What is this "studio.h" file you speak of? A header file for landlords?

Re: Giant problem

[go-nix.ca]

This case is not about use, but about reimplementation.

Re: Giant problem

[go-nix.ca]

Actually a lot of creativity goes into the design of an API. You have to imagine what developers' code will look like as they use your API in various use cases. Will that code be legible? What abstractions do you implement? These are all design decisions - i.e. a creative process. Just look at the UNIX vs. Windows implementation of the API for launching a process: Windows is an ugly mess of filling out enormous structures, calling CreateProcess() and hoping you've crossed all your t-s and dotted all your i-s. In UNIX? fork() followed by exec(). BOOM! And I know both APIs do the same thing, because one has been implemented with the other (cygwin and wine). So yeah ... I can see Oracle's point.

Re: Giant problem

[Dcnjoe60]

This case is not about use, but about reimplementation.

It doesn't matter what the case is about, if there is a finding that APIs are copyrightable, then we are all screwed.

Re:Giant problem

[BasilBrush]

Nothing of any worth.

Re: Giant problem

[bingoUV]

Protocol is, the data you sent over it isn't. After "http://", if you send "slashdot.org", do you have explicit permission for that?

Re:Giant problem

[sjames]

It's far worse. What of stdio? That crosses several different OSes and many implementations. Most lamguages specify a number of standard functions that must be implemented and can only be defined one way.

If the courts let APIs be copyrighted we might as well turn our calendars back to the 1950's since there will be no way forward.

Re:Giant problem

[sjames]

So you have no problem with a world that has an IIS browser that can only talk to IIS servers and an Apache browser that only talks to Apache, etc etc? Because at heart, http is a form of RPC API.

Re:Giant problem

[gnupun]

...and describes the interface

And how did this interface description come into existence? Did computer software generate it? No. Did an "interface description" fairy write it? No. A designer had to do the work. Out of hundreds of possibilities, the API designer had to select the right one, thereby requiring creative skills.

Sorry, but your phone book analogy is downright wrong and possibly, dishonest. A robot could visit every house in the city, knock on the door and obtain the name, address and telephone number needed to populate the phone book. Therefore, phone book creation == mechanical task == non-creative task. But there's no robot that will write the interface description (API) of a function.

Re:Giant problem

[ultranova]

Software companies will all close shop in the U.S. and move their operations to countries where APIs are legally declared not copyrightable.

Or more likely big companies will gather protection money from smaller ones while having MAD treaties with one another. After all, isn't the whole point of Trans-Atlantic/Pacific trade treaties to "harmonize" various IP laws across the world?

That's the nature of the free market. It interprets stupidity as damage, and routes around it.

When the whole world is a single global market, there's nowhere to route.

Re: Giant problem

[gnupun]

Protocol is, the data you sent over it isn't. After "http://", if you send "slashdot.org", do you have explicit permission for that?

LOL, "slashdot.org" is argument passed to the function, not the function itself:

page = http_GET("slashdot.org") // http_GET API is copyrighted, not the "slashdot.org" argument

Re: Giant problem

[bingoUV]

Yes, do you have explicit permission for providing that particular copyright protected argument?

Re:Giant problem

[hucker75]

Capitalism sux.

Re:Giant problem

[sjames]

The headers is all that Google uses. Personally, I am in full agreement with Page. Oracle wants the courts to make it a problem for everyone so they can grab some of Google's money.

Re:Giant problem

[gnupun]

That's the future -- if you want multiple implementations of certain APIs, they should either be an open standard, or the corp that owns them should license them to multiple different vendors.

I have repeated this a f**ing billion times that HTTP is not owned by any corp... it's an open standard... and so I don't have pay any licensing fee to reimplement it in my product. So stop repeating same annoying lies every other post.

Re:Giant problem

[sjames]

I take it then you prefer dystopian futures?

Re: Giant problem

[gnupun]

It doesn't matter what the case is about, if there is a finding that APIs are copyrightable, then we are all screwed.

That's like saying, books are copyrighted, so if you read them, an army of lawyers will descend upon you to sue you, demanding massive licensing "book-reading" fees. LOOL.

Re:Giant problem

[lsatenstein]

I thought the functionality of the API is free and open source. The title to the API (The API's name and sequence of parameters) is what Oracle wants copyrightable. And with that I can't agree. Its like saying that the words in a table of contents are copyrighted.

If I sell a hamburger garnished with onions and pickles, I can't copy that recipe. I can call it a Hamburger Special and you can copy that name.

You can go into competition with me and create your own hamburger, garnished with onions and pickles as a Hamburger Special.
Its your right, since it's a generic item.

But if I named my hamburger the "LeslieSpecial", where I trademarked LeslieSpecial, then you are not allowed to use LeslieSpecial.
Just like McDonalds can't use Wopper", or Burger King not allowed to use "BigMac", because of trademarks.
The API's are not trademarked as far as I know.

Re: Giant problem

[s4m7]

Private space flight is rapidly advancing, and I'm pretty sure there's no copyright on the moon... ...yet

Re:Giant problem

[gnupun]

As opposed to the present where you profit from stealing others' work? Sorry to burst your "utopian" bubble.

Re:Giant problem

[shutdown -p now]

And? Do you have problem designing your own APIs instead of starting design with a competitors' APIs and modifying it?

Yes. The name of that problem is "interoperability".

Re:Giant problem

[shutdown -p now]

You make it more complicated than it needs to be. The protocol is any set of rules that describe how two components in a system communicate. An API is a subset of a protocol - it's also a set of rules that describe how two components communicate, it just happens to have a more formal language of describing them.

So, for example, if I have an app that allows plugins, the communication between the app and the plugin is a protocol, and in most cases that protocol is an API. There's no way to have "other APIs implement that protocol".

You're also wrong that you can't have plenty of protocols behind one API. There are many libraries that do exactly that - wrap various different protocols that ultimately do similar things, and present a single unified interface to all those things. For example, there are libraries that abstract away various cloud storage protocols (AWS, Azure, Rackspace etc). Or the ultimate example of them all, "everything is a file" on Unix - files (and specifically system calls like open, read, write etc) are an API, but the underlying protocols can involve NFS, SMB, FTP, SFTP and many others.

The distinction between protocols in general and APIs has been getting more blurry of late, too. For example, we talk about REST APIs on the web - but such an API is not tied to any language, and is really just a higher-level protocol on top of HTTP (describing the meaning of the payload).

Re: Giant problem

[i.kazmi]

or maybe it's like saying music is copyrightable so if you play a movie in a theater you own, an army of lawyers will descend on you unless you pay separate licensing fee for the music in the movie. LOOL. Oh, whoops, wait a sec, that one actually does happen.

I haven't ever accused anyone of being a shill, you just might become the person to win that honour

Re:Giant problem

[sjames]

I am not stealing anything. Are you claiming that since Google used the headers Oracle has lost the ability to use them?

The ability to use the same headers has long been understood, expected, and taken advantage of by the producers of both proprietary and free software. This has been the universal understanding since before the PC existed. It is you who would steal from the entire industry.

Re:Giant problem

[gnupun]

Are you claiming that since Google used the headers Oracle has lost the ability to use them?

If this is the lame excuse you give for Google using the APIs, then any one can pretty much copy and use any digital content without paying a cent because the original content is not lost by piracy. This is the pirate's excuse for his crimes.

Oracle/Sun created Java to make money. If Google made money using Java, then they owe Oracle some of the money, don't you think?

BTW, steal has many definitions:

2.
to appropriate (ideas, credit, words, etc.) without right or acknowledgment.

http://www.dictionary.com/brow...

Here's another definition of stealing:
profiting from other people's commercial work without paying them anything.

The ability to use the same headers has long been understood, expected, and taken advantage of by the producers of both proprietary and free software.

LOL, who made this rule? It must be the guys who enter the market after a software product is successful and start cloning the software.

Re:Giant problem

[sjames]

LOL, who made this rule? It must be the guys who enter the market after a software product is successful and start cloning the software.

Yes, Microsoft, Apple, Oracle, and Sun were participants in that accepted norm.

I noticed you couldn't find a reference for your funky definition of stealing. Gee, I wonder why?

Re:Giant problem

[eCubeH]

Trillions?

Re: Giant problem

[gnupun]

You're a complete moron if you don't understand why you can't play the song you bought for $1, in your movie theater. The $1 pricing is only for personal use, and perhaps family. If you want to entertain more people with that song you need to pay a sum proportional to the number of people that are listening -- the licensing fee.

Re:Giant problem

[yithar7153]

I agree with you. I think some amount of creativity is needed to create an API, but I guess the question is what amount of creativity dictates that a work should be protected under copyright.

Re: Giant problem

[i.kazmi]

Who's talking about playing a song someone bought for $1 in a theater you pillock? Besides lacking any common sense, you clearly aren't very good at reading comprehension, are you?

Let me try and spell it out for you, this time actually try reading and understanding (I know that will be hard for someone like yourself but try nonetheless) what's being said before responding, so here goes:

If someone licenses a MOVIE to play in a theater they own, on top of the licensing fees they've already paid for the movie, they have to pay a separate licensing fee for the MUSIC CONTAINED IN THAT MOVIE.

Now go ahead and explain to the rest of us who is stealing from whom in this particular case. I'll wait

Re:Giant problem

[gnupun]

Uh, no. Not if they open-sourced it, which they did. You can't steal what is freely given.

Wrong, Sun hoped you could develop your software on cheap Wintel machines, but run it everywhere, specifically on expensive Sun hardware. Only a moron company spends tens of millions for no ROI.

Apple gives away OS X upgrades for free. Of course, you need a much more powerful machine (costing many thousands of dollars) than what you have to run the new OS. Rinse and repeat the same strategy with iPhone/iOS.

Re: Giant problem

[Dcnjoe60]

That is Oracle's argument if you substitute API for music.

Re: Giant problem

[SvnLyrBrto]

So there's a silver lining then, is what you're saying? Any action that finally kills off Tomcat can't be all bad, after all.

Every time I have to install Java or Tomcat or .net or Mono or Flash or silverlight, I die a little bit on the inside.

Re:Giant problem

[AK Marc]

No, if the argument is taken as given, "using" an API is a copyright violation, as it's a copyrighted derivative work of a copyrighted work, unless explicitly licensed.

You are right in your implication that it'd be stupid for the US to implement copyright that way. But it's not FUD. It's the direct and obvious result of the argument given. Of course, the government would refuse to implement it in that manner, as it'd result in the exodus described. Which means the rulings would need to be inherently contradictory, or find that APIs are not copyrightable.

Re:Giant problem

[AK Marc]

But the names were thought up by the parents, so the phonebook should be copyrighted by your definition, because the inputs (names) were creatively created in the first place.

Re: Giant problem

[AK Marc]

Yeah, they reinvent the wheel, while copying each other. Wheelbase is almost identical between all cars in a class. Either they copy, or collude.

Re: Giant problem

[AK Marc]

If every implementation I rely on is removed, then it's about use. You can't use it if nobody implements it.

Re:Giant problem

[angel'o'sphere]

We have an API, e.g. for files, with functions/methods like:
open(filename:String)
read(buffer: Byte[], int: amount)
write(buffer: Byte[], int amount)
close()
flush()

A protocol makes clear that both read() and write() only work if you call open() first. And that you are supposed to call flush() when you want to be sure that written data is persisted on the disk. It also usually makes clear that close() will call flush() before the relevant data structures are releases.

The protocol also makes clear that the 'file" is 'invalid' after you called close(); in other words reading and writing from/to the file won't work anymore after it is closed.

There is a huge difference between an simple API as noted above and a protocol. And funnily even as my example above is a protocol "on top" of an API, most protocols are 'below' of what we consider an API.

Re:Giant problem

[shutdown -p now]

I have to disagree. In my understanding, "you have to call open() before you call read()" is part of an API. Basically, an API is not just a bunch of function declarations - it's also the description of semantics of those functions, their contracts, invariants, dependencies etc.

And I also have to add that this definition is the one that I have seen used pretty much everywhere else.

So I don't know why yours is different - perhaps it's a German thing? - but it's definitely far from universal.

Re:Giant problem

[angel'o'sphere]

The difference between an API and a protocol is as the word protocol implies. And german is so similar to english that basically everything we talk about is the exact same thing in both languages.

A protocol is about which words to say in which situation and in which order to establish "a connection".

An API is in C-speak a header file defining the c-functions. In C++ it is usually a header file, too. In Java it is an Interface or a class.

A protocol defines in which order calling such functions/methods make sense and will work.

Look e.g. at the SMT protocol.

You can talk to any SMTP server via telnet.

See: https://en.wikipedia.org/wiki/...

You can type simple commands and then the message.

However all that won't work if you sent commands in the wrong order. If you do that via an API, e.g. in C or Java, it won't change anything. You still have to call the appropriated functions/methods in the right order.

The word protocol in CS is used for a reason. It has the exact same meaning as in having a protocol in a meeting of states or a formal meeting, as in a ritual of marriage or how to welcome a guest of state.

You don't present the arms after the guest has entered the limo, you do it before.

Re:Giant problem

[shutdown -p now]

Like I said, your definition simply doesn't conform to practical usage, at least not here in US. The fact that German and English languages are related is completely irrelevant - the exact meaning of the word "protocol" specifically in CS/IT is a recent thing, and does not have to correspond to the past meaning, especially in its details. And, of course, the term "API" is a complete neologism, and so its meaning is purely invented.

I think your problem is that you're talking about API in the context of some language or the other (C, C++, Java etc). Stop for a moment, and think about what language context you would use for a typical RESTful Web API today.

Re:Giant problem

[budgenator]

The result of the creative effort of the API is contained in the actual programming code that implements the API,not the header file that point to the code. It's not that far-fetched to write a computer program to scan the source code and generate header files from it.

Re:Giant problem

[budgenator]

But the names were thought up by the parents, so the phonebook should be copyrighted by your definition, because the inputs (names) were creatively created in the first place.

No the phonebook is just reporting the fact that the names that were thought up by the parents and the named offspring lives at an specified address and phone number. Phonebooks were the test cases that really hammered home that facts can not be copyrighted. Advertising in the phonebook used to be the big-thing in advertising, like page-rank on Google and Bing are now; there were wars in the courts to get the phone numbers out of copyright of the phone companies.

Re:Giant problem

[AK Marc]

The phonebook is compiling facts. That the facts were creative doesn't make the facts copyrightable.

APIs document programming interactions. That the programming interactions were creative doesn't mean the documentation of them is.

Re:Giant problem

[Bengie]

A protocol is a set of methods, and an API is a set of protocols. A set can be a collection of one or more objects unless you accept an empty set. Therefore, a single method can be copyrighted as an API.

Re:Giant problem

[Bengie]

Actually what you described is the API. An API cannot not(purposeful double negative) have a protocol. It's just the flip-side of the coin. They are one and the same, just a different view. A library can implement a protocol simply by implementing the API. It's up to the caller to follow the protocol.

Re: Giant problem

[Coren22]

Well, you could record yourself burning it in your driveway if you wanted, but I think you should rip it and publish it to the internet.

Re:Giant problem

[Coren22]

copy /w c:\*.* d:\

That is an API, likely it will get mangled, so it was a command to copy the recursive contents of the C drive to the D drive.

Re:Giant problem

[angel'o'sphere]

You are contradicting yourself.

A library can implement a protocol simply by implementing the API.
And how would a library know to call open(), read(), close() in the correct order?

It's up to the caller to follow the protocol.
Exactly. So what is your point?

Re:Giant problem

[angel'o'sphere]

Therefore, a single method can be copyrighted as an API
APIs can't be copy righted.

A protocol is a set of methods, and an API is a set of protocols.
No it is not. A protocol is a sequence of "actions" done in the right order.
You can not declare a man and a woman to be husband and wife before asking them if they both say "I will".

The API is for the priest:
ask groom
ask bride
declare marriage

For the two of the couple it is:
Yes I will
No, I won't (what the fuck am I doing here?)
Kiss

The protocol is:
P: do you want to take her, say "Yes!"
G: Yes I want!
P: do yo want to take him, say "Yes!"
B: Yes I want!
P: I declare you now husband and wife.
P: "you may kiss the bride".

Every other order is: out of protocol and not valid, regardless of API.

However: you don't need to grasp that as you are likely not in the software business anyway.

Re:Giant problem

[angel'o'sphere]

A RESTFUL WEB API is not per se an API, but a) a technology and b) a system architecture.

A protocol defines which URLs I have to access with which verbs to achieve a certain goal.

E.g. the first request would probably be an authorization/authentification "call".

If the first call fails, the protocol is broken and the rest wont (hopefully?) succeed.

APIs and protocols are different things. And that is important to understand for a software engineer.

A judge can not start a trial by convicting the accused one. He has to follow the protocol: hearings, jury, verdict, judgement. Plain and simple. It does not matter what API they use: personal meeting in a court house, skype or a phone conference.

Re:Giant problem

[shutdown -p now]

You keep insisting that your definitions are correct, even though a large chunk of the industry plainly disagrees with these definitions, and uses the terms like RESTful APIs (which you claim aren't APIs), with everyone understanding precisely what is meant by this.

All I can say is that you might want to reconsider your definitions, if you want others to understand you, or at least follow the nuance that you believe to be there.

There's no strict formal definition for either "protocol" or "API"; especially the latter. As such, the definition is what the industry generally understands by those things at any given time. It's not set in stone. Your interpretation is one of the possibilities, but there's no reason why it should be the preferred one. Don't be so self-centered.

Re:Giant problem

[Coren22]

And what is a script but a simple program?

Re:Giant problem

[Bengie]

You must have missed the part of a library being the implementer of an API, not the caller. The library doesn't need to call Open, Read, Close in the correct order because it never calls them. The protocol is part of the API definition because you can't have an API without a protocol and you can't have a protocol without an API. They are the same thing, just different viewpoints.

You may want to spend some time researching what "flip-side of the coin" means.

Re:Giant problem

[Bengie]

Your analogy is so bad, it's not even wrong.

Re:Giant problem

[Bengie]

You seem to have issues with abstractions and take things too literally. I guess I will stop arguing with you. I only just realized it was the same person trolling/misunderstanding the issue.

Re:Giant problem

[angel'o'sphere]

From an academic standpoint, and that means writing a test in an university: you are wrong. Plain and simple.

So, lets look at a C-function like printf(). That is (part of) an API (called the standard C library). It has no protocol associated at all.

Now lets look at the hand shake between an mail transfer agent like sendmail (S) and an mail user agent like Mail.app (C):

S: 220 smtp.example.com ESMTP Postfix
C: HELO relay.example.org
S: 250 Hello relay.example.org, I am glad to meet you
C: MAIL FROM: bob@example.org
S: 250 Ok
C: RCPT TO: alice@example.com
S: 250 Ok
C: RCPT TO: theboss@example.com
S: 250 Ok
C: DATA
S: 354 End data with CR LF.CR LF
C: From: "Bob Example" bob@example.org
C: To: "Alice Example" alice@example.com
C: Cc: theboss@example.com
C: Date: Tue, 15 January 2008 16:02:43 -0500
C: Subject: Test message
C:
C: Hello Alice.
C: This is a test message with 5 header fields and 4 lines in the message body.
C: Your friend,
C: Bob
C: .
S: 250 Ok: queued as 12345
C: QUIT
S: 221 Bye
{The server closes the connection}

Copied from: https://en.wikipedia.org/wiki/...

As you see: this is clearly a protocol. And it has no API associated. See here: https://java.net/projects/java... for an API that supports the protocol above. And again that API 'is not the protocol'.

Sorry, you either have no clue about computer science or you missed some basics. Protocols and APIs have a lose association (as both can exist without the other) just as grammars and programs have a lose association.

And thanks for insulting me in your other answers.

Re:Giant problem

[angel'o'sphere]

Well, perhaps I was unclear.

A certain RESTfull API is an API. However the protocol usually used to access it: is HTTP. So, there is a very important distinction between the protocol and the API.

There's no strict formal definition for either "protocol" or "API"; especially the latter.
For the first there definitely is. You only need to look up the standard dictionary definition as that did not change just because we are talking about computer science.

The latter is vague as a simple collection of functions is often called "API" when it in fact is just a simple collection of functions. E.g. the standard C-Library is IMHO not an "API", but one might rightful disagree.

Anyway, the point about RESTful or not is, the API is defined in C-Headers or Java Inerfaces etc. And that API later gets exposed by a Web server as a set of URLs that form the "RESTful" interface. In other words: the API is defined by the underlying programming language constructs, and not by the URLs. However this might be a corner case. Plenty of people indeed say "RESTful" API ... I wonder why no one says SOAP API.

Perhaps I'm nitpicking, but for me that is an important difference.

E.G. you can define protocols in ASN1, use a tool to generate the implementation and the API of that implementation. The API is language specific. So a certain programming language is needed to use the generated implementation and API. The generated state machines and various ways of using the protocol are obviously language independent and could be implemented in any language. Hence the protocol exists without any connection/reference to an API.

The protocol is defined by the two state machines on both sides of the communication and the messages they interchange to keep both state machines in a coherent state. E.g. establishing a connection, transferring data packages, receiving acknowledges etc. All this not really anything to do with an API, however if you want to use the protocol you need an API on top of it ... if that protocol is supposed to be a library. If it is hidden inside of a kernel component or something, it probably does not even have/need an API.

Re:Giant problem

[AK Marc]

I've created lots, and his point is spot on. The purpose of IP laws is to support the art and sciences, and if the IP laws don't, they are unconstitutional. They have been for a while. They protect profits. There would be more creative works if there was no copyright. There would be more innovation if there was no patent.

Re:Giant problem

[AK Marc]

Nope. It wouldn't. Not a single word of the Constitution would need to be changed to abolish all copyright and patent.

Re:Giant problem

[mattack2]

https://en.m.wikipedia.org/wik...

_The Congress shall have power ... To promote the progress of science and useful arts, by securing for limited times to authors and inventors the exclusive right to their respective writings and discoveries;

Re:Giant problem

[AK Marc]

And you've proven you can't read.

Congress has the power to create IP laws, but not the requirement, duty, or other motivation to do so, other than the bribes they take.

A simple law change could wipe out IP. As I said, a Constitutional Amendment isn't needed, unless you wanted the states and President to be the ones to make IP laws in Congress' absence.

Re:Giant problem

[Bengie]

A photo is not a list of facts. A scene may be, but the lighting, angle, etc are "creative". You can parody a scene from a photo and take your own photo, but the original photo itself is copyrightable.

Has Sun/Oracle ever copied any APIs?

[jonwil]

Someone should go back and look for any examples where Sun or Oracle have copied APIs but didn't have any specific license to use the code behind those APIs.

There must be some example somewhere of Sun or Oracle doing exactly what they are now claiming Google has done...

Re:Has Sun/Oracle ever copied any APIs?

[LichtSpektren]

Couldn't tell you for sure, but I would think any RDBMS (including Oracle and MySQL) would've had their ancestry in an unlicensed implementation of IBM SQL.

Re:Has Sun/Oracle ever copied any APIs?

[LichtSpektren]

Oh, and also--as stated above--basically everything POSIX that wasn't licensed from Bell Labs, which would include Oracle Enterprise Linux.

Re:Has Sun/Oracle ever copied any APIs?

[jfdavis668]

Isn't Java based on C syntax? You think they would have copied the API somewhere to do that.

Re:Has Sun/Oracle ever copied any APIs?

[LichtSpektren]

Bell Labs...

Re:Has Sun/Oracle ever copied any APIs?

[Anonymous Coward]

The name you're looking for is System-R

Re:Has Sun/Oracle ever copied any APIs?

[robmv]

Oracle cloned Red Hat Enterprise Linux (RHEL), RHEL contained GNU Classpath, Oracle distributed GNU Classpath without problems before buying Sun

Re:Has Sun/Oracle ever copied any APIs?

[HornWumpus]

IIRC Ellison worked for IBM on SQL before stealing the idea and APIs to form Oracle.

Re:Has Sun/Oracle ever copied any APIs?

[iampiti]

Nope. Java copied some syntax from C including names for primitive types, loops and so on but they didn't copy the function signatures of the C standard library so they didn't copy any APIs.

Re:Has Sun/Oracle ever copied any APIs?

[bluefoxlucid]

Function signatures would be an ABI. An API is for the programmer.

You need to recompile your code to produce a Dalvik binary. In that way, it's possible to use a completely different ABI with different name mangling, but keep the same API.

WABI from SUN

[Anonymous Coward]

Or indeed WABI from Sun (now Oracle) that copies the API of Windows so it can run on Sparcstations.
Or Java from Oracle that implements the Berkeley Collections library APIs.
Or Java from Oracle that copies the API conventions of C++.

They really are trying to fool a jury here.

Re:WABI from SUN

[h8sg8s]

Because they didn't think they needed to, and especially WRT Microsoft, they were disinclined to pay up. Larry is simply trying to sue Google because there may be money in it. Sun had the IP (bought from SavaJe) to implement something similar to Android but not the time or money to invest in it and CHOSE not to pursue it. JavaME was so far from usable as to be irrelevant. Google was willing to invest and succeed, Oracle is angry. Poor Oracle.

Full disclosure - former Sun employee.

Re:which outcome is better for society?

[LichtSpektren]

I doubt the loss of a couple billion wouldn't hurt Google too terribly.

But the precedent would be disastrous. It would basically mean any API not specifically released with an open license on day 1 would be unused out of fear of copyright retribution.

Re:Type systems

[Geoffrey.landis]

Irrelevant. APIs can not be copyrighted, period. End. Of. Discussion.

According to the Federal Appeals Court-- whose opinion is the only one that matters (since the Supreme court declined the case)-- you are wrong. APIs can be copyrighted. End of discussion.

You may not agree, you may not like it, but that's irrelevant.

http://fortune.com/2015/06/29/...
http://readwrite.com/2015/06/2...
https://www.techdirt.com/artic...

Poetic APIs

[pruss]

IANAL, but I could imagine a case where someone names a method with a copyrighted haiku: void old_pond_CR_a_frog_leaps_in_CR_waters_sound(). (From Wikipedia's example of a haiku translation; I don't know if their example is copyrighted, but you get the point.) In that case, I think it's not an unreasonable case that the API is copyrightable at least in part. In such a case, even code calling the API--not just an implementation of the API--would require a fair-use defense. I would hope such a fair-use defense would be possible.

So, yes, my example shows that it should be possible for an API to be copyrighted, at least in theory (whether java.lang is sufficiently poetic is a different question!). But the example also shows that unless a fair-use defense is possible, programming is really stifled.

Re:Poetic APIs

[mrbester]

A world where it is illegal to implement my own version of die_you_gravy_sucking_pig_dog because the signature is copyrighted as part of a API is a world I tell to get stuffed. The same applies to software patents.

Re:APIs are not code

[Sique]

Just because the single elements of some work are not copyrighted, it does not mean that the specific arrangement of those elements can be copyrighted. The letters of the latin alphabet aren't copyrighted either, but several sequences of them (called poems, novels, articles...) definitely are. While I get your idea, you have to argue more carefully.

Re:But

[jfdavis668]

Don't be evil.

Re:Type systems

[Holi]

One more thing. I believe Google is claiming fair use. That claim in itself would mean that the API in question is covered by copyright. There is no need for "Fair Use" if it is not protected by copyright.

The API _is_ the semantics of language

[mysidia]

An Ad-hoc one, but part of language nonetheless.

The ENGLISH Language has an API too. You will find much of it documented in a dictionary.

The words are the element of the language; but an API tells you how to exchange messages between two people.

Attempting to have exclusive rights to an API is like a restaurant wanting exclusive rights to phrases such as "GET WATER", or "ONE BEER PLEASE".

So patrons will be sued if they go to a competitors' restaurant and formulate requests such as that

The code does things...... the API is just a functional (non-creative) description of the correct way to interact with the code.

Re:The API _is_ the semantics of language

[bigpat]

The code does things...... the API is just a functional (non-creative) description of the correct way to interact with the code.

I think that is basically correct. When talking about an API we are talking about something closer to naming mathematical variables, than to creative expression. Their utility is in in having a common reference name, not in the creativity of the name itself. Like saying I could copyright using a particular set of greek letters to describe physics, or copyrighting the E and the M and the C in E=MC^2.

Re:The API _is_ the semantics of language

[phantomfive]

Attempting to have exclusive rights to an API is like a restaurant wanting exclusive rights to phrases such as "GET WATER", or "ONE BEER PLEASE"

The courts deal with this problem by using the "abstraction-filtration-comparison" test. Essentially, they remove all the parts that are common and unexpressive, such as "get water" or "one beer please," and then they make a comparison with whatever is left. In this case, math.abs() is probably not original, but clearly the package name "java.math.*" is not necessary for expressing the idea of absolute value.

There's a lot of good information in the appeal court's decision, and also Wikipedia has a decent article on the abstraction-filtration-comparison test.

Re:The API _is_ the semantics of language

[mysidia]

clearly the package name "java.math.*" is not necessary for expressing the idea of absolute value

TO A HUMAN

The identity of the package may very well be critical for expressing the concept of invoking the absolute value function to the computer. The package is just part of the name, and you have to use the name; You cannot just pick a name that makes sense to a human, because it's an API that is being invoked, then there actually is not a choice.

Thus why... the decalaration of what java.math.abs is; Is not a computer program, but gives the name of something external to be acted upon, But the definition (or implementation) of java.math.abs, would be a program.

Re:The API _is_ the semantics of language

[Chalnoth]

I really hope this interpretation doesn't stand, because it will make it impossible to reimplement any closed API without licensing agreements. It's definitely the case that there are many possible ways to organize an API, but a ruling of this kind limits competition.

I know that very similar patents are allowed as a matter of course for physical interfaces, e.g. Apple's lightning connector or razors with replaceable heads. But honestly I feel that the markets would be better off all-around if such interface patents were disallowed across the board.

Re:The API _is_ the semantics of language

[jschultz410]

"... the API is just a functional (non-creative) description of the correct way to interact with the code."

Google argues that all the design work that people put into figuring out the best APIs for their systems cannot be protected by copyright. That all that design activity is "not creative," in your words, basically worthless and not worthy of legal protection. I really have no clue how this became the predominant belief amongst software people. Convenience? Stealing someone else's API design is easier than figuring one out yourself, I guess.

Look at the design of the C++ language and its standard library. Think about the huge amounts of effort that Bjarne Stroustrup (and others) put into making the language and all of its API pieces fit together in the best way in their view. Now, imagine that he instead did all that design work only for his own company's use and never intended it for general consumption or use outside his company.

The arguments put forward by Google, and many others, are that if all those complicated, interconnected APIs somehow leaked out onto the internet (e.g. - a disgruntled employee surreptitiously posted them somewhere without permission), then everyone else would be legally free to copy them verbatim and reimplement the backing code without a single bit of permission nor consideration going back to Bjarne nor his company. They are APIs that aren't copyrightable and almost surely not subject to patent protection. Google's approach values all that API design work as entirely worthless and not intellectual property in the least.

That's ridiculous. API design is a HUGE part of software design and development. I'd argue that it is often more important and valuable than any particular backing implementation of the API.

Ok, now imagine a bit different C++ scenario. Stroustrup really likes his C++ language and wants to publish about it, including his specific API design. Does the mere fact that he voluntarily revealed his API to the public (without any license but with a copyright claim), now allow everyone to run off and copy it verbatim again without permission nor consideration back to him? Again, that does seem to be Google's argument and it seems bonkers to me.

Arguing, as the EFF does, that open and free APIs are a good thing that facilitate competition, wide adoption, superior implementations, etc. is one thing. But arguing that all APIs are inherently open and cannot be protected as intellectual property -- that anyone can legally come along and copy verbatim the huge, complicated class hierarchy and interfaces that you designed for your software without your permission nor consideration -- is an entirely different proposition. Authors should absolutely retain the intellectual property rights to their specific APIs. They can license them or put them in the public domain as they see fit.

Now, the obvious criticism of my stance is that what is to prevent someone from putting and enforcing a copyright on something absurdly simple like C's strlen() function or something similar? Would we have the equivalent of patent trolls trying to extract money from anyone who codes? My answer to that is it would be up to the US Copyright Office and the courts to determine what is fair-use and what is simply too trivial to copyright. For example, a book author's copyright does not give them the right to go and sue anyone who happens to use a sentence that happens to appear in their book, but it does allow them to sue people who reproduce significant sections of their book that go beyond fair-use.

Re:The API _is_ the semantics of language

[phantomfive]

I really hope this interpretation doesn't stand

It's been adopted around the world, so you're basically out of luck there.

because it will make it impossible to reimplement any closed API without licensing agreements.

No, you're wrong! Why do you even think that? There are many reasons that you can re-implement a closed API, among them for interoperability purposes. That covers most things you would want to do with an API, actually.

Re:The API _is_ the semantics of language

[Chalnoth]

No, you're wrong! Why do you even think that? There are many reasons that you can re-implement a closed API, among them for interoperability purposes. That covers most things you would want to do with an API, actually.

Because in order to re-implement an API, it is necessary to copy almost verbatim the definitions of the functions and other entities that make up the public interface of the API.

Sure, you *can* change around things such as the names of the variables in the function arguments, and can define things in a different order, but those are meaningless changes. There's little flexibility beyond this.

Re:The API _is_ the semantics of language

[phantomfive]

Because in order to re-implement an API, it is necessary to copy almost verbatim the definitions of the functions and other entities that make up the public interface of the API.

Oh. That's where the fair use defense comes in. Obviously in a lot of cases, you can redo your API differently, like C# standard library is different than Java's, but if you need to be exactly the same, there are plenty of reasons you can get away with under fair use.

Re:The API _is_ the semantics of language

[Chalnoth]

Oh. That's where the fair use defense comes in. Obviously in a lot of cases, you can redo your API differently, like C# standard library is different than Java's, but if you need to be exactly the same, there are plenty of reasons you can get away with under fair use.

Apparently that's the question of the trial in the OP: whether or not this use of the API is fair use. I really, really hope they rule for Google in this, because otherwise it could have some pretty far-reaching negative impacts on the software industry as a whole.

Re:The API _is_ the semantics of language

[phantomfive]

Apparently that's the question of the trial in the OP: whether or not this use of the API is fair use.

Yeah.

I really, really hope they rule for Google in this, because otherwise it could have some pretty far-reaching negative impacts on the software industry as a whole.

The appeal that ended probably will be cited in many cases from now on, but I can't see how the current case will have much affect.

Re: The API _is_ the semantics of language

[go-nix.ca]

Even if the court rules fair use, it's still a bad precedent, because fair use would subsequently have to be established for any and all future reimplementations of APIs - established in court. The risk of having to spend so much money just to prove fair use would likely put reimplementatipn out of reach for all but the most deeply pocketed companies, because, as a large company, you could suppress a potentially superior reimplementation simply by taking the upstart to court. This is uilty-until-proven-innocent. The onus must then be on the plaintiff to prove that it's not fair use, rather than on the defendant to prove that it is. And again, if it comes to that, the defendant will likely go belly-up long before any case sees the light of day. Law of the jungle :(

Re:The API _is_ the semantics of language

[mysidia]

Yes, this is basically a matter of a Mechanism not creative expression. I see how API methods could potentially be subject to a design patent (providing your system allows software to be patented).

Makes sense that an API could be patented as an invention, just that it should be non-copyrightable.

Also, it's worth pointing out that Patents have a more limited lifetime for a good reason..... Patents are about Functional things or Mechanism design, which an API is, not a thing whose value is creative expression.

Re:The API _is_ the semantics of language

[mysidia]

Google argues that all the design work that people put into figuring out the best APIs for their systems cannot be protected by copyright. ... I really have no clue how this became the predominant belief amongst software people.

Nope nope nope. You know.... all that design work done by AT&T engineers to come up with DTMF to allow Touch-Tone Dialing on Telephones.... was not protected And CANNOT be protected by copyright either, Because the purpose of the tones, or otherwise known as the value of the work is Non-Expressive and Functional in nature.

AND the DTMF Touch-tone tones your Telephone emits are an API just like any software API or Network protocol API.

Imagine what would have happened if they could copyright those tones? Ma Bell or their designated successor could be the exclusive maker of Touch-tone telephones for the next 100 Years under copyright!

Thankfully, such mechanical things as Mechanisms and Functional interfaces are particularly excluded from copyright. Instead, the only option to protect them is a Design patent which lasts for 20 years, instead of 100+, and no more.

I say the opposite. Law makers should do that

[raymorris]

> which outcome is better for society?
> It's time people's courts ... instead considered what benefits society most.

Should individual unelected judges make up laws based on what they think will turn out best?

I (and the framers of the Constitution) think that the legislature and the voters should carefully consider that when they create and pass laws. Judges should then read the law and apply determine how it applies to a particular case. Occasionally, the Supreme Court and other courts have pointed out "this law doesn't work well, the legislature should change it". I think that's the best approach.

* Here I'm not talking about cases in which the legislature tried to create a law which they had no authority to create. I'm referring to laws which the legislature properly passed, within their authority, but didn't do a very good job.

If Oracle wins, get into corporate law

[LichtSpektren]

If Oracle wins this case and all the appeals, where it's ruled that using open APIs is copyright infringement, then I would strongly suggest you get into corporate law.

Because the end result is that basically every software company in the world (including not just Oracle and Google but Microsoft, Apple, IBM, Intel, Samsung, etc.) will suddenly find themselves in a Mexican standoff of potentially trillions of dollars in "intellectual property" suits ready to be fired off. The only winner will be the one with the best legal department; oh, and the lawyers.

All the aforementioned companies would be wise to pen amicus curiae letters in favor of Google.

Re:If Oracle wins, get into corporate law

[segedunum]

Indeed so. Anyone who wants to sell software of any kind is going to have to be pretty aware of this, especially those writing developer tools. However, getting into corporate law won't help anyone. Smaller software companies simply don't have the money to argue fair use in a court.

If Oracle wins JAVA is dead, and so are every

[pjv936]

non public domain extendable system that has an API. Even if the current company says it is open one day Oracle will buy that company and sue you for licensing fees. IF API are copyrightable then keywords and statements might be. Nobody should use any programming language that is not public domain until this is settled.

Re:If Oracle wins JAVA is dead, and so are every

[Anonymous Coward]

I've kinda thought this myself ... if Oracle wins, they just shot themselves in the foot. Who will use Java after an Oracle victory? Certainly no one in any open-source community. It's not like Java is really a growing language (outside of Android). If there are copyright issues just in looking at the API specs, no one will touch it.

Compaq copied APIs from IBM

[wiredog]

To make the first PC Clone. I wonder how much HP will owe to IBM?

Re:Compaq copied APIs from IBM

[drerwk]

Compaq reverse engineered the BIOS. It did not copy the text of some file that defined the API. I don't think that the INT operations even had fixed names - they had numbers. So a BIOS call would be documented as http://stanislavs.org/helppc/i...
INT 16,0 Wait for keystroke and read
This exact operation can be described using different words e.g.
On Int 16,0 the system will pause until a keystroke is pressed and the value will be placed in AH.
I understand the issue in Oracle v. Google to be exact copying of some number of interfere files. Such files did not exist for BIOS as far as I recall.

Re:Type systems

[segedunum]

According to the Federal Appeals Court-- whose opinion is the only one that matters (since the Supreme court declined the case)-- you are wrong. APIs can be copyrighted. End of discussion.

Alas, that will not stop them being wrong I'm afraid. This has also been debated, and overturned endlessly, throughout the 80s and 90s with things like DR DOS.

There are the way a bunch of lawyers would like things to be in an industry they know nothing about, and the way things actually are. You might not like that, and you might not agree, but that is neither here nor there. There is no software industry of any kind with copyrighted APIs.

Re:Only because it was Sun at the time...

[LichtSpektren]

Maybe you should read the article you just quoted. Google wasn't seeking a royalty license to use the intellectual property of the Java API. They were offering to co-opt Java with Sun and develop it together.

Re:Type systems

[segedunum]

All Google can claim here is fair use, but it won't stop the issue of copyrighted APIs being shown to be stupid. If you reuse APIs to help developers with a familiar language and for them to reuse their code....that qualifies as fair use without even thinking about it. Oracle have tried to dance around this with ridiculous notions that because Android isn't completely Java compatible then fair use can't apply because it isn't interoperable.

Re:which outcome is better for society?

[segedunum]

On the other, Google just did what got Microsoft in trouble with msjvm.dll, but people just didn't like Microsoft, while people like Google, even though Google has taken far more control from people than Microsoft ever gave (before it too went cloudy). On balance, then, fuck the whole collective of spunkpuffins.

No. Microsoft licensed a JVM implementation from Sun and Sun argued that what Microsoft did contravened that deal. They settled out of court.

Hold on...

[fieldstone]

Why was Google trying to get a license for Java if they ultimately felt they didn't need one? That's right there in the article.

Re:Hold on...

[LichtSpektren]

Not a license to use Java's API. They were seeking an alliance with Sun to develop Java together.

Re:Hold on...

[oh_my_080980980]

No they were seeking a license to use Java for Android.

Re:Hold on...

[tbird20d]

They considered getting a license, but ultimately decided against it. I believe Larry Page said they considered it because they wanted to use Sun's java implementation (not the same thing as just using the API via the Apache Harmony implementation). But even if they thought they needed a license for the Java API, they may have decided otherwise after legal analysis.

It bugs me when lawyers think they have a smoking gun because some employee writes something in an e-mail or a presentation. They employee might be raising speculative issues that even they don't know the answer to, or they might just be wrong on the legal status of something.

Bloody IP

[SlashDread]

Riddle me this.

Intellectual means "of the intellect" and is thus intangible.
Property has always been used as a nomer for physical items that are clearly in possession, after all possession is 9/10th of the law.

This whole "IP" terminology is thus clearly double speak, and should be avoided. The whole legal constructs around them, be it patents, invention or copyright are only there to not disrupt existing economic structures. They are a philosophical abomination, especially in the digital age, where copying is cost-less, and distribution nearly so. This is true for books, code, movies and basically everything digital IMHO, and in this case even more so.

In this particular case of Oracle vs Google regarding Java "IP" we are talking about API Headers. To anyone with some coding background, API Headers are a description of a system. They are not patentable, as patents require implementation. (In Europe software is considered "math", and atm not patentable at al) They should not be copyrightable, for the same reason that announcing you will write a book about Fire and Ice and Dragons is a description of a book, but not the book itself. This description should not grant you the right to be the sole author of books about Fire and Ice and Dragons.

I applaud Google in this fight, and I hope they fight till they win.

Re:Bloody IP

[tbird20d]

Property has always been used as a nomer for physical items that are clearly in possession...

I think you missed the part of history (in the 1700's) when property rights started being assigned to intangible things like the text of books, in the form of copyright. I mean, you can pretend that society doesn't recognize this particular abstraction of property rights, but there's voluminous case law and legal tradition for this, so I'm not sure what the point is.

Re:Bloody IP

[tlhIngan]

In this particular case of Oracle vs Google regarding Java "IP" we are talking about API Headers. To anyone with some coding background, API Headers are a description of a system. They are not patentable, as patents require implementation. (In Europe software is considered "math", and atm not patentable at al) They should not be copyrightable, for the same reason that announcing you will write a book about Fire and Ice and Dragons is a description of a book, but not the book itself. This description should not grant you the right to be the sole author of books about Fire and Ice and Dragons.

I applaud Google in this fight, and I hope they fight till they win.

Which is good, because a lot of Linux headers are GPLv2. So if headers aren't copyrightable, then they can be lifted and used in proprietary apps as well.

It also means all those Linux APIs marked "GPL" (e.g., EXPORT_SYMBOL_GPL) are no long GPL only and can be used in proprietary kernel modules, too.

Android benefits, since Bionic no longer has to maintain a set of "clean" Linux header files.

And that's the problem - who ever wins, loses. Google wins, APIs are not copyrightable and thus, GPL doesn't apply anymore (GPL requires copyright). Oracle wins, well, we lose as well, though it makes GPL APIs require GPL.

It's a very messy situation.

Re:Bloody IP

[Marginal Coward]

Agreed. Let's not throw the legal baby out with the semantic bathwater.

Re:Bloody IP

[jbengt]

when property rights started being assigned to intangible things like the text of books . . .

Still intangible, and maybe pedantic, but the actual property is the government-issued exclusive right to copy, not the text of books that the copyright covers.

Re:Bloody IP

[F.Ultra]

FSF have never claimed that you cannot use headers carrying the GPL copyright in them. What they claim is that you cannot link to GPL:ed code without being compatible with the GPL. Same with the EXPORT_SYMBOL_GPL in the Linux Kernel, that is not about using the headers but about allowing linkage with the specific kernel function (i.e they are license exceptions to the GPL that normally covers the whole kernel).

Re: Bloody IP

[ZeroWaiteState]

All GPL code is copyright by definition. If it wasn't then GPL would not be enforceable under US law. GPL is simply the legal agreement under which the attached code is distributed.

Re:Bloody IP

[sjames]

It also means all those Linux APIs marked "GPL" (e.g., EXPORT_SYMBOL_GPL) are no long GPL only and can be used in proprietary kernel modules, too.

Not actually. The kernel won't link those symbols in your module unless you declare the module to be GPL. It simply will not load.

Linux was written with the assumption that APIs can't be copyrighted.

Re:Bloody IP

[tbird20d]

Good point. That distinction is important, and is part of the abstraction that make arguing about copyright and violations somewhat difficult.

Re:Worse

[manu144x]

A former programmer becoming a lawyer could make a ton of money in these patents wars...it's actually not a bad idea at all...

Books, Music, and APIs

[rockmuelle]

Ok, I'm going to take a slightly unpopular stance here and suggest that APIs probably should be copyrightable.

Ignoring all the legal issues, my rational is simple: An API spec represents the output of the intellectual effort of the architect far better than any implementation code. Designing a good API is difficult. Doing so requires finding exactly the right abstractions to allow users to use your API to perform complex operations in a simple, straightforward manner. The design process often involves several iterations of implementation to refine the API - not only implementing the functionality, but writing software that uses to to make sure it meets its goals.

The book title/chapter title argument is often used to show why APIs shouldn't be copyrighted. That's a poor analogy. Many books don't bother with chapter titles, so they're clearly not essential to the interpretation of the material. When present, they usually can't be used to quickly summarize a book. A well designed API will clearly and concisely present to you everything the underlying library can do. In fact, you should never care about the implementation of the library. If you ignored the text of a book, you wouldn't really be reading it.

If we're going to look to artistic pursuits for analogies, I'll suggest music is a better one. Melodies and lyrics are primarily what's copyrightable in music. Chord changes and musical embellishments are not. Arrangements are copyrightable when written down. Specific performances are also copyrightable (which is why samples must be cleared for use in other songs). Melodies and lyrics are akin to an API - the instantly let you identify the song/library and are the primary way most people remember it. For example, I can play "Yesterday" on a piano, guitar, speak-and-spell, and it's still a Beatles song. I still owe the Beatles royalties for using their lyrics and melody, regardless of how I arrange and perform it.

Now, if we allow APIs to be copyrighted, we gain a lot of flexibility. Most importantly, the copyright holder can release the API under a free and open license if they want. The designer can say: here's my work, feel free to do with it what you want. Or, they can lock it down and restrict what can be done with it.

For better or worse, Sun wanted the best of both worlds with Java. They implied that it was free and open, but never actually released the APIs under a specific free and open license. In the music world, the "Happy Birthday" saga is similar. The melody and lyrics were thought to be under copyright and Warner collected a few million a year from artists for performing it and using it in their works. Just like the core Java APIs, everyone knows "Happy Birthday" and most people used it casually without paying royalties (yes, I realize not everyone knows Java, but most readers of /. do). With the song, it turned out an earlier version that wasn't under copyright was found, which invalided Warner's claims. Unfortunately, that's unlikely to happen with Java.

tl;dr: APIs are the creative output of the design process, just like melodies and lyrics are in music. They probably should be copyrightable.

-Chris

Re:Books, Music, and APIs

[Anonymous Coward]

Just because something is creative output that takes work is not sufficient reason it should get a government protected monopoly.

Re:Books, Music, and APIs

[Anonymous Coward]

Your music analogy is a flawed one. Melodies and lyrics are not akin to an API, as a melody is far more concrete a thing, likewise a set of lyrics, than an API. The musical equivalent of an API would be a singer calling back to his bandmates, "Alright, give me a blues riff in B natural."

Until we live in a world where countless musicians can successfully sue each other for following the same identical chord progressions - https://www.youtube.com/watch?v=oOlDewpCfZQ - then we shouldn't live in a world where coders can sue each other for following the same identical APIs, as long as the code underpinning the implementation is different.

There's a practically infinite number of chord progressions and ways notes can be ordered, but there's a finite number of combinations that people want to hear and which sound good, and we don't bemoan musicians for using chord progressions that are verifiably identical. There's a practically infinite number of settings, scenes and characters that a movie can be made about, but there's a finite number of combinations of settings, scenes and characters that make a successful Hollywood hit, and we don't have JJ Abrams suing Michael Bay over their cookie-cutter action flicks. There's a practically infinite number of gameplay mechanics that you can have in a game, but there's a finite number of gameplay mechanics that work well, and we don't see game companies successfully suing each other for games being too similar in nature, outside of design trademarks like the Tetris pieces. Capcom USA Inc v. Data East was pretty definitive on that point. There's a practically infinite number of member functions and member variables that you can have in a class, and a practically infinite number of classes that you can have in an API, but there's a finite number of them that are actually useful in any way, and if companies can now copyright the API itself rather than the source code implementation of said API, then that's a dangerous precedent for every other industry.

tl;dr: APIs are part of the creative output of the design process, but are more akin to the chord progressions in music, which are definitively not copyrightable.

Re:Books, Music, and APIs

[PRMan]

Which MIGHT be true, except Sun said they were open source and free to use. Calling backsies was garbage on the playground and it's still garbage.

Re:Books, Music, and APIs

[dgatwood]

In general, the fact that something is a creative work or takes time to create doesn't necessarily make it copyrightable. For a creative work, any functional aspects of that design are supposed to be protected by patents, not copyright. And an insufficiently creative work isn't protected at all, no matter how much time it took to create it.

For example, the courts long ago ruled in Feist Publications, Inc., v. Rural Telephone Service Co. that the difficulty of creating something is not sufficient to make it copyrightable when they declared that a phone book is a non-creative collection of facts. One could reasonably argue that a header file collects the declarations from source code, and that the real creative work is the source code itself. After all, the sole reason for a header file is to consolidate a bunch of declarations into a form that that makes it easier for a compiler to digest. This arguably makes a header no more a creative work than the phone book. That's not arguing that an API shouldn't be copyrightable per se, so much as that a header shouldn't be unless it contains other creative works beyond the declarations.

Also, per 17 U.S.C. section 1302, anything that is "dictated solely by a utilitarian function of the article that embodies it" is not eligible for copyright. The intent of copyright law is to shift responsibility for protecting such creative works into the domain of patent law. So given that there's a strong utilitarian aspect to APIs (because any function has basically exactly one valid declaration, or else your code won't link correctly), if you want to argue that an API should be protected by copyright, you have to come up with a concrete argument of why that API's design is more than just utilitarian in nature. So any creative effort that was focused on making an API easier to use doesn't count towards the creativity requirement for copyright purposes.

Re:Books, Music, and APIs

[Anonymous Coward]

Not everything that takes a lot of intellectual effort is copyrightable.

Lists of ingredients in a recipe is considered not to be covered, no matter how long the chef spent in making the ratios perfect or how many spices they tried before they came across the right combination. Likewise, a haiku I write in a tweet with little thought or time spent on it is probably covered under copyright.

Mathematical equations are not copyrightable even though it might take years of very specialized effort to prove a mathematical theorem. But in this case it's because it's considered a discovery not a creation.

My point is that effort has nothing to do with whether or not something is copyrightable.

I think for APIs there can be some grey zones, as you say about architecting APIs there can be various interpretations of the same concept, and for that I can see some argument for copyright coverage. But for some things it definitely approaches the level of mathematics. For example can I copyright the API of java.util.Math.sin, which takes a number and receives a number?

Even if we solved the copyright question and say some APIs can be covered by copyright, it seems reasonable to me that re-implementations of that API to support existing things written to that API is fair use under the concept of compatibility. At a minimum, it is existing long-established industry practice. WINE implements the API of Windows to allows Windows applications to run on Linux. Samba has reimplemented the SMB APIs for file sharing from Microsoft. Apple re-implemented various filesystems. A lot of caching servers re-implement the API provided by memcached. Countless emulators like qemu have reimplemented the instruction sets of various processors. AMD implemented Intel's x86-32 architecture and Intel re-implemented AMD's x86-64 architecture and no one got sued and the industry was better for the competition. And don't say CPU architecture isn't an API. The list of instructions supplied by a CPU are direct equivalent to a list of functions in a Java API. Each instruction says it takes a list of parameters and returns a list of results and the types of results and even the name of the instruction, which has all of the same components of a typical software API. To go back to your argument about "architectural effort" I'm sure Intel and AMD spent years perfecting their instruction sets and picking the most useful ones, but that has no bearing on their reuse. Even for the Java API case specifically we have the example of GNU Classpath which re-implemented Java APIs and preceded Google Android yet with no legal action (that I've heard of) from Sun, implicitly endorsing the re-implementation of API.

So, if all of these projects can re-implement the APIs, network interfaces, instruction sets, etc. of another system in such a way as to allow running of the same software on a different implementation, how is a re-implementation of Java any different.

Re:Books, Music, and APIs

[horza]

A melody or a lyric is not like an API. A musical note or an alphabetical letter is. To take your own example, "For example, I can play "Yesterday" on a piano, guitar, speak-and-spell, and it's still a Beatles song". The musical notation is the API, and you are able to implement the copyrighted melody via that API on a variety of different instruments. Imagine if somebody held the copyright to the API and only allowed a guitar solo to be performed on a particular brand of guitar? Would music be where it is now?

If you allow an API to be copyrighted then you will destroy a good amount of the software industry. Designers already do lock down APIs when they want to, even 'open' APIs such as Google and Facebook require you to generate an API key which they control the validity of.

It should definitely NOT be copyrightable. It would be detrimental to both industry and society.

Phillip.

Re:Books, Music, and APIs

[gnupun]

Yet everything that is creative and valuable is protected by the government. Because otherwise, only the lazy/incompetent idea stealers would benefit... kinda like you work for a company, but your work's salary is paid someone else, not you.

Re:Books, Music, and APIs

[phantomfive]

Which MIGHT be true, except Sun said they were open source and free to use.

They are open source and free to use, but you still have to follow the license. Google didn't follow the license (which is why they recently switched to the GPL for their Android dev system; if they had done that long ago, there wouldn't be any problem now).

Re:Books, Music, and APIs

[Marginal Coward]

Ignoring all the legal issues, my rational is simple: An API spec represents the output of the intellectual effort of the architect far better than any implementation code.

You make a good point, but what is the purpose of an API except to separate the interface from the implementation, if not to allow and encourage multiple implementations? In that vein, whenever someone publishes an API, they are implicitly allowing/encouraging multiple implementations. I suppose that one could argue that someone who does that might expect a royalty from someone who does an alternative implementation, but the "fair use" of APIs seems to be a train that long ago left the legal station.

Many years ago, I asked a lawyer the corporation where I worked at the time if I could use the old Hayes modem command set for another purpose. He said that I could. Of course, that was just his own opinion and likely was uninformed by any relevant court rulings. Still, it illustrate that the concept of an API needing to be licensed made a certain amount of sense in order for me to ask it, and it illustrates that a trained legal mind could easily conclude that it didn't.

To me, the idea of "fair use" in copyright law is intended to draw a line between the net benefit to society of people being able to use works in certain non-revenue-producing contexts such as scholarship or research, while allowing creators of works to be paid in the remaining commercial context. My common-sense, IANAL perspective on this is that society gains more than API creators lose in the process of allowing APIs to be used without licensing.

Re:Books, Music, and APIs

[jbengt]

Yet everything that is creative and valuable is protected by the government.

Not even remotely true.

Re:Books, Music, and APIs

[The Raven]

Ok, I'm going to take a slightly unpopular stance here and suggest that APIs probably should be copyrightable.

Ignoring all the legal issues, my rational is simple: An API spec represents the output of the intellectual effort of the architect far better than any implementation code. Designing a good API is difficult.

You forget that an important part of copyright is 'To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries.' APIs are so fundamental to all creation, that being able to own an API would completely lock down and prevent the progress of science and useful art.

You can copyright a painting, but not a painting style. Even if your style of painting is new, innovative, unique, and you spent years developing your unique method... you do not get any control over others copying your technique and using it in their own works. (e.g. Picasso and Cubism, Seurat and Pointilism)

You can copyright a book, even a paragraph, but you cannot copyright a unique way of looking at the world. You could spend months on your ideas, on your unique take on a topic... but that does not grant you a copyright to the idea, only to the specific implementation of your paragraphs, chapters, and novels. (e.g. Tolkein and Elves, Niven and Ringworlds)

The reason that ideas (and, by extension, APIs) are not copyrightable is because the only way to claim ownership an idea is via Patents. Now you can have endless debates on what should or should not be patentable, how unique it is, and the merits (or lack) of software patents, but the end point is that if you believe your software idea deserves protection the only way you can is via a patent. Because copyright only protects a specific implementation of an idea, not the idea itself no matter how much work went into generating that idea.

Re:Books, Music, and APIs

[jbengt]

There's a practically infinite number of chord progressions . . .

There are two basic chord progressions: IV-V-I and V-IV-I; everything else is just variation.
Even counting variations, you won't get a practically infinite number of chord progressions unless you move away from the seven modes and the diatonic scale, and even then, only if you create a practically infinite number of new scales and modes could you say there you have a practically infinite number of chord progressions. And what you'd be left with is a practically infinite number of incomprehensible noise plus a bunch of chord progressions that sound pretty much like the ones we know already. Our ears are just tuned that way.

Re:Books, Music, and APIs

[rockmuelle]

The musical notation is the character set you use to communicate the melody. Saying notation is like an API is like saying ASCII or UTF-8 is an API.

I agree that a good part of the software industry will be impacted by allowing APIs to be copyrighted and it may be detrimental in many cases. But, as this case is demonstrating, it's a conversation we need to have as an industry. We need to decide if creators have the right to protect their intellectual property and, if so, under what provisions they can that provide the best balance between creator rights and user rights.

-Chris

Re:Books, Music, and APIs

[jschultz410]

Very well stated! Personally, I find it incredible that so many people think all the design effort that goes into developing APIs (e.g. - class hierarchies, etc.) is essentially worthless and not a form of expression worthy of legal protection.

Re:Books, Music, and APIs

[jschultz410]

"One could reasonably argue that a header file collects the declarations from source code, and that the real creative work is the source code itself."

This kind of argues that the way you organize your code has no value. Or, that extracting a main design component of your code -- its organization -- renders that design no longer protectable (but it would have been if you didn't create a header?).

I see no reason to believe that -- quite the opposite in fact. In particular, I see no reason why to believe that lines within some function are more worthy of legal protection than the way you designed invoking that code in the first place. The API of something is often considerably more important and valuable than any particular implementation of it.

Re:Books, Music, and APIs

[rockmuelle]

Your points are why I think we need to have a broader discussion about this.

Historically, "open" specifications were industry designed "APIs" that enabled interoperation between multiple implementations. However, implementing them required a license and/or certification from the organization that maintained the spec. The specs were published and implementations were encouraged, but only under specific terms. Of course, the availability of the specs did wonders for technology and competition. Pretty much everything we rely on today from networking, to hardware, to graphics, to sound processing evolved this way.

As we transitioned more to software APIs, certification requirements became less important (a bad API implementation isn't going to cause a fire). APIs also tended to be more tightly coupled with a single implementation. Competition usually evolved in the form of a new implementation/API (e.g., QT vs. GTK vs. wxWidgets to pick a somewhat recent example) rather than something that was API compatible. In fact, most APIs out there will only ever have one implementation.

Developing a spec or API that's truly general purpose and usable for interoperability is time consuming and costly. The old approach accounted for this by designing them through industry funded organizations with all parties going in knowing they would benefit. Software APIs, by and large, are developed by one person or a small group on their own dime. If their API is generally useful and manages to succinctly capture a problem domain in a way that would benefit from multiple implementations, they should be compensated for that effort.

At a higher level, society doesn't have any more right to the API than it did before it was developed. The simple fact that it does benefit society proves that the design was valuable. Again, the developer should be compensated and society should gain (we need to stop thinking these two things are mutually exclusive). This also is the general basis for our intellectual property laws - creators are granted a term of exclusivity in exchange for sharing their work with the world.

I understand the desire to have instant, free access to every great idea. But, as a creator, I also see it from the other side.

-Chris

Re:Books, Music, and APIs

[Marginal Coward]

At a higher level, society doesn't have any more right to the API than it did before it was developed. The simple fact that it does benefit society proves that the design was valuable. Again, the developer should be compensated and society should gain (we need to stop thinking these two things are mutually exclusive). This also is the general basis for our intellectual property laws - creators are granted a term of exclusivity in exchange for sharing their work with the world.

By bringing "fair use" into this, I was trying to illustrate what I see as the optimum balance between society and API creators. Evidently, we disagree on where the balance should be (which is, of course..."fair"), but I wonder why someone would open an API if they don't want people to use it?

In the particular case of Java, I'm sure many of us here remember how hard - and successfully - they marketed it as a "write once, run anywhere" language when it first came out. I think that turned out to be a bit of a bait-and-switch thing, possibly due to the acquisition by Oracle, which may now have a different vision for it than Sun had originally planned.

Specifically, I don't think Java would have been adopted so widely and so quickly as it was when it first appeared if the marketing had instead been "write once, run anywhere, but never re-implement it." I'm not sure what specific legal promises were made about it at back then, but nobody understood it that way at the time. In fact, Sun took great pains to keep it standardized and even eventually succeeded in getting Microsoft to back out of the tactic of "embrace and extend" that they were known for at the time.

Likewise, on something like Python, its creator, Guido van Rossum, seems to like to steer it's future course, but doesn't try to quash alternatives. In that vein, in the book "Little Big Man," (highly recommended, BTW) the wise Indian chief, Old Lodge Skins, is not the chief because he forces anyone to do anything; instead, when he says "I think I'll put my teepee over there," people naturally put their own teepees nearby because they trust his wisdom.

Then again, tribal chiefs of the 1800s were much more oracular and less litigious than their counterparts in some of their modern corporate tribes. :-)

Re:Books, Music, and APIs

[dgatwood]

This kind of argues that the way you organize your code has no value. Or, that extracting a main design component of your code -- its organization -- renders that design no longer protectable (but it would have been if you didn't create a header?).

I would argue that an API itself is not a main design component of well-written code, but rather a formal specification for how that code interacts with other code. I can take that same API and implement it in an infinite number of ways, each with fundamentally architectures underneath. The whole point of an API is to separate the interface from the implementation so that you can change the implementation without breaking compatibility, which means it tells you almost nothing about the actual organization of the code, per se (assuming the API isn't too leaky, that is).

An API contract is basically the equivalent of a feature list for a piece of software. It tells what the software does. It doesn't tell how the software does it. The best real-world analog would be the index in a science textbook. It tells what the book teaches. It doesn't provide the actual details. And because someone else writing a science textbook has to use exactly the same terms (to allow mutual communication), every science book that covers similar topics will invariably have many identical names in their indices.

The counter-argument you should have used was to say that although mere collections of facts (e.g. libfoo contains a function x that takes parameters a, b, and c) aren't necessarily copyrightable, the specific organization of those facts is potentially copyrightable if there is artistic expression in its design. Then, you could argue that the choosing which classes/functions/data types to include in the public headers constitutes artistic expression. At that point, we would then have to debate whether that decision represents a functional aspect or not, to what degree you can change that without breaking the functionality, whether the organization of headers is inherently rigid based on functional area or has some degree of flexibility, whether the fact that reorganizing the contents of headers would result in compilation errors would force things back into purely functional territory (much like reordering a phone book would render it useless), etc.

So yeah, in truth, it isn't clear-cut. Nothing in law is, particularly when the Supreme Court rejects certiorari on cases that contradict everyone's general understanding of prior case law, as established by the ninth circuit in Sega v. Accolade (1992). And in the twenty-plus years since then, we've built the entire computer industry on the assumption that APIs are not protectable by copyright. So frankly, it's downright terrifying to see the courts leaning the other direction. The flood of lawsuits that are sure to result in the coming years could very easily destabilize the entire computer industry, and nothing short of an act of Congress can prevent the coming chaos at this point. As it stands right now, we're all pretty much screwed, which is bad for everybody... except the lawyers. But that's just my opinion.

Re:Books, Music, and APIs

[jschultz410]

"I would argue that an API itself is not a main design component of well-written code ..."

And I would strongly disagree. API design is one of the hardest and most valuable things software engineers do: determining the best places and ways to expose appropriate functionality so that it is most useful to others (including yourself).

Look at the design of C++'s standard library APIs (part of it being the former STL). Then compare that to some half-ass collections interface (e.g. - early versions of collections in Java). You are claiming that there is nothing worthy of legal protection in the design of those far superior C++ interfaces. That they are merely some necessary functional bits to invoke the (truly valuable) code that sits behind them.

I'm saying, yes, they are functional, but they are very much more as well. They represent the design decisions of the best *WAY* to facilitate, for example, manipulating in-memory data structures. To easily allow subsequences of one collection to be used while operating on another collection, perhaps of even a fundamentally different type. And so on. There is a ton of value in the design of those APIs. I would argue much more than in any specific code that implements the backing functions themselves. I'm not sure if that value is what you meant by "artistic expression," but good API design absolutely is an art that is hugely valuable and worthy of legal protection.

Re:Books, Music, and APIs

[sjames]

On the other hand, it would grind the entire industry to a halt and render the point moot. Enjoy your new desktop adding machine.

Re:Books, Music, and APIs

[dgatwood]

And I would strongly disagree. API design is one of the hardest and most valuable things software engineers do: determining the best places and ways to expose appropriate functionality so that it is most useful to others (including yourself).

Just to be clear, I'm not saying it isn't valuable. I'm saying that the API has almost no impact on the design of the software that implements that API, and that its only impact is on other people's code. That makes it not part of the fundamental design of the software (unless the software is relatively simple), but rather a thin veneer on top of the design that acts as a gatekeeper for the machinery below it. It is a really important thing for developers to do, don't get me wrong, but it isn't a fundamental part of the design of that software.

To use a car analogy, an API is like a car stereo. A car stereo needs to meet a certain threshold of usability or else people might consider other options, but it is rare that anybody decides to not buy a car because the stereo is the wrong color. And like a car stereo, a good API is relatively easy to retrofit, assuming what's under the hood works well. If it doesn't, you can put any API on top of it that you want, and the software is still going to suck.

And in much the same way that nobody (sane) replaces an entire car just to get a stereo upgrade, almost nobody ever replaces a working chunk of code just to get a cleaner API. It is far easier to wrap an ugly-but-functional API with a thin shim that makes it more suitable for your needs. Developers do that frequently, at least for nontrivial APIs.

Thus, I would argue that the most important thing about an API (by far) is whether the code underneath it works, and that what the API looks like is much less important. And I say this even as somebody who has spent a lot of time over the years pushing engineers to develop good APIs. It is important, but if I had to choose between "works but ugly" and "broken but pretty", I'd choose the first any day of the week. You can always wrap a bad API to make it pretty. You can't usually wrap a broken API to make it work.

Look at the design of C++'s standard library APIs (part of it being the former STL). Then compare that to some half-ass collections interface (e.g. - early versions of collections in Java). You are claiming that there is nothing worthy of legal protection in the design of those far superior C++ interfaces. That they are merely some necessary functional bits to invoke the (truly valuable) code that sits behind them.

IMO, both look like pretty straightforward C++/Java ports of the Objective-C collection classes plus NSEnumerator to me, and I'm pretty sure those predate Java and STL (and are based loosely on classes that go back even further). Given that Sun worked with NeXT on OpenStep for two years before Java came out, I have no way to know whether Sun copied NeXT's design or played some role in both designs. Either way, though you can reasonably argue that C++ and Java collection classes are prime examples of why the entire industry is better off when we have more copying of well-designed APIs, rather than less.

As for the collection classes being thin veneer over truly valuable code, no, in the case of collection classes, they're mostly thin veneer over the kinds of code that every beginning computer programmer implements as part of an Intro to Data Structures class in college. The only reason collection classes even exist is to save people a few extra hours writing a bunch of boilerplate code that everybody knows how to write. They are quite literally the bricks of the software world—very useful, but about as interesting as a rock....

Copyrightability

[Anonymous Coward]

FYI: http://www.cafc.uscourts.gov/sites/default/files/opinions-orders/13-1021.Opinion.5-7-2014.1.PDF

There was also another ruling or opinion that I can't seem to locate now.

Per my understanding, the jury was of the opinion that method signatures were themselves not copyrightable because there was nothing creative about it. For example int max(int, int). If a programmer were to come up with declaration of a method that identified and returned the maximum of two integers there are only a few ways to do it that make sense and IMO all of them involve just the name of the function itself, e.g. max, maximum, greater, larger, etc. On the other hand, the organization of such methods and names of packages are much more numerous. For, e.g. sin falls under math. However, the question "shall one further classify (no pun intended) under trigonometry?" can generate a lot of varied responses and arguments. Each of such instances would need to be evaluated individually. Additionally, the jury should also consider whether the defendant had any option to deviate from the plaintiff's API without causing much grief to the consumers of such API

Re:Type systems

[segedunum]

No it hasn't, throughout the decades copyright of software has been upheld.

Yes it has. Software implementations, yes, APIs no. Not sure if you're just ignorant or are deliberately painting over that. The developer tools market is built on this and has been since the year dot.

Nah, because there is a strong interoperability defense, that allows you to copy copyrighted APIs (which is what your friend dr dos did).

Nope, because every company is now going to have to go to court to prove 'fair use'', which Oracle has made various versions of as it has gone along. If you can't prove that then there are billions in free money waiting for everyone who can claim copyright over APIs. At the time of DR DOS APIs were certainly not copyrightable and haven't been deemed to be so until recently. There is no *strong* fair use defence. That was shoehorned in when the people making the laughable ruling realised what trouble it would cause, but it creates a nice walled garden nonetheless.

1) They didn't make a clean-room copy.

Yes they did, and it's not a copy. Dalvik isn't a Java.

2) They didn't make their copy for interoperability reasons.

Yes they did. They wanted a familiar language where developers could reuse *their* code and port over. There are developer tools that have been on the market for decades that will do exactly that. Oracle's idea that because Android isn't 100% compatible with Java, and they didn't copy *all* the APIs, so therefore it can't be about interoperability is absolutely laughable.

3) They didn't use any of the licenses that were available for Java. Google has now switched to the GPL for their Java, so there is no more problem for them going forward.

They didn't need a license because they didn't copy anything from Java and what they implemented isn't Java. What code you could write for Android looks like Java, as a language, but that's all.

It's a distinction Oracle are rather desperate to muddy because they'd like to make some money out of this case because they failed to develop anything remotely useful people wanted. A lot of their customers are starting jump ship as well. Revenue-wise this is quite important to Oracle, and you see that in how desperate their lawyers get.

If headers are not copyrightable...

[mveloso]

If headers aren't copyrightable, why do headers have copyright statements in them?

Re:If headers are not copyrightable...

[wardrich86]

- Jayden Smithhttps://developers.slashdot.org/story/16/05/20/1432233/declaring-code-is-not-code-says-larry-page#

Re:APIs are not code

[segedunum]

Copyrighting words in dictionary isn't possible.

Declaring code is docs, but Android screwed Sun

[Theovon]

Although it’s meant for a machine, I think declaring code is documentation. It’s also somewhat redundant because in theory, a compiler COULD just find the function definitions directly and infer the prototypes. This is true about Verilog, for instance. Declaring code is in the form of code, but it doesn’t represent any functionality, only the interface you use to get access to the functionality provided by the defining code.

That all being said, I hold an unpopular opinion. What Google did should be techinically legal, and it should obviously be possible to develop compatible implementations of operating systems and other software infrastructures. However, Google’s choice to usurp the Java empire totally fucked over Sun. Android started at a time when Sun was still Sun. They were making revenue from Java, and if that revenue stream had continued, the may have been able to avoid going under. Instead, Android totally ripped the rug out from under that part of Sun, and Sun had to liquidate and get sold to to the assholes at Oracle.

So while technically, within the law, Google doesn’t owe a penny to Oracle (in my opinion), what Google did was morally wrong, and there were consequences (surely anticipated by Google to some degree or other) that lead to Sun’s demise.

Yes, if Java was the one thing that broke Sun, then there were bigger problems there, but that doesn’t change the fact that Android fucked over Sun. Basically, people at Sun put an enormous amount of effort into developing a platform independent language and software infrastructure that we have all benefitted greatly, but they never got the chance to reap the rewards because Google took it all away.

What this basically tells me is that unless I’m just a pure altruist and humanitarian and ready to give away all of my hard work for no reward, then I should just not do anything, because all my hard work is just going to be (legally) ripped off by some other company. I’m a huge fan of both using and contributing to free software, but a dude’s gotta eat, and we should have a moral right to get something back from our efforts. Copyrights are FAR too lengthy, and patents are given away for the stupidest shit, but the spirit of these protections is sound in that for a limited time, you should be able to profit from your hard work. Sun’s ability to profit from Java was far too limited, because they were never able recoup the investment. If Google had played nice, then Sun would still exist, and the world would be a better place.

Oh, and don’t give me bullshit about how Google could have chosen a different language. Sure, they could have. Apple sure did, and Objective-C sucks. That doesn’t change the fact that Google’s boostrapping would have taken FAR LONGER if they’d had to start from scratch. And I’m of the opinion that although I hate GC’d languages in general, and they suck battery like there’s no tomorrow, Android apps would be a hell of a lot crashier in general if they’d chosen a language with manual memory management. If Google had made other choices, Java would have remained longer under the control of Sun, and Android would have taken far longer to get off the ground. It’s possible that if Google had taken that route, their software stack would be more mature now and not tied down by the drawbacks that Java has with regard to energy usage.

Re:Declaring code is docs, but Android screwed Sun

[PRMan]

What this basically tells me is that unless I’m just a pure altruist and humanitarian and ready to give away all of my hard work for no reward, then I should just not do anything, because all my hard work is just going to be (legally) ripped off by some other company.

Maintain your copyrights instead of telling the world that they can freely use them. That's a start.

Re:Declaring code is docs, but Android screwed Sun

[Theovon]

I’m not saying Sun didn’t make any mistakes. They were, in part, trying to appeal to the open source community, which represents a lot of kinds of the people who would be developing on the Java platform during their day jobs. So there are perhaps things that they could have been more restrictive on, but they’re all double-edged swords. My whole point is that while what Google did was LEGAL, there are many ways in which it might be considered WRONG from an ethical standpoint.

When the little guy (like ReactOS, for instance) clones the APIs of the big guy with an entrenched platform (Microsoft), all we’re doing is protecting our freedoms. But Google was not a “little guy” at the time and certainly isn’t now, while Sun HAD been big but was already suffering financially at the time Google developed Android. So basically, way to kick a brother while he’s down, eh?

Re:Declaring code is docs, but Android screwed Sun

[iampiti]

I was under the impression that Sun never made much money from Java.
They didn't ask end users money for using Java, they didn't charge for the compiler nor for any IDE.
They did sell books and courses, also certifications. I think they also charged to JavaEE server vendors to certify them as JavaEE compliant, but as I said I believe nothing of that ever made them earn huge amounts of money.
Whether Google shoud've paid them money to use Java is another completely different matter.

Re:Declaring code is docs, but Android screwed Sun

[Solandri]

Sun went under because they were heavily invested in a hardware platform which got squeezed out of existence - the minicomputer / workstation. Mainframes and supercomputers became cheaper, and microcomputers became more powerful (CISC improvements closed the gap with RISC), squeezing out Sun's primary revenue stream. Same thing happened to Silicon Graphics and HP's PA-RISC line.

Java was always open and free - Sun made money by selling systems built on Java. Their business model was to create a large population of Java-proficient programmers by making it free to use, then sell hardware which ran systems coded in Java. Because it's an interpreted language, it requires more CPU power than compiled code, helping stave off the assault from low-powered microcomputers. So your argument that Google somehow screwed Sun by using something they were giving away for free is beyond ridiculous.

Oh, and donâ(TM)t give me bullshit about how Google could have chosen a different language. Sure, they could have. Apple sure did, and Objective-C sucks. That doesnâ(TM)t change the fact that Googleâ(TM)s boostrapping would have taken FAR LONGER if theyâ(TM)d had to start from scratch.

And Sun's bootstrapping of Java would have taken FAR LONGER if they'd had to start from scratch instead of outright copying C++. I never learned Java but I have little problem reading Java code since it's nearly identical to C++.

Re:Declaring code is docs, but Android screwed Sun

[Theovon]

They were set to make plenty of money from licensing embedded JVM to phone makers, until Android came along and wrecked that market for them. It’s the one niche where they COULD have made money directly from licensing the JVM. All other deployments were there just to get people hooked on the language, although perhaps Sun could have charged for support for some high-end Java-based web server or something. In short, Google took away Sun’s only avenue for profiting from Java that would not have annoyed the shit out of the developer community.

Re:Declaring code is docs, but Android screwed Sun

[Theovon]

As much as Java looks like C++, it’s not a direct copy. The APIs and libraries and even the culture in the development communities are completely different. Sure, it’s another C descendent, and as a C++ programmer, I picked up Java without too much effort, but it’s defintely not the same language. The Java language used by Android IS the same language, a complete carbon copy.

Re:Declaring code is docs, but Android screwed Sun

[Theovon]

If Android had failed, perhaps Sun could have managed to stay alive in part from licensing fees to phone makers running embedded JVM. Instead, everyone ditched Sun Java and went with Android because the licensing fees were less (or zero?).

Yes, Solaris and SPARC were a problem, but Java could have been a major paradigm shift for the company, allowing them to shift their focus to something new and still profitable in the new market.

Re:Declaring code is docs, but Android screwed Sun

[Graymalkin]

That all being said, I hold an unpopular opinion. What Google did should be techinically legal, and it should obviously be possible to develop compatible implementations of operating systems and other software infrastructures. However, Googleâ(TM)s choice to usurp the Java empire totally fucked over Sun. Android started at a time when Sun was still Sun. They were making revenue from Java, and if that revenue stream had continued, the may have been able to avoid going under. Instead, Android totally ripped the rug out from under that part of Sun, and Sun had to liquidate and get sold to to the assholes at Oracle.

So while technically, within the law, Google doesnâ(TM)t owe a penny to Oracle (in my opinion), what Google did was morally wrong, and there were consequences (surely anticipated by Google to some degree or other) that lead to Sunâ(TM)s demise.

Put the brakes on that line of thought right there. Google tried to work with Sun in the beginning but could not come to terms. Whether Google wanted the Moon from Sun is immaterial, Sun had the opportunity to get the branded Java platform running on Android. My guess is Sun wanted Google to mate themselves to either J2ME or Swing at the UI layer and Google didn't like either of those options.

So at Android's inception we have Sun setting the stage for Sun getting fucked over. In addition Google used the Apache Harmony project because Sun at the time did not offer an Open Source implementation of the entirely of the Java Class Library.

If Google was "morally" wrong to use Apache Harmony then Apache themselves was "morally" wrong for writing it in the first place. Likewise Red Hat's IcedTea project is morally wrong as is GNU Classpath. I really don't want to have to defend the actions of Google but it is absurd to accuse them of being "morally" wrong in making a business decision for their platform.

Sun's worst enemy was often Sun. They had a specific vision for how they wanted Java to exist on mobile platforms and did not want to waver from it. Their vision was not compatible with what the market actually wanted. Google wanted to satisfy market demands, not Sun's vision for mobile devices.

Re:Declaring code is docs, but Android screwed Sun

[DarkOx]

Well smart phones were not a thing when Sun started Java so what you are really saying is Sun never had a plan but might have got lucky if Google had not come along. Sun perhaps correctly had managed to make J2ME quite a thing in the feature phone mobile space. The alternative of writing highly hardware specific applications for each handset sucked. So I am sure that was a nice bit of revenue for them. Just like lots of software vendors made lots of money writing non-shitty shell replacements for DOS and Windows in the early 90's. Was it wrong for Microsoft to replace progman with explorer because it killed the market for the Norton Desktop (ndw)? Technology changes.

Stuff happens its called a free market. I would also suggest that Google could have very easily gone with an alternative platform. Mono springs to mind. It ran on Linux was clean enough to compile on many architectures and there were/are large numbers of developers with useful .Net experience. Arguably choosing Java probable helped Sun/Oracle by slowing the trend away from the Java ecosystem.

Re:Type systems

[phantomfive]

You're blowing ignorance out your fingers now. You hate Oracle, you misunderstand this case (because of your ignorance), and your emotion/fear is making you say stupid things. For example:

They didn't need a license because they didn't copy anything from Java

They didn't copy anything from Java? Really?

Yes they did [make a clean room copy], and it's not a copy.

No, you're wrong, Joshua Bloch wrote code in both Android and in Sun's version of Java. If you have the same person writing code in both places, that's the sloppiest "clean room" implementation ever.

Oracle's idea that because Android isn't 100% compatible with Java, and they didn't copy *all* the APIs, so therefore it can't be about interoperability is absolutely laughable.

Wait, you just said it's not a copy. So did they copy or not?

Nope, because every company is now going to have to go to court to prove 'fair use'', which Oracle has made various versions of as it has gone along.

Every company is not going to have to go to court to prove fair use, you're letting your emotions carry you away again. And it doesn't matter what 'version' Oracle 'makes,' it matters how the courts rule. The lawyers are supposed to present several arguments to support their case, that's what lawyers do.

Yes it has. Software implementations, yes, APIs no. Not sure if you're just ignorant or are deliberately painting over that.

In what case have APIs ever been treated as non-copyrightable?

Again, calm down, don't let your emotions carry you away, you will think more clearly.

Lawyers

[stumblesthedrunk]

Lawyers, can't live with them, and too many of them are in too good of shape to hit with our cars

Real world analogy?

[istartedi]

You can own a house. You can't own the directions to get there.

Man...

[pruedz]

...I miss Groklaw so much. =(

Re: Man...

[ZeroWaiteState]

Groklaw died with attorney-client privilege.

Re:APIs are not code

[Zeroko]

Perhaps existing words in existing dictionaries, but words in general can be copyrighted. Otherwise, someone could use base 26 to encode a copyrighted work as a "word" & then distribute it. (Adjust encoding as needed to make the word follow English pronunciation rules.)

(Disclaimer: I do not like copyright at all, & IANAL, but this is the way I expect a lawyer would see it.)

Can put anything into C header files

[jphamlore]

For legal purposes, it seems that there is an extra consideration for C-like programming languages: One can put basically anything into header files, including huge blocks of code. Even the GNU Lesser General Public License makes a distinction in its licensing terms of object files produced using header files that contain macros or static functions more than 10 lines long.

Re:Type systems

[kimvette]

> 1) They didn't make a clean-room copy.

Why would they have to considering that Java was released under open source licenses?

I don't agree

[JustNiz]

Dunno that I agree with Page's stance at all.

His argument seems to hinge on declarations not being part of the code, and are somehow automatic consequences of the implementation or at best trivial afterthoughts. It seems to me that APIs are actually the toughest part to get right and it takes experience and skill to design a logical, flexible and useful API, Hardly zero value stuff.

Re:I don't agree

[Anonymous Coward]

Oracle already got paid for that by the increase in the size of the Java ecosystem due to Android. Some developers bought programming tools from Oracle to help them write Java code for Android. Other developers learned Java because of Android, and later filled job positions in Java-heavy companies that are Oracle customers. Indirect benefits like these should be sufficient compensation.

Re:I don't agree

[Anonymous Coward]

The claim isn't that APIs have no value, just that copyright shouldn't cover them.

Re:I don't agree

[sjames]

Yet, I can write a novel telling essentially the same story that some other author worked long and hard on and as long as I use my own words, I'm fine legally speaking.

Vague and Meaningless Laws

[pefisher]

I kind of hope the court gets it "right" this time and declares APIs completely and totally protected. Then, when everything comes tumbling around our ears, it'll be obvious that everything Congress has ever written in regard to intellectual property is vague and essentially meaningless.

Re:Oracle knows they are dying.

[Hognoxious]

Is that the one that's webscale because it doesn't use joins?

An API is an interface

[johannesg]

Doesn't anyone know how to explain this properly? An interface explains how you connect things together. It is a standard, meant to facilitate interaction between components from diverse parties. This particular interface facilitates interaction between java application programs on the one hand, and a java implementation on the other. (and that's why we call it an "Application Program Interface")

Everybody agrees that the java implementation is itself covered by copyright. The interface, however, is not, a fact established, I believe, explicitly by law, and by decades of historical precedent.

An interface is also clearly not the same as 'code'. An interface, all by itself, does not do anything - it cannot be compiled into an executable or a library. It is merely a set of agreements that the (copyrighted) implementation, and the application program, conform to, stated in such a way as to be readable and verifyable by a computer.

Re:Don't be a cuckold. Ignore the ruling.

[rochrist]

Off your meds, coward?

Re:Oracle knows they are dying.

[bluefoxlucid]

No, that's MongoDB. MariaDB is a fork of MySQL with newer database engines, more standardized SQL behaviors, and improved performance; MongoDB is a document store. You use a relational database when you need a set of indexed CSV files; you use a document store if you're working with XML/YAML/JSON-style complex data. If appropriate, store some types of data in one, and other types in the other, and use foreign keys as usual (an ObjectId from MongoDB can store in an RDBMS just fine, or vice versa).

Re:Type systems

[bluefoxlucid]

Wait, you just said it's not a copy. So did they copy or not?

Google made a car that has 4 wheels and an engine. Oracle says it's basically a Chevrolet Cobalt, when Google actually built a Mazda 3. Both have four wheels, five seats, the same steering wheels and pedal layouts, and engines which run on gasoline; neither is a copy of the other.

Re:APIs are not code

[bluefoxlucid]

So Dalvik is a different arrangements of elements than Java, and thus isn't Java. Google wins, let's all get pizza.

Re:Type systems

[phantomfive]

No. In this case, Google definitely copied Java. They fully admit that. It's not even a question in court.

The questions in court were:
1) Were the copied parts protected under copyright?
2) Were the copied parts allowed as fair use?

Re:Type systems

[I4ko]

Does Oracle have a license for the SQL syntax from IBM?

You should be able to copyright APIs ...

[jschultz410]

Google argues that all the design work that people put into figuring out the best APIs for their software systems cannot be protected by copyright. That all that design activity is basically worthless and not worthy of legal protection. I really have no clue how this became the predominant belief amongst software people. Convenience? Stealing someone else's API design is easier than figuring one out yourself, I guess.

Look at the design of the C++ language and its standard library. Think about the huge amounts of effort that Bjarne Stroustrup (and others) put into making the language and all of its API pieces fit together in the best way in their view. Now, imagine that Bjarne's team instead did all that design work only for their own company's use and never intended it for general consumption or use outside their company.

The arguments put forward by Google, and many others, are that if all those complicated, interconnected APIs somehow leaked out onto the internet (e.g. - a disgruntled employee surreptitiously posted them somewhere without permission), then everyone else would be legally free to copy them verbatim and reimplement the backing code without a single bit of permission nor consideration going back to Bjarne nor his company. They are "just" APIs that aren't copyrightable and almost surely not subject to patent protection. Google's approach values all that API design work as entirely worthless and not intellectual property in the least.

That's ridiculous. API design is a HUGE part of software design and development. I'd argue that it is often more important and valuable than any particular backing implementation of the API.

Ok, now imagine a bit different C++ scenario. Stroustrup really likes his C++ language and wants to publish about it, including his specific API design. Does the mere fact that he voluntarily revealed his API to the public (without any license but with a copyright claim), now allow everyone to run off and copy it verbatim again without permission nor consideration back to him? Again, that does seem to be Google's argument and it seems bonkers to me.

Arguing, as the EFF does, that open and free APIs are a good thing that facilitate competition, wide adoption, superior implementations, etc. is one thing. But arguing that all APIs are inherently open and cannot be protected as intellectual property -- that anyone can legally come along and copy verbatim the huge, complicated class hierarchy and interfaces that you designed for your software without your permission nor consideration back to you -- is an entirely different proposition. Authors should absolutely retain intellectual property rights to their specific APIs. They can license them or put them in the public domain as they see fit or not.

Now, the obvious criticism of my stance is that what is to prevent someone from putting and enforcing a copyright on something absurdly simple like C's strlen() function or something similar? Would we have the equivalent of patent trolls trying to extract money from anyone who codes? My answer to that is it would be up to the US Copyright Office and the courts to determine what is fair-use and what is simply too trivial to copyright. For example, a book author's copyright does not give them the right to go and sue anyone who happens to use a sentence that appears in their book, but it does allow them to sue people who reproduce significant sections of their book that go beyond fair-use. The same sort of logic would apply here too.

Much like what already happened with encryption.

[Ungrounded Lightning]

Software companies will all close shop in the U.S. and move their operations to countries where APIs are legally declared not copyrightable. ... The U.S. will be relegated to a software backwater, as most of the software made and sold in the rest of the world cannot legally be distributed in the U.S.

Something similar to this happened with encryption. The US regulated it as a weapon and banned / limited / added red tape to the export of strong encryption software. US companies also couldn't import strong encryption software, include it in their products, and resell them elsewhere. The software had to be installed outside the US by non-US companies.

The result was that commercial development and deployment of strong encryption software pretty much stopped in the US and picked up outside its boundaries for several years, and various workarounds were developed (such as "encryption with a hole" so a strong encryption module could be installed later).

This continued up to about the turn of the centur, when laws, policies, and court decisions loosened things up enough that US companies could play again.

A definition for lawyers?

[lskovlund]

Raymond Chen of Microsoft has often equated an API to a contract. An API has an implementor and a user, just as there are several parties to a contract. Each party expects the other to do certain things (use the API in a certain way) and in return promises other things (to do what the API is specified to do). If one party does not act in accordance with the contract, chaos ensues.

You forgot

[Ungrounded Lightning]

It works like this: Come up with a baseless claim against another company. Take the amount the court could award us, A, multiply by the probability that we can convince the court to rule in our favor, B. A times B equals X. If X is more than our lawyer fees, then we sue.

You forgot: "What counter-claims could they come up against us and how much, C, could they sue for? How likely, D, is the court to decide to award that? Is AxB - CxD still greater than the lawyer fees?"

And then there's: "How big is their patent pool? How big is ours? Do they have any patents that would be really useful for something we want to do? Do we have patents that they might like to use (that won't result in them competing us into oblivion)? Are they open to settlements of the form: 'We'll cross-license our patents, they guy with the smaller pile gives the guy with the larger pile some money, and then we BOTH go back to work - including our lawyers, who use the combined pile to spike our mutual competition (or suck them into a similar deal).'".

Re:Wrong tact talking about 'APIs'

[chuckugly]

I liked the wheel bolt pattern example I read somewhere here. If an automaker was allowed to declare that pattern protected IP then it would be illegal for aftermarket wheel companies to make custom wheels to fit without a negotiated license deal from the OEM.

I think Joe average would get that and be outraged by the idea.

Re:Type systems

[segedunum]

No. In this case, Google definitely copied Java.

Errrrr, no, they didn't, and desperately repeating this won't make it true I'm afraid.

They fully admit that. It's not even a question in court.

No, they haven't. Wishing this won't make it true.

1) Were the copied parts protected under copyright?

No actually, and I'm afraid the Supreme Court ruling is going to be continually questioned here - because it is so obviously wrong. For another thing Sun open sourced *Java* and is relying on hearsay and the vague opinions of developers on mailing lists to attempt to say this doesn't apply.

2) Were the copied parts allowed as fair use?

Obviously. What Google has done as been done in the compiler and developer tools market since time immemorial.

Oracle love trying to avoid the elephants in the room and continually reframing things with questions that have no relation to reality regarding how software actually works. Even when you apply their own questions, they still fail.

Re:Type systems

[phantomfive]

Read through this case and you'll be much smarter. Or don't read it, and remain ignorant.

Re: Declaring code is docs, but Android screwed Su

[ZeroWaiteState]

Set to make plenty of money... Clearly not, if it was worth a complete reimplementation to avoid license fees. I think this is a case where you set up a $100,00 toll road and get mad when people pave their own roads to bypass it.

Re: Declaring code is docs, but Android screwed Su

[ZeroWaiteState]

That's fair. It only copies the design mistakes of C++. The good parts they mostly managed to avoid.

Re:which outcome is better for society?

[sjames]

No. Sun vs. MS was a trademark dispute. Sun maintained that by adding windows-only "extensions", MS gave up the right to call the result "Java".

Google never called the result "Java".

Re:which outcome is better for society?

[sjames]

You missed the important subtlety. "The Java programming language" isn't the same as Java (TM). The former is merely descriptive.

Re:which outcome is better for society?

[sjames]

What does that have to do with anything?

Re:Much like what already happened with encryption

[Ungrounded Lightning]

By "centur" you mean half-man half-horse, right

Only if he did something in my keyboard to make the Y key intermittent.

Re:Much like what already happened with encryption

[AK Marc]

Nothing launched Israel's IT businesses like the US's anti-competitive regulations. We'd never have Allot (and dozens of others) if the US hadn't run off tech, and those that work on it.

Re:APIs are not code

[segedunum]

Perhaps existing words in existing dictionaries, but words in general can be copyrighted.

No, they can't. This is the case as everything would get completely ridiculous - even by copyright standards.

Re:Type systems

[segedunum]

You've responded and come up with nothing other than repeating the same debunked tripe because it is all you have. Ditto Oracle in this trial. Their lawyers have done exactly the same thing - repeat the word 'copy' multiple times. Maybe Google should copyright it? ;-)

Re:Type systems

[phantomfive]

Did you read it? I would be much more impressed if you could comment based on your reading of the case.

Re:Type systems

[segedunum]

Using a compatible language or interfaces is not copying.

The laughable thing is, if Dalvik is an implementation, up to a point, then without at least some of the same interfaces and the ability to use the same code.....it ceases to be an implementation.

What Google did is create an equivalent to Java's runtime that didn't use any Sun IP, and a tool "dx" that translates Java bytecode into Dalvik bytecode. Did they have the right to do that?

This is done by various developer tools every day of the week.

All this is only relevant to the question of APIs because Oracle had to focus on the one thing they could prove Google took from Java. The rest of the toolchain is clearly NOT based on Sun's technology, so Oracle would have no case.

Indeed not. They hoped to find unlicensed implementation code in Java and didn't find any, so they switched to the ridiculous notion of APIs.

There is no such thing

[cwsumner]

In actual fact there is no such thing as a right to "intellectual property". The very idea is relativly new, less than a thousand years old. Before that there was no such idea.

The copyright and patent laws came about as a "fix" for ideas and tech being lost when people died. As in: Disclose your trade secrets and we will protect you from loosing your business. So, many ideas were documented and shared and tech took a really big surge in development that is still going on.

We have the laws because they work and make everyone better, but that does not mean it is an inherent right. Actually ideas are like breath, once you breath out it is gone and you have no more claim to it.

Re:Wrong tact talking about 'APIs'

[cwsumner]

I liked the wheel bolt pattern example I read somewhere here. If an automaker was allowed to declare that pattern protected IP then it would be illegal for aftermarket wheel companies to make custom wheels to fit without a negotiated license deal from the OEM.

I think Joe average would get that and be outraged by the idea.

Good one, I'm going to copy that! 8-)