I think if Oracle wins, the best thing that could happen is IBM immediately suing for infringment on SQL. And since Oracle built their whole business on the SQL standard, IBM should ask for an amount high enough that it's sure to bankrupt Oracle.
I believe that's a fair price to pay for breaking the software industry.
And, since the issue is copyright instead of patents, it doesn't expire after 20 years. Oracle isn't in the clear just because SQL came out in the 1970s (IIRC). Even in the 1960s, they aren't in the clear.
> I believe that's a fair price to pay for breaking the software industry.
There is a theoretical legal question of whether APIs should be copyrightable, and then there are the practical issues.
As a purely legal matter, there is a strong (but not slam-dunk) case that an API is copyrightable. As a practical matter however, everyone in the software industry has been operating as if APIs were free to copy for decades, and enforcing such a copyright would break a ton of things.
Practical effects of a legal ruling are generally not "officially" considered by the judge, but more-often-than-not, they're operating behind the scenes and judges craft their opinions to support an established status-quo.
There's an interesting analogy with microprocessor architecture..
I believe the Z80 was a copy of the 8080 architecture - it used the same binary opcodes but it used an assembly language with different words.
So an API is at source level, so it uses words which seem more aligned with copyright of text.
I wonder what would happen if the api had the text "oracle" in the function names?
p.s. and amusingly when intel did the 8086, it was source level compatible with the 8080, but not binary.
This reminds me of the gameboy copy protection. The device looked for the Nintendo bitmap in the cartridge boot screen before it continued execution.
That way you couldn't make third party cartridges without stepping on their trademark.
(On mobile so can't find video source)
> As a result of the piracy and unlicensed development issues, Sega incorporated a technical protection mechanism into a new edition of the Genesis released in 1990, referred to as the Genesis III. This new variation of the Genesis included code known as the Trademark Security System (TMSS), which, when a game cartridge was inserted into the console, would check for the presence of the string "SEGA" at a particular point in the memory contained in the cartridge. If and only if the string was present, the console would run the game, and would briefly display the message: "PRODUCED BY OR UNDER LICENSE FROM SEGA ENTERPRISES LTD." This system had a twofold effect: it added extra protection against unlicensed developers and software piracy, and it forced the Sega trademark to display when the game was powered up, making a lawsuit for trademark infringement possible if unlicensed software were to be developed.
[...]
> The Ninth Circuit reversed the district court's order and ruled that Accolade's use of reverse engineering to publish Genesis titles was protected under fair use, and that its alleged violation of Sega trademarks was the fault of Sega. The case is frequently cited in matters involving reverse engineering and fair use under copyright law.
Couldn't find this anywhere, but I swear John Carmack once mentioned that a reason they included the textures in Quake BSPs was as a form of copy protection. They were annoyed with people grabbing lots of Doom wads and selling them.
Maybe he mentioned that in his .plan file that you had to use finger to access.
Interesting, that's pretty cunning... Not indefeatable i wonder? The interesting thing about cartridges is their potential to house more than just a ROM, there have been a few HN posts about such games - in one of them it effectively worked around the physical memory address limitations by switching blocks based on the contents of a small area of memory.
In this case perhaps a gameboy cartridge could differentiate the sequence of reads for nintendo bitmap detection (which could be argued as API) and reads for the actual boot display and present different data... that's assuming they are separate reads, if the gameboy handles boot display all by itself and checks in the same step then i guess it's indefeatable.
A real Game Boy reads the logo data once to copy it into video RAM, then a second time to validate it, so a cart with clever hardware can make the boot-up logo display whatever they want:
Of course, you still have to include a copy of the Nintendo logo to get past the BIOS check, even if it's not displayed, which I think is supposed to be the trademark infringement.
> Of course, you still have to include a copy of the Nintendo logo to get past the BIOS check, even if it's not displayed, which I think is supposed to be the trademark infringement.
Yeah i think this is the bit that a brave publisher could have argued in court, I think for it to be a trademark violation it would have to be visible somewhere beyond the raw content of the ROM. That's why i'd argue it's essentially being used as an API token, and trademark definitely doesn't cover that.
Written by someone who worked on MSN Messenger. Talks about repeatedly reverse-engineering the AOL messenger protocol, and AOL's attempts to stop them.
Yes, but only because during your fork, you neglected to run the "white label" script that replaces the trademarked words and graphics. IOW, what you describe is not a problem in practice.
> So Ubuntu is open-source, but if I fork it, it comes with « Ubuntu » in package names, therefore I’m infringing on their trademark?
Yup. However, I suspect that Ubuntu gives a pretty permissive trademark license in their distribution.
This isn't a theoretical argument, the Android OS is open source, but the "Android" brand is a protected trademark. If you're a cell phone manufacturer, you can use the Android code freely, but if you want to put an Android sticker on your phone, you have to follow Google's rules.
The part that's missing from Ars' story is when IBM and Oracle shook hands and decided that SQL was a super-awesome standard that everyone else in the industry should be able adopt for free. Yay! So not happening, sry.
Java was different because Sun was actively trying to prevent the "SQL" or "UNIX" semi-compatible fork scenario. IANAL, but bad analogy.
Totally untrue. Sun had all sorts of legal contracts committees and procedures and testing suites to manage java forking into different environments. Sun sued Microsoft for $1 BILLION dollars for violating their Java license.
Sun and Google had negotiations about licensing Java, and they certainly did not end with shaking hands.
Old post, so just saying this guy is factual-free.
I've been wondering if it would be possible to create an Internet movement large enough to impact Oracle's bottom line. Encourage employees and managers to immediately drop their business with Oracle, both as customers and as vendors. Encourage Oracle employees to quit and find more ethical places to work. Oracle has crossed a line here, and I wonder if we can kill that beast before they kill us. Or at least take them down with us.
This has already beginning to happen. Almost all of $work's customers (industrial plants, all sizes) have Buying Guidelines that forbids a new solution to be bought if it needs an Oracle database.
Which was amusing as Postgres is by most measures the better system (yes, I know streaming replication wasn't easy on earlier versions and that was a definite plus for MySQL).
Amazon had a celebration when they turned off their last Oracle system ...
I doubt it. Oracle has done a great job dissuading new business by suing customers for discussing benchmarks, suing customers for discussing security, auditing customers, jacking up prices, jacking up penalties, suing everyone else, etc... Plenty of reasons to drop already.
Everyone left stays because they're in deep and migration would be worse.
> Oracle has done a great job dissuading new business by suing customers for discussing benchmarks, suing customers for discussing security, auditing customers, jacking up prices, jacking up penalties, suing everyone else, etc...
Do you have some sources, or specific instances I could do my own searching for? Feel free to email me privately. I'm somewhat serious about trying to kill Oracle in retaliation for what they've done here.
There's also something that bit me personally, probably in the fine print somewhere. If you drop support, you have to pay 3x to get back into it. Something like "treble fees".
The problem here is that US government wants to "maximize the USA IP interests" and supports Oracle in this case although they haven't studied the implications in details... So we have an "elephant in the porcelain shop" here and this elephant may destroy a lot of things...
When this case previously was submitted to the Supreme Court the SG's position was that API's were copyrightable but that Google had persuasive arguments that their use may be proper under the fair use doctrine and instead of hearing the case the fair use claims should be allowed to played out in lower courts first.
The current SG's opinion that Google's fair use claims aren't reasonable is new to this administration.
That is underestimating the so-called old guards alliance. There old school IT providers are quite conscious about their imminent irrelevance giving the trend in society and tech. They know very well who are their common enemy.
IBM has a lot of money, Oracle has a lot of money. If IBM took a large chunk of Oracle's money, they could survive for decades more without selling anything.
I meant to say that IBM likely doesn't have any deterrents to sue Oracle as they are no longer on the same page with regards to their business markets.
Is it taking it out of context when you only provide the context after the fact?
That being said Oracle and IBM still compete in many markets such as cloud computing and software platforms. Since Red Hat became part of IBM the areas where they compete has increased lately.
But the information that IBM and Oracle are still competitors in many markets is explicitly what I was unsure about. Thanks for reminding me about the Red Hat acquisition, I completely forgot about that already.
As far as I know "international standard" is a term that carries no legal weight in the realm of copyright, do you have any reason to believe otherwise?
ISO is not some organization created by the statute with the right to take your copyrights and make them public domain...
> I think if Oracle wins, the best thing that could happen is IBM immediately suing for infringment on SQL.
IBM's potential claim on SQL wouldn't be a threat to Oracle.
IBM uses Java heavily. The most likely outcome is that the two companies reach a deal to cross-license with maybe a modest amount of money exchanged, freeing them each to go after everyone else.
That is the thing Google fanbase keeps missing out, there are plenty of JVM implementations out there, although the number has gone a little down since OpenJDK and GraalVM introductions.
None of them was ever sued, because they play by the rules, instead of playing the "I am the big boy, I follow no rules" that is Google's stance at this.
Breaking the Java compatibility story, working around that Java free licensing was originally only allowed for desktop and server deployments, helping Sun go bankrupt and not doing what have rescued them from a lawsuit by buying Java assets from Sun, and whatever else courts might rule.
That's why Google was so cautious to avoid using the Java trademark, and strictly talked about the Dalvik bytecode and compiler and so on.
Java compatibility is enforced by trademarks. In order to call something Java it has to pass certain tests and there is a cost attached to it. There has been many free Java implementations before that had to call themselves something else to be in the clear, IcedTea being perhaps the most well known.
This litigation, however, was never about trademark law. Oracle knows that would be a short lived process. They instead made up argument about how function definitions under certain circumstances could be copyrighted, that could keep their lawyers busy for a long time. By throwing a lot of money at this they could sow fear about their competitor's business model. It's straight out of the Microsoft, by way of SCO, playbook.
Ironically, given that Android Java is a J++ copy cat regarding the damage to the Java portability story, trademark or not.
Worse, Google cleverarly takes advantage of their Android Java fork stagnation to sell Kotlin over Java, while being fully aware that modern Java makes many of those code examples pro Kotlin worthless.
This is all pretty irrelevant whatboutism. It is all entirely unrelated to Oracle sueing Google.
Google could be 100% tracking newer Java language features and Oracle would still have made this lawsuits. It's financial compensation or competitive advantage they are after or something, compatiblity and feature parity is very low on Oracle lawyer's list.
Sun and Oracle never sued other JVM implementations, only Microsoft and Google, aka J++ and Android Java.
If Google did not wanted a lawsuit, they could have easily made an offer to buy Sun after torpedoing their profits helping the company to close doors, no love for Google from my side on this story.
The whole thread in about hating Oracle. It's probably warranted, but Google shouldn't get a pass. They induced this situation. Someone did a back of the envelope calculation and decided a lawsuit was going to be cheaper than licensing Java would be. Or maybe they'd get really lucky and Sun would go under. But, Oracle bought Sun and brought along the suit that Google had counted on. And then Oracle kept throwing things at them until one stuck.
This all would have been avoided if Google wasn't a bad actor in the first place. They wanted to play by different rules than everyone else and thought they had enough weight to get their way. Now someone in their own weight class came along and we all get to live with the fallout.
> Someone did a back of the envelope calculation and decided a lawsuit was going to be cheaper than licensing Java would be.
I don't think it was an issue of monetary value. Sun simply wasn't going to offer terms that would allow Google to make Android with Sun's blessing, because Sun wanted to retain tight control over the feature set of different Java editions.
> This all would have been avoided if Google wasn't a bad actor in the first place. They wanted to play by different rules than everyone else
Please don't do this. The irony of making such a silly claim using a software stack that is so thoroughly built on those "different rules" is too much.
Okay. If you need a license for something and someone isn't going to license it to you, you don't have carte blanche to do whatever you want with their IP.
> Please don't do this. The irony of making such a silly claim using a software stack that is so thoroughly built on those "different rules" is too much.
Give me a break. You just said yourself they circumvented Sun's licensing. If software licensing and trademark usage doesn't matter, then why do even bother with them?
> You just said yourself they circumvented Sun's licensing. If software licensing and trademark usage doesn't matter, then why do even bother with them?
Please don't conflate trademark licenses with copyright licenses.
> It's probably warranted, but Google shouldn't get a pass.
If Google doesn't get a pass on doing what the whole industry is doing - then no one will get a pass - that is a bad thing regardless of your thoughts on Google. Reimplementing interfaces is the lifeblood of compatibility, and has been for decades. A win for Oracle is a win for vendor lock-in: open source and upstarts lose.
There's a lot more going on here than just implementing an interface. If Google had just used OpenJDK, there wouldn't have been a problem. I fail to see how what they were doing is any different from what Microsoft tried to pull with Visual J++.
> I fail to see how what they were doing is any different from what Microsoft tried to pull with Visual J++.
That's because you're repeatedly failing to see the distinction between trademark law and copyright law. The Visual J++ lawsuit that was settled was a trademark infringement suit, because the Java trademarks are what Sun had locked behind license terms mandating compliance to their compatibility test suite. Google was more studious about avoiding use of Sun trademarks in Android, and chose to not seek a license for those trademarks. Now they're being sued over copyrights, not trademarks.
I'm not failing to see any distinction. They were sued over a bunch of things. Copyright is what stuck. Lawyers are going to use every tool in their belt. And since there's a lot around software licensing, copyright, and fair use that haven't been established by case law because no one really wants to find the limits of it, now the lawyers get to duke it out.
At the end of the day, Google wanted to use Java and not really be compatible with Java, so they tried to skirt around it and got called out for it. This was evident by pages they had that stilled referred to it as Java and by passages of code taken in whole. So, yes, I'll contend that Google tried to get away with something and hoped they were big enough to come out of it unscathed.
It's not like this was unforeseen. And it's not like Sun or Oracle has sued any compliant Java implementations. They could have just used OpenJDK, but didn't want to play by those rules either. If you don't like how this is shaping up in the courts, it's fair to say that it could have all been avoided by Google being a better actor.
I think you're missing the bigger picture. I personally don't care if Google is punished or not. But I don't want Google's punishment to come in a form that will break the entire software industry.
I agree, it sucks. All I was saying is I think Google is also at fault for setting the stage for this. It looks like their gambit was litigation would be cheaper than licensing and now we all get to deal with the blowback from that.
> APIs aren't designed in vacuum, they are the outcome of the work of a group of people that put in the effort and endless hours of work to design them.
You could say the same about the design of an electrical plug or a radio signaling protocol. That doesn't make the functional aspects of the design subject to copyright.
Bad examples, they are protected by certifications, market compliance processes, and paying for ISO and similar standard documents.
Even implementators of languages considered free beer like C and C++, have at the end of the day have someone paying for those 100 CHF.
Naturally there are black markets to work around those issues, then if a fire can be tracked back to a not-certified plug, the insurance can consider it isn't responsible for paying.
> Bad examples, they are protected by certifications, market compliance processes, and paying for ISO and similar standard documents.
So then what do you need copyright for? Do the same thing for your API. Copyright is the wrong tool for this.
But in particular, notice that if your "market compliance processes" start trying to charge monopoly rents, someone will reverse engineer the thing and launch a competing compliance process which insurance companies will happily accept as long as it has reasonable quality.
Also notice that the compliance process for things like that is generally shepherded by a third party non-profit like UL or IEEE and not a competitor in the same market.
I'm not sure I'll ever properly get my head around this case. On one hand, it's certainly possible to make an intellectually sound argument that APIs are eligible for copyright. On the other hand, such an argument seems to imply that IBM PC clones, MS-DOS, and Linux have all been infringing from the start and it's just that everybody has been too timid to actually enforce their API copyrights over the course of decades where there were plenty of affiliated deep pockets to raid. And that seems really hard to swallow.
The idea that so much existing infrastructure would infringe on this new kind of copyright is tough to accept, but at least it's very straightforward in a way, with brutal direct consequences.
What I have more of a problem with is that we have no clear precedents for how API copyright will work in practice if it is suddenly foisted upon the real world. What does it mean for an API to be licensed under the GPLv2, or any other copyright license that was written with source code and object code in mind but not APIs? How will we determine which license agreements executed long ago should be retroactively considered to include or exclude the APIs? How many industry standards will have to be assessed for whether the relevant APIs are available under FRAND licensing terms as the relevant patents usually are? Is there a distinction between providing vs using an API, for the purposes of determining copyright infringement?
In order to get insight in that future I look to examples close to API. One such area is proprietary standard documents that covers proprietary protocols. What does it mean for a protocol to be proprietary? Usually that a single company control all the software that communicate with each other under that protocol. Software stacks became platform for that vendor, and Microsoft was infamous in using this technique in binding people to the Microsoft ecosystem in the previous two decades. However in recent time DRM has been used to create a similar effect and companies has started to abandon the idea of preventing others from creating protocol compatibility by hiding how the protocol works or by burying it in legal swamps. If you want a walled garden you just put in cryptographic verification tests at the client, server and hardware level.
Using DRM for a programming language in order to create a walled garden is a bit harder. We can imagine a Java 2.0 (evil version) where the byte code has DRM that checks for unauthorized java compilers, but it won't work if the physical programmer can choose to move to a new platform. DRM can thus not create a wall garden for a programming language unless there is legal walls that prevent a competitor to create a compatible platform.
> The idea that so much existing infrastructure would infringe on this new kind of copyright is tough to accept, but at least it's very straightforward in a way, with brutal direct consequences.
I don't anticipate a doom-and-gloom scenario if APIs were all-of-a-sudden copyrightable. Today, open source software is backed by powerful companies, and there is far less lock-in to any particular set of software functionality. The likely outcome is that big tech companies would just cross-license their basic APIs like Win32, SQL, NTFS, POSIX-like functionality, and other basic interface layers.
Today in 2020, the value is not in the interface, but data. Facebook probably wouldn't care if you created a clone that used the same API structure. But if you started imported their user data, you could expect a lawsuit.
Your best case scenario is that hardly anyone attempts to follow in the footsteps of a resounding Oracle success, and that everyone in the industry is saddled with huge potential liabilities until a massive multi-year relicensing project can be completed to confirm who is committed to never trying Oracle's tactics when they fall on hard times. That is a doom and gloom scenario for anyone who takes legal threats seriously and doesn't have an IBM-class mutually assured destruction IP portfolio. It's postulating a series of events that leaves us with most of the software industry intact, but for the most part would still be a scenario where the only true winners are the lawyers.
> everyone in the industry is saddled with huge potential liabilities until a massive multi-year relicensing project can be completed to confirm who is committed to never trying Oracle's tactics when they fall on hard times. That is a doom and gloom scenario for anyone who takes legal threats seriously and doesn't have an IBM-class mutually assured destruction IP portfolio.
This multi-year cross licensing project wouldn't be a big impediment. It happens all the time in standards setting organizations, and wouldn't slow down progress significantly.
The worst case scenario would be trolls somehow obtaining the copyright to a foundational API and collecting money from everyone. That would be a pretty big annoyance, but that too would't be a doomsday scenario. Patent trolls have been active for decades and have had minimal impact on overall progress.
"Patent trolls have been active for decades and have had minimal impact on overall progress."
Where did you get this from? It's mighty hard to quantify what might have been. Patent trolls disproportionately affect small organizations that are not on anyone's radar unless and until they deliver. They die with not a roar but a whisper.
I believe there were lawsuits over IBM clones, way back when, amd the clones won, based on interoperability. Apis are software, not hardware, but you'd expect this to be the same, because of the same underlying policy considerations.
Sometimes courts uphold the letter of the law, but say the legislature should change it.
I believe the substance of those suits was on the copyright protection IBM were due on the ROM BIOS image, which was the most substantial piece of IP developed by IBM for the PC. In the end, clones won because the BIOS call interface could be replicated without directly copying that software artefact -- merely its behaviour -- and so actually seems pretty relevant to API copyright issues generally.
You're referring to a distinction that's largely a peculiarity of how technological terminology has been shoehorned into an ad-hoc legal framework; there's no real deep insight here. If you ask the lawyers in this case what "an API" (singular) is, they'll give you a definition that's more on par with what a developer would call a single function/method signature. If you ask a developer to name some common APIs he uses, he'll list off named collections of functions, and such collections in the abstract are pretty much what Oracle's suing over. So when a developer rather than a lawyer says that Oracle's suing over "the Java API", they're trying to convey the correct meaning, and using the right terminology for the context. "Structure, sequence and organization of APIs" sounds much more like a legal test (in the same vein as the factors considered in determining fair use) rather than a decent name for the kind of creative work at issue.
I'm pretty sure that's not actually in question any more. And it's quite orthogonal to the question of whether it's appropriate to simplify "copyright of structure, sequence and organization of the API" down to "copyright of the API".
I don't think "copied the declarations" and "copied the declarations and implementation" are interchangeable or generally understood to be interchangeable. If you told me someone "copied your API", I would absolutely assume that they'd copied the implementation and not just the declarations or the way the declarations were organized/named. The "SSO" language is not an arbitrary or legal distinction. It is a technical one that is necessary to convey the exclusion of the implementation precisely because people would otherwise assume we were also talking about the implementation when we say "API".
> If you told me someone "copied your API", I would absolutely assume that they'd copied the implementation and not just the declarations or the way the declarations were organized/named.
That's just you being unreasonable. I've literally never seen anyone else make a similar assertion or assumption, while the opposite is very common—most APIs that get copied are ones where the source code to the implementation is not even readily available to be copied, or where even looking at the original implementation's source code is dangerous for the author of a clone because of its license terms.
Confusing the API with the entire standard library implementation is not a common mistake, especially among people who pay any attention to this legal case.
> The "SSO" language is not an arbitrary or legal distinction. It is a technical one that is necessary to convey the exclusion of the implementation precisely because people would otherwise assume we were also talking about the implementation when we say "API".
The "SSO" language is not about clarifying that the API is separate from the implementation; that distinction is pretty clear on its own. It's about trying to make sure the API doesn't run afoul of copyright law's exclusion of "any idea, procedure, process, system, method of operation, [...]", by making APIs out to be something more than just a collection of parts that are individually not copyrightable.
Confusing the API with its implementation may not be a common mistake among people following this case, but the people following the case are not the ones deciding it (much as I wish that were true).
It's very much relevant to what we're talking about when we talk about "the API". I am skeptical that when people think about what the above reply described as the "creative work at issue", they're not thinking about the implementation at all.
In 886 F.3d 1179 (2018) [1][2], the Fed. Cir. noted that:
"62 classes (and some of their methods), spread across three packages within the Java API library, must be used. Otherwise the language itself will fail."
"On remand, the parties stipulated that only 170 lines of code were necessary to write in the Java language. It is undisputed, however, that Google copied 11,500 lines of code — 11,330 more lines than necessary to write in Java. That Google copied more than necessary weighs against fair use."
What? Java String alone has close to 100 members and even without function bodies would be over 170 lines unless you put every method on a single line.
Here's some additional context in from a lower court: Oracle Am., Inc. v. Google Inc., No. C 10-03561 WHA (N.D. Cal. Jun. 8, 2016) [1]:
"Oracle has portrayed the Java programming language as distinct from the Java API library, insisting that only the language itself was free for all to use. Turns out, however, that in order to write at all in the Java programming language, 62 classes (and some of their methods), spread across three packages within the Java API library, must be used. Otherwise, the language itself will fail. The 62 "necessary" classes are mixed with "unnecessary" ones in the Java API library and it takes experts to comb them out. As a result, Oracle has now stipulated before the jury that it was fair to use the 62 "necessary" classes given that the Java programming language itself was free and open to use without a license"
"That the 62 "necessary" classes reside without any identification as such within the Java API library (rather than reside within the programming language) supports Google's contention that the Java API library is simply an extension of the programming language itself and helps explain why some view the Java API declarations as free and open for use as the programming language itself. At least to the extent of the 62 "necessary" classes, Oracle agrees."
> I don't suppose it will persuade you that String (and many other classes) are in the Java.lang package.
From the prior source [1], immediately below the previously-quoted text:
"Trial Exhibit 980, The Java Application Programming Interface, Volume 1, is a book that covers four packages and refers to them as the "core packages." According to the back cover of the book, these four packages "are the foundation of the Java language. These libraries include java.lang, java.io, java.util, and java.net. These are the general purpose libraries fundamental to every Java program."
TFA: Copyright law specifically excludes "systems" and "methods of operation" from copyright protection.
Sounds like a "clean room implementation" is needed, and that Google copied more than what was needed for inter-op.
If so, Google might lose the case, but the legal precedent would be you can copy apis but not implemention (unless that's the only way to implement them).
IBM tried to regain control with the PS/2 architecture, but it failed to do so, and only the mice connectors survived.
Big difference in regards to legal process.
Siding with the company that created a fork in the Java eco-system, just like Microsoft did with J++, just because "Do no evil", without legal understanding, is just typical.
Like wishing for IBM to sue Oracle for SQL, without understanding unlike the way Google screwed Sun and the Java community, there was eventually an agreement between both companies, because hating Oracle is cool in some circles.
Man I would absolutely LOVE to see IBM suing the pants off of Oracle and sending those muppets into insolvency. I don't think there is a single company in the software industry more widely hated than Oracle today, it seems to me they have devolved into mere patent trolls because they couldn't figure out a way to adapt their business model.
> The term Nazgûl has been used to refer to IBM's cadre of lawyers, with whom it has been said that IBM can blacken the sky - particularly with reference to the SCO v. IBM lawsuit because they supposedly never sleep, are utterly ruthless, and are completely loyal servants to their master.
I thought it was SCO who were the bad guys in that one?
There were no good guys in that one. There was a bad guy who was wrong, and a bad guy who was initially right but then tried playing the exact same game on the other guy.
Whenever I hear Oracle mentioned it reminds me that it's once again time to re-watch the "Never make the mistake of anthropomorphising Larry Ellison" rant.
There are some very basic elements of this case that this article (and most others) miss, which makes me wonder if they'd read the relevant court documents at all. That Oracle is "trying to copyright APIs" is a popular (and biased) framing of the case, but this is not at all what they're actually saying. As I understand the filings, they're saying that if there is some already-copyrighted work and you copy substantial portions of it, those portions aren't exempt from copyright if they're "declaration code" (although the copying, as always, could potentially be fair use). In other words, it's not a new kind of copyright, but about exemption from established copyright. So regardless of whether SQL is an API, unless anyone copied substantial portions of copyrighted code from IBM, this case -- as it actually is, not as it's presented by some media outlets -- is irrelevant.
It is hard to find any popular blog post that faithfully represents the sides' claims, so it's best to read what they actually are in one of these locations:
Yeah, but Google copied only "declaration code" (i.e. the class structure of Java to make it compatible). There are a few other lines, yes, but those came about due to being utterly trivial code that looks more like two people choosing the same trivial implementation randomly from what I recall.
Also, regardless of intent, this would have the effect of making APIs copyrightable. That would be terrible for compatibility and would destroy the viability of a lot of work for no good reason at all, unleashing a lot of copyright parasites to go around suing for trivial nonsense.
I'm sorry, but this is basically a phone book that can be used by machines of where to find the code that does X. It shouldn't be copyrightable any more than the actual phone book and the structure was copied only to make it compatible.
It'd be like suing everyone for making similar electrical plugs, ignoring how they have to meet certain requirements to actually fit in the socket.
I was wondering about physical equivalents. Does anyone know if the Torx system was copyrighted/patented? Not a trademark on the name Torx, a real protection on that design of screw head/driver
> Many companies do patents as means to protect their IP when copyright isn't enough.
It's hard to believe that 95 years of protection after publication (or 120 after creation) "isn't enough" for corporations, but I'm sure they'll find longer terms in one country and then push the others to "harmonize" on the new value at some point or what have you.
Walt might lose his incentive to create new works if the Mouse's copyright is allowed to expire on January 1, 2024.
Copyright and patents apply to different works. In the case of software in the US, patents apply to algorithms or protocols (more precisely, to their implementations on computers) while copyright covers code.
Source code, which is what we're discussing here in Oracle vs. Google, may be covered by both, despite some Supreme Court rulings that tried to limit what may be claimed to at least avoid simple recitations of a standard computer.
Of course, my view is that the real problem is that 101 can be met piecemeal. The novel part doesn't have to be patentable subject matter and the patentable subject matter doesn't have to be novel. So one would just recite claims of allegedly novel software running on an non-novel, but otherwise patentable computer. If novelty had to reside in the part of the claims that was patentable subject matter, I think a lot of the nonsense would have vanished, though I might well underestimate their cleverness in finding new and strange ways to disappoint us.
You're using the legal term, I'm using the ordinary definition of the word. In other words, you can't use the code without a patent license, just as you can't use the copyrighted work without permission.
> this would have the effect of making APIs copyrightable
No, only if there has been some copying of substantial portions of copyrighted works. Talking about analogies is irrelevant if you're unfamiliar with the legal framework that determines the suitability of the analogies. For example, one could claim that copyrighting code is "just like" copyrighting algorithms, yet it is established that code is copyrighted (but not patentable) and algorithms are not copyrightable (but are patentable), and the legal system is perfectly fine with that. Why? Because there are important distinctions here, and the question is not whether things are "the same" in the eyes of developers, but whether they're the same in the eyes of IP law. If you don't understand the legal distinction between code and algorithm, then you're missing the most essential background material.
As to the rest of your arguments, the relevant ones are the subject of this case. I suggest you read the actual arguments; they're quite interesting.
> No, only if there has been some copying of substantial portions of copyrighted works.
The only 'substantial portions' at stake in this lawsuit are the API declaration itself, which merely tells the system where to find the right code and does not implement any logic.
It is absolutely required to copy that and other APIs in order to be compatible, which is why I'm really worried about a lot of judges who have minimal, if any, understanding of the ramifications of this deciding it.
Alsup actually understood the issues, but he got overruled by clueless judges.
> which merely tells the system where to find the right code and does not implement any logic.
This is not true (declarations in Java are evaluated at runtime and compiled to real machine instructions -- i.e. they perform very real logic; also, what algorithm or logic does the following "implementation" Java code describe `return a + b;` ?), but even if it were, I don't see the relevance to copyright. Maybe there are other arguments for excluding such code from copyright, but I am not aware of exclusions for "code that doesn't implement any logic". That's just not the law.
> It is absolutely required to copy that and other APIs in order to be compatible
That is a fair use question, and it is certainly possible that copyrighted code can be copied for compatibility as a fair use. But this case is about Android, and Android is not and was never intended to be compatible. Google admitted that in court, and said that their goal wasn't compatibility but reaching a large pool of developers who would be familiar with the general structure. I don't know if "familiarity" is a fair-use defense, but that is another question before the court.
> This is not true (declarations in Java are evaluated at runtime and compiled to real machine instructions
Yeah, so what? That's just the system putting the right values in the right place. Also, it obscures the fact that this resulting JVM bytecode could, in fact, be very different for Google & Oracle's implementation, though some parts of it will likely be similar just because programmers choose the simplest/most efficient ways to do things and those are necessarily similar.
> what algorithm or logic does the following "implementation" Java code describe `return a + b;` ?)
Addition, normally, though operators can be overridden so it might be string concatenation or whatnot depending on the types.
> That is a fair use question, and it is certainly possible that copyrighted code can be copied for compatibility as a fair use.
More to the point, Google won as to fair use before the jury before a judge overturned their verdict...
Anyhow, yes, changing all the names means that you have to do trivial and stupid rewrites of lots of code to replace names. Whether someone named something to return the maximum of several elements max() or maximum() or what have you is not the sort of 'creativity' that Congress ever had in mind to protect.
Copyright was designed in an age when written works were creative rather than functional and several of the doctrines need to be adapted to make any sort of reasonable purpose out of this.
The fact is that making APIs copyrightable would cause a lot of legal destruction--senseless lawsuits that enrich only lawyers and impoverish the public--while destroying a lot of innovation and open source that the public already has for the sole benefit of IP law firms.
It shouldn't be surprising that only those who hope to profit by trolling the people who actually make useful stuff are excited by this.
> That's just the system putting the right values in the right place.
Not in Java, but again, it's irrelevant for the question of copyright.
> Addition, normally, though operators can be overridden
This line could be one of three or more different algorithms in Java. Both it and the declaring code together define the operation. But this, too, is hardly relevant.
> Also, it obscures the fact that this resulting JVM bytecode could, in fact, be very different for Google & Oracle's implementation
This has nothing to do with copyright. The law doesn't say that as long as you don't copy everything it's OK to copy anything. It does, however, take into consideration the amount of material copied when it comes to fair use. For example, it's possible that it's OK to copy a small, simple API, or that it's even OK to copy a large API for the sake of compatibility, as neither of these is the case being discussed here, and the size of the copied code, and the fact that it's not compatible are crucial elements of the case, and a focus of the court.
> Whether someone named something to return the maximum of several elements max() or maximum() or what have you is not the sort of 'creativity' that Congress ever had in mind to protect.
True, and if you'd read the court documents you'll know that this is not at all the case here. The corresponding code in the, say, Swift or C# standard libraries is drastically different, yet it was this particular very large chunk of code that's been copied; not from C#, not from Swift. They copied hundreds of pages of unique code.
> The fact is that making APIs copyrightable would cause a lot of legal destruction
Maybe, but that this is about "copyrighting APIs" is just some an opinion and one possible interpretation of the case. Would punishing a company for copying hundreds of pages of code, for commercial gain, and not for compatibility cause a lot of legal destruction? Are you familiar with many other cases of people doing that?
Prove this? Also prove how it compares between Google and Oracle's JVMs. I believe it's just setting up the stack and registers with the right values, one of which should be whatever the JVM's equivalent of the stack pointer is (e.g. finding the right code to run).
> This has nothing to do with copyright.
Perhaps, but only because the law is ignorant of it. It's not really much of a "copy" if it's a purely functional description that gets translated into very different software doing different things. That goes to my point that it's an interface for compatibility, not something copied because it was desirable in its own right.
> True, and if you'd read the court documents
Please don't give me that, when I've been reading docs since this first came out, enough to remember these old filings on a long-defunct site:
That was later overruled by a judge, yes, but there has been no jury finding other than fair use. When you go down into the weeds of this, there just isn't any real creativity there that's being protected by this and a broad precedent that "APIs are copyrightable" would be a terrible thing for all people who use computers, except only for a few lawyers to get rich off of suing.
> Maybe, but that this is about "copyrighting APIs" is just some people's opinion, and is just one possible interpretation of the case. Would punishing a company for copying hundreds of pages of code, for commercial gain, and not for compatibility cause "a lot of legal destruction"?
In this case, on this set of facts, yes. Oracle's plan was always to buy Sun and make Google (and everyone else) pay for it. It's just how they are, they love suing/auditing even their own customers, it's part of their sales pipeline or something.
The above is merely your opinion and not one that seems to be widely shared. I know I certainly do not. Can you point to a more detailed line-by-line discussion of the allegedly copied code than Groklaw had?
All code is "functional" and yet creative and copyrighted. While the function of a quicksort routine — namely the quick sort algorithm — cannot be copyrighted (although it could be patented), any specific implementation of it in code is copyrighted, just as a news event isn’t copyrighted, but each and every written report of it is. That this particular expression is creative is also obvious from the fact that while the Swift standard library performs similar functions, its expression is completely different (and saying that the thousands of choices that went into the design, took years, and are unique among other runtime libraries are "trivial" is just factually false). That the function of declaring code is required for compatibility, and therefore copying it might be fair-use, in this particular case, Google did not create a compatible implementation nor intended to (although maybe they could have other valid arguments for fair use).
The problem with the interpretation of "copyrighting APIs" is that there can be many different kinds of interfaces. Some of them are code, some are algorithms, and some are physical. This case is not about copyrighting the concept of an interface, but of the copyright of about 11KLOC. Analogies that do not involve the copying of hundreds of pages of a copyrighted work are irrelevant.
I am not saying that we should or should not exempt declaring code from the copyright of the work it is part of; I am also not saying that fair-use should or should not apply to Google's copying. I am saying that the statement that this case is about "copyrighting APIs" in general is biased, because the case here is peculiar and extreme. I cannot think of any other similar case in the history of software, and the number of cases that are somewhat similar can probably be counted on one hand (we've certainly never seen copying of this magnitude).
For more details and discussion of this actual case (rather than a general issue which may or may not be pertinent), see former Sun executive Scott McNealy's amicus brief: https://www.supremecourt.gov/DocketPDF/18/18-956/133505/2020... It is of particular interests because it actually talks about the specifics.
This is how he starts:
> This case is about Google’s unlicensed copying of approximately 11,000 lines of Java SE code written and copyrighted by Sun/Oracle
and then goes in more detail into what was copied, the creativity involved, the common understanding in the industry that at the very least these particular APIs (regardless of others) were protected etc.
So before people start hypothesizing whether and how this case could generalize, I think they better understand the specifics.
> Prove this?
In Java, declaring code specifies complex class resolution, loading and initialization algorithms.
> All code is "functional" and yet creative and copyrighted.
People used to say that about logos too, but Sega v. Accolade put a stop to a particular misuse of copyright in a way that I believe is similar to what Oracle is trying to achieve here.
As for whether the copy was meant to be "compatible" we both know that's a huge can of worms, it was meant to make source usable with minimal porting effort (i.e. on the level of the old "write once, run everywhere" Sun once touted Java via) rather than meet the particular Java compatibility test scheme that existed.
Also, there are always going to be compatibility bugs between versions, but I don't see that as having any bearing on this being a fair use and neither did either jury who found fair use...
> This case is not about copyrighting the concept of an interface, but of the copyright of about 11KLOC
The bulk of which is merely an interface.
> I am saying that the statement that this case is about "copyrighting APIs" in general is biased, because the case here is peculiar and extreme.
It is peculiar, but I strongly feel that it would go in the wrong direction. I believe the original ruling in Alsup's court was correct, if somewhat novel.
> In Java, declaring code specifies complex class resolution, loading and initialization algorithms.
That's not what I'm asking to prove and that, again, is just a matter of finding the right code and putting the right values in place (i.e. an interface).
Java doesn't give a damn what's implemented in the JAR file's classes, it just knows that it was asked to find the code there with a specific class name and pass it specific values that were named. The actual bytecode is nothing alike, so the "copying" is just to let compilers find the right code to link up, trying to make good on Sun's old write once, run everywhere promise.
So it's just an interface to find the right code and feed it values.
I don't understand what any of what you said has to do with established copyright law, and are you saying that IFTTT or Zapier are not copyrighted because they're "merely an interface" (what Java does for declaration code is as complex as what they do)? What about Haskell's mtl or lens that do even less? They seem to think they're copyrighted: https://github.com/ekmett/lens/blob/master/LICENSE
Oracle sued over the act of copying of 11K lines of extremely creative code for commercial purposes and not for compatibility. Nothing of this kind and magnitude has happened in the software industry. Any claim that this is about "copyrighting APIs" in general or changing anything about copyright and fair-use are biased interpretations.
I have a question that's slightly off on a tangent.
The project for some compilers courses is implementing a compiler for a subset for Java. Would the current ruling mean that doing the project is copyright infringement?
> The project for some compilers courses is implementing a compiler for a subset for Java. Would the current ruling mean that doing the project is copyright infringement?
Fair use would probably protect you because you're doing it for non-commercial educational purposes. But further, this lawsuit is not over the Java language, but it's libraries.
Probably not, but if you're worried derive your work from the OpenJDK implementation that has a valid GPL + linking exception license granted by Oracle, and comply with the license (which basically just means licensing your course project GPL + linking exception and supplying source code whenever you supply a binary).
I fully expect the Supreme Court to rule as narrowly as they can on this case. As others have pointed out, to rule otherwise could potentially disrupt the entire software industry.
"Alternatively, the Supreme Court could hold that software interfaces are sometimes eligible for copyrights but that Google's copying falls under the fair use doctrine. This would save Google from writing Oracle a 10-figure check, but it could still drag the software industry into a legal quagmire."
I'm hoping for a ruling that can be basically summed up as "The merger doctrine is evaluated at the time the copying takes place, therefore we reverse the federal circuit and don't have to decide the rest of this nonsense".
Explanation: The merger doctrine is the doctrine that if there is only one way to write something it isn't copyrightable/copyright infringement. Alsup (the original judge) interpreted this as being interpreted at the time Google copied the API, at which point in time there was only one way to write an API compatible with existing java programs, thereby killing Oracle's case. The federal circuit reversed based on the idea that it should be interpreted at the time of the creation of the copyrighted work, at which time there was no reason to favor calling something "java.lang.String" instead of "java.std.String" and so on.
Fair use is a lot more complicated to deal with than the merger doctrine. Ruling based on it will almost certainly result in a lot more pointless court cases as people debate whether or not this instance is fair use.
I think there's a case to be made that there's nothing novel in an API itself (emphasis on the interface). The novelty comes from the implementation, whereby competition actually kicks in (novel algorithms, data structures, storage techniques, etc.). But maybe I'm missing something? I come from a distributed systems background, so my bias is likely titled.
Naming decisions are pretty inherently creative, I don't this this argument works. "Stack", "push" and "pop" are obviously novel imho. The inventor of the stack api could have instead called them "LIFO", "Put" and "Take" for instance.
I agree, I'd never argue that there isn't creativity involved. It's essentially language. And someone said before that there's a base level of competency involved in making API decisions. It's more the argument of what's actually making you money or providing competitive edge. I can see edge cases where, with matching feature sets for two competing products, the API matters a great deal. API and functionality definitely influence each other, I just see it as a weak argument that copyright is broken when the interface is copied, not the implementation.
> It's more the argument of what's actually making you money or providing competitive edge
This would factor into the fair use analysis and the damages analysis, but not the analysis of whether or not the material was copyrightable in the first place.
PS. For what it's worth I agree with you that this isn't copyright infringement, I just think it's important to get the arguments for why it isn't copyright infringement right. The two arguments I like best are "the merger doctrine" (If there is only one way to write something, in this case a API that existing java libraries can use, then it isn't copyrightable) and "fair use" (Vaguely speaking an exception for copying we as a society don't mind, defined in the law here https://www.law.cornell.edu/uscode/text/17/107).
yep, APIs are a work of art. the API you chose would vary a lot by the individual who designed (and Acceptance tests they were required to pass) as such, there is a novelty in them. whether it is worth patenting or copyrighting is separate matter.
I agree there's nuance to the issue, and thst's where the argument is to be made. But I think it'd be a bad faith application of copyright or patent law, as your competitive edge largely doesn't come from API design but the product being interfaced with.
IBM wanted companies to embrace SQL - because then people implement applications already compatible with their database product, and conceptually could migrate without rewriting their applications.
Amazon wanted companies to embrace S3 - for the same reason. Or maybe they didn't, but they decided that the API was the least significant compelling part of their product - that people would still choose S3 regardless of whether other storage offerings had the same API - for the cost, and durability.
Sun wanted Google to use Java. Because more developers using the language, regardless of the underlying implementation is better for the entire ecosystem.
Oracle doesn't.
So to some degree i do feel like consent matters here. It doesn't matter if Oracle copied Amazon's S3 API illegally if Amazon doesn't care enough to pursue it.
Finally, I hate arguments that say "It's just the API". We all know a good API makes or breaks developer tools.
Ultimately, I feel like it goes without question that a decision in Oracle's favour will cause irrevocable damage to the industry and permit all sorts of bad actors to start looking to purchase ownership to APIs just so they could sue those they consider infringers.
But I can't help but feel that ultimately Oracle has a point :(
> But I can't help but feel that ultimately Oracle has a point :(
Copyright is not some innate right. Interfaces should not be copyrightable just because they require some level of competence to design.
If it was a patent then at least the term would expire, but copyright lasts a very, very long time. Car companies would love to copyright mechanical interfaces and so prevent anyone from making aftermarket parts.
> Copyright is not some innate right. Interfaces should not be copyrightable just because they require some level of competence to design.
The purpose of copyright, according to the constitution is "[t]o promote the progress of science and useful arts". So generally, things should be copyrightable if granting the copyright results in more and higher quality work. If APIs are indeed protected, there it is plausible argument that we will have more of them and they will be of higher quality.
That is an argument for the idea of copyright itself. It's not an argument in favor of the current system and it also proves no justification to expand the current system.
> That is an argument for the idea of copyright itself. It's not an argument in favor of the current system and it also proves no justification to expand the current system.
You're wrong. The constitution grounds copyright (and other IP rights), in utilitarianism. Meaning, if granting stronger protection promotes overall welfare, then that is justification.
The problem with utilitarianism is that it's very difficult to determine what is greater "overall welfare". By its nature, it's an empirical decision. Once you start invoking data (rather than basic rights), lots of people and companies will come out of the woodwork to promote their own data points.
> If APIs are indeed protected, there it is plausible argument that we will have more of them and they will be of higher quality.
Sure, but that immediately brings to mind the question of whether such fragmentation will be a hindrance to technological progress. And there's little doubt about which way the evidence tilts on that question—there's way too much mainstream software that would not have been legal without the right to reimplement an API without a license. So then it becomes a question of whether it is better for the law to promote good API design, or to promote actual useful software.
> The idea that giving people an effectively eternal copyright interest in making interoperable software would improve software strains credulity.
Why would it? Giving a company the right to prevent interoperability does not necessarily mean they will invoke that right. It also might promote alternative APIs potentially fragmenting the market, but also inventivizing various approaches. It's not clear that this is the case, but it's not clear that it isn't either.
You may as well argue standards have lowered innovation.
> Giving a company the right to prevent interoperability does not necessarily mean they will invoke that right
I hope that whoever created int max(int a, int b) is benevolent because just about every programmer has reinvented that at some point. What about Response get(String url) which returns an HTTP GET response. We have probably all written that at some point and most HTTP libraries implement it.
> I hope that whoever created int max(int a, int b) is benevolent because just about every programmer has reinvented that at some point. What about Response get(String url) which returns an HTTP GET response. We have probably all written that at some point and most HTTP libraries implement it.
FUD. You're using extreme arguments that traditional copyright law handles them well. API functions like "max" or "get" are so basic and general that they would not be protected by copyright law because they are not original "creative" works... a "max" function can only be written in a few ways that don't really rise to the level of creativity.
However, a massive amalgamation of functions and classes, could be protected. I don't see any theoretical reason why they shouldn't, just practical ones based on what the software industry has expected as standard behavior.
It means most will or alternatively their next of kin 10 or 30 years later. The human race hasn't proved benevolently disposed without a positive social norm to abide by in the entire REST of human history.
Given the choice between honest work and preying on our fellow human being its always easier to exploit. This is why despite being proposed as a means to inspire creation copyright theoretically expires 7O years after you die and realistically never. Once someone has conceived of a way to extract value out of their fellow human beings that extraction becomes a right regardless of how it effects civilization as a whole and most of this value doesn't even flow to creators it flows to soulless intermediaries who have inserted themselves between creator and consumer. Why given the opportunity to exploit more would they NOT?
> Given the choice between honest work and preying on our fellow human being its always easier to exploit. This is why despite being proposed as a means to inspire creation copyright theoretically expires 7O years after you die and realistically never.
Your argument is not really about intellectual property rights, and is more about property rights and capitalism generally. If you don't believe in property rights or investment, then sure, IP rights don't make sense either.
I believe in property rights with reasonable limitations like taxation on same. I do not believe in IP at all beyond say trademark protection making it possible to know what you are buying.
We will have more of them, but they would be of _lower_ quality. Because they could no longer build off one another. You would start to see different API's because they _had_ to be different, not because they were better.
For an example of how this plays out, look at the proliferation of desktop GUIs in the late 80s and into the 90s. Everybody was throwing in gratuitous differences in the hopes of making their look and feel "different enough" to avoid a lawsuit. So we ended up with a mess: swapping the location of "OK" and "Cancel" buttons, every platform's scroll bars behaved differently, "Trash" vs "Recycle", and so on. There was some well-intentioned experimentation to see if the status quo could be improved, but those good ideas couldn't spread and become universal.
> look at the proliferation of desktop GUIs in the late 80s and into the 90s. Everybody was throwing in gratuitous differences in the hopes of making their look and feel "different enough" to avoid a lawsuit. So we ended up with a mess: swapping the location of "OK" and "Cancel" buttons, every platform's scroll bars behaved differently
I don't see this as a mess at all. I see this as very positive experimentation and eventual consolidation. Would it really be better if one company came up with a GUI and everyone latched on to it?
> Sun wanted Google to use Java. Because more developers using the language, regardless of the underlying implementation is better for the entire ecosystem.
> Oracle doesn't.
> So to some degree i do feel like consent matters here. It doesn't matter if Oracle copied Amazon's S3 API illegally if Amazon doesn't care enough to pursue it.
If consent matters, then Google implicitly received it from Sun, but had it removed afterwards by Oracle. So if you actually support Oracle here, I don't understand how you can say "consent matters". The consent was given, yet you yourself don't consider it in Google's favor.
> Sun wanted Google to use Java. [...] Oracle doesn't.
By your reasoning, IBM could spin-off a division with intellectual property rights to SQL, sell it to Google for 10B, who could then claim "we never agreed SQL should be free!" and sue Oracle into bankruptcy
Oracle implemented similar technology at a time when organic growth was good for both companies. More technologist adopting SQL meant more sales for both companies. Oracle implementations on IBM hardware were and still are pretty common. I think IBM had no good reason to shoot a competitor that likely was helping their bottom line via adoption and popularization of database technology. The industry and the technology were evolving. Squashing it would have been a bad move for them at the time.
(I suppose just saying "Trump backs.." can be a signal indicating what the Trump supporting readers ought to think. OTOH, the same language on CNN has a similar effect in the opposite direction.)
No, the GNU AGPL doesn't have anything to do with copyright of APIs question (at least, no more than any other copyright license given these court decisions). After all, the GNU AGPL was published in 2007 -- long before this whole legal battle started and even before Android itself was released.
The GNU AGPL has additional restrictions that require redistribution of the source code under the GNU AGPL to users which access the software over a computer network (AFAIK those particular restrictions have not yet been tested in court, so it's entirely possible that they're unenforceable).
GPL (and particularly gplv3) was designed to follow the scope of copyright in what ever country it get used in. If a country choose to have a very wide definition of derivative work then that is the rule that GPL will use, while in an other country it can be much more narrower.
This case is also about fair use. Like all copyright licenses fair use give people exceptions when the exclusive right of copyright can be broken.
1) the comparison may be inapplicable. The case in hand does not rise or fall on hypocrisy. I am a bad actor does not forbid me pursuing a law case based on the law I break myself in another matter.
2) IBM has at least three strategies
a) leave alone: let sleeping dogs lie
b) pursue oracle but settle for cash or in-kind or IPR swap or RAND, or some outcome which advantages them (Redhat?) but nobody else
c) be an advocate for a movement and take a posture in the wider interest.
I think by "Copying a functional spec" he meant to say implementing someone else's functional spec, rather than just re-publishing it. So that what's being copied is not the copyrightable text of the spec, but the non-copyrightable abstract ideas described by the spec.
> I think by "Copying a functional spec" he meant to say implementing someone else's functional spec, rather than just re-publishing it. So that what's being copied is not the copyrightable text of the spec, but the non-copyrightable abstract ideas described by the spec.
Implementing an API spec is not just using the "abstract ideas" in the spec. It requires copying the specific text of the API: a function named DoSomething will incompatible with one named do_something.
I don't think that's a valid way to distinguish copying APIs and implementation.
On a purely theoretical basis, I do think APIs could be copyrightable, I don't think there is a valid way to distinguish them from implementation. The main argument against copyrighting APIs is practical: everyone has been doing it for decades, and changing the status-quo will be disruptive.
Another practical reason is that copyrighting APIs will decrease competition by impeding companies from creating better drop-in competitor products to established players. But this is really an argument against all software copyright, not just API copyrights.
I believe that's a fair price to pay for breaking the software industry.