Well,the opposite is true as well -- if you use an Oracle product, you've paid for it, you are safe. If you use a product that seems unrelated but could somehow infringe on Oracle's patent, then could have lawyers come after you.
Reminds me of the story with Suse Linux paying Microsft protection money for allegedly infringing on their patents.
Oracle employees are only shooting themselves in the foot by continuing to work for them. Guys, it's a nice, healthy job market out there. Please consider.
Can one write and have the court enforce a free software licence that discriminates against companies that impose API copyright on others like what Oracle is doing?
Something along the lines of:
You can use this software, freely distribute it yada yada as long as you do not "pull an Oracle".
I'm sure you could (though it would have to be tested in court), but I'm missing the point slightly because Oracle (/Sun) is the original creator of Java, so they would not be building it on top of your license (nor would any other "Oracle" with similar intentions).
If this style of licensing became so ubiquitous that essentially everyone in the future demanded it, then I guess it could make sense.
Imagine all GPL software required the licensee to never enforce API copyright, and if they ever enforced API copyright (over unrelated code), their license to the GPL code was null and void. Then Oracle can't run Linux.
What I don't understand, is why other big tech organisations don't join Google on this (like Microsoft, Apple, Facebook, Red Hat, IBM, Intel, etc)? The result will obviously affect them, whether it is now or in the long run.
It's unclear, since this case is basically making all software illegal in retrospect. Browsers freely implement each others' APIs; SQL servers all use the same API developed by a myriad of entities; the Unix API has been copied over and over and it's impossible to determine ownership. This was a really, really, really bad decision, and it will get worse if Google loses the fair use case.
If you thought software patents were bad, you ain't seen nothing yet.
> What are the implications for my free, open source software? And my closed source commercial software?
Software that implements other party's APIs might be obligated to agree to a licensing agreement - projects like Wine, Samba and various 3rd-party emulators. Ironically, Microsoft's discontinued, Android-compatible project Astoria would be exposed (to both Google and Oracle) - Microsoft submitted an amicus in the first Oracle v Google case supporting Oracle's cause. I am not sure if Xamarin- and Cordova-/Phonegap-type projects would be subject to Apple's lawsuits.
I also suspect web-APIs might also become risky, making it possibly for Amazon to sue you for providing AWS-compatible APIs[1] for example
Disclamer: I am not a lawyer, this is just my layman's perspective.
> Software that implements other party's APIs might be obligated to agree to a licensing agreement - projects like Wine, Samba and various 3rd-party emulators.
It's far, far larger than that. Netscape implemented the Blink tag first and other browsers followed suit. Now Netscape (or whoever owns that copyright) can sue all browsers that implement the Blink tag.
IANAL, but my take: Are you re-implementing anybody else's API without their permission? If not, this has absolutely no bearing on you. Hopefully a real lawyer can shed more light.
The problem is the First Circuit gets ALL patent cases nationwide, so with this precedent in place anyone wanting to claim copyright infringement on a API will toss in a Patent claim as well to ensure it goes only to the First Circuit
With the high court refusing to address the issue, we will never see another court get one of these cases.
That the last decision that API's are copyrighted is already the problem. Google - or anyone else - shouldn't have to need to use the fair use argument for this. This is already a law suit which shouldn't be necessary.
This idea that APIs are copyrighted in the US is a bigger problem beyond its borders. I don't know how familiar Americans are about how aggressively the US pushes its own legal interpretations of copyright law into other countries, but it is a continuing hassle.
The main problem here is that many countries do not have fair use! So if the legal interpretation that APIs are copyrighted spreads, it doesn't matter if it is fair use in the US. Even if countries specifically enact laws to exclude APIs from copyright law, you can bet that there will be huge pressure from the US to include it.
The Java trap after all -- only worse. We can't even reimplement it. We can't even implement to specs unless there is a license agreement (and we thought that patents were bad...)! I hate to be Chicken Little, but the sky does seem to be moving ominously quickly in the downward direction.
In some countries, like Brazil, softwares are not copyrighted, nor ideas. They are considered as "art", like a book, so you can't copy, use, etc., without authorization. But you can get the idea and rewrite it. You can't use the same buttons from some Microsoft product, but nothing stops you from deciding that a disk symbol means "save".
Exactly. The original decision was that APIs are not copyrightable. That was overturned on appeal, and it's a disastrous precedent if it is allowed to stand.
Just try to imagine the history of computing if this doctrine had always existed. To give just 2 high-impact examples: PC clones wouldn't have been allowed to implement IBMs BIOS APIs, Microsoft wouldn't have been allowed to implement a Javascript capable browser to compete with Netscape.
It's an alternate history that would have been so different it would be unrecognizable to us.
Clear room prevented any copyright claims on the implementation, but if the API itself between the bios and the OS/application was copyrightable [1], or even between the bios and the hardware, there wouldn't be any PC clones at all.
[1] Although that's arguably a much simpler API where a fair use defense would be more likely to succeeds.
IANAL but as I see it, the interface between hardware components is a binary interface, and this is where the difference lies between this case and others like Sony and Sega. The API here is not a binary interface but rather a textual description for humans to consume, and hence has aspects like creativity and expressivity, the very things copyright applies to. Binary interfaces have none of that. They are literally numbers for machines to interpret. Copyright cannot protect that because that is pure functionality and has no capability for expression.
Not to say there's no creativity there, there certainly is. But that creativity exists in the ideas and solutions used to solve technical problems, which is then the realm of patents.
Google tries to conflate these two issues. Programmers may find it reasonable because of course binary code seems equivalent to program code, the former being deterministically derived from the latter. But from a copyright perspective they are very different. Binaries enjoy copyright protection as they are "derived" from copyright-eligible software code, but Google is not accused of copying binary code here, rather textual APIs that they did not clean room reverse.
Unfortunately tech media and organizations like the EFF of course portray it differently because they have an agenda, and most people accept it without critical thought.
I don't think you deserve the downvotes, still the objection seems invalid; a binary ABI derives as much from a textual description (but not necessarily declarative) as a binary object from its source code. In fact I would say that the actual precondition, invariant definition, postconditions and data layout (which an ABI reimplementation would need to match) are a much more significant expression of creativity than the mere naming of functions.
So, assuming the copyrightability of APIs in the first place, an ABI should get as much protection as a textual API. The problem is that everybody had assumed until this ruling was that while APIs, ABIs and protocols were definitely an expression of creativity, they didn't reach the bar for copyright protection, especially when contrasted with the legally recognized right of reverse engineering for interoperability.
The ABI, being essentially an ordering of bytes at specific offsets, has no expressive capability. Tons of creativity, sure, but of the functional kind, the stuff copyright explicitly exempts.
Note that if only ABI compatibility was required, Google could very well have defined their own API. For instance, they could have defined an API called "openFile()" that compiles down to the exact byte code as "new java.io.File()". But they were not after binary interoperability, they were after the Java developer base Sun had spent billions building.
An ABI is certainly not just an ordering of bytes at a specific offsets, no more than a text file is just a long string of bytes. There are very specific semantics assigned to those bytes.
Yes, and those semantics are purely functional, lacking any form of expression, which copyright expressly excludes from protection. The only reason binaries are copyright-protected is because they are "derivative works" from the original copyright-protected program code.
Google's defense claimed the Dalvik VM was a clean room implementation also so that defense doesn't necessarily prevent a litigation scenario or adverse decision.
It's simple, as a professional developer (that gets paid, more is better) I want companies to get paid for software and well.
When they don't, I'm not happy, so I hope Oracle wins. But Google will win, not because they are right.
Oracle's lawyers are idiots as they can't show it's same. For example run apache http client jar on android and java. It's same. Idiots.
It's my understanding that the problem is not with source theft/copying in violation of licensing. It's with cloning an API.
If Oracle (or anyone) can copyright an API then we might as well pack up and go home. By that measure, you make a new JavaScript library for LeftPad and copyright the API along with the source. Now people start using your library. But it's inefficient. So I come along and clone it, make it faster, better, stronger, the $6 million LeftPad-compatible clone. You can sue me for violating your API copyright.
Clearly what they did is read how the code in question works, then stole the idea to do it their way. They were looking at the source code! They did not start w/ API, there is no clean room argument that can stand ground to reason. I blame the Oracle lawyers for loosing.
That is what Chicken Little would like you to believe, but you always have the option of devising your own API, call it prefixWithChars. If your implementation really is that much better, people will go through the effort of migrating their software.
But it's not a compatible API. At that point, I have a second library and everyone has to rewrite their code to use it. This defeats one of the main benefits of having libraries in the first place.
The benefit of a library, fundamentally, is that any library with a compatible interface (described by the API) can be dropped in and used in place of another library without modification to the calling code. Cloning functionality is not the same thing if we have to put a prefix: thrawaykf05s_leftPad or Jtsummers_leftPad in front of everything.
In theory, as a developer using dynamically linked libraries, I can drop in any version of a library without recompiling. As a user that means you can drop in AMD's OpenGL implementation or a GPL implementation or Nvidia's and see no difference in how you launch your program (though you'd see a difference in performance and perhaps behavior).
(OpenGL isn't a great example because the consortium running it won't do this, but it is a great example because there are many implementations.)
Now, as a developer you have to develop 100 code paths to handle each potential OpenGL implementation. Or maybe some nice person does that for you with a wrapper library. But now that wrapper library API is also copyrighted and it's out of date. So another API comes into existence that wraps it AND adds new APIs to its backend. That'd be really fucking stupid.
As a consumer of APIs I agree that having drop-in replacements for APIs is the ideal state. However, as a producer of APIs, I also appreciate the efforts required to design a good API. There's some value in that. This translates to any product other than an API, of course, but in general if somebody creates something of value, I believe people who derive value from it should respect the creators' wishes.
This case is not, of course, about APIs. It's because Sun created this enormously valuable Java developer base, and Google totally free-loaded on that to bootstrap Android. The API just happens to be the means, and hence the crux of the lawsuit.
Why on Earth would this be better than just letting people copy APIs? Ignore whatever theoretical arguments: are you actually arguing in favor of a better world?
Yes, in my view people should not get to free ride on the labors of others. The ease of copying information belies the efforts required to produce quality information that is valuable, and so people think they have a right to freely copy whatever they can get. But there was a period in recent history when people thought this kind of thing was ok for physical labor, and the world largely agrees that was a bad time. I don't see why things should be any different for mental labor.
