Alsup is wrong.

Congratulations to Google for completing the trifecta, coming out victorious on all three key court challenges brought against them by Oracle, and thus making Java more free today than it was at any time in the past. But like so many technical decisions made by a non-technical judiciary and jury pool, Judge Alsup’s conclusion on the final bone of contention is wrong. He was wrong to declare that programming API’s cannot be protected by copyright.

An API is more than just a collection of components

Maybe you can't copyright the idea that a programming language needs a String class. Perhaps it's not that creative for an API designer to put a method named rangeCheck into a component named Integer. Maybe it’s not that earth shattering to put a flush method in the FileWriter class.  But the Java API is more than just a collection of components with simple methods that, as Judge Alsup commented, "a high school student could do."

I agree with Judge Alsup on the rangeCheck dilemma. Indeed, a competent high school student could competently write the body of the rangeCheck method. I also think a high school class could come up with a decent list of methods that should be part of the Math class. But the Java API isn't just a simple collection of components that exist as little islands in a sea of bytecode.

The Java API is beautiful. 

Programmers and developers are often slagged as being a bunch of uncreative nerds, but the best programmers I know are also the most creative people I have ever met. The manner in which classes in the Java API are related through inheritance, associated through interfaces, and intertwined through aggregation is as beautiful to me as any Van Gogh or Rembrandt hanging on the walls of the Getty. There is clearly intellectual property hidden there in the Java API, and since it's an accepted concession of the US judicial system that intellectual property is copyrightable, then copyright laws should protect the Java API as well.

Java developers know the truth

Developers know it. Java developers also tend to want Java to be free, so they're not out there rioting against the court's decision. But Java developers know the truth. Developers know how a solid API justfeels right. Developers can see and feel the symmetry, insight, beauty and creativity that goes into a well-developed API. And every developer worth his salt knows how miserable and painful it is to work with an API that was developed hastily, haphazardly and without forethought regarding the real challenges a programmer will encounter when leveraging it to implementing a solution.

Good APIs vs bad APIs

For example, the Java API is far from perfect. Let's face it, they screwed up the Date class. Every project I've ever been on is on fire with yellow warning lights in the column of every line of code that invokes the deprecated methods of java.util.Date. There's still debate on TheServerSide about what should be done with the Date class, and the lack of forethought into the complexity of designing that API component, over ten years ago, still permeates its way through modern enterprise applications. And more to the point, if every component in the API was delivered with so many inherent shortcomings, the Java API would have been tossed in the recycle bin long before its first official release. The reason the Java API is so universally and enthusiastically loved is because of the intellect and insight that went into designing it, and there should be some legal way to protect that type of effort.

Every developer who takes their first programming class is completely mystified by the utter silliness of all of the abstract classes and seemingly useless interfaces that pepper the Java API. Implementing all of these codeless interfaces always seems academic and laborious to a newcomer. But there's always a point where a developer leaves the college classroom and starts doing some real development where the light goes on and they hit that Eureka moment where they finally appreciate the benefit and beauty of the way the various Java components participate in interface based polymorphism, or inheritance based abstraction. 

Maybe only developers know what developers know?

I don't think any lawyer or Judge on a district court would have any appreciation or understanding of what was written in the previous paragraph, but every Java developer does. Beauty, symmetry, form and functionality are only created out of nothing in the Bible. When it happens in the real world, it's a product of intellect and ingenuity, and when that type of ingenuity manifests itself in an API, the minds responsible for it are entitled to some type of protection for their creation.

When looking at the API question, perhaps too much emphasis gets placed on the minutia of the code. Looking at individual classes and methods would be like looking at a door and a support wall and telling Frank Lloyd Wright than none of his architectural drawings were worthy of protection because they're simply a bunch of doors, walls and support beams. It's easy to see the inherent beauty of a architectural drawing of a magnificent building. It's not nearly as easy to see how the same degree of beauty and creativity manifests itself in a magnificent programming API. That's the problem we run into as the judiciary goes from making complicated legal decisions to making complicated technical decisions.

Perhaps software is too complex and ephemeral to protect these days. Perhaps the ability of companies like Oracle to protect their intellectual property is being steamrolled by the open source ethos that is so rampant in the IT community.

Today, Java is more free than it was yesterday, but that's only because Judge Alsup made the wrong call by declaring that the Java API could not be protected by copyright.

Judge rules for Google, against Oracle, in copyright case

Is it possible to copywright a song title ?

NO !

 

 

If APIs were copyrightable, then every time you override a method or implement an interface, you'll have to pay up.

Spend some time reading at groklaw.

If APIs were copyrightable, then every time you override a method or implement an interface, you'll have to pay up.

Exactly. If APIs were copyrightable, even using an API (calling its methods) might be a copyright violation. That would be really ridiculous.

Robert -

If APIs were copyrightable, then every time you override a method or implement an interface, you'll have to pay up.

