>This is a complete dramatization. Are you copying 10k lines of code from a licensed code base into your project without permission and using it in your commercial product?
To point back to the substance of the thread and Oracle's claims...
Google didn't copy any of Oracle/Sun's Java source code base into Android Java. Oracle lawyers acknowledge this.
Instead, Google copied the API of function name spellings and also the hierarchy of organization (tree of namespaces) of those API methods. I asked about this in a previous comment and some folks more familiar with the case replied with citations of court opinions: https://news.ycombinator.com/item?id=7852100
So to give a flippant summary of the current situation: you _can_ copy some exact spellings of API function names (e.g. other browsers Chrome/Firefox/Safari can copy Microsoft IE XMLHttpRequest() exactly without renaming it to RetrieveHttpXtensibleMarkupLang()) -- as long as you don't copy too much of the API surface area. The threshold of "too much" and getting in legal trouble is yet to be determined by The US Supreme Court.
If Oracle ultimately wins, it seems like millions of programmers will have to reach for a thesaurus to find synonyms to name functions. We'll have to waste brain cycles coming up and alternative spellings of methods to stay away from copyright infringement.
> If Oracle ultimately wins, it seems like millions of programmers will have to reach for a thesaurus to find synonyms to name functions. We'll have to waste brain cycles coming up and alternative spellings of methods to stay away from copyright infringement.
It's worse than that isn't it? Naming is how you link things. What happens to WINE if it is illegal to use the same names Kernel32 does?
It's bad for programmers everywhere. If Oracle wins, you couldn't reimplement a compatible version of anything that's not open source. You couldn't make a third-party implementation of a corporate-owned programming language without putting yourself at risk.
Imagine you're a company using some Oracle database, and you want to reimplement some component of that system in order to migrate and escape their vendor lock-in... You can't, not without taking a huge legal risk.
In the short term, it's a victory for huge litigious corporations like Oracle. The good thing, I hope, is that in the long term, this will make people distrust closed source software even more. What Oracle wants, and has always wanted, is to bind you in the worst possible form of vendor lock-in. Open source and open standards are the answer. Refuse anything else.
> If Oracle wins, you couldn't reimplement a compatible version of anything that's not open source
It's worse than that. OpenJDK, including the java standard library, is GPL. It's open source.
Oracle is claiming that even though source code defining the API is open source, they retain copyright to the API itself.. regardless of the open source implementation of the API by themselves.
If this case goes through, you won't be able to mimic an open source project's API unless you also verify they provide the API under a similarly permissive license.
> OpenJDK, including the java standard library, is GPL. It's open source.
The code at issue is pre-OpenJDK, and wasn't open source when used (though much of it may now also be available in OpenJDK, not that Google uses it under the GPL, or claims to, anyhow.)
Sun released Java under the GPL in 2006 and most of JDK in mid-2007, but the first release of Android was in 2008. Or is the issue that they were developing it behind closed doors while it was still proprietary, even though they never distributed it to anyone?
The first public release of Android was a beta in 2007 (also, layer in 2007, the first SDK preview was released), and it was released to OHA members before that.
But the GPL is irrelevant, Google has never distributed under the GPL terms. That whatever it was doing was not under a Sun/Oracle license is not in dispute.
Yeah I agree the GPL is not relevant to the case at hand, though it does raise the question whether (assuming Oracle wins) the logical conclusion is that the Java APIs are under the GPL/Proprietary dual-license Oracle offers today or that the copyright license itself doesn't apply to the API and a separate license is needed -- in which case I guess it's high time for GPLv4.
> Oracle is claiming that even though source code defining the API is open source, they retain copyright to the API itself..
Are you sure they are claiming that? A weaker claim could be that Google's usage does not conform to the GPL. Indeed if you were correct and the ruling is in Oracle's favor then the GPL is broken as designed, I haven't heard anyone express that concern in connection with this case.
by the by... wasn't Oracle's original product a relational database management system (RDBMS) that offered a SQL API... which was invented/copyrighted by IBM ?
You don't have to pay for ISO to implement an ISO standard. In addition, Oracle released their database software in 1979 but SQL only became an ANSI standard in 1986 (and an ISO standard in 1987) so they did originally reimplement an API which wasn't a public standard.
I'm pretty sure that a fair number of commonly used QR libraries were not developed by people who shelled out for a copy of ISO 18004 (they probably just looked at descriptions of how it works outside of the standard document). Similarly, you can implement your own SQL dialect without needing to read the ISO standard for it.
Yes if you want to be certified and want to get a copy of the standards document you'll need to pay, but it's not necessary (and I doubt that Oracle did, given that they implemented SQL before the standard existed and probably were involved in drafting it).
I'm not disagreeing with the validity of ISO or anything like that, I don't know where you got that impression.
The original point being made in this thread was that Oracle copied the API of SQL from IBM and thus is guilty of the same thing that they are accusing Google of doing. The counter-point was that SQL is an ISO standard and Oracle (allegedly) licensed it, which was then followed up by my point about Oracle DB predating the ISO standard. Hence why ISO is being discussed and why I was making the point that buying a standard document from ISO or paying for certification are not really relevant to this discussion.
Yes and no. Yes, Oracle was a database with a SQL API. Yes, SQL was invented by IBM. No, it wasn't copyrighted by IBM, because at the time, nobody thought you could do that.
There was still controversy about software copyrightability in 1974. That said, I expect IBM still explicitly copyrighted their implementation of SQL (and licensed it [1]) as they had first started doing with some of the System/360 software during the prior decade. Note that, in 1974, you still had to explicitly copyright something; it didn't just happen automatically like today.
[1] As a side note, IBM may not have been the first to license software but they certainly helped make it a standard practice. When they unbundled much of the System/360 software, they felt that copyright was a weak protection (given its uncertain legal status) so they combined it with a license.
There can still be advantages to being explicit as I understand it to enforce copyright/collect damages. For example, most people don't actually deposit copies in circumstances where they're technically supposed to.
Pre-1976, authors had to explicitly add a copyright notice. The Copyright Act of 1976 changed all that. Creative works automatically gained copyright the moment it was created.
You can make an open-source database that uses the SQL language without paying a dime to anyone or signing any contracts. You don't have to pay for the ISO standard document to implement it - you can just infer behavior based on what you already know about sql.
The state of SQL databases would be better if more people did pay for and try to actually implement the standards as written... same goes for many of these expensive standard documents.
I’ve made a life long habit of collecting and archiving these in my personal documents whenever I get my hands on one. Because these are valuable guidelines as to how things are supposed to work.
Let us assume for a moment Oracle wins this so what? Android will become illegal and then Oracle would ask Google to do what? Pay royalties? Pay Damages? Ask all the android programmers in the world to stop using Android ? Abandon android runtime? I think what is gonna happen realistically is capitalism will take over they will settle it among themselves and share user data as a bargain probably get some royalties. The worst that can happen is Google will abandon android runtime or transfer the development to Oracle. Either way nothing much is gonna happen. Android has already won now say from tomorrow Oracle develops and owns the android development toolchain, so what, from a programmers perspective nothing much.
Nothing much? This isn't just about the Java API. This is about EVERY API. You might not be able to write a web server anymore, depending on who owns the copyright for HTTP. You didn't invent GET, PUT, and POST, you thieving copyright abuser.
I dont think so, Webserver are based on HTTP protocol which is an Open web standard published by IETF. https://tools.ietf.org/html/rfc7231 It could be copyrighted but its usage doesn't mean you are thieving it. For instance "Linux" is a copyright owned by Linus Torvalds, Redhat isnt thieving it. Your understanding is incorrect here.
> It could be copyrighted but its usage doesn't mean you are thieving it.
Says who? Oracle is claiming exactly the opposite, and if they win this will become "law" in the USA.
I think you've missed the whole point of this issue here.
> For instance "Linux" is a copyright owned by Linus Torvalds…
For starters: Linux™ is a trademark, not "a copyright".
> Your understanding is incorrect here.
It seems, at least to me, that you actually missed a few core point of the whole story. ;-)
Quite interesting claim as Nokia was still an EU company back then and software "as such" can't be patented to this day in the EU. (That's sadly not true in practice any more for some time by now as more and more software patents are granted under the notion beeing "computer aided inventions". This also overlaps with strong political will to finally lift the general ban on software patents. Thankfully some people are fighting this nonsense though[1]).
Well sort of. You don't need to have built the actual thing to get a patent.
You cannot patent the completely generic idea of "a tool to lift people in buildings", but you can patent an elevator.
Similarly, you cannot patent "the ability to scan a database", but you can patent an api for doing so, even without a complete implementation of that api.
I don't think it would be infringement. The main difference between WINE and Android is where the interoperability integration points are.
WINE is using the Windows names for the purposes of allowing Windows programs to run. This is a case where a judge would easily grant fair-use because you have to use the API surface area to provide compatibility for existing programs.
Android is using the Java names for the purposes of allowing existing Java developers to be productive, not so that existing Java programs can run.
>I don't think it would be infringement. The main difference between WINE and Android is where the interoperability integration points are. [...] Android is using the Java names for the purposes of allowing existing Java developers to be _productive_, not so that existing Java programs can run.
>Since Oracle's claim is that Google's use of the Java APIs wasn't to provide compatibility to existing software written in Java but to have a _familiar_ language for Java developers it becomes a novel but normal copyright case.
You're making a distinction between "interopability" and "end user familiarity". But Lotus also sued Borland on the basis of "familiarity" of the menu "names and structure" and they lost. The Supreme Court's 4-4 split decision left the lower appeals court's ruling intact.
It's not just about "developer interoperability" vs "program interoprability". Implementing Java APIs means that entire libraries can run.
Sure you might not be able to take a legacy SWING Windows Java app and run it on android, but you can run entire libraries in your android app. It absolutely _is_ about interoperability in both cases. Perhaps to varying degrees
Correct, and I was always surprised that Google didn't argue this point more. In my Android apps I've used Java libraries that were created years before Android even existed, and they work perfectly. And vice versa; I've reused code I originally wrote for Android in a Java desktop app with zero changes.
There is actually, and the court argued as such: if Android had been compatible with Java programs, Google could have claimed a fair-use exemption. Since Android can't run many Java programs, by design, they can't claim such an exemption.
WINE could very likely win a legal battle through claiming a fair-use exemption (of course, if the case fails, they wouldn't have to go to court at all).
Why is the distinction between "runs with zero changes" and "runs with minimal changes"—or even just "runs with fewer changes"—so critical?
Where is the line? Is Android "compatible" with Java programs if those programs need to be recompiled first, but no source edits are necessary? What if source edits are necessary, but can be automated? What if recompiling isn't necessary, but you need to hex edit the binary?
"Compatibility" is a spectrum, and I'd say Android falls within that range.
Because the actual implementation isn't what the courts are looking for. This is a case about Google's intention for copying the Java API. Oracle is claiming that Google copied their API because it was easier than designing a new language; Google is claiming that they did it for interoperability reasons.
There is no distinction between the two because these things are presented as evidence of Google's intent, it's not proof. There's no line. Google's case would be much stronger is Android-Java could run most Java software unmodified but it doesn't mean they'll lose just because it's not true.
Thanks, that's interesting! It seems reasonable—if Google was explicitly trying to enable compatibility, that should be allowed, whereas if they were just trying to save a buck, that should be illegal.
Of course, in reality Google's decision was probably a little of both, right? They selected a technology based on a wide range of factors, including development costs and compatibility.
I'm still concerned that a decision in Oracle's favor would have a massive chilling effect on everyone else. All companies want to limit their potential liabilities. How can you prove in advance that you selected a language or API for the sake of compatibility, even when that is in fact the driving factor?
> Of course, in reality Google's decision was probably a little of both, right?
I wouldn't think that Google's development costs were part of the decision. There aren't that many Java APIs -- as the article says, it's ~11k lines of definitions -- so Oracle is seeking ~$818k per line. Assuming Google's lawyers predicted that there was some risk of a lawsuit like this, any engineering costs associated with redesigning the APIs would just be negligible compared to the legal risk.
One could argue that it is quite difficult to design a good API, but Java's APIs are frankly full of mistakes: Date/Calendar, immutable collections with no type safety, "optional" methods like Iterator.remove, etc. It wouldn't take a team of world-class engineers to come up with something better with the benefit of hindsight.
On the other hand, developer familiarity and compatibility with existing Java libraries could have had a significant impact on Android's adoption. I think that was what justified the legal risks.
> "We've been over a bunch of these, and we think they all suck," Lindholm wrote. "We conclude that we need to negotiate a license for java under the terms we need."
> This is a case about Google's intention for copying the Java API.
Not centrally. The copyrightability issue is absolutely not about Google’s intentions (and if Oracle loses that, it's game over), and Google’s intentions are relevant to one half of one of four fair use factors (the “purpose and character of use” factor) which are weighed together (it's not a pass-fail each factor test) in the fair use portion.
Wine makes programs written for Windows work on Linux. The key difference is that Linux is an independently developed system. The extent that wine copies Windows code is limited to a compatability layer. It doesn't transform Linux into just a copy of Windows.
In contrast, Google didn't have their own independently developed programming language. They needed one so they copied the Java api and created one from there. They did not use the Api to create a compatability layer. It was used as a starting point to make their own copy of Java.
Didn't they though? They've had their own vm and bytecode for as long as Android has been released. The use of Java is for making libraries compatible.
If I'm understanding your argument, if Google independently developed a programming language, and then they implemented a compatibility layer that accepted Java bytecode invoking Java APIs and translated it in realtime to their not-Java programming language, then this would be okay?
How would such a programming language be detectably different from being an implementation of Java?
>If I'm understanding your argument, if Google independently developed a programming language, and then they implemented a compatibility layer that accepted Java bytecode invoking Java APIs and translated it in realtime to their not-Java programming language, then this would be okay?
Yes
>How would such a programming language be detectably different from being an implementation of Java?
It would have it's own unique API. As an example, Ruby can run on the JVM via JRuby and it's clear that Ruby is a different language than Java.
In this example Google independently developed a language and made it compatible with the JVM.
In the real world Google wanted Java and didn't like the licensing terms. So they copied the Java API and from that starting point built out their own version of Java.
Developing a programming language does not give you brownie points with a judge, and has no bearing on the matter.
What you are suggestying is copying the binary API instead of the texual one. It is equally the subject of copyright.
In the real world Google deleoped their own equivalent of the JVM, which uses different bytecode. This is technically more difficult than putting together a language. But that has no relevance to the subject of copyright.
But "making it compatible with the JVM" would involve implementing the Java standard library, right? Recognizing terms like "java.lang.String" or "java.lang.Math.max" and doing the right thing? To do that, aren't you creating a copy of the Java API?
Strange, in hardware land I thought that a clean-room reimplementation of something (where you make something with the same interface -- the API of the hardware) was legal.
Only if the clean-room re-implementation was properly done with separate teams, proven in court that both teams never had any contact with each other beyond written specification architecture documents.
But one of the reasons Android chose Java was for compatibility with existing Java software. It was code rather than binary compatibility, but I'm not convinced that's a meaningful distinction.
I mean, a programming language is fundamentally a set of instructions that produces output, right? So, a Java programmer writes `System.out.print("Hello")` and the Java implementation does the work to make "Hello" appear on screen. Similarly, a Windows executable running via Wine will tell the Windows API to print "Hello", and Wine will do the work to make that message appear on the screen.
> In contrast, Google didn't have their own independently developed programming language. They needed one so they copied the Java api and created one from there. They did not use the Api to create a compatability layer. It was used as a starting point to make their own copy of Java.
This isn't an argument that has been made in court in anyway, and Google's use of the Java language hasn't been questioned.
Google could have used the Java language with completely different APIs (google.lang instead of java.lang for example). It's the APIs that this case is about.
Also, the key analogy is wrong anyway: while Android used java.lang and java.util and other related APIs, the key functionality of the phone was accessible via custom APIs that aren't copied. Note that the "interoperability" argument was lost by Google because of this exact thing.
> Google could have used the Java language with completely different APIs
Well, no, because many Java language constructs are defined in context to the standard library, for instance all classes being children of java.lang.Object. They'd need quite a bit of java.lang at the very least.
Which even after their adoption of OpenJDK still isn't compatible out of the box with the standard library available at https://adoptopenjdk.net/
In 2020 it is still pretty much hint and miss getting a Java library working without changes on Android, given that the Android team cherry picks whatever they feel like from OpenJDK for their own Android API implementation purposes.
Easily to find that out from Gerrit commits and AOSP source code.
Meanwhile, effort has been spent ensuring that 100% of ISO C and ISO C++ are available on Android NDK.
Thus out of the window goes the interoperability argument.
Nothing happens to the interoperability argument. Nothing says it need to be 100% interoperable, or else you wouldn't be able to ship an MVP for any reimplementation of an API. And hell, the official JDK isn't even 100% interoperable with it's past selves.
Maybe if Sun didn't play games with access to the TCK in the past we wouldn't be here adn there'd be a valid test for compliance that wasn't "do what the official JDK does".
Maybe if Google had bought Sun after torpedoing it, we wouldn't be having this discussion and everyone was enjoying a Go style management with Java stuck at version 6.
If Google didn't wanted to be sued (IBM would likely have done the same), their solution was to own Java instead of hoping that their torpedo would have sunk Sun's ship without a hiss.
I am not pivoting, Google has only itself to blame for their little J++ adventure.
"James Gosling Triangulation's Interview on Google vs. Sun"
Basically wanting Java as free beer, without paying Sun any money given that Java actually required licenses for handsets/embedded deployments in pre-OpenJDK days, in the not so good economical situation that they were, withdrawing them from possible Android license revenues.
That is torpedoing, regardless how Google employees, or wannabe employees play it.
Except Sun never charged for handset/embedded deployments. They charged for access to the J2ME trademark. This case is neither about trademarks nor J2ME.
That means they wouldn't have gotten any money from SavaJe like phones either.
The only people who "torpedoed" Sun was Sun themselves.
And yes, switching from an interoperabilty argument to 'they were morally obligated to buy Sun' is very much pivoting to a different argument.
> What happens to WINE if it is illegal to use the same names Kernel32 does?
I was wondering where would the Oracle win hurt most, and I think there is worse than WINE.
The Unix syscalls would have been Bell Labs’ copyright. That copyright was sold to Novell, which was sold to… Micro Focus International plc?
So this British consulting company that is, according to its website, “powering digital transformation”, could transform the digital world by suing BSD, Linux, Apple and Microsoft for tremendous sums of money and forbid them from using the famous syscalls.
I guess a given set of CLI programs may also be seen as an application programming interface, which makes all of GNU liable too.
Looks like the case was settled fairly quickly, so exactly what the claims were aren't as clear, and whether or not the API is part of the settlement depends on the exact details of that contract which aren't public.
It was very established ninth circuit case law at that time that APIs weren't copyrightable. This exact point came up today during oral arguments, with Oracle not denying it but instead saying that the terms "interface" and "API" weren't intended to apply to something so massive as the structure, sequence, and organization of the Java standard library.
Additionally, the contract is public. http://www.groklaw.net/pdf/USLsettlement.pdf Point 9C on page 14 has the university declaring that as far as they know, no AT&T IP is present in 4.4BSD, despite it clearly having a UNIX compatible API.
In addition to the specific claims and their validity, one fact remains. Oracle bought Sun for the sole purpose of suing Google. Full stop. I used to date someone involved in the case when it was just getting started. Oracle can go pound sand.
Everyone seems to have forgotten that Sun licensed Java under an open license that would have allowed Google to use these interfaces without issue, if they had met certain criteria for supporting the full Java platform. Google essential thought "Well, we have too much bloat, and these parts are totally unneeded in our platform, so we're going to strip them out."
I seem to recall Sun refusing to allow Apache Harmony's implementation of the Java stdlib to be certified, or didn't allow access to the TCK or something like that. It may have seemed at the time like trying for an official certification for Android was pointless.
And adding to that, the entire enforcement mechanism was through trademarks, not copyright. And trademarks are about the only IP construct not brought up in this case.
Thing is Google were also nasty towards Sun and helped it go under quite well. In many ways this is karma but too bad there's so much externality to it.
IIRC they were going to use the reference impl of Java but Sun wanted to inject themselves and the Java brand all over Android.
Plus Sun couldn't design a decent UI to save their lives, so Android probably wouldn't have been successful if Google had allowed Sun a large role in the platform.
> If Oracle ultimately wins, it seems like millions of programmers will have to reach for a thesaurus to find synonyms to name functions. We'll have to waste brain cycles coming up and alternative spellings of methods to stay away from copyright infringement.
This isn't how copyright works though. It's neither necessary or sufficient. If you copy an API but change the words using a thesaurus you are still copying it so it would still be infringement. If by happenstance you come up with the same wording in your API, then that would not be copyright infringement because you didn't copy anything.
>If you copy an API but change the words using a thesaurus you are still copying it so it would still be infringement.
From the previous thread I referred to, a commenter cited an excerpt from a circuit court opinion about alternative naming :
[...] Using the district court's "java.lang.Math.max" example, Oracle explains that the developers could have called it any number of things, including "Math.maximum" or "Arith.larger." This was not a situation where Oracle was selecting among preordained names and phrases to create its packages. As the district court recognized, moreover, "the Android method and class names could have been different from the names of their counterparts in Java and still have worked." Copyrightability Decision, 872 F. Supp. 2d at 976. [...]
If I take a book, say Harry Potter, and use a thesaurus to change words to their synonyms in the hopes of avoiding copyright, no court is going to agree that I can now publish Barry Otter and the Association of the Eagle as my own creation.
I don't know if that's true. At least it you wrote a story which is almost exactly like Harry Potter from scratch, without referencing the original and with none of the original characters, I don't believe this would be an issue under current copyright rules.
That's true, but not relevant to the point of the comment you are replying to. Taking a copy of an existing work, and simply replacing words with synonyms and renaming characters would still count as copying. Maybe there would be enough creativity in your choice of synonyms to make your work separately copyrightable as a derivative work, but that would still require permission of the existing work's copyright owner.
Producing a new work that happens to be similar to, or even word for word identical to an existing work, if you truly created it yourself from scratch without taking anything from the existing work, would not be copying.
As a practical matter, unless you had extraordinary proof that you really had never read Harry Potter books, watched the movies, read the plot summaries on Wikipedia, attended a party shortly after one of the books came out where everyone was talking about it, you would lose in a copyright infringement lawsuit. If you work is very similar to Harry Potter and you had access to Harry Potter, that's sufficient for the plaintiff to make their case, switching the burden to you to prove that you did not copy it.
A book is subject to veru different considerations - it has a plot, main characters, and other characteristics that you would be copying. All of these are a protected product of the author's creativity.
There is no plot in an API, no main characters, etc. It communicates matters of technical nature, and there aren't five different way of writing 'sqrt()' or whatever. It is more appropriately compares to architechtural blueprints and other technical documents.
My vague recollection of this case is that Oracle was kind of up a creek with the "java.lang.Math.max" argument, because max() itself is such a well-understood mathematical function and has been defined in numerous programming languages before Java. This put some constraints on Oracle, and thus "the name is the copyrightable contribution" became their (weak) argument. This does not necessarily mean that changing the function name (as opposed to calling interface and interface organization) would have been sufficient to avoid copyright infringement in every case (in Oracle's opinion.)
Using the district court's "java.lang.Math.max" example, Oracle explains that the developers could have called it any number of things, including "Math.maximum" or "Arith.larger." This was not a situation where Oracle was selecting among preordained names and phrases to create its packages.
Which is amusing, because Sun almost certainly chose "max" in part for "compatibility" with the C standard library.
> This isn't how copyright works though. It's neither necessary or sufficient. If you copy an API but change the words using a thesaurus you are still copying it so it would still be infringement. If by happenstance you come up with the same wording in your API, then that would not be copyright infringement because you didn't copy anything.
That also isn't how copyright works.
You're essentially asserting copyright over the semantics of an API.
The semantics of an API may (although I would argue otherwise) be protected, but if they are it would have to be either as a design patent, or as trade dress, not as copyright.
That said, even if the un-synonymized API is protected by copyright (and I would generally argue otherwise), reimplementing it must be seen as fair use, all the more so an API with renamed functions.
For a more recent example: Amazon's DocumentDB reimplements the MongoDB API. This should be allowed, even though we could wish Amazon had acted otherwise.
Here is the crux of the matter: unless there is some sort of no-man's-land between the various intellectual property regimes for software, no interoperability will be allowed except that which a vendor explicitly opts into. If copyrights, trademarks, and patents overlap sufficiently, even clean-room reimplementations will be forbidden.
We can argue about which aspects of software should be protected, for how long, and by what means, but at the end of the day there must be an unprotectable area of some kind, or we're all going to be doomed to either working entirely within vendors' vertically integrated stacks, or else implementing NSidedWheelAPIFactoryFactory() all the way down to bare metal for the foreseeable future.
I think in the case of Amazon selling hosted MongoDB calling it DocumentDB, they are actually using a fork of mongo's previously open source codebase. Prior to their license change in 2018 from AGPL to SSPL [0], Amazon would have been free to use mongo's codebase directly if they didn't need to make any changes to it.
> The semantics of an API may (although I would argue otherwise) be protected, but if they are it would have to be either as a design patent, or as trade dress, not as copyright.
Wouldn't semantics be functional and thus require a utility patent, rather than a design patent or trade dress?
Wouldn't semantics be functional and thus require a utility patent, rather than a design patent or trade dress?
The argument being made by Google (and stipulated by Oracle) is that the reason Google copied the API was for its familiarity to developers, rather than any inherent quality or functionality.
This is, essentially, a "look-and-feel" lawsuit, only applied to code, rather than UI.
That's how they're trying to make copyright work though. The protection being asserted here is over the "Structure, Sequence, and Organization" of the API.
> We'll have to waste brain cycles coming up and alternative spellings of methods to stay away from copyright infringement.
You do realize that if literally all you do is change the names and spellings then you'll still be in violation of copyright, right? Translating a book into another language (where the names and spellings of every word are different) is still copyright infringement. The fact that the names and spellings are the same just provides evidence to the judge that copying occurred.
If you just rename all the methods and their argument variables you still open yourselves up to a lawsuit because all the plaintiff is going to do is show the judge a mapping between their and your names and it will be plain as day as to what happened.
You do realize that if literally all you do is change the names and spellings then you'll still be in violation of copyright, right?
In general that is largely true. In the particular type of copyright being argued in this particular case Oracle has stated that changing the name or spelling of the methods would have been enough to avoid being in violation:
Using the district court's "java.lang.Math.max" example, Oracle explains that the developers could have called it any number of things, including "Math.maximum" or "Arith.larger." This was not a situation where Oracle was selecting among preordained names and phrases to create its packages. As the district court recognized, moreover, "the Android method and class names could have been different from the names of their counterparts in Java and still have worked."
You are misinterpreting that argument. To prove copyrightability, Oracle had to show that designing an API is a creative act and not a purely mechanical/functional one. That is the purpose of this argument: if the function would only work if named java.lang.Math.max and not work if named Math.maximum, then anyone describing the same concept would be forced to use the same name, so the name wouldn't be copyrightable. They are not stating that Google would have been in the clear if they had named it differently, they are just trying to show that Google could have named it differently without changing the meaning of the code one iota.
For example, someone writing a recipe for omelette has to say "2 eggs" simply because that's what omelette needs. You can't express it any other way, so it's not a creative act, so it can't be protected by copyright.
Java namespaces fall into the latter category, since there is an embedded graph of symbolic coordinates. The existence of Refactoring negates that it can be seen as an accidentally creative act.
Refactoring is somewhat similar to translation, and it similarly does nothing to affect the notion of copyright. A novel is copyright-able even though it can be mechanically translated into a different language.
The fact remains that APIs are creative works. This can also be seen from discussions about APIs in the industry - everyone knows that the Unix APIs are often seen as elegant while the Windows APIs are seen as ugly. The C++ people love the design of their iterators and algorithms and data structures and believe it is superior to Haskell's equivalents.
> everyone knows that the Unix APIs are often seen as elegant while the Windows APIs are seen as ugly
I think people consider the UNIX CLIs ("do one thing and do it well") to be elegant, not UNIX APIs. UNIX APIs have quite massive (and well-known) warts in them.
Sure, there is a lot of nuance - for example, the Unix CLI is very much seen as a kind of API, and appreciated mostly for API-level decisions (pipe-able commands, everything is a file, everything is text), not necessarily so much for CLI-level features (such as variable handling, looping etc.).
Also, some Unix OS APIs are much preferred over Windows alternatives - e.g. many people think fork()/exec() is much more elegant than CreateProcess(), same for pthreads vs the Windows threading model etc.
The bottom line though is that people have opinions about API design, it is clearly seen as a creative process, it is not rote technicality.
Designing an API is a creative act. An API is source code. Witness thousands of languages, all with recognizably different standard libraries, including languages like Go or Dart created by Google themselves. The problem is less with individual examples like "max" vs "maximum" or "write" vs "scribble", but more with thousands of packages, classes and methods, 99% of which have the exact names and structure as the Sun's Java ones. That is blatant theft. Google stole Java code from Sun. Shame on them.
What we need the law to do is to distinguish between copying a piece of code and using a piece of code. Just because I use your code doesn't mean you own my code too. What we need the software industry to understand is that relying on a proprietary library makes it impossible to cheaply switch your code to an alternative implementation without rewriting your own code. Alternatives exist: use software with an open license model, or shim out the proprietary library.
> The problem is less with individual examples like "max" vs "maximum" or "write" vs "scribble", but more with thousands of packages, classes and methods, 99% of which have the exact names and structure as the Sun's Java ones. That is blatant theft.
You know, it might be worth asking the engineer who wrote java.lang.Math how he came up with those names. Actually, you don't--he already answered it one of the amici briefs. The answer was that he took it from C.
In other words, taking Oracle's argument at face value means that the example API it is accusing Google of illegally copying is itself an illegal copy of the UNIX copyright, whoever actually owns that now.
Perhaps the Sun engineer did indeed copy from UNIX to some mild degree The line between "inspired from" and "copied from" is a fine line indeed. When does a term stop being proprietary and enter the vernacular of a specific profession or of humanity at large? I lean rather liberal on this question, and I hope the law will too. OTOH, what is blatant theft is for your 'original' work to overlap 99%, in both names and structure, to prior work. Google engaged in blatant theft, there is no doubt about it. We are not even talking about a derived work, we are talking about copying word for word a substantial part of somebody else's work.
Look up the names of the functions in java.lang.Math. They are exactly the names and semantics used in the libm functions. Even down to the presence of the atan2 function which computes tan¯¹(y / x).
(You could also point out that JavaScript literally lifts java.lang.Math and java.util.Date into JS code as well, down to Date.getYear returning the Gregorian year - 1900).
Almost completely irrelevant side note: atan2 is immensely useful because it actually does more than calculate the arctangent. It handles all the corner cases in converting a 2d vector to an angle. There's no chance of division by zero, it gets the answer into the correct quadrant automatically, and so on. Those things add up to an annoying series of if statements if all you have is an arctangent function.
First, this is not a 99% blatant copy. I see things on the java side that are not in the libm side, like addExact, IEEEremainder or nextDown. I see things on the libm side that are not in the java package, like fpclassify, gamma or jN. I see things that have been adapted to match java conventions, like copySign vs copysign. The Jaccard similarity index appears to be pretty far from 1, whereas it is a perfect 1 in the case of Google. The perfect 1, up to keeping the 'java' in 'java.*', makes it a 'blatant theft' in the case of Google.
Second, unclear what the legal status of libm is. It appears to implement a standard, thus is legitimate to ask whether the set of implemented functions and their names are the original contribution of libm authors, or are derived from the standards. Generally, if one wants to implement a standard, one needs to acquire the rights to do so, usually in the form of a reasonable fee.
Third, if there are significant overlapping parts that are the creative work of libm authors, and they can establish a prior art claim, they are entitled to seek fair compensation from Sun / Oracle.
PS. Re: atan2, wikipedia: 'The function atan2(y,x) first appeared in the programming language Fortran (in IBM's implementation FORTRAN-IV in 1961). It was originally intended to return a correct and unambiguous value for the angle θ in converting from cartesian coordinates (x, y) to polar coordinates (r, θ).' Perfect example of a term that arguably migrates into the common technical vocabulary over decades.
> Oracle has stated that changing the name or spelling of the methods would have been enough to avoid being in violation:
“Oracle has stated” doesn't make it consistent with the law. Sure, the Supreme Court could create a new rule in this case which would make it true, but there is no existing legal rule I can ser that would make thesaurus substitution not infringement of something that was otherwise infringement.
Oracle proposes a change for the sake of uniqueness, but uniqueness is not copyrightable. And if non-copyrightable change is all you can reasonably do, then there's little if any room for creativity. Also it's obvious `max` is not a creative, but a traditional name for such function, not to mention one can't copyright a common word in wide use.
There's no technical way to not copy the interface, especially method names, and imagine what happens when you implement an interface: it's copied verbatim.
IIRC Judge Alsup (the original judge, and the only person in this whole shit-show who knows anything about programming) ruled against this, as he determined that there were only so many ways to write a range-checking function. He said it was entirely plausible that the Google developer would have come up with the exact same function independently.
> IIRC Judge Alsup (the original judge, and the only person in this whole shit-show who knows anything about programming) ruled against this, as he determined that there were only so many ways to write a range-checking function.
No, it was found to be a copyright infringement in the first trial; it's one point on which Oracle sought to have the district court upheld and Google sought to have it overturned in the original set of appeals and cross-appeals. (While on many other issues they split the other way.)
> No, it was found to be a copyright infringement in the first trial
I believe GP is correct. The jury found it to be infringement, but then Alsup ruled it wasn't copyrightable in the first place, so the jury's finding was irrelevant.
edit: oops, sorry, didn't realize the rangeCheck scope of this subthread
> The jury found it to be infringement, but then Alsup ruled it wasn't copyrightable in the first place, so the jury's finding was irrelevant.
No, the final judgement in the first trial by Alsup found the APIs weren't copyrightable, but that the literal copying of rangeCheck and some other compiled files was infringement. (For which no damages were awarded, by stipulation of the parties, I think because everyone was planning to appeal everything and didn't really want to wait for damage calculations to get that ball rolling.)
I used to know a very bright chap who refused to use meaningful identifiers - his argument was mainly that you could never capture enough information in an identifier to be really accurate so you shouldn't even try.
Nice chap, but fortunately he was a school friend and not a colleague!
The problem isn't that programmers will have to get more creative with naming, it's that it will be fundamentally impossible for pieces of software owned by different entities to communicate over shared names without an explicit license agreement. That's a much, much bigger deal.
It's not just the names, it's the structure as well. Oracle is implying that the structure (heirarchy) is also a signifier of the API. You can't actually get around that if you're trying to mirror an API but do a white room implementation of the underlying code. It would still be considered illegal if the SCOTUS decides for Oracle. You would still have to license or hope you didn't get found out.
I wonder how a meaningful discussion about namespace trees and API spelling takes place at the Supreme Court considering the background of the justices.
It still requires domain-specific knowledge and there are vested interests from both sides. I'm afraid because the world has little to gain and much to lose from the outcome of this case.
These people are experts at getting up to speed on diverse topics and have amazing teams clerking for them and a huge bench of experts to call on. I'm sure the domain-specific knowledge will be fine although the vested interests will clearly be a problem.
I have never been involved in a US Supreme Court case but back in 1999 or so I was asked to prep a barrister in the UK on the guts of TCP/IP. I literally jumped in a black cab at short notice with 6 or 7 volumes of W. Richard Stevens and spent an afternoon showing him and a few others from his chambers packet dumps and TCP state diagrams and drawing some diagrams of my own showing what a webserver, browser does, how caching works, etc. The next day using my information synthesized with some really archaic law about what is and isn't a document he issued his opinion about where particular actions occur (and therefore what legal jurisdictions apply) when someone does something on a website. It was extremely thoughtful and nuanced and literally a day earlier he didn't even know what a webpage was.
This doesn't really surprise me. I think it's a bit of an ego-condition that the tech industry believes because only tech people understand technology that only tech people should be allowed to set policy on it.
In reality, technology (and technology companies) mirror their predecessors in other industries. And often abuses of copyright or antitrust by tech companies really isn't much different than the actions of companies decades ago, just obscured by a layer of technology magic.
Of course they are smart people but they are also quite backwards when it comes to technology and I doubt they would take the time to learn the real differences between APIs, code, algorithm implementations vs theory, etc. They will probably try to use a car analogy in their final arguments and rulings.
Especially since there's no actual "tech" in the discussion here. Since Oracle's claim is that Google's use of the Java APIs wasn't to provide compatibility to existing software written in Java but to have a familiar language for Java developers it becomes a novel but normal copyright case.
Do you wonder the same for an abortion hearing or a sanitation case? The court system can and must decide regulations on many things they are not personally experts in, and usually does so quite successfully.
No, I don't because I'm not an expert in those fields. To be clear, I'm not suggesting that they can't understand the subject matter or that they need to be experts in it, I'm just curious about how much technical detail is communicated and how.
I would assume a great deal in what I imagine are the many expert witness reports that both sides have submitted.
The one I helped write an expert witness report for a technology-related case, there was quite a bit of technical detail in it (although it was written so as to be intelligible to a non-specialist).
The problem for Google is that "compilations" in copyright law may be considered copyrightable even if the underlying data being compiled is not. The legal requirement is that the data needs to be "selected, coordinated, or arranged in such a way that the resulting work as a whole constitutes an original work of authorship". (https://www.bitlaw.com/copyright/database.html)
As an example, individual recipes are generally not copyrightable, but if you compile a set of recipes and publish them in a cookbook, the cookbook itself would be copyrightable.
As applied to Java, even if individual method signatures like max/min/split/replace/delete/etc might not be copyrightable, the fact that you've organized those specific methods into specific classes named Math/String/File and then organized those classes into specific packages named java.lang and java.io might meet the threshold for copyrightability as a "compilation".
While it would likely not be good for the software industry for reasons discussed in this thread, I would not be particularly surprised if the court ruled in favor of Oracle on this particular subject.
What if Google copied the name of Oracle's car and stamped it on the back? What if Google also copied the name of the in-car entertainment system and put all the buttons in the same place and stamped the same name on the dash? What if the shape of the car was exactly the same, and was only available in the exact same colors as Oracle's car? What if Google opened a car dealership next door to every single Oracle dealership with giant signs that said their cars are effectively interchangeable?
I don't think that's a good analogy at all. A car's precise width is not part of its interface nor a part of its design anyone particularly cares about. Its interface is more like, the design of the UX... how the steering wheel, dashboard, etc. look and feel. If a company copied those but changed everything underneath so that people could buy a cheaper alternative without seeing a difference on their usage... I don't know, is that actually legal?
The car's width is absolutely its interface with respect to roadway interoperability.
We aren't talking about user interfaces here. This lawsuit does not involve UX. We are talking about interfaces between functional components. The analogy is spot on.
The interoperability width is already set by the road... you're copying the road at that point, not the car.
The lawsuit involves UX for a software framework. Which its API constitutes. The user happens to be a developer here and their usage is software development.
And this is why Google had to copy the interface -- otherwise their runtime would not operate with other existing products. As you can see given your example, the analogy is a perfect fit.
Your argument that the copying is once-removed is unfortunately irrelevant to copyright law.
What does "1 inch narrower" mean to you, in the context of this analogy? Are you suggesting the interfaces have different names? Different sized arguments?
None of those things would work.
Besides, creating minor differences do not solve this problem as they would still be derivative works.
> What does "1 inch narrower" mean to you, in the context of this analogy? Are you suggesting the interfaces have different names? Different sized arguments?
Your question is exactly my point. I'm suggesting what I said earlier:
My proposal => that you chose to make the door handles six inches because of UX, and Oracle showed up and said they made theirs six inches before you did.
You can't seriously suggest copying the width of 1 door handle is equivalent to copying all of the Java API, right? I don't think if Google provided an alternative for 1 function it would be in this lawsuit. Your analogy is just a tiny portion of the alternative I already portrayed: they copied the entire structure of the framework. Copy 1 door handle, 1 steering wheel, 1 precise dashboard design, 1 glove compartment, etc. and I feel your analogy would result in a lawsuit just the same?
(For reference none of this is meant to reflect my position on what the law actually is, or should be. I'm just considering analogies here.)
The issue is that in engineering there are certain patterns of implementation that are simply converged on.
Upholding the API copyright would be like giving Craftsman grounds to sue Ryobi for manufacturing circular saws because Ryobi combined a power cord, an electrical motor, a toothed circular blade and a housing; a state of affairs that only seems even remotely plausible to endorse because source code is inherently a read product.
You look at it and see an authored work. I look at it and I see an n-dimensional turing-space relationship diagram as expressed through transform functions.
And last I checked, you could patent some math(RSA), but not not copyright it. Eventually it's just prior art.
This is where I think a lot of people are talking past this case. If you use the API surface area for the purposes of interoperability with existing software then you're covered and it's not infringement.
If you use the API surface area for your own software because you like the design, copying it is easier than coming up with something new, or you want to provide a familiar programming environment to developers then you're looking at infringing.
> If you use the API surface area for the purposes of interoperability with existing software then you're covered and it's not infringement.
Google did that: for compatibility with existing Java tooling, which is software.
Sure, Java apps aren't, unmodified, compatible with Android, but the compatibility makes tooling and intermediate libraries compatible, which is a functional, interoperability concern.
Google tried to argue for fair use under the idea of interoperability, but the (few) intentional differences from Java that prevent most Java programs from running unmodified on Android pretty much bombed that case...
Note that Google won both the jury trials (first on not violating copyright, and then on the violation being fair use after the first was overturned on CAFC).
In other words, Google won on most or all of its arguments at the jury trial level, and CAFC kept overturning all of its arguments. The sentiment I'm getting from the oral arguments is that SCOTUS is leaning much more towards "CAFC is off its rocker" here.
> With respect to Oracle’s claim for relief for copyright infringement, judgment is entered
in favor of Google and against Oracle except as follows: the rangeCheck code in TimSort.java
and ComparableTimSort.java, and the eight decompiled files (seven “Impl.java” files and one
“ACL” file),
And here's Oracle’s reply brief in the appeal; the relevant part on this issue is under the heading THERE IS NO “DE MINIMIS” DEFENSE TO COPYRIGHT INFRINGEMENT.
Distinction without a difference. My code is an interoperability layer between making a computer do a particular computation and other developers or composers of software.
Looking at an API and going "you could do this any other way than ours" is absolutely nothing more than a fundamental deconstruction of the entire field, at which point it's just Math. You're wasting everyone else's time. No one gets to copyright 2+2.
I'm not shoving in 3 API layers to represent "Math.max()".
Google is making this case, we'll see if the judges buy it. Just because porting Java apps to Android is easier because Google copied the API doesn't suddenly absolve them when it's Google's intention that will decide this case.
> when it's Google's intention that will decide this case.
Why do you presuppose to know the legal rule that the Supreme Court will articulate in its decision? I mean, you seem to presuppose that the Court will uphold the Federal Circuit on all contested questions of law and only reconsider whether the decision on the facts is reasonable, which is...mighty presumptuous.
It's quite conceivable that Google could win on a more fundamental ground, since the question of whether the API is even protected by copyright or unprotected as a functional element (which also does not turn on Google’s intent) is a love issue in the appeal. They win on that, and the Court doesn't have to touch anything else.
Even if they do need to address the fair use question because Google loses on copyright ability, the Court a lot will turn on the standard of review and the Seventh Amendment as to whether the Court is really probing Google's intent (de novo review) or merely probing whether any reasonable jury could have concluded that the use was fair, as the actual trial jury did here, preserving the right to jury trial. I would expect the latter, the Federal Circuit seems to have gone completely off the rails invoking de novo review to overturn the jury verdict.
That seems to be what a lot of legal folks are speculating. That an 8-person court will find essentially technical legal reasons to overturn the appeal and essentially punt on making a major copyright ruling one way or the other.
A ruling overturning the CAFC on the basis that fair use is a fact issue for the jury not subject to de novo review on appeal would still be a major (though not transformative, since outside of the CAFC in this case that seems to be how it has historically been treated) copyright decision.
And how will you use that API? If it is based on things like headers, you can no longer have a copy of that header to refer against. The compiler can no longer read that header into memory, as that's a copy.
The use of an API will be copyrightable too. Now you understand the depths of the disaster this will be.
> Google didn't copy any of Oracle/Sun's Java source code base into Android Java. Oracle lawyers acknowledge this.
You're saying the textual contents of the interfaces that define the APIs are not part of the source code base? Of course Google copied them, or a nearly identical paraphrase of them.
I'm not quite sure what Google's legal theory is. Listening to the oral arguments this morning certainly didn't make that more clear to me. But I don't think it includes redefining what we mean by copying text.
And interfaces, in common parlance, are certainly lines of code.
Nor do I think Oracle's argument is that no one else can define interfaces that use the same words as in the Java standard library interfaces. read, write, get, put, etc. did not become Oracle's property by virtue of them being used as method names.
I have a bit of trouble with the concept "the threshhold of too much", too, as it applies to this case. Google copied or paraphrased essentially _all_ of the text of interfaces they used from Java libraries.
>I have a bit of trouble with the concept "the threshhold of too much", too, as it applies to this case. Google copied or paraphrased essentially _all_ of the text of interfaces they used from Java libraries
Oracle is trying to argue that just because you intentionally left a bunch of implementation detail out because it isn't relevant toward transforming something like the Java API's to a new context, it should still count as copyright infringement because they Still yoinked everything they did take... Which seems circular to me.
Google's point is "no shit, Sherlock, it wouldn't be Java otherwise." Oracle is couching this issue from the perspective that Google should have invented a completely New language and runtime, absorbing the same costs of them doing so. Google argues, on the other hand, that what they made, in order to confer to the syntactic structure of the programming language known as Java, dictates the duplication of the organization of the fundamental functions, packages, and namespaces, and that furthermore, Oracle has no standing to call them on it, because those APIs are a necessary prerequite to drive the operation of the JVM, and are by definition the only way to do it, so that API constitutes a method of operation.
Oracle's argument isn't legally circular or anything like that. It's actually very strong, which is why it's problematic: the industry status-quo consensus that you can't copyright APIs has no obvious basis in copyright law beyond the notion that you can't copyright "facts".
Is an API a collection of facts? I would hate to be a lawyer tasked with arguing this one in front of the Supremes. Programmers sweat bullets over API design, an API is very obviously not a mere collection of facts, it's a creative work. Copyright law protects creative works. Hence, Google's problem.
An API is not a mere collection of names either. The Java API is defined by the specification, which is contained in the JavaDocs. Thread safety rules, when callbacks are invoked, what sub-types can be passed into a parameter, all these are a part of the API as well. Strip out the source code of the methods but leave the types, prototypes and JavaDocs and you have the Java API - it's been done and the result is still huge.
Google's point is essentially one of convenience; the industry has never recognised APIs as copyrightable before and shouldn't now. This is not a legal argument at all so I am mostly expecting Oracle to give them a solid thrashing, because the SC is meant to interpret existing law, not simply agree to whatever one of the parties thinks the law should be. And other than declaring API reimplementation to be fair use, there's no obvious legal escape route to make APIs non-protected.
It's thus interesting to consider what happens if or when Oracle win. In the short run a lot of disruption, especially to projects like Wine and maybe WSL.
In the long run it's harder to say. Something unprotectable would have become protectable. We might see, for example, the birth of companies that specialise in nothing except API design. Today such a company would be unviable because there'd be no way to protect or own the results. You can imagine that this would occur in the same way that specialised agencies do graphics design, translation, logo design, API implementations, etc. This might lead to higher quality APIs across the industry: a difficult to anticipate side effect of expanding IP protection. It would also presumably reduce competition as it became even harder to compete with lockin via reimplementation of APIs. However, doing that is relatively rare today. I can't say for sure that the (small) loss of plug-compatible competing implementations of products would be worse than a hypothetical increase in API quality from allowing specialisation in it.
The easiest solution if the software industry wants to preserve the status quo is to just lobby Congress to amend the laws to explicitly distinguish interfaces from implementations.
No where in the copyright statute does it explicitly call out a software API as being copyrightable. The representation of one may be, but not the API itself extending copyright protection to APIs now is nothing less than legislating from the bench. It should be a legislative decision, not a judicial one.
> You're saying the textual contents of the interfaces that define the APIs are not part of the source code base? Of course Google copied them, or a nearly identical paraphrase of them.
Well, they aren't part of the implementation, since they just describe the interface. Google's theory is that interfaces, being needed for interoperability, are not protected by copyright. Google's alternate theory is that, even if they are protected by copyright, using them is fair use.
> If Oracle ultimately wins, it seems like millions of programmers will have to reach for a thesaurus to find synonyms to name functions.
I think you are a bit off the mark on this line. (mostly agree with the rest of your post)
Google's goal was to make a white-room implementation of java that was 100% api compatible. This was explicitly to avoid licensing Java while still being Java compatible.
I don't think this is true. Google doesn't let you run java that was compiled for the JVM. They have an entirely different mechanism that is not the jvm for their java code to compile to.
All they did was port the language to a new compile target. When you port a language over you also port the standard library or at least the parts that you need. This is standard across the industry. Every language implementation does it. What Oracle is trying to say is that you need a license to do it and that is a dramatic change in the industry practice right now.
It's also short sighted. If Oracle wins then you'll need a license to implement java the language (as opposed to the JVM) anywhere. Short term Oracle get's a pile of money. Long term everyone stops using Java. But then again if you are Oracle, with it's current values, Java's only real value is short term money gains. It's hard to make money on a programming language the way Oracle prefers to operate so this may be the best they can do.
Or better yet let's not talk about the people at WG21, but instead their employers (and whoever acquires their employers in the future) and what is in those employees' contracts about IP they create that is owned by those companies.
Let's compare this to a completely different field: cookbooks.
Recipes themselves aren't copyright protected. However, specific instructions for the recipes are protected.
In addition, though individual recipes aren't protected, a collection of recipes is protected.
There is a line, though, between copying a few recipes, and an entire collection. That line is not easy to define, but that doesn't preclude the existence of such a line.
So – is an API considered a single recipe? Or is it a "recipe collection?" That seems to me to be an important distinction.
If you were to copy one set of API function names that cover a limited area, then it could be argued that you used just one "recipe" and that it would be OK. However, if an entire collection of API function names across a very broad range of categories was copied, then it is harder to argue that you didn't copy any entire collection, and not just an individual recipe.
I think if Oracle wins, what really needs to happen is we need to begin lobbying congress to explicitly exclude APIs from copyright protection. I think that this could definitely work, particularly since so much software relies on APIs not being copyrighted.
Unless the first marriage is viewed as invalid in the second jurisdiction (which simply occurring in another jurisdiction usually won't do), or the second jurisdiction allows polygamy (in which case, it doesn't need to be a separate jurisdiction, anyway), that generally is insufficient.
If Oracle ultimately wins, it seems like millions of programmers will have to reach for a thesaurus to find synonyms to name functions. We'll have to waste brain cycles coming up and alternative spellings of methods to stay away from copyright infringement.
Or the companies that the developers work for pay the original creator of the API, which is the solution Oracle are angling for.
It might also be worth mentioning that this case is first and foremost a big money power play (arguably even with abuse of the legal system), between two immensely powerful businesses (each of which probably deserve to be called a criminal enterprises, but hey .. this is America), and very little about the merit of their respective arguments.
In other words: both primary care about winning the case. No matter how they get it done, or whatever the fallout/consequences will be for anyone but themselves. Arguably that is fine for any company, since their sole responsibility is to look after itself. But the legal ramifications of their (legal) actions can extend far beyond that, for which I certainly consider them and the US legal system responsible, collectively.
I sincerely wonder sometimes, that besides the potential damage many do recognize as a fallout of this court case, how many people realize that mud fight between two way-too-powerful sandbox bullies may end up being responsible for making the USA a pariah within the landscape of future software development?
Or does everyone believe that if this goes sideways, that the rest of the world will just respect this "funny logic" and all go with it?
In fact, how many Americans even realize that the increasing radicalization and absurdity of their intellectual property rules will inevitably harm the USA big time in the long run? Or does everyone still think that the USA will remain the center of everything and the only one dictating the rules?
Things like these do not happen in a vacuum. The rest of the world is watching.
> Those in Oracle's camp say if its copyright is not protected, that will discourage innovation.
Look at the way YouTube Content ID encourages innovation and then imagine GitHub Content ID.
“Your repository contains 3 copyrighted method calls. You’ve been issued a copyright strike.”
I’d love to see every open source repo on the internet go private for 1 day as a demonstration of what could be lost if copyright is allowed to weasel its way into APIs.
GitHub and NPM should give users the option to block their repos for a day. A bazillion failing builds would open some eyes IMO.
Then imagine the outrage from European companies and users getting hit by this ludicrous US copyright thing that doesn't apply to them (the European court rejected oracle claims long ago).
To add to this, EEA members still have to comply by EU laws. Norway and Iceland are EEA members. Switzerland is not, but it has made a separate deal with the EU that has almost the same content as the EEA deals (idk the differences in detail).
It applies to them the same way the GDPR applies to American companies: If they have sufficient money in the US which can be hit by a judgement, it applies.
Wine's userspace being legal is probably what keeps the gamers from just running the available userspace source code from Microsoft. I doubt getting it banned would be something Microsoft actually wants.
It's an interesting perspective. Microsoft already promised not to harm Mono, so if the lawsuit is won by Oracle, it's certainly possible for Microsoft to promise not to harm Wine as a PR move without addressing the actual issue, and this strategy can actually work better for Microsoft to keep its control on APIs! It can be similar to how Apple had broadened the scope of its repair program to weaken the Right to Repair movement.
But unless Microsoft actually embraces Wine, that would still leave the project in a weird legal gray area. Will e.g. Valve want to support the project, knowing that at any moment Microsoft could theoretically have a shift in strategy and become litigious?
anyone who believes that GPLd dynamically linked libraries impact code written to use them effectively believes that APIs can be copyrighted. (ex: the FSF believes this).
Those two are complete different concepts within copyright.
Oracle claim is that google copies of header files requires copy right permission, with google saying that header files are either not protected by copyright or that using them is fair use.
FSF claim in regard to dynamically linked libraries is that using them in a work creates a derivative work. For C code, software without its dynamically linked libraries won't even load past the linker, and in their view, a judge/jury will see the program as a single work rather than two independent works.
This court case will not define what is a derivative work or when two combined works should be seen as independent of each other. It may explore the limits of what is copyrightable and what is fair use, which is interesting in terms of API's and compatibility but less so for defining the limits of the GPL as an copyright license.
You don't just dynamically link a library. You link it and then use its API, it's precisely the using of the API that creates the derivative work (if you accept FSF's position). I don't see how e.g. calling dlopen() on its own but not using the API could create a derivative work any more than calling fopen() does.
The original case for RMS when he created the position for dynamically linked libraries where when apple created an GCC version that had a Objective-C frontend. RMS initially did not think this would be covered by copyright but after talking with the lawyer Eben Moglen he got the following explanation: A judge would unlikely see it as an objective-C fronted as an independent work that is talking with GCC, but rather just a compiler. That compiler would be the work, and thus a derivative work since it combines the GCC code and the objective-C fronted.
Nothing in there is about API's. There is also nothing about linking. It just about what a judge would perceive as being "the work". FSF however do seem to have a policy about enforcing the license at the technical distinction of linking, but that is just a policy decision based on where they think a judge would likely side with them. Apple were free to go to court arguing that it is not a compiler but rather different independent works simply communicating with each other, but they chose not to do so.
hmm. I had a discussion about dynamic linking with Eben years ago, and my memory (hazy as it might be) what that he implied that it was coming from the FSF, not from him (at least the libreadline argument). But as I said, this was a long time ago. (probably 15 years at least).
Apple could have decided it wasn't worth the fight, i.e. the benefits of thei front end being GPLd or not being GPLd in the end made no difference, so no reason to fight it.
I heard that version about Apple and the Objective-C frontend case from Stallman during a talk at Gothenburg if I remember right. He consulted eben moglen and based on that change his opinion. It is possible that Eben consider the decision to still be Richards, which technically it was.
When it come to apple I strongly suspect there are a few things companies like them will try avoid putting lawyers and money on. What is the definition for derivative work and what is the definition of fair use. If you do want to stake money on that you likely want aspects of the case being stacked in your favor, and basing the majority of a product on a GPL code base is not that. A single function call to libreadline would likely be more favorable, but a company like apple would just rewrite such trivial amount of code.
You may be right, but can you supply a citation for this? I believe many open-core software vendors work around this idea by doing exactly what you suggest: creating an API barrier where the proprietary software lives on one side and the GPL'd software on the other. It requires some care so you don't cross GPL'd software into the proprietary side, but it's fairly common. I think the Linux Nvidia GPU driver works this way.
It's called a GPL condom, and that's a bit different in the end in that the GPL mandates GPL'ing code that links against GPL symbols. It's more of a contract than copyright. If you want to use these in your code, you must GPL, or reimplement at your leisure!
That's less Copyright in the sense that it's mandating the relinquishing of monopolistic control of the work product in question to the public. Oracle wants the opposite. They want Java used everywhere, and the right to sue anyone who does anything too similar to it too.
This is absolutely an act of monopolistic market shaping. No smaller firm would ever have utilized this nuclear option of a lawsuit given the widespread damage this could potentially cause to the entire software ecosystem.
This would honestly be enough to get me moving completely out of Software if the Court screws the pooch on this badly enough.
I'm not spending the rest of my life debugging code that as a matter of fact must be run through obfuscate steps to avoid copyright liability.
I agree that many create that API barrier (ex: ZFS on Linux). Those that argue that ZFS on Linux is legally problematic agree with the FSF's definition (which I would argue leads to the belief that APIs are copyrightable). Those that think ZFS on Linux is on a fine footing believe that APIs aren't copyrightable and one can create a shim to decouple your non GPLd code from GPL "libraries", especially if the coupling that ends up happening is never distributed as done by the end user.
Yes, that's exactly what I was looking for. Thanks for the read, it was very interesting. I thought this was a settled matter, but it looks like I was wrong.
if I distribute the GPL library (say libreadline) with my app, I'd probably agree with you.
If I expect the end user to have libreadline installed on their machine (from debian / redhat repos, and for argument sake Debian/Red Hat/et al aren't distributing my app), I think I'd disagree. I'm not distributing any GPLd code.
I think its a bit more complicated if Debian/Red Hat are distributing my non GPLd app that links against a GPLd library that they also distribute, but aren't really distributing them together. The reason I say this, is because even though they are "distributing" both "together", we wouldn't say that GPLd code and BSD code that they "distribute" "together" infects the BSD code.
I might also agree that its not exactly the same issue, but I do think it should make one think about it.
If you explain to a judge the difference between distributing a library and app code to the user, and expecting the user to download the library themselves and then you combine the app-code and the library afterward, will they care or will they see the two methods as being practically identical in terms of forming a single derivative program out of the library and app-code.
In the past people argued that streaming could not be copyright infringement since the recipient never received a copy of the movie. Courts however did not see much of an meaningful distinction between streaming a movie and downloading a movie since the experience from the user were close to identical and the perceived impact on the publisher were also identical.
During a conference I recall a lawyer explaining that a judge does not like arguments that try to use tricks to walk around laws. It makes the judge look like a fool and that annoys them.
except in the case of libreadline, its highly likely that any Linux user (i.e. bash depends on it) already has the library on the system. I'm not distributing it.
But lets get into the weeds a little. Lets say I am distributing it according to all definitions. I'm allowed to distribute GPLd material. I'm allowed to distribute non GPLd material. I'm allowed to distribute them together even (say a linux CD without the GPL impacting the rest).
The question the judge would have to answer, is the non GPLd portion a "derivative work" of the GPLd portion and is that derivative work being distributed. I'm not so clear that this the case unless one really believes that APIs can be copyrighted (then it is clearly the case).
As a simple example: lets say we accept that it is a derivative work, but then lets say I made a replacement version of libreadline that was ABI compatible (but not feature complete) with the original one, so hence my program can be dynamically linked against both but it will be a better end user experience if they use the GPL version.
To provide a somewhat more concrete thought experiment (concrete as an ABI copatible reimplemntation under a different license, thought as its making up a fact):
imagine microsoft dual licensed windows with GPL and not and they believed that if one wanted to ship a non GPL program one had to pay them a license fee to keep the program not GPLd. Now, as wine has implemented the required APIs to run my program, can I ship a non GPLd program where I refuse to license the right to be non GPLd from Microsoft that will still run on Windows? Does it change because wine exists (i.e. the answer would be different if wine didn't exist) and if so why? This case isn't to nitpick how windows is different than libreadline or the like, but just as an example of ABI compatible non feature complete implementations can exist.
> The question the judge would have to answer, is the non GPLd portion a "derivative work" of the GPLd portion and is that derivative work being distributed.
Technically the derivative work is the combination of the two, not just the non-GPLd portion. Part of the argument that a lawyer would have to do is to define what "the work" is, and arguing distinction in linking technology might not be that great strategy to an non-technical judge or jury. If you present a video player what people likely will see as the work is the video player, not some independent code, independent glue and 20-30 independent library dependencies. As programmers however we might see things a bit different in the same way a painter will look at paint on a canvas.
However I would agree that if there exist multiple interchangeable libraries the argument for two independent work seems to be much stronger. There are for example multiple libc implementations, and for those one could make a case that a program and its libc dependency does not create a derivative work. In practice however I doubt such argument would be much of a benefit in real GPL infringement cases.
The wine project has a rather strong fair use clause regardless of the outcome of this court case, since it would be a rather difficult argument for Microsoft to argue that wine has caused considerable commercial damage. Basically every point of fair use is applicable here, from "Purpose and character of the use", "Amount and substantiality", "Effect upon work's value" and additional values like acknowledgement of the copyrighted source (if the API is copyrightable). Wine is a compatibility layer, not an re-implementation. Courts would naturally have to consider if that distinction is relevant but I suspect they would have a much easier time than java on android.
I think there were some legal fighting over PHP and the Mysql client over that exact issue. PHP generalized their interface and was deemed not derivative, but I don't know what kind of judgment it got.
> If I expect the end user to have libreadline installed on their machine (from debian / redhat repos, and for argument sake Debian/Red Hat/et al aren't distributing my app), I think I'd disagree. I'm not distributing any GPLd code.
Well, IANAL, but I fail to see how you are bound by the GPL in any way on that situation.
There used to be a market of proprietary software patches, that fixed stuff the software creator didn't bother changing. AFAIK, nobody ever contested its legality until EULA came and made it illegal to the end-user (instead of the distributor). There is a famous guy who sells proprietary security patches for Linux, isn't there? Your example is much clearer than patches.
The situation of RedHat distributing both isn't as clear.
I think I'd personally put the line a bit farther. If you distribute libreadline, that would be fine without GPLing the main program. If you make any check to verify that you are running a specific version of libreadline, then that is not fine, because you are preventing me from replacing it with a different version.
This is a complete dramatization. Are you copying 10k lines of code from a licensed code base into your project without permission and using it in your commercial product?
Github projects already should strive to use correct licensing, and comply with the license of code they use. There is nothing new here.
You don't understand what this case is about. This is about copyrighting API descriptions. Not copying code, but reimplementing an API that someone else created. Think about how many people created each part of the various web APIs. Is XmlHTTPRequest now owned by Microsoft? Who invented the Blink tag? Who owns which parts of the SQL language? The entire software industry is built on the idea that APIs are not copyrightable. If you thought software patent trolling was bad, buddy, you ain't see nothin' yet.
hehe this is the correct answer. basically if i make my own FileWriter class and choose to name one of the methods in that class "write()", then I'm infringing on Oracle XD
Using String as a ProgType(tm)? That's a paddlin'. We use CharGroup around here, which we are willing to license for a small fee. For a limited time, get 10% off when you license three or more ProgTypes(tm)! Indemnification licensed separately. Contact our enterprise relations desk for details.
And then when you contact them it goes to voicemail, they call you back 9 times 3 days later and sell your email address to everyone under the sun :)
OH and then when theyre about to drop in stock price because they dont know how to deliver valuable products, they use the US government to force other companies to buy their product otherwise the US government will kick that prospective customer out of US markets ^.^
This is why clear copyright and licensing is so important. Unless something is in the public domain, don't use it unless you have permission.
> The entire software industry is built on the idea that APIs are not copyrightable.
The entire open source movement was built on copyright (ala FSF and the GPL). So this doesn't even make sense. It's not anarchy as you imply and copyright has a purpose.
Also, copyright is far more limited than patents. Patents are dangerous because it's like claiming ownership over a mathematical formula that anyone can derive. It's completely different.
11k Lines of code seems like a lot especially if you're insisting that it was just wholly ripped out of an existing codebase but that isn't the case here at all and even Oracle make that clear in their analogy:
>It says what Google has done is like taking key parts of those books — chapter titles, character names, the first sentence of each paragraph — writing a new book, and selling it.
If you're reimplementing APIs as Google has done then at some point you _need_ to copy the structure of the existing API, the method signatures, the names of the methods, the descriptions of what they do, etc, and while you may be able to dig out a thesaurus to claim enough original creative work at some point it's all for moot because there's only so much you can do before you'll start infringing upon Oracles creative expression of their API which severely limits what you are able to do with it.
If Oracle wins this case it will have huge implications for any reverse engineered work like Wine or graphics drivers where such projects will cease to exist, because it won't actually matter if it's 100% your own implementation as any interface to existing APIs or hardware _will_ infringe upon other companies copyright.
As far as Youtube Content ID goes it doesn't actually matter if it's 3 seconds or 3 minutes of copyrighted work, if it's matched then Youtube will let those companies claim revenue from your video which may be an hour long. The alternative here is the legal system and courts which may absolutely agree that 3 seconds of use in an hour long video is fair use, but you're still going to end up in court to defend that usage. It's unlikely that Oracle has enough sway to force Github to implement a similar content matching system but if they did it doesn't really matter what threshold the courts set for fair use for reimplementing APIs just like it doesn't matter for Youtube, best make sure all your repos don't use something like XMLHttpRequest() or your repo may disappear, and of course if Oracle doesn't have the sway to force Github into implementing such a system you're still going to have to go check through all your your repos because if they feel you've infringed upon their creative work they'll be able to issue takedown requests and your only recourse will be through the courts.
I'm not sure it is. Given that an original API might have a single method with the same signature as one used in a copyrighted API or the malicious actors we have in this industry, I can see the problems with YouTube Content ID coming to GitHub.
I think it is quite likely that we as a society would be better off without any kind of copyright or IP.
This might prevent some of the parties doing huge upfront investments in some of the projects, but if we learned something from OSS and, most importantly, Linux is that gradual and tiny improvements over 30 years can compound to a behemoth that eats any commercial solution for lunch.
I am not sure I agree with this statement in the absolute. I think about art, and artists as a musician myself.
One advantage of copyright is that it does, indeed, give artists recourse when people use their works without compensation. The photographer whose picture was copied and pasted onto an advertisement. The musician trying to sell their first album.
You could argue that litigation is too costly for an individual, which may be true, but this is one reason artists choose to sell their images via Getty. They gain access to a marketplace, and Getty handles licensing and enforcement, which makes it easier for artists to be fairly compensated for their work.
This isn’t absolute either: there is enforcement too aggressive (ask any Youtube creator), or limits too long (Disney).
But I cannot help but think that, with no copyright whatsoever, then the little guys will have a harder time protecting themselves from folks who would otherwise like to use that art without compensating the creator.
The truth is somewhere between your statement and parent's, in my opinion.
Copyright is necessary but the laws today are draconian and far too extensive. For works since 1978, copyright lasts for the entire length of the author's life, plus an additional 70 years. The "Mickey Mouse" protection act (https://en.wikipedia.org/wiki/Copyright_Term_Extension_Act) increased this even further for some works.
There's a need to allow artists and writers to make money from their creations and not just get their work instantly reproduced by pirates. At the same time, it's in the public interest for their work to become widely available after a short period of protection. I don't know exactly how long that period should be to maximally benefit society, but 15 years sounds a lot more reasonable than life+75 years.
It's absolutely absurd that Arthur Conan Doyle's distant ancestors can today be suing people for creating derivatives of Sherlock Holmes, a literary character conceived in 1887. Sherlock Holmes belongs to the public, not some greedy relatives trying to leech a living from him.
"There's a need to allow artists and writers to make money"
The current system does not satisfy that standard. Artists and writers don't make money due to far-reaching copyright. Musicians make money by selling tickets to concerts and contract performances. Journalists make money from newspaper pay-walls and advertising.
Your music argument is plausible, but the journalism one doesn't hold water: if there were no copyright, it would only take one paywall subscriber to copy the contents to a paywall-free site (e.g. wsj.com -> freewsjarticles.com), and poof: journalists aren't making money anymore.
I used to work for an education-resources publisher that had a problem with lecturers photocopying their books. We created a portal with value-add features, and put the ordering-user ID on every page of every book. Photocopying all but disappeared once those measures were in place - people valued and used the bundled services. The institutions that were buying the books were slow to ship IT services. But we were fast. The lecturers started asking us for forums and work-submission and marking-workflow features to help them work with their students, and we did.
(The software lead had an idea that users should be able to just store and share stuff on the site. She moved to Canada during the project to join a new team, and did the same thing for the game they were running. They noticed that a lot of people were using the feature to share photos. So they focused on that, and that became Flickr.)
Newspapers are already well down the road towards this future - as part of subscription you get comments sections, and forums, and dating sites, and wine clubs. Still, I see significant unused potential. Each newspaper should view itself as some mix of bloomberg/twitter/linkedin, and encourage interaction between its members audience.
>I am not sure I agree with this statement in the absolute.
I don’t know, you see, sometimes I have some doubts about my uncertainty. But should I trust my memory about what might have happened in my head in the past?
>I think about art, and artists as a musician myself. One advantage of copyright is that it does, indeed, give artists recourse when people use their works without compensation.
Practices of art and culture, including music, long predate any copyright law. Or even money, most likely (an archeologist will tell you that with more confidence about the veracity of such a claim).
According monopoly of exploitation rarely turn into proliferation of diversity, most of the time it will fall into feedback loop where a few entities will "take it all" and widely spread the "best fit for all".
>The photographer whose picture was copied and pasted onto an advertisement.
There are different topic here. In the French droit d’auteur, you have a separation of "moral rights" – including who is granted to publish your work in which context – and "patrimonial rights" – how monetization of the work is managed.
Copyright mostly only became relevant once it become practical to mass produce works, e.g. with a printing press. (Which was, although it took some time, the proximate cause of copyright law in Europe.)
The term copyright misguides your assumptions I think. Apparition of printers in China, long before Westen rediscovered it, didn't lead to that kind of laws.
I mean, cultural and social structures also play a meaningful part on what is enacted.
The topic behind copyright is not simply about copy, it's about who benefit of some exclusive privileges on cultural works and what kind of social inequalities are enforcable by law.
The only reason we know of that particular case is because they happened to charge the original creator.
The dynamic is ripe for corruption. If Getty failed to report all the works they were collecting for, and instead siphoned money off on the side, how would anyone know?
In a no copyright world, I assume you would have aggregators who vacuum up photos, books, etc. and index/package/curate them in a way that they're more easily discoverable and consumable by the people willing to pay for that service. Without paying anything to the original creators.
You've seen this on a small scale in areas like clipart. It's not a very lucrative business though and it does mean you only have creators with either "passion" or money.
> I think it is quite likely that we as a society would be better off without any kind of copyright or IP.
I agree with that. IP also doesn't make any sense to me from a philosophical perspective. I don't understand why making one thing once should give me a monopoly on making things that are similar to that thing.
The fact that the question of how similar a thing must be to fall under my monopoly is so arbitrary and ill-defined also leads to an enormous amount of resources being wasted on litigation and designing around the law.
Non-disclosure agreements are sufficient to allow an inventor to be first to market. They should not be able to use the government to enforce a monopoly after that.
> I think it is quite likely that we as a society would be better off without any kind of copyright or IP.
This is pretty much the FSF's argument in a nutshell. It's pretty obvious what the end game for "intellectual property" is once you read RMS's "Right to Read."
True. IMHO IP law is based on a moral and not a utilitarian basis, and as we know from almost all recent FLOSS projects especially in Cloud (Linux, Kubernetes, ...) IP is just a massive hindrance to productivity and has a net negative effect on the industry.
True, but that motivation was based on assumptions which are no longer true. Things no longer take effort to copy, and information can flow across the world in an instant. There is no longer any need to encourage copyright in order to get better information from foreign countries.
I guess the argument is that "copyleft" is not needed without "copyright". In particular, look at the four freedoms:
0) free to run the program as you wish, for any purpose
1) The freedom to study how the program works, and change it so it does your computing as you wish.
2) The freedom to redistribute copies so you can help others.
3) The freedom to distribute copies of your modified versions to others.
The only thing taking away these freedoms is copyright and public domain software gives you all these freedoms.
The only caveat is with 1) in that one could use digital restrictions management to make this harder. However, there is a difference between "circumventing DRM is difficult" and "circumventing DRM is illegal".
No, the GPL depends on copyright to function. Otherwise it degenerates into a BSD-family license (actually not even that, as you wouldn't have to give credit to the original author). GPL requires you to provide the source of binary software you ship to your users by revoking your copyright grant if you do not do that. If you remove the threat of copyright enforcement, then I can ship your GPL library without shipping source.
A bsd family licence allows the next programmer to add on new legal restrictions (e.g. no modifying the binary, no distributing the modified binary, no reverse engineering the binary, ...).
In a world with no copyright the source code requirement dies, but all the remaining freedoms stay intact. Reverse engineering and decompilers become much more important.
Copyright isn't the only thing that can keep people from having those freedoms -- even without copyright a developer could choose not to distribute the source code. It seems likely that less proprietary software would exist without copyright, though.
Who can say for sure what would have happened if Linus had used an MIT-style license instead. Linux would not necessarily have failed. But if, for example, a proprietary version had become dominant, that would have been enabled by copyright law. It's not the existence of copyright law that allows Linux to succeed as an open-source project.
Huge upfront investment like writing a book or composing music. It's a common moral intuition that it's not ok to take what others spent time developing and profit from it instead of them without adding much yourself.
It's the scope and duration of the protection that is a problem but I think it's too simplistic to say we don't need it at all.
It’s not at all clear how you are comparing Linux to its closed competitors, but frankly, if that’s the best example you can pick, I’d suggest copyright is largely winning that battle. Yes, Linux has probably “won” in some markets (servers/IoT being the obvious ones), but there are plenty of markets where that is not even close to being true.
Phones, billions of devices running various embedded real-time os, gaming like Xbox and playstation, watches, smart TVs, medical devices, space systems, and many other places are not Linux dominated, and many of these have almost zero Linux presence.
For smartphones, Linux-based Android has the largest market share. It is linux dominated. For less smart phones, there are Linux based operating systems like KaiOS.
Yes, I think most deployed devices don't use Linux, and I'm not aware of any major linux using gaming console, but it's not unheard of, e.g. SNES classic mini. Also, from what I saw, Linux has a good foothold for game streaming offerings, but it's a new market and not yet established that it'll last.
It seems to me very intuitive that a lack of IP protection of some sort discourages innovation.
I cannot imagine wanting to write a book if I didn't have some recourse against people distributing my book freely.
The policy concerns around IP protection for both patent and copyright are clear: the minimum amount of protection that doesn't discourage innovation.
Lawmakers know or should know that we all benefit from a rich public domain, which is why there are limitations on both copyright and patents in terms of both duration and general application, and I am happy to argue that copyright is too strong, particularly in terms of duration (thanks Disney), but I simply can't agree that we "would be better off without any kind of copyright or IP".
There are so many ways of distributing thought and expression with little to no cost other than the time and effort of the creator. In practice, books almost always require more. I'm struggling to see how using a blog instead, is some sort of "failure of empathy".
But I guess the broader point remains, even if only 20% of potential authors are, like me, so evil that they wouldn't devote a year of their lives to writing a book that they couldn't monetize in some way, well that's still represents a 20% decrease in innovation on some level.
Those that absorb effort, resources and risk in creating something new/innovative should at least have the opportunity be compensated for their investment. The balance needs to be fair, and that’s what is being argued. It’s simply not as black and white as how you have described this issue.
Interesting question. The GPL was first published in 1989. Let's assume it was first used for something Stallman wrote, by himself, with no other authors. Stallman is 67 now. US male average life expectancy gives him about another 10 years (sorry to be morbid). Current US copyright law means his work is under copyright for 70 years after he passes away. So that's about 80 years from now, or in 2100 the first-ever GPL program can be distributed in binary form without its source, as it was written in 1989. What a gift to the public domain.
IMO IP protection should be short lived. Imagine if copyright ownership lasted 10 years. The profits made on producing a video game would be almost identical since almost all profit is made in the first few years and half of the lifetime profit is in the first week.
What it would mean is the games that we all played as kids but are long since out of store shelves would now be free to distribute.
I wasn't able to listen to all of the arguments, but some general takeaways I had:
* The justices seemed to be asking mostly technical legal questions of Google (e.g., discuss merger doctrine) and mostly doom-and-gloom questions of Oracle (e.g., how does your argument impact QWERTY keyboards?). This suggests to me that they're more in favor of Google's position, and are querying how to arrive at that decision from a legal basis.
* Some of the questions suggest to me that the justices agree with Google's view that declaring code is categorically distinct from implementation code, and perhaps that copyright for the former doesn't exist.
* Thomas had an interesting question that went unanswered: "the four factors to determine fair use are not exhaustive, can you think of any other factors?" (paraphrased).
The expert to turn to in cases like this is Florian Mueller. While everybody else insisted the Alsup ruling was a slam dunk for Google and would settle API copyrightability once and for all, Mueller insisted that Oracle would win on appeal -- and they did.
He points out that the justices have been asking some really pointed questions of Google since you made this post, questions which suggest that they don't buy Google's crap for a second and they think Google is trying to pull a fast one.
The law is pretty unambiguous that Google is liable for copyright infringement. Just because techies thought the law didn't work the way it does for decades doesn't actually change anything.
> This suggests to me that they're more in favor of Google's position, and are querying how to arrive at that decision from a legal basis.
I wouldn't read that much into it. Google has made the argument that "this means doom-and-gloom" and Oracle that "this is technically illegal". It makes sense that they're interrogating the parties along the lines of the arguments that have been presented. I wouldn't say it's a signal that they favor one over the other.
The decision can theoretically come anytime between now and the end of next June, largely dependent on how complex the decision is. My personal guess is somewhere between January and March of next year.
It's shocking to me that two jury trials spent months considering arguments from lawyers and experts from all sides and carefully came to a decision only to have the appeals court throw that all away and impose the opposite ruling, twice. What was the point of the trials? I don't know why the Federal Circuit court is so biased towards maximalist interpretations of IP law but I really hope the Supreme Court slaps it down hard. Again.
The Federal Courts Improvement Act of 1982 did that. District judges are about geographical boundaries and need to make decisions about every kind of subject area, but Federal Circuit court judges operate based on subject area. That way a patent lawyer that want to be a judge handling patents can go to the Federal Circuit court, and unsurprising a very large portion of Federal Circuit court judges are past lawyers working in industry with companies within the same subject area. As a result it is not very strange that a court packed with past IP lawyers are biased towards maximalist interpretations of IP law.
It would be a derivative work of the api, so per Oracle's argument you would be violating their copyright absent a license. (You could use the gpl OpenJDK license if your code was GPLed, I think).
You could try and argue fair use, and it would be distinct from the case at hand so you might win, but fair use is always a fact intensive analysis and it's certainly not obvious that you would win.
Sort of. Copyright is a civil matter, not criminal, so it requires two to tango. What I mean is, you can copy the API, but then the creator can choose to sue you. Or not. It turns our mostly-open computing landscape into a stand-off, exactly like the current software patent situation. The big guys have all the guns to hold each other off, but they can all take out the small guys who threaten them.
AWS SDK is under Apache 2 license, so anyone is able to use it (suppose you comply with the license - attribution etc..).
Google did a similar thing with OpenJDK (which is GPL) starting with Android N, why they didn't do it in the first place I don't know, Sun published OpenJDK under GPL in 2007, first 1.0 Android release was in 2008.
Though for the purposes of this case it is interesting to note that oracle did copy the aww api and did not comply with the apache 2 license (nothing, including distributed derivative works like their api documents, contains attribution).
My wish is that this case be decided clearly. Either APIs can be copyrighted, or they cannot. Either outcome has potentially good consequences, for open source in particular.
Obviously if APIs cannot be copyrighted, then a ton of open source work geared towards making things compatible remains viable. Wine is one of the most obvious, but I can think of many others. Efforts to port CUDA code to non-Nvidia hardware. A potential effort to reimplement SwiftUI. And there are many more.
On the other hand, if APIs can be copyrighted, then buyers now know that there's a single-source risk for any API that's not released under a permissive open source license. So, to continue this example, Apple has the legal right to shut down any port of code written in SwiftUI to non-Apple hardware, and similarly for CUDA. This would immediately increase interest in actually open source alternatives; Flutter already exists, a Vulkan based runtime could be developed for TensorFlow, etc.
Sadly, I think this outcome is unlikely. What's more likely is that the ruling will be specific to the facts of the case. That basically means that there won't be clear guidance that you need to run away from proprietary APIs, but also not clear guidance that you can continue to rely on open source interop projects. Rather, any time any of this gets sticky, the only way through the mess will be to pay lawyers millions of dollars. That will have the effect of making it easier for the big players to dominate the market further, and harder for independent people to play. That's very much to the advantage of those in power, so I'm pretty sure that's what we'll see.
> If APIs can be copyrighted, then buyers now know that there's a single-source risk for any API that's not released under a permissive open source license.
Buyers won't be very motivated to care because they are consuming the original product, not competing with it. The first mover to release an API frequently has no interest in allowing compatible, competing offerings to exist. It's the second mover, the competition, that desperately wants to be compatible with the first offering, so that they can effectively compete for the business of the customer who bought the original product.
I was making an analogy in my mind between API function names and song titles. IANAL but I thought at first that it doesn't make sense to copyright song titles, they are generic and uninteresting most of the time but after giving it further consideration I realized that some can be quite meaningful, for instance everyone recognizes 'Stairway to heaven' and 'Bohemian rhapsody' therefore, even though it seems a bit silly I wouldn't be surprised if those song titles are in fact copyrighted which could mean copyrighting function names is not that different. I then decided to actually google this and found out that:
>Generally, copyright law protection does not extend to song titles because they usually are short and lack sufficient originality. Therefore, you can (and often do) have multiple songs with the same name, and the first to name their song, for example "Crazy," does not have the right to stop other people from releasing their own songs named "Crazy." An exception to this is that some long titles may be found to have sufficient originality to be afforded copyright protection. I suspect that my friend's song entitled "The Concept of the Quantum-Mechanical Bodymind Has Sparked a Great Idea" is one of them. [1]
The whole article from [1] is worth reading. I wouldn't be surprised if the final verdict will be similar to song title laws from the music industry.
What may throw Oracle for a loop is that Ruth Bader Ginsburg was considered in legal circles to have a strong view of property rights and many people I've read online considered her to be a near-certain vote for Oracle. Her death makes this a much less certain Oracle victory.
To quote The Verge:
"The absolute least important part of Ginsburg’s legacy is that she was the most reliable vote in copyright law cases, tending to vote in favor of rights-holders. Her loss also means that Google v. Oracle is being heard by eight justices and is therefore prone to a split court. (In the 1996 software copyright case Lotus v. Borland, an eight-justice court split evenly and was unable to set national precedent)."
IBM contributed SQL to international standards (Or is it just ANSI? I don't care too look that up), so probably not. It isn't clear though, joining ISO generally requires you to license your patents for a "reasonable price" (Reasonably for a big company, tens to thousands of dollars....), but of course IBM didn't agree to that back then, so would courts say IBM implicitly agreed to the standards of the day where it was thought not required or not... Could go either way but I'd guess IBM would lose such a battle.
Any ISO requirements about reasonable patent licensing would be irrelevant here, because this case is about copyrights (albeit a very patent-like category of copyrights that Oracle is trying to establish).
There are specific exceptions for compatibility. Android Java never tried to be compatible, various required APIs were replaced or are just flat out missing from the runtime library.
I don't believe there is any existing specific exception that allows for completely compatible API s (which you appear to be claiming sql is) but not partially compatible ones (Java). Can you cite a source for this claim?
Usually when someone on Oracle's side brings up compatibility, they are referring indirectly to the test suite required for using the Java trademarks. And they usually are also implying that compatibility should be defined solely by Sun/Oracle, ie. that Oracle should be allowed to require your own Java implementation to be fully functional and 100% compliant to their spec before it is in any way legal, and implementing a mere subset of relevant functionality is not permissible.
After going over the laws(i am not a lawyer) my reasoning might be a bit backwards. I think it would not be a 107 exception but an argument over the technical facts and the creative work contained in an API. To be compatible you have to create a copy of the facts an API describes and copyright is rather limited on collections of facts.
Due to the pandemic, we’ll actually be able to hear the arguments and SCOTUS questions live as well. Possibly an acquired taste, but I found the last round of phone hearings very interesting and entertaining.
I wouldn't be surprised if the decision is very narrow in this case or if it is even postponed again until there is a ninth justice. But I have a bad feeling it will be decided in favor of Oracle, since considering specific APIs part of the "idea" rather than the expression seems to be more of a convention among software engineers rather than actually part of the law. APIs can be "expressions", after all, it just depends on how literal or pedantic you want to be in your reading of the law. The real solution seems like it would be to update the outdated law.
If they decide it narrowly I bet they overturn the federal circuits decision to override the jury (constitutional right to a jury trial, oracle waived the argument about a court ruling on legal aspects of free use when they agreed to the jury instructions) and leave all the interesting legal questions open.
Oracle is pursuing a dubious interpretation of copyright that puts the entire software industry at risk of chaos. This is deeply irresponsible, and would be irresponsible even if Oracle's theory had a leg to stand on. And nevermind software, allowing Oracle's position to prevail would call into question the legality of every set of facts that are freely used across many knowledge domains.
I have what's maybe a stupid question, but this is a stupid issue, so let's give it a whirl.
If writing Java programs is okay, but the issue is copying the API, would it be okay to take 10,000 popular Java programs, read through their byte code, and use that to construct a set of classes and functions that those programs would need to run? It would, of course, be a nearly complete subset of the Java API, but it would be produced without any reference to the Java API itself. Instead, it'd be produced simply by examining programs you wanted to support.
That's the argument that always springs to mind for me, as well, and I'm curious why Google's lawyers haven't used it since it seems obvious. (That's the whole point of this, after all: we're implementing an agreed-upon interface that application developers are using. Implementing an interface happens all the time outside of computers and is not a difficult concept to turn into shitty car metaphors if you really must).
So, the interface is published in every consuming application. If you look at an application which is missing a shared object and figure out how to implement the missing pieces in your own version of that shared object, you've re-implemented (part of) an API. So the question is, in doing so, have you infringed their copyright?
For a case argued in October, a quick decision for a 9-0 case (or I guess 8-0 in the current court) that involves settling a circuit split or something else that's just simple textual analysis would come out in late November or December.
This is probably going to be complicated. I wouldn't be surprised to see a 8-0 outcome, but there's likely to be a concurring opinion or two, which will make the decision take longer. My expectation is that the opinion will come out in the January-March timeframe.
By way of comparison, Bilski v Kappos (the first big patent case in recent years) was a 9-0 case argued in November whose opinions only came out in the end-of-year opinion blitz.
Sigh...I've been commenting on this case almost as long as I've been on HN. At this point I enjoy fantasizing about a coronal mass ejection causing an electrical storm that would obviate everything to do with it. Well, there's always n-gate.
I am always downvoted when I comment on Oracle stories but if Tiktok has any IP around social or uploading videos... you that is exactly their intention.
The solution here is to pass a law that exempts APIs from copyright, not to rely on a geriatric body of lawyers to interpret laws not designed around technology
The current law does exempt APIs from copyright via sensible general principles (you can't copyright functional things, which as applied in this case is known as the merger doctrine).
If the court gets it wrong congress should fix it, but ideally we don't want a law that is a patchwork of tiny little exceptions because that fails to generalize to new things, so we would rather that the court just properly understands how to apply general principles.
Even if the court gets it wrong, my favored way of fixing it would be to modify the general principle to be less ambiguous to this case, not to explicitly make an api exception.
With a single legislative act, we need not worry about this or anything else, modulo constitutional issues which can also be fixed via amendments.
No, it is not obvious that API is a "functional thing" covered by existing law by the mere fact that SCOTUS has taken it on and it was a case to begin with.
I'm not sure why a trivial act of congress isn't the first thing we jump to rather than risk ruin. All the act needs to do is clarify what copyright means.
A copyright act for the digital millenium, if you will -- you can call it DMCA 2.0 :)
It's deeper than that. Ellison and Jobs were best friends (to the point that they could be seen in public occasionally wearing matching best friends tshirts).
Jobs died thinking that Android (and particularly Eric Schmidt's part in sitting on the Apple board while Android was being cooked up at Google) was a personal affront to his magnum opus of iPhone, and the rumor is that Ellison agreed to hurt Android any way he could more or less without regard for the costs.
I think we would be better off, if we follow the pharmacy world. Like they have full controls over a new vaccine for x years and then it becomes generic! Problem is that technology space moves so fast that if x year term is say 5-10 years , that would nullify entire process!
> I think we would be better off, if we follow the pharmacy world. Like they have full controls over a new vaccine for x years and then it becomes generic! Problem is that technology space moves so fast that if x year term is say 5-10 years , that would nullify entire process!
That is, in fact, how copyright works, and the original term was 14 years. Since then, the term has been extended several times in the name of "harmonization", and the term is currently so long it might as well be infinite, as far as software is concerned.
Having been across the table from Sun licensing people when using an open source Java in a project, "some reasonable sum" is optimistic. In fact any transparency about what sum they might demand is optimistic.
AFAIK they were pretty open to some reasonable sum as they were internally fans of Google, but due to Google's arrogance the upper management relationship with them soured, then opportunistic Oracle bought them and here we are.
IIRC IBM was in the play as well, but yes. I guess Google didn't want to inherit all the internal late-SUN problems so they passed on a chance to own it. Now Google had to switch to an alternate strategy utilizing JetBrains for Android.
IIRC SUN's revenues at that time were flat $16B, so they were in a zombie mode, likely could have survived for the next 10-20 years but the board gave up seeing all their competitors growing like crazy YoY.
If the Supreme Court does not find in favor of Oracle, it could undermine the basis for copyright law entirely. Google copied Oracle's code. The CAFC found, correctly, that API declarations are as expressive and protectable by copyright, as any other code. Therefore, finding that the Java APIs are not covered by copyright, or that copying them was fair use, undermines copyright entirely: if the unique expression of those Java APIs are not protectable by copyright, what is?
> If the Supreme Court does not find in favor of Oracle, it could undermine the basis for copyright law entirely.
If the Supreme Court does not find in favor of Google, it most likely will do so by finding that the trial jury acted reasonably (not necessarily correctly -- because the litigants have a Constitutional right to a jury trial, judges or appellate courts aren't Constitutionally, or under the Rules of Civil Procedure, supposed to substitute their judgement of correctness as long as a jury could reasonably conclude as it did from the evidence) that Google's use was Fair Use, and that the CAFC was wrong to negate the jury verdict and act as the jury itself.
Now, sure, the Court could reach Google's copyrightability argument on APIs, but its a stretch to assume it would.
And even if it did, ruling that APIs are functional elements not subject to copyright for that reason would not "undermine the basis of copyright law entirely". It might weaken the basis for copyright applied to computer programs entirely, but that's a very different thing.
> if the unique expression of those Java APIs are not protectable by copyright
In order for use to be "fair use", the thing used must, in fact, be protectable by copyright.
If you cannot build a case for protecting the significant creativity and unique expression in the design of an API, then there is little you can build a case for copyrighting.
If techies want APIs to be uncopyrightable, the solution is to go to Congress and seek a carve-out exception in statute. Asking the courts to affirm what they assume to be the case undermines all of copyright. I know some Hackernews are okay with that, but I have friends and family who are artists and musicians, and they want to be able to put food on the table doing what they love.
> If techies want APIs to be uncopyrightable, the solution is to go to Congress and see a carve-out exception in statute.
By the same token, if we are rejecting judge made law that isn't expressly in the statute, if technies want APIs (or, for that matter, computer programs!) to be copyrightable, the solution is to go to Congress and get an explicit carve-in put in the statute. As it is, the only things explicitly included in copyright protection are:
--quote--
(1)literary works;
(2)musical works, including any accompanying words;
(3)dramatic works, including any accompanying music;
(4)pantomimes and choreographic works;
(5)pictorial, graphic, and sculptural works;
(6)motion pictures and other audiovisual works;
(7)sound recordings; and
(8)architectural works.
--end quote--
Now, certainly some computer programs include things that fall on that list as components, and some might arguably be described as being interactive forms of one or the other category.
But APIs, themselves, don't fall into any of those categories, so why would they need an explicit carve-out when they aren't carved-in in the first place?
The law specifically protects programs as a form of literary work. An API declaration is a fragment of a program, which is copyrightable under statute, just like chapter titles and headings are fragments of a literary work. API declarations constitute expression of an idea which has many ways to be expressed. And... even if a small part of a larger work is copied without authroization or license, then the copyright has been infringed.
Therefore, it should be uncontroversial that APIs are subject to copyright and that Google was infringing.
> The law specifically protects programs as a form of literary work.
No, it doesn't (it's true that it implicitly does so with limitations on the protection that can be applied to them later than where it specifies what is protected, but it does not explictly include them in the list of what is protected, or explictly define them as “literary works” which are explicitly protected.) Computer programs (whether source code or otherwise) are processes. They aren't literary works describing processes. It's easy enough to see this is true.
If you change the expression of a literary work but not the process it describes, if someone is executing the process based on the new description as part of a larger set of processes, there is no impact—the process itself is unaffected.
If you change the supposed “expression” of a piece of computer source code, say by changing the names used for functions and arguments either that it calls or that it defines, and then compile it with other software it normally links with, it either breaks or creates object code that behaves differently at runtime. There is no “literary expression” that is not part of the process code describes, whether it relates to the compile time process the code describes, the link time process, or the runtime process. Code is pure process, and not only is process not explicitly protected it is explicitly not protected by copyright.
> API declarations constitute expression of an idea which has many ways to be expressed.
No, they are a concrete embodiment of a process (well, a set of potentially compile time, link time, runtime, and maybe other processes), and any change alters the process embodied materially. That's even more obviously the case with API definitions than it is with code generally, since the whole use of API declarations is to formally, mechanically define the functionality of the interface between separate pieces of code.
Please at least attempt to address the gaping holes in your arguments when posting.
When a work as a whole is copyrightable, that does not automatically mean that any subset of that work is copyrightable. You need to actually explain why and how your examples of chapter titles and headings are still eligible for copyright protection.
> Google argues that no one should be allowed to claim ownership of this kind of code.
Imagine if we took Google's argument seriously and extended it. What if code were inherently less copyrightable when it is more structural and boilerplate-filled? That could be a great thing, but Google themselves might be surprised at how little of their proprietary code qualifies for copyright under this standard.
For example, would Google's protobuf schemata still be copyrightable? They're needed for interoperability, after all. Would Google's client-side code for Youtube and Google Docs still be copyrightable? It's delivered in textual form to the end-user. Would Android's interface code be copyrightable? Probably not, by exactly the same argument that Google has been making before the courts!
If Google wins, then not only does Oracle lose, but the institution of copyright might also lose, which is an exciting proposition.
Id rather have nothing copyrighted than everything copyrighted. I also don’t have a huge problem with interfaces = no copyright and implementations = copyright.
That is an absurd position. APIs are facts, like sports scores, or the amounts and ingredients in a recipe. Those are not protectable, and making them protectable is plainly ridiculous.
Careful there. Source code to a program is also a fact; it's merely the proof of some statement in some theory. This is one way to view the Curry-Howard-Lambek isomorphism. So, then, what is it about source code which would make it copyrightable again? Are systems like Metamath and Opentheory eligible for copyright or not?
To me, the current copyright regime is what's "absurd" and "plainly ridiculous"; I am merely drawing conclusions based on what exists.
To point back to the substance of the thread and Oracle's claims...
Google didn't copy any of Oracle/Sun's Java source code base into Android Java. Oracle lawyers acknowledge this.
Instead, Google copied the API of function name spellings and also the hierarchy of organization (tree of namespaces) of those API methods. I asked about this in a previous comment and some folks more familiar with the case replied with citations of court opinions: https://news.ycombinator.com/item?id=7852100
So to give a flippant summary of the current situation: you _can_ copy some exact spellings of API function names (e.g. other browsers Chrome/Firefox/Safari can copy Microsoft IE XMLHttpRequest() exactly without renaming it to RetrieveHttpXtensibleMarkupLang()) -- as long as you don't copy too much of the API surface area. The threshold of "too much" and getting in legal trouble is yet to be determined by The US Supreme Court.
If Oracle ultimately wins, it seems like millions of programmers will have to reach for a thesaurus to find synonyms to name functions. We'll have to waste brain cycles coming up and alternative spellings of methods to stay away from copyright infringement.