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

[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

[LichtSpektren]

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

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

[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

[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

[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

[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

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

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?

[HornWumpus]

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

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

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.

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: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: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:Hold on...

[oh_my_080980980]

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

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.

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

[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

[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

[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: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.

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

[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

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

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.

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: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).

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.

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.