Why? Because before you were using a pay-for product without paying for it, and now that you override a method, you have to pay? You have a deluded (i.e. Groklaw) view of software and licenses.

For example, now that APIs are not copywritable, I can link to GPL without having to publish my work under GPL (since the linking portion of the GPL license is only enforceable if APIs are copywritable).

Peace,

Cameron Purdy | Oracle

(Writing as an individual and not a spokesperson.)

 

For example, now that APIs are not copywritable, I can link to GPL without having to publish my work under GPL (since the linking portion of the GPL license is only enforceable if APIs are copywritable).

Dear Cameron, your view of law is deluded.

You can NOT link to a GPL library and distribute the result because that produces a derived work. It doesn't matter that the API of the library is not copyrightable because you also depend on very copyrightable implementation of the API.

For example, I can start my company (say, named Kangasol) and create a Kangasol Coherence that has exactly the same API as Oracle Coherence. That's allowed and is not problematic (we ignore software patents for now) because APIs are not copyrightable.

However, I certainly can not just take Oracle Coherence implementation and sell it as if it's my own product.

So what you're saying is that all those Java core functions using the APIs taken from other softeware are properly licensed? No? Yeah didn't think so.

Not to mention, if APIs were copyrightable the first person to come up with a tangent calculation function would own that function and everyone would have to pay just to do a simple math calculation.

Good thing you and this article writer weren't the judge. Since the person writing the article couldn't even be bothered to get the fact right. Since the Judge is a technically literate mathematician who knows how to program software. OOPS! So much for the correct facts, being reported. Couldn't even get the first paragraph correct. Meaning this article is worthless, who knows what else is wrong, or maybe perhaps the writer is just assemling a bunch of lies in hopes of spreading the wrong information. Epic fail.

So what you're saying is that all those Java core functions using the APIs taken from other softeware are properly licensed? No? Yeah didn't think so.

Not to mention, if APIs were copyrightable the first person to come up with a tangent calculation function would own that function and everyone would have to pay just to do a simple math calculation.

Good thing you and this article writer weren't the judge. Since the person writing the article couldn't even be bothered to get the fact right. Since the Judge is a technically literate mathematician who knows how to program software. OOPS! So much for the correct facts, being reported. Couldn't even get the first paragraph correct. Meaning this article is worthless, who knows what else is wrong, or maybe perhaps the writer is just assemling a bunch of lies in hopes of spreading the wrong information. Epic fail.

I think you're confusing reverse engineering, inspired by and copying. Copyright is about preventing copying written content verbatum. Reverse engineering something in a clean room has zero copying. Creating API that is inspired by pre-existing system that does not copy written content from some other person/business does not violate copyright.

We can all agree Java was inspired by prior art. Being inspired by existing designs in data structures and algorithms doesn't mean Sun copied other people's work verbatum. In the case of algorithms, it used to be that algorithms weren't patentable. Now that software is patentable, we do see companies defending those assets.

Seems like lots of people have a simplistic view of what copyright and patents mean. If you look at the actual decision by the judge, it clearly shows the "amount of copying" found in the case did not merit the amount Oracle is asking for. You have to view in those specific terms. The judge did not say all API is not copyrightable. If I understand it properly, his decision is saying this specific case, the amount of copying did not match the value claimed and therefore in that context was not valid.

People are jumping to conclusions without taking time to understand the ugly mess that is copyright laws. It's not 50 shades of grey. It's 5000 shades of grey.

You see, Cameron, you are free to write your OWN IMPLEMENTATION of some GPL code. Just as before.

But you cannot use someone else's implementation of some GPL code. Just as before.

the author is confusing his / her love of the language with the law.

logical names have been used in many languages which happen to be same. doesnt mean newer languages have to be sued by older.

Imagine Mr. George Boole suing every one on this planet for using 1's and 0's as the basis of computing. yeah i know he is dead .. but you get the point :).  

Alsup was right in every way.

No. No. No. No.

A phone book might be beautiful and its creation might require a lot of work. Yet the collection of phone numbers is NOT copyrightable.

Alex -

A phone book might be beautiful and its creation might require a lot of work. Yet the collection of phone numbers is NOT copyrightable.

A phone book used to be copyrightable. That changed (at least in the USA) as the result of a court case, when a company was found to be copying phone book contents wholesale, and they successfully argued that the contents should be copyable (i.e. that the copyright should not be enforceable).

At any rate, you've managed to find about the only specific case of something that can be built / written and published, but on which a copyright cannot be directly enforced.

Peace,

Cameron Purdy | Oracle

(Writing as an individual and not a spokesperson.)

At any rate, you've managed to find about the only specific case of something that can be built / written and published, but on which a copyright cannot be directly enforced.

Well, I'm not an IP lawyer, but as a CIO I have to know a bit about copyright and other laws. So even I know about several cases where wholesale copying is permitted.

1. When there's no creative input. Like: list of constants in a header file or images from a CCTV camera on public street.
2. Simple fact statements. It's not really applicable here.
3. Copying necessary for purposes interoperability.

The third one is the most important in this case. For instance, certain console manufacturer used to include a copyrighted poem in a ROM cartridge handshake protocol. Their idea was to sue everyone producing unlicensed cartridges since they HAVE to include this poem on them.

However, US courts ruled that because the use of a poem for interoperability was mandated and couldn't be affected by third-party vendors then it must be permitted for the sake of interoperability.

(The next version of this protection used a logo protected by trademark laws which was read from a ROM cartridge and displayed at boot. This time it worked - trademark laws are much more strict)

Then there's the famous decision about the BIOS of IBM computers. IBM tried to use an argument that since they created the BIOS and owned copyrights to it, then all cloned PC hardware developers should get a license for it. Again, courts ruled otherwise.

Just think about it - the whole success of x86 PCs was based on a decision to allow copying for the sake of interoperability.

BTW, the computer you're writing from also has a BIOS implementation (even if it's a Mac). Do you have a license for it from IBM?

Great Scott, TSS, what happened to you?  That was just sad.

"There is clearly intellectual property hidden there in the Java API, and since it's an accepted concession of the US judicial system that intellectual property is copyrightable, then copyright laws should protect the Java API as well."

Just because you have a good idea, doesn't mean that it's property. This is ludicrous. Yes, the Java API is amazing. It's very well thought out (for the most part.) Nobody is arguing this. However, just because something is beautiful doesn't mean it's copyrightable.

Since when has it been "an accepted concession of the US judicial system that intellectual property is copyrightable". This is absurd on so many levels. Copyright only covers a portion of intellectual property so this statement alone can be interpreted as "I have no clue what I'm talking about." APIs are subject to patentability. So go ahead Oracle. Try to patent your APIs and watch developers flee en masse.

And you're right. Developers know when an API feels right. Something that feels right isn't copyrightable. If it were, I would have copyrighted sex a long time ago.

You're right again that building a really good API takes a lot of work. Now, show me the clause in the copyright law that says that stuff that's requires a lot of effort is copyrightable.

I'm glad you're not a lawyer so that you have no chance of ever becoming a judge.

Mike -

Yes, the Java API is amazing. It's very well thought out (for the most part.) Nobody is arguing this. However, just because something is beautiful doesn't mean it's copyrightable.

A copyright is used to protect something that you write from being copied. It's a relatively simple concept. In software, particularly in software components designed to be used widely, I personally believe that there is  tremendous value in good API design, which is why I spend so much time on the design aspects, and expect others that I work with to do the same. As a result, it is natural that I would imagine that APIs should be copyrightable. Why are they any less copyrightable than a book, if in reality it takes me much longer to design good APIs than it takes someone to write a bad book?

That said, it is hard to argue for our current copyright and patent systems, which date from an era in which we didn't even have steam engines. Concepts like literal copying and patenting of inventions don't "map" at all well to software, but unfortunately they are the only IP protections that we have to work with, so companies have to make do with them.

I suppose if you've never had your own commercial work copied by others, then it would be hard for you to understand why IP protections are important to the viability of our industry. I have experienced it, and it's disgraceful.

Cameron Purdy | Oracle

(Writing as an individual and not a spokesperson.)

Why are they any less copyrightable than a book, if in reality it takes me much longer to design good APIs than it takes someone to write a bad book?

APIs are not books. They are more like table of contents in books. And TOCs are actually NOT copyrightable.

Sorry but I don't believe an API is a table of contents in fact if we consider that most API's should be viewed as black boxes (though sadly most can't seem to get this right or even understand such a concept) then it is indeed worthy of some form of copyright protection (as it represents the design itself). Such protection should be divorced from the implementation (of which there should be many possible if it is indeed an Open API).

To me a good API represents more so the many elements of a painting and the implementation the color and texture of such elments.

The real issue that is being overlooked here because it requires some effort (thinking) is when does a collection of methods and/or classes become an API (and a distinctive work) that warrants such copyright protection and how does one decide that one particular API has being copied (plagiarized) from another API.

Those that can't see valid reasons for some form of protection (or policing) in the copying of an whole API clearly have never designed a API themselves - at least a good one.

Copyright of API's is not looking to stop people using such API's but to stop them copying them (altering them ever so slightly) and passing the result off as their own work. Such acts are punished in universities when its done by a student or worse a professor in submitting some research to a science journal.

Copyright of API's is not looking to stop people using such API's but to stop them copying them (altering them ever so slightly) and passing the result off as their own work. Such acts are punished in universities when its done by a student or worse a professor in submitting some research to a science journal.

Again, you're confusing several issues. APIs are like table of contents in a typical book. Students can steal TOC from another work and use it as a TOC in their own paper. That's totally fine (though it might be tricky for a student to prove that they really wrote their paper independently).

And as I've said several times - you wouldn't be writing these words on a PC if not for non-copyrightable APIs.

Please explain to all of us how you have equated a books TOC with an API. From the perspective of a caller of a library the API is the book itself. That is all it should see in a well designed API..the underlying plot (or library implementation) is something that must be discerned from readings and the clues presented including the TOC. The only way I can see how you could relate a TOC with an API is that you see an API being simply a listing of files within an archive which I agree with you is not copyrightable.

Please explain to all of us how you have equated a books TOC with an API. From the perspective of a caller of a library the API is the book itself. That is all it should see in a well designed API..the underlying plot (or library implementation) is something that must be discerned from readings and the clues presented including the TOC.

See, there's a chapter "Delete file" it tells me that it's about deleting files and if I need to delete a file then I should check the chapter filed in the "Delete file" file.

Or more seriously, APIs define the external interface of a system. APIs do not define how exactly the functionality of a system is implemented. So in general APIs serve a utilitary need - they show HOW to work with a system. Exactly like a TOC showing which chapter you should consult for a specific bit of knowledge.

Besides, in general APIs lack creative input, they are mostly dictated by externalities. And courts have consistenyly ruled that "sweat of the brow" is no defence in this case. I've already mentioned CCTV cameras - their coverage is not copyrightable, since no creative input goes into it (even though one might spend considerable amount of money installing them). There's another example - students' exam papers with solutions to typical math/physics problems. Even though a student might have to work hard to solve a problem, it doesn't entitle the student to get a copyright on the solution. Neither does the student's work infringe copyright of other students before him.

Nothign of what I tell is in any way controversial. It's how IT industry works since times immemorial.

So let me get this straight you think the the following are all worthy og copyright protection.

int max(int a, int b);

real sine (real opp, real hypot);

real pow (real anumber, real apower);

string writeln(string expression);

 

Because that is what your argument is. If APIs were copyrightable only the first person to come up with those forms would have the sole right to use them without compensation. Not to mention simply changing the names of the variables would be viewed as derivative and infringing works, so the first writer of those APIS would own them for 100 years. Any clue how many millions of other trivial, obvious, and  brainless APIS exist. Not to many the thousands of what would be infringing implementations in JAVA alone.

So let me get this straight you think the the following are all worthy og copyright protection.

int max(int a, int b);

real sine (real opp, real hypot);

real pow (real anumber, real apower);

string writeln(string expression);

 

Because that is what your argument is. If APIs were copyrightable only the first person to come up with those forms would have the sole right to use them without compensation. Not to mention simply changing the names of the variables would be viewed as derivative and infringing works, so the first writer of those APIS would own them for 100 years. Any clue how many millions of other trivial, obvious, and  brainless APIS exist. Not to many the thousands of what would be infringing implementations in JAVA alone.

Just to be clear, if someone literally did "copy/paste" then yes, that is an offense. On the otherhand, if someone was inspired by the interface and did this:

int maximum(int firstinput, int secondinput);

Decimal sine(Decimal opposite, Decimal hypotenuse);

Decimal power(Decimal number, Decimal power);

String writeLine(String text);

It would be totally fine. No "copying" was done. The key point is literal copying, not borrowing ideas. There is a subtle difference.

Why are they any less copyrightable than a book, if in reality it takes me much longer to design good APIs than it takes someone to write a bad book?

APIs are not books. They are more like table of contents in books. And TOCs are actually NOT copyrightable.

My degree is in literature and writing. A TOC is a summary of a book. Just look at the titles of a chapter tells you nothing about what happens in a book. In fact, most chapters titles are meant to misguide the reader.

A great/good set of API defines how something works and how it is used. It defines what you can or can't do. TOC doesn't do any of that, so the analogy is totally bogus. I would suggest you do a survey of several hundred book and see if TOC really tells you enough about the book that another writer could copy. My bet is "no, TOC doesn't tell you squat". Having read hundreds of book to get my degree, TOC is not reliable. It's only good as a bookmark.

Very good point, Alex. To copyright an API is as copyright the measure of the tyres, the pass of a screw, the width of a pipe, the shoes numbering, the idea of making phone numbers made of digits, ... the etc is endless. Oracle is not my ideal company but with this type of news is going even worse.

Cameron,

I guess we'll have to agree to disagree.

Good design is absolutely critical to a good API. I agree 100% with that idea. I often invest more time in creating an API than I do its implementation. And I strongly believe that APIs are not copyrightable.

Even though copyright came from a period before software, the fundamental problem it was trying to solve was encouraging people to create works becauuse their works could be easily copied using the printing press. Granted, it's even easier to copy today.

Given that it's even easier to copy today, do we need to provide additonal incentives to developers to create better APIs? I would argue that we don't. Developers are investing in good APIs. Why do we need to extend copyrights to APIs? If your goal is to make money then writing good APIs is a poor business plan.

-Mike

What the about the intellectual property hidden in the beauty of object-oriented programming? Also owned and copyrightable by Oracle? What about the beauty of high-level languages? The beauty of the von Neumann architecture? The beauty of math and logic???

Article "Posted on: June 01 2012 12:51 EDT"

Anyone else think the corks must have "Popped on: June 01 2012 09:00 EDT"?

By copyrighting APIs, Linux is is trouble (it implements POSIX), Xorg is in trouble, WINE is in trouble, OpenOffice / LibreOffice are in trouble and probably anyone implementing anything...

Even Microsoft layers already know APIs aren't copyrightable.

One more such ridiculous article like this one and I'll definitively unsubscribe TSS posts...

First of all, Judge Alsup is also a Math major and has programmed in other languages besides Java.  He, is without a doubt more competant than you in Math, Programmering and especially copyright law.  

To foolishly imply that method signatures should be copyrightable is not only insane, but it tells me how ignorant you really are about this case.  Congratulations on embarrassing yourself.

First of all, Judge Alsup is also a Math major and has programmed in other languages besides Java.  He, is without a doubt more competant than you in Math, Programmering and especially copyright law.  

To foolishly imply that method signatures should be copyrightable is not only insane, but it tells me how ignorant you really are about this case.  Congratulations on embarrassing yourself.

I would suggest you read the mountain of literature on copyright. The concept of copyright is complex and has shifted in both directions over the last 100 years. An interface with a set number of methods defines what it can or can't do. A single method signature "might" not constitute something that merits copyright, but a set of methods that define something very specific should be copyrightable.

What law defines as copyrightable isn't black and white, so any attempt to paint it as such is foolish. I'm not a lawyer, but as part of my writing courses we did learn what "may" be copyrightable.

Ignoring the issue of copyright for a minute, clearly google should have created their own language to begin with to avoid these kinds of issues. That or they should have bought a license.

As a long time reader of TSS, long time reader of Groklaw, and a long time Java programmer, I'm very interested by this discussion.

I am biased, I think the software industry is a safer place following the Allsup decision, but it's nothing like as clear to me as Groklaw suggests.


Anyone remember the Microsoft J++ litigation a decade or so ago? Microsoft had bought the relevant license for Java, but had gone their own way on implementing it. They only implemented some of the APIs, implemented platform specific additional features, broke the spirit of the APIs, broke cross-platform compatibility, and generally caused problems for the Java community. Sun eventually went after Microsoft for Trademark abuse (calling it 'Java' when it didn't pass the JCK), and the case was settled out of court. That litigation didn't involve Copyright, but covered many of the same underlying issues as the Google litigation. Most of the Java community were anti-Microsoft at the time, just as most are pro-Google now. But the behaviour of Google and Microsoft with respect to Java aren't so very different.


I always thought Copyright for software was about copying of source code. The right to reverse-engineer software has been enshrined in law for a long time. That is, you study software by its behaviour and create a clean-room version. In so doing, you have no choice but to recreate the API for that software. And while you may fall foul of patent law, you don't infringe copyright law as you never had access to copyrighted source material (including the header files and associated documentation). That doesn't mean you can copy the APIs wholesale, but you can recreate them from first principles, expressed in your own terms. Such recreated API files may be vanishingly similar to the original API files, but you'll not have copied them. It seems self evident to me that APIs are both copyrightable (from the point of view of source protection), and non-copyrightable (from the point of view of reverse engineering). It surprises me that so many developers think otherwise.

I'm not convinced that the Allsup decision has changed anything for the IT industry. Maybe it's easier to reverse engineer software now as less of a work is subject to copyright protection in the first place. But fundamental rights haven't changed.

Anyone remember the Microsoft J++ litigation a decade or so ago? Microsoft had bought the relevant license for Java, but had gone their own way on implementing it.

Google is not trying to undermine Java. They're specifically try to avoid trademark issues and their Dalvik VM is fairly compatible with Java. And most importantly, Google is not trying to fragment Java as Microsoft did.

Anyone remember the Microsoft J++ litigation a decade or so ago? Microsoft had bought the relevant license for Java, but had gone their own way on implementing it.

Google is not trying to undermine Java. They're specifically try to avoid trademark issues and their Dalvik VM is fairly compatible with Java. And most importantly, Google is not trying to fragment Java as Microsoft did.

The reality is Google did fragment Java, since Dalvik does not support 100% of java. Just go read the android forums and see how many times people ask "can I use this java app on android?"

Honestly, Google should have created their own language. After all, Google wrote their on VM, and compiler. Sure, they wouldn't have been able to take advantage of Eclipse or Net beans and would have had to write new plugins for their new langauge. They also would have needed to write their own server. So much for "do no evil". There's lots of things I like and love about Google, but their decision to use java's design without buying a license was just wrong.

The reality is Google did fragment Java, since Dalvik does not support 100% of java. Just go read the android forums and see how many times people ask "can I use this java app on android?"

And the answer is "no". So? The situation was exactly the same with J2ME. You simply can't move desktop apps to mobile devices without changing their structure.

Nobody cares about "fragmentation" as long as it's not a way to fragment Java community. And Google explicitly doesn't want that - they provide OpenSource tools working on all major platforms, they're using as much standard API as feasible, etc.

The reality is Google did fragment Java, since Dalvik does not support 100% of java. Just go read the android forums and see how many times people ask "can I use this java app on android?"

And the answer is "no". So? The situation was exactly the same with J2ME. You simply can't move desktop apps to mobile devices without changing their structure.

Nobody cares about "fragmentation" as long as it's not a way to fragment Java community. And Google explicitly doesn't want that - they provide OpenSource tools working on all major platforms, they're using as much standard API as feasible, etc.

I agree 100% that J2ME had a similar situation, but it wasn't exactly the same if I understand correctly. It's not like 100% of the things in J2ME that weren't included is exactly the same as Dalvik. I've heard from friends some things they "expect" to work on Dalvik simply aren't supported. At the same time, Dalvik/Android supports much more than J2ME, so the comparison isn't all that useful. Both were/are targeted to mobile, but you J2ME wasn't really designed to be a smart phone platform if I remember correctly. My foggy memory is that J2ME was designed for embedded devices, which is a complete different beast.

I agree 100% that J2ME had a similar situation, but it wasn't exactly the same if I understand correctly. It's not like 100% of the things in J2ME that weren't included is exactly the same as Dalvik. I've heard from friends some things they "expect" to work on Dalvik simply aren't supported.

Most of these things are totally expected. You can't dynamically generate bytecode on Dalvik and reflection is somewhat limited. SWING and AWT are missing (duh) along with other obvious staff.

But that's all. Core Java language works as expected and most of the libraries work as expected.

At the same time, Dalvik/Android supports much more than J2ME, so the comparison isn't all that useful. Both were/are targeted to mobile, but you J2ME wasn't really designed to be a smart phone platform if I remember correctly. My foggy memory is that J2ME was designed for embedded devices, which is a complete different beast.

J2ME as its name suggest was designed for mobile phones ('smartphones' at that time).

Alex -

Nobody cares about "fragmentation" as long as it's not a way to fragment Java community. And Google explicitly doesn't want that - they provide OpenSource tools working on all major platforms, they're using as much standard API as feasible, etc.

I'm astonished at how certain you are of your correctness. (I suppose that I shouldn't be astonished; most people that post online are absolutely certain of their correctness, and of the idiocy of those who disagree with them.)

What Google did, regardless of their intentions, has contributed to the fragmentation of Java.

Peace,

Cameron Purdy | Oracle

(Writing as an individual, not as a spokesperson.)

I'm astonished at how certain you are of your correctness. (I suppose that I shouldn't be astonished; most people that post online are absolutely certain of their correctness, and of the idiocy of those who disagree with them.)

And I'm astonished that people compare Google's Dalvik with Microsot's J++. The J++ JVM had incompatible core language constructs (delegates) while Dalvik mostly differs in the set of implemented libraries.

What Google did, regardless of their intentions, has contributed to the fragmentation of Java.

No. Google moved Java into new areas. They were not trying to fragment existing userbase by, say, writing incompatible VM for desktop apps.

Google did create their own language and you can write Android apps in Dalvik. Android also built a translator, which allows people to port existing Java to Android. It's a good thing it allows coders to reuse previously written code, rather than do a total rewrite for YANL.

You're either intentionally ignoring the fact that MS did to Java was in an intent to kill Java, and what Google has done is to actually make Java more widespread. One is evil and the other is good. You seem to have trouble distinguishing bad from good.

Google didn't fragment. Java had no product for the platform Android runs on. If anything, Google has provided the roadmap in how to make a Java version for this platform. Every JAVA platform is a fragmentation. Sun created many fragments. which only shows the complete naivette of WORA. There is no such thing. It's a myth. Any coder worth his salt could have predicted this three decades ago.

Google did create their own language and you can write Android apps in Dalvik. Android also built a translator, which allows people to port existing Java to Android. It's a good thing it allows coders to reuse previously written code, rather than do a total rewrite for YANL.

You're either intentionally ignoring the fact that MS did to Java was in an intent to kill Java, and what Google has done is to actually make Java more widespread. One is evil and the other is good. You seem to have trouble distinguishing bad from good.

Google didn't fragment. Java had no product for the platform Android runs on. If anything, Google has provided the roadmap in how to make a Java version for this platform. Every JAVA platform is a fragmentation. Sun created many fragments. which only shows the complete naivette of WORA. There is no such thing. It's a myth. Any coder worth his salt could have predicted this three decades ago.

Totally agree that every Java platform is a fragment and SUN did it themselves. Also agree that fragmentation was bound to happen, even if SUN tried their best not to. YANL is a fact of life. I'm pragmatic about it. Sometimes it's good to reuse and other times it's not. The point is doing copy/paste, which is wrong.

I've railed against many people for doing exactly that on various platforms. If you're going to copy/paste, then do the right thing. Many people have told me I'm nit-picky for it, but to me it is important. If I quote someone's work in a paper, I should cite it. If I use open source code, I should give credit and follow the copyright rules for that project.

Why is it that when google does copy/paste, it's suddenly ok. It's not ok. That's just being lazy and dishonest. There are times when it's ok. For example, code that is published as public domain and completely open, go for it. It's important to respect the author's copyright.

re: "You seem to have trouble distinguishing bad from good."

 

Correct. I'm really struggling on that point. So far as I can see, Microsoft and Google did pretty much the same thing, except that Microsoft was a paid-up Java Licensee and they misused the 'Java' trademark for their partial implementation. Other than that, good and evil seem to be in the eye of the beholder.

 

I'm glad Microsoft were forced to abandon J++, and I'm glad that Google have won with Android. But from a legal/ethical point of view I'm really struggling to see the difference. Both argued that they were extending Java to a new community, both argued that they didn't need to implement the whole platform, both argued that they were the good guys. We may believe that Microsoft had an insidiuous plan to destroy Java, and that may even be true, but other than the trademark issue is the legality any different? The only obvious difference I see is that Microsoft had licensed Java.

Oh, please not. I totally agree that you should not be able to make money by copying someone else's work, but you have to look at this from a bigger picture. If you were to copyright everything in software development, it would instantly kill software development as a trade for all but large companies. Java did not become big because large companies jumped on the wagon when it came along, it became big because every developer could tinkering with it because Sun made it available for free. Java is not the cash cow, Java is the means and provides Oracle with great power. It should be handled with care. If Oracle "Hudsons" or "Open Offices" it, it will be finished.

Oracle is making serious money from software as it stands, it should leave the trade open and dynamic. Google has contributed to Java, it would be much wiser to seek partnership and move forward. Create new things. Google will be more than willing to compensate for their indigression, by contributing stuff the Java as both companies try to advance Android. 

Cooperate not dominate. Every company the tried the "dominate" approach in the past (IBM, MS) has paid the price.

Here is what the judge actually said.

 

"This order does not hold that Java API packages are free for all to use without license," Alsup wrote. "Rather, it holds on the specific facts of this case, the particular elements replicated by Google were free for all to use under the Copyright Act."

There's a very important and distinct point the judge is making here.

Sadly, Mr. McKenzie thinks this is a question of how "beautiful" the Java API is.

Beauty has nothing to do with the legal issue at hand. If that were the case, then courts would be burdened with the responsibility of judging the esthetic worth of every software API. 

What does matter here is whether the structure of the API library -- names are explicitly excluded from copyright protection by law -- is a series of steps functionally necessary to call a given function. The answer being YES means that the hierarchy of the name structure constitutes a command structure.

Previous cases have definitively declared that command structures are not copyrightible. 

That, not beauty, is the basis of Judge Alsup's ruling.

AND IT IS A VERY WISE RULING INDEED. Were the Java API to qualify for copyright, then every user of the Apache Harmony library would be committing an illegal act calling their own, uniquely creative, implementation source code.

I want to raise a question here. The court chose (in accordance with the law I suppose) non-technical jury so their judgement won't be affected by their bias.

If the concern is the bias, what percentage of this jury used any of google services (search, email, etc.) and how can court be sure that the affilication to free google services didn't play a role here. I am not questioning the outcome or blame anybody, I am questioning the premise . The requirement of not being technical is pointless for this case because there are other lines of attachments here. If a company like Facebook that has 900+ million users is dragged to court one day for some reason how many poeple you can find who are impartial? probably none.

My point being the court system is outdated with regard to software technology in particular. In fact I prefer the jury of peers in this case to be people with knowledge of the domain so they avoid a basic question such as difference between memory and stack and get confused by laywers answers. At the end of the day any verdict that they have on any software patent is redicoulous to me if they just found out what is stack and what is memory.

I can see how moral values and things of that nature fit nicely with this type of judgment (Florida exempted :-) ) but technical and engineering and software disputes to be left in the hands of randomly selected people looks unjust to say the least. Aren't we gambling ?

 

Suppose java was closed source- still it has to expose API (The method signature) as microsoft did for VC++. (implementation is internal to microsoft which no one knows) - That never means- I can't create a new language with API same as VC++, but do some other things.

If Oracle thinks, Google copied source code- there is no way to prove it either now or in future (although its a open secret- they might have walked through the code base)

RMS says it correct regarding this judgement. Alsup still got it wrong regarding patents, though final ruling is correct. To maintain IPR- just keep it closed source from now on.

Suppose java was closed source- still it has to expose API (The method signature) as microsoft did for VC++. (implementation is internal to microsoft which no one knows) - That never means- I can't create a new language with API same as VC++, but do some other things.

If Oracle thinks, Google copied source code- there is no way to prove it either now or in future (although its a open secret- they might have walked through the code base)

RMS says it correct regarding this judgement. Alsup still got it wrong regarding patents, though final ruling is correct. To maintain IPR- just keep it closed source from now on.

If you look at the details, I believe the court proved a Google engineer did copy/paste code. The Judge made the decision that a couple of lines did not merit the billions Oracle wants. Instead, the judge said the damage is only worth tens of thousand. Whether people feel it is right or wrong will likely never be settled.

The example you're talking about is reverse engineering. That is generally ok as long as no patents are violated.

Once java committed code to open source- it was like telling- Here is our GPL code- you can use it modify it in whatever way (GPL is all about sharing and modifying and resharing. GPL strongly support fragmentation of Java in that way)- unless you don't resell it. And Google didn't resell the code. Their SDK is open source as GPL wanted it. There is no wrong from google, although- they could have morally paid sun some money .

Once java committed code to open source- it was like telling- Here is our GPL code- you can use it modify it in whatever way (GPL is all about sharing and modifying and resharing. GPL strongly support fragmentation of Java in that way)- unless you don't resell it. And Google didn't resell the code. Their SDK is open source as GPL wanted it. There is no wrong from google, although- they could have morally paid sun some money .

I contribute to several open source projects. Apache projects are explicitly prohibited from using GPL code, so the statement "you can use it, modify it in whatever way" is wrong. GPL's main focus isn't pushing fragmentation. It's to insure code is contributed back to the project. In comparison, BSD and Apache license don't force users to contribute back.

. Apache projects are explicitly prohibited from using GPL code, so the statement "you can use it, modify it in whatever way" is wrong. GPL's main focus isn't pushing fragmentation. It's to insure code is contributed back to the project. In comparison, BSD and Apache license don't force users to contribute back.

Oracle's only choice now is to - move along with open source (They can't sue anymore). Its like Devil is forced to help God (Finally devil will understand- he benefited by supporting God).

Let's take a time machine about to 2002-2003.  Back then Sun refused to let us (JBoss) license the TCK for Java EE.  Our lawyer at the time said it was legally ok for us distribute JBoss and implement the Java EE APIs so long as we didn't call it Java EE.  Basically that, public APIs aren't copyright-able, but Trademarks can be enforced.  Its cool to learn that at least one judge agrees.

As far as the Sun vs. Microsoft deal, its the same thing.  Sun fought using Trademark laws, not copyright laws.

As far as Google "fragmenting" Java.  I agree and disagree with this statement.  The Java trademark to a large degree will ensure that anything called Java will remain compatible and unfragmented....But, with Google things are a bit different.  How many times are you faced with something Java, that won't run on Google App Engine?  How many pieces of Java code won't run on Android?  Will developers code to the lowest common denominator of both?  If so, then thats fragmentation.

In creating a good API, a developer creates a system of interfaces which work together.  This is definitely a creative act, for example java.io.* is a fine system for working with fies and a lot of work went in to the system of interfaces.

The names of the functions and interfaces (FileInputStream, OutputStream etc) could all be changed without changing the design of the system (eg FileStream, FileFlow, FileIS instead of FileInputStream).

Section102(b) of the copyright act excludes 'systems' from copyright, so there is by law no protection for the creative part of the API.

By precident there is no protection for the short names used for functions and packages which was not a very creative effort anyway.

So Alsup decided it all correctly.

15 years ago Lotus 123 claimed that their menus were copyright and they lost on the same grounds:  The system of menus and submenus (a file menu contains open, close and save choices) was not copyrightable and the short words used for menu choices were not copyrightable by themselves (File, Open, Save etc)

 

 

 

 

 

 

Alsup doesn't just get to follow his heart when deciding a case like this.  He needs to base his decision on the actual law and legal precident, both of which say APIs cannot be copyrighted. If you feel differently then lobby your Congress person to change the law.

As soon as I heard Google used Harmony I knew they were going to win.  Harmony was a backup plan born out of IBMs fued with Sun over Java licensing in 2004.  It was designed to be free of Sun IP and usable without a Java license under copyright law.  So yeah, the strategy designed by the perennial top patent filer and recent victor of copyright throwdown with SCO held up in court. Shocking!

 For those of you who don't remember the Sun/IBM spat:

http://www.theregister.co.uk/2005/06/30/ibm_java/

Of course a good API contains work, but this does not mean that one should prohibit re-implementations, which of course need to contain the API as well. This would be highly anti-innovative and of doubtful value - IMHO it serves the community much better if just the actual implementation is protected.