What the panel essentially did was continue to apply Ninth Circuit law as it has existed since the 1989 Johnson Controls case holding that the sequence, structure, and organization (so-called "SSO") of a computer program may be entitled to copyright protection depending on the facts of a case. Judge Alsup had not disregarded this precedent but had found what in my view were superb ways of treating APIs in particular in a special way that rendered the copying of their SSO non-infringing - to wit, acknowledging that developing an API was even highly creative, a structure of this type, functioning as a method for compatibility only, should not in itself be protected by copyright but should be protected, if at all, only if it rose to the level of warranting patent protection. How he got there was somewhat complex given that this is a complex area of law. But that is where he had landed. The result, as a matter of policy, was very clean for developers: it gave the courts a workable roadmap for moving the copyright analysis into conformity with the modern digital age on the critical area of APIs and inter-operability without the need of having Congress address the issues.
This panel did the exact opposite. It held that, when it comes to the subject matter of copyright, if a form of expression meets the threshold of being "original," that is enough to make it copyrightable no matter what its function. If the developer of an API had to make creative choices in deciding how to set up the SSO of the API (and almost certainly he will), then the API is protectible and any attempt to copy the same SSO is infringing on its face, subject only to fair use and similar defenses. In so holding, this panel vigorously reasserted the Johnson Controls precedent that has hung over SSO analysis in the Ninth Circuit for many years - meaning, in the case of APIs, it is for a jury to determine case-by-case whether any particular SSO is protectible by copyright. The panel here by no means disregarded the concerns and issues raised by Google (and highlighted in Judge Alsup's decision) but it relegated them to being a potential defense under fair use analysis for acts that are otherwise presumptively infringing. The result: stronger IP protection for APIs and a wealth of uncertainty created for developers in trying to work with inter-operability issues in our modern age.
This case sparked intense interest and drew upon many top lawyers on both sides to argue the issues. It is by no means some hack result. Indeed, it could be argued to be far more in line with Ninth Circuit precedents than Judge Alsup's decision. It can be appealed further, possibly to the full Ninth Circuit complement of judges and possibly to the Supreme Court, and who knows whether it will be upheld or not.
But the really sad thing is the missed opportunity. This was a chance to bring clarity and order to an otherwise muddled area of law and this panel, rightly or not, chose to go back to the muddle. Should it ultimately be upheld, the only real solution in light of this is for Congress to amend the Copyright Act to do a carve-out for APIs to enable them to get special handling under the law to facilitate inter-operability.
Please indulge the following hyperbolic exaggeration to make a point: In the natural-rights view, the most important people to recognize and compensate are (supposedly) those who think up good ideas; other folks who deal with "mere" execution details are less deserving (again, supposedly) of status and financial reward.
One might call this the "think and grow rich" school of intellectual property. Or, from The Music Man, Professor Harold Hill's "Think System" of learning to play a musical instrument without actually practicing.
I'm going to steal that one, though I may have a slightly different understanding of the dichotomy: the natural-rights view would focus on rewarding creative people, and the utilitarian view would focus on benefiting everyone.
The utilitarian view is obviously the correct one, but up until now, I didn't have the words to express it.
That's the precisely the general tenor of the Jeffersonian view, according to a canonical Supreme Court opinion, Graham v. John Deere Co. of Kansas City, 383 U.S. 1 (1966), starting at page 7 of the opinion .
Here's an excerpt (with the Court's citations omitted and emphasis and extra paragraphing added):
Thomas Jefferson, who as Secretary of State was a member of the group [three Cabinet officials who served as what might be thought of as the first U.S. patent office], was its moving spirit and might well be called the "first administrator of our patent system." He was not only an administrator of the patent system under the 1790 Act, but was also the author of the 1793 Patent Act. In addition, Jefferson was himself an inventor of great note. His unpatented improvements on plows, to mention but one line of his inventions, won acclaim and recognition on both sides of the Atlantic.
Because of his active interest and influence in the early development of the patent system, Jefferson's views on the general nature of the limited patent monopoly under the Constitution, as well as his conclusions as to conditions for patentability under the statutory scheme, are worthy of note.
Jefferson, like other Americans, had an instinctive aversion to monopolies. ...
Jefferson's philosophy on the nature and purpose of the patent monopoly is expressed in a letter to Isaac McPherson ... He rejected a natural-rights theory in intellectual property rights and clearly recognized the social and economic rationale of the patent system.
The patent monopoly was not designed to secure to the inventor his natural right in his discoveries. Rather, it was a reward, an inducement, to bring forth new knowledge. The grant of an exclusive right to an invention was the creation of society—at odds with the inherent free nature of disclosed ideas—and was not to be freely given.
Only inventions and discoveries which furthered human knowledge, and were new and useful, justified the special inducement of a limited private monopoly.
Jefferson did not believe in granting patents for small details, obvious improvements, or frivolous devices. His writings evidence his insistence upon a high level of patentability.
As a member of the patent board for several years, Jefferson saw clearly the difficulty in "drawing a line between the things which are worth to the public the embarrassment of an exclusive patent, and those which are not." ...
Some good discussion on API design:
Even though no patent issues were appealed, fed cir still has jurisdiction, and oracle used it to appeal to fed cir.
This is in keeping with our existing notions of IP. It would preclude someone who wants to make a toy related to Mickey Mouse claiming that the only way to make such a toy would be to use the trademarked and copyrighted material of Disney.
Fair use exists so that fans of Mickey Mouse can put up websites about Mickey Mouse, write reviews of cartoons, etc. Disney benefits from this activity, just as Sun has benefited from all of its pre-2010 goodwill toward Java.
For example, this was an internal email by Google's Android boss Andy Rubin in 2005:
"If Sun doesn't want to work with us, we have two options: 1) Abandon our work and adopt MSFT CLR VM and C# language - or - 2) Do Java anyway and defend our decision, perhaps making enemies along the way"
Intent and knowledge matters a lot in court decisions, so the above makes it seem that Google had full knowledge of the risk it was taking and still went along with it kicking the can down the road rather than officially license .NET or Java by paying Microsoft or Sun.
I remember Alsup used Sega v Accolade/Sony v Connectix from the Ninth circuit and Lotus v Borland from the First to justify his ruling. Did this panel decide that his line of reasoning was flawed/misapplied with regards to the previous fair use decisions (aka this isn't a case of fair use) or was this issue just out of his jurisdiction (which is what "it is for a jury to determine case-by-case" sounds like)? Or did they over turn the precedent that Alsup used?
Also, how does this ruling change the rest of the case? Does Oracle have a chance to restart the battle from square one or will they only be able to go to court for infringement on IP that Alsup had previously claimed uncopywritable?
I don't see how that should change the result. An API is an API from the time it's created. It's inherently functional. You can't change a single argument or function name without changing the functional behavior of the API, which is as true the day it's created as the day someone wants to create a compatible reimplementation.
It seems to me like trying to claim a copyright over e.g. the shape of a toner cartridge for a printer because some creative process was used to generate the shape, even though it's the only shape that will fit in that printer, with the intent of using that to prevent anyone from making compatible toner cartridges for 95 years. That's clearly not what Congress had in mind when passing the Copyright Act.
As I understand it, what can't be copyrighted is the proportions/ingredients/cooking methods. So if someone writes a new recipe that happens to describe the same dish that someone else's cookbook's recipe would have you make, that is not infringement. But if you copy the recipe from the cookbook, it is.
Whether you should be able to protect such a creation from copying is an issue for society to choose. So far it has chosen poorly.
I don't think that argument is a winner. Take any man-made thing, you can find some creativity that went into designing it. And that's the point -- creativity is not the sole determinant of copyrightability. What would be the purpose of the Patent Act if you could get 95 years of copyright protection just by describing invention as a creative process? Drug companies use creativity when creating cures for diseases. Should the formula or process of manufacturing for the Polio vaccine have to be licensed to this day under copyright?
One recent, concrete and particularly brazen example is the llquantize() DTrace aggregating action, which was added to illumos after Oracle forked OpenSolaris by closing it. Oracle has copied this API verbatim in Oracle Solaris 11.2, despite not holding copyright to it. One presumes that they didn't copy the implementation (it's open source, but with a weak copyleft that would prevent its inclusion in closed source software like Oracle Solaris), but by Oracle's principles in the Google case, they would have violated copyright. While I would love to pursue this on a purely personal level, the reality is that the principle itself is wrong: Oracle actually should be able to implement the llquantize() API, just as Dalvik should be able to implement the Java APIs. But it would make my day if llquantize() could somehow be used by Google's lawyers to show that Oracle themselves do not abide by the perverted and depraved principle that they espouse...
There are a lot of built-in functions (the API part) that are just expected to be in every implementation (TRUNC(), UPPER(), LOWER(), etc, etc).
edit: just to be clear, this is not sarcasm.
IE Say FredCo has C++ and Java clients for their API. You decide to make and publish a Ruby client. If you use the same Structure, Sequence, and Organization of the API (IE you use the same API), congrats, the court thinks you are infringing copyright.
This is the simple version. Think about compilers and ABI's and SQL extensions and all sorts of things, and you can see this decision is truly terrible for open source.
1) This isn't binding precedent nationwide, like a patent ruling would be, and most copyright cases aren't going to end up in the Federal Circuit. The other Courts of Appeal will have their say in deciding the issue, and with any luck a circuit split could result in Supreme Court review. In particular, I'm not sure they're going to buy the Federal Circuit's merger doctrine analysis.
2) The court repeatedly mentioned that Google copied 7,000 lines of declarations verbatim. I wonder how many gaps are in the reasoning of this case to stick a knife through in cases where there wasn't such literal copying.
I meant that open source projects that reuse API declarations or parts aren't typing them themselves, they are copying those API declarations verbatim from somewhere.
Ray's point what if they didn't copy, it may not be an issue, but they all do copy.
Here's a related but not exact example of what typically happens that i actually happened to have open in another window:
Notice the comments.
These are taken, verbatim, directly from the definitions in Google's GQL reference.
Because it's a parser, there are no declarations, only a grammar implementation (which, BTW, would also fall under this precedent).
However, you'll see the same thing in open source projects that do API implementations as well.
Person A reads the declarations and writes down what they do, without mentioning any function names or argument names.
"This function returns the index of a character in a string."
int findIndexOf(String s, char c);
Now, at this point, what you have is something functionally the same as Java's String object. Do this for all classes. Call this bundle something like AlterJava. (Or YerksDiddy if you really worry about the name.)
Then someone writes a tool that translates Java into AlterJava. It's an easy thing to put into the compiler chain.
I'm skeptical of these "just hop through this hoop and you aren't breaking the law" ideas when other people make them, so feel free to tell me I'm missing something.
EDIT minor edits
This was much discussed in the early days of the PC; if memory serves, it's basically the approach that was taken by the first successful cloner of the IBM PC BIOS .
 http://en.wikipedia.org/wiki/Phoenix_Technologies#Cloning_th.... Also http://www.linuxinsider.com/story/33839.html
Do you have examples of FOSS projects copying code while not abiding by the license?
Again, I really think you're taking this out of proportion. This decision does not affect you if your implementing an API in accordance with the license.
Some people keep saying that this decision is bad for FOSS, but they can't come up with examples of FOSS that will be affected (there are probably a few projects, but nothing that will shake up the industry).
"AFAICT, GQL is Apache licensed"
This page (https://developers.google.com/appengine/docs/python/datastor...) is not Apache Licensed.
It's "Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 3.0 License,"
Given they haven't complied with the license (no citation, no attribution), calling this a "licensed use" is quite a stretch. It's actually pretty clearly not a licensed use.
"This decision does not affect you if your implementing an API in accordance with the license."
Which open source projects rarely do ...
Really, do you think the TOS of most of these websites or software allow you to make your own implementations?
Are most of them who do get "licenses" being careful about actually following license requirements?
As to copyrighting a language:
The appeals court makes a clear distinction between the Java programming language (i.e., the commands/keywords that are free for everyone to use) and the APIs, and finds that only three of the Java APIs in question are basically part of the Java language, but "Google could have written its own API packages using the Java languages", which, as the opinion notes, "Google chose not to do".
Do you think this is a licensed API?
Your "nobody will sue tiny projects" thought is contravened by history.
We'll strongly disagree as to where this decision will lead. Thankfully, I know i'm not the only one worried.
Also, fosspatents is not a legal decision, nor did you actually cite anything that backs up your claim:
Your claim was the decision says the language was not copyrightable. It says no such thing.
What it says is "It is undisputed that the Java programming language is open and free for anyone to use."
This is because it was licensed, not because it is uncopyrightable.
He is loyal to his employer but his analysis and projections are often contradicted by facts.
I didn't know about the Katzer case, but I still see no danger to the FOSS community and ecosystem by the new ruling. All it would do is require developers to clearly specify the license for their APIs. Cloning of proprietary APIs is most certainly not a cornerstone of FOSS today (unless, that is, Linux is in actual danger, in which case I'll change my position).
"Cloning of proprietary APIs is most certainly not a cornerstone of FOSS today (unless, that is, Linux is in actual danger, in which case I'll change my position)."
I would disagree, but I can't say more, sadly.
Perhaps Google didn't comply with OpenJDK license because it didn't exist when Google used Java Apache Harmony implementation.
And even if they were, if the originals were copyrightable, there's no copyright-relevant difference between "typing them themselves" and "copy and pasting", both are verbatim copying (and, even not doing a verbatim copy and merely doing a "derivative work" based on the existing API would be -- barring fair use or other explicit exception -- a violation of copyright if the API, as such, was copyrightable.)
So I'm imagining a bunch of Java classes loaded into memory. They're objects, and they have methods, and those methods refer to methods in other objects. Creating this state of memory is functional, and definitely not protect-able. Now, the interface declarations, then, are just a description of this state of memory. A method has a particular name or a particular set of parameters but those are just a description of the functionality, and there is no other way to precisely describe that state of affairs. The closest analogue I can think of to an API is a phone book, and the names and addresses in a phone book are not copyrightable, although higher-level structure might be.
I think the court got stuck on the verbatim copying and that prevented them from seeing things this way.
Though both making verbatim copies and making derived works are exclusive rights of copyright owners so that doesn't really reduce the impact of API copyrightability on API reimplementations,
And what is copied verbatim are just the headers
If you are using different languages that compile to a compatible target, or if you are using the same language that admits different literal declarations expressions that produce the same interface, it is possible to have an API reimplementation -- for the same target platform even -- that does not involve verbatim copying of even the headers/declarations.
For example, in C, this would involve function name aliasing which is usually a compiler specific extension.
This might give you name compatibility, but to get struct-level compatibility, you'd have to copy the exact layouts due to padding issues.
In C++ it's even harder, due to when vtables are emitted, etc.
My java knowledge is old (java 5), so i don't know if they made it possible.
Objective-C, I believe it would only be possible if you used the runtime reflection methods directly. I don't think you can easily do it with just headers (corrections welcome!)
And that's the crux of this case... is an API copyrightable?
Apple's decision to stick with (objective) C is turning out to be a really smart move. That it runs 2x faster than java is another bonus.
Bottom line: you can use java but don't get stuck so bad you can't refactor out of it. And don't trust Oracle. Regardless.
Also, what's being litigated here is not Java-the-language but Java-the-core-API-interfaces.
You could refactor your way out of those, just provide alternate versions of java.io, java.lang, etc, new redesigned core APIs.
It would break core Java compatibility, but Android is so big, most people would port their Java libraries, and in the end, Oracle would be hurt more, since they rely far more on server-side Java, but most of the world's Java programmers would be migrating to writing mobile apps, probably with non-Java backends, or Java + new Core APIs.
is owned by "The Open Group"
One of its purposes is to provide Single Unix Specification (SUS) certification.
Mac OS X is SUS v3 certified (I don't think iOS is) and can call itself UNIX, and there is 0 danger of anyone suing you for implementing POSIX API or SUS. You just can not claim you are providing a UNIX without getting certified. This is why Linux is UNIX-like OS and not a UNIX.
This has never been litigated before. Past UNIX copyright wars were fought over copying actual code between Unix and clones. No one has ever tested whether API reimplementation of Unix is copyrighted. Implementing as public spec won't save you. Java has a public, open, specification and was clean-room reimplemented in much the same way that Linux is not Unix, Android Java is not Java.
Claiming there is 0 danger in being sued sounds like naively wishful thinking, especially with Apple's deep pockets, there are plenty of lawyers out there looking for ways to crack that nut.
Oracle's claims here are rather ridiculous, and even Oracle doesn't believe Swing or J2ME apps are appropriate for today's smartphones. It's a red herring of compatibility that no one cares about or wants to be compatible with.
What makes Java valuable to most developers is byte-code portability, the widespread use of the language, the core APIs (not the GUI), and the developer tool chain.
The Sun licenses for Java go back to a time when they had a dream to displace Windows on the Desktop with all native desktop apps written in Java. That reality was delusional, but Java succeeded brilliantly on the server.
My personal opinion is not about what is legal, but what I think is ethical and justified. The current system is broken and needs to be reformed.
You seem to want to defend the status quo. That's your prerogative, I think you're advocating for a world that makes everyone worse off, but we can agree to disagree.
Google's use of the Java APIs is different; Google intentionally makes it so that Java applications do not run on Android and Android applications do not run on Sun's JVM. Google is not trying to implement those APIs for the purpose of interoperability. A finding that Google's appropriation of those APIs for their own runtime environment is not fair use is not a finding that WINE's use of Windows APIs in order to enable interoperability is not fair use. What's at stake here is more narrow than what several posters have surmised. You can argue that what's at stake here is still important, which is a discussion worth having, but posts in this thread about (for instance) how the PC compatible market wouldn't be allowed to exist under this ruling are mistaken.
And why would it not be copyright infringement to implement a full API, but is copyright infringement to implement a subset of one?
When Phoenix cloned the PC bios, they did it on the assumption that if they reverse engineered the complete API specification, and then had a separate group of engineers perform the implementation, there would be no infringement, because no one in the history of computer science thought API interfaces could be copyrightable.
IBM was powerless to stop them, and clones flourished. With this precedent, would Phoenix have attempted the clone? Would IBM have not sued over copyright infringement of their interface?
Pretty much all clean room implementations since then have proceeded on the basis that implementing someone else's API, even against their wishes, is not an infringement. It's been the default assumption for decades.
To act like this Court decision has not flipped over decades of practice is putting way too much trust in the companies out there to show restraint and not unleash a tidal wave of copyright suits.
Not quite. The freedom to re-implement Unix APIs was litigated. If I recall correctly, it was settled rather than won (that is, there was not a court decision but rather a settlement agreement).
Blanket statements like "ObjC is 2x faster than Java" is... well, a blanket statement, and in general, wrong. It depends so much on what, precisely, you're doing, how you're doing it, the compiler and JIT implementation, etc.
Go, Erlang, Haskell, C++, Rust
The reason for using Java is the corporate penetration and being the de-facto language for thousands of developers. I seriously think that Java as a language is old and hard to use (hello Clojure & Scala) and on the top of that owned Oracle is the biggest patent troll in the history of humanity, so even implementing the APIs can lead to lawsuits just like the example above.
Now the only question is, why the hell do we still implement new things in Java in 2014? Time to wake up, get a language that is free by every meaning free has and bury Java for good. Is this hard? Definitely is, but if we don't start it today when can we stop Oracle from suing your startups because you implemented an API. Changing US law seems harder. :)
Go has about 0.0001% of the third party library base that Java does. Many of which are essential for large scale enterprise development. It's why languages like Clojure and Scala have become a lot more popular because they leverage the ecosystem.
No one will move just because of some insignificant lawsuit.
Virtually none of the 'go' job ads have anything to do with programming.
This is a "let's send the US back into stone age!" kind of decision.
You mean like how Dalvik is Google's BSD (Well, Apache 2.0) licensed clone of Oracle's GPL licensed Java? (http://www.fsf.org/news/fsf-welcomes-gpl-java.html) :)
The issue at hand was that Oracle specified that any implementation using their Specifications license be compatible, and the Dalvik implementation is not compatible.
So it isn't that Oracle is going back on their word, it is that Google did not follow the rules of the license.
It's more proper to view it as a right.
Dr. Seuss Enters., L.P. v. Penguin Books USA, Inc., 109 F.3d 1394, 1403 (9th Cir.1997);
Supermarket of Homes v. San Fernando Valley Bd. of Realtors, 786 F.2d 1400, 1408–09 (9th Cir.1986)
In this case however the biggest damage is that they reversed the ruling that APIs aren't copyrightable. Is there any way that Google can reappeal it in a higher court, or it's a final decision? In Europe APIs were ruled uncopyrightable some time ago, but somehow this didn't help in this case.
Whether that happens or not, they can also appeal it to the supreme court.
Suffice to say, my completely personal view is that it was appealed to this very court for a reason. Normally, this is the court that hears all patent appeals. Because the original lawsuit involved patent claims, they have jurisdiction, even though there are no patent claims being appealed.
Otherwise, it would have gone to the 9th circuit, who, i suspect, would have been more favorable.
A fair use defense means that something happened that would otherwise create liability, but doesn't because of some (often policy) reason. Making something an affirmative defense has procedural implications. But "rights" can be implemented as affirmative defenses. For example, truth is an affirmative defense to defamation in the U.S., even though it's closely connected with free speech rights.
EDIT: But see dragonwriter's very pertinent comment about defamation cases involving matters of public concern, where falsity is an element of the claim rather than an affirmative defense.
The practical distinction is that it's easier to dispose of cases on a motion to dismiss when something is a required element of the claim versus when it is an affirmative defense.
This is wrong, at least on matters of public concern, specifically because it is connected to free speech rights, both for public figures and private figures as plaintiffs, who bear the burden of showing falsity rather than the defendant having the burden of showing truth.
See Philadelphia Newspapers v. Hepps, 475 U.S. 767 (1986); New York Times v. Sullivan, 376 U. S. 254 (1964).
Second, not too many open source projects implement proprietary APIs. FOSS today does not get its value from producing fully compatible clones of proprietary software.
Third, proprietary software vendors will face the choice of limiting the use of their APIs (i.e. copying) by OSS and risk reduced adoption, or allow it to get wide adoption and offer a superior implementation. I'm not sure most would choose the former.
So with the state of FOSS today, I don't see how such a decision changes much. I would very much like to hear if people have counterexamples (other than WINE).
The jury ruled infringement in the Oracle - Google trial
Jury was deadlocked with 9 juries supporting fair use and 3 saying that there was not fair use
The gpl exists to promote the creation of open source software, not to keep people from using open source. Just because this makes it more enforceable in no way makes this good for open source.
we conclude that the declaring code and the structure, sequence, and organization of the 37 Java API packages are entitled to copyright protection. Because there is an insufficient record as to the relevant fair use factors, we remand for further proceedings on Google’s fair use defense.
Some further detail found later on:
On balance, we find that due respect for the limit of our appellate function requires that we remand the fair use question for a new trial. First, although it is undisputed that Google’s use of the API packages is commercial, the parties disagree on whether its use is “transformative.” Google argues that it is, because it wrote its own implementing code, created its own virtual machine, and incorporated the packages into a smartphone platform. For its part, Oracle maintains that Google’s use is not transformative
So it looks like there will be a new trial.
And the opportunity to appeal the CAFC decision on copyrightability to the Supreme Court.
The entrenched players benefited from an enormously more free era of software development, we now live in an age where every line of code, every UI widget, every pixel, is going to be patented and copyrighted.
If you develop any code and achieve any success at all, there will always be a sword hanging over you.
The whole system is going to have to implode before it will be reformed. Last year 92% of patent applications were approved. Every area of human thought is being fenced off.
It's funny & sad how US customers are seen as property of corporations.
That is why Free Software is important.
There was plenty of effort to lock people out of competing; they just didn't have software patents back then.
If AT&T had strong copyright claims on the "APIs" that make up the system calls of UNIX, for example there goes Linux (and essentially the entire GNU and BSD projects as well), there goes modern MacOS, etc, and the reverberations would be enormous even with fully closed sourced OSes like Windows... With strong copyright on APIs there, essentially, goes the Internet as we know it when there isn't a clear path of UNIX->BSD/POSIX->sockets for everyone to copy (and thus be interoperable with each other).
This is something developers (and anyone who cares about technology, really) should absolutely be hysterical about.
I am not aware of any significant proprietary API today that is in widespread use, and is cloned by FOSS. But I could be wrong on that. If you know of such APIs, I'd love to know which ones are in danger.
Linux is a perfect example of a proprietary API (Unix) which is in very widespread use, which was cloned by FOSS. Most of the Unix command line utilities were explicitly cloned by the FSF to be compatible with existing shell scripts on Unix.
Adobe made Flash proprietary and it became incredibly widespread, so widespread that if you turned if off, many websites would break, despite the fact that it had numerous performance and security issues. Flash made it to something like 97% penetration of all Web clients (prior to Apple iPhone) People have cloned Flash (hAXE for example), but there was really no reason to do it, because Adobe offered the player free of charge.
WINE is in widespread use. Samba is in widespread use. Lots of Website REST APIs have been cloned.
Adobe PDF was proprietary and widespread cloned until in 2008 it became an open standard.
Cloning APIs is a time honored tradition for "embrace and extend". Microsoft even cloned proprietary APIs, and DOS itself started out as an unauthorized clone of CP/M. Where would Bill Gates be today without Seattle Softworks?
I hate having to resort to the tired ole idea of rich people having gotten rich by theft, but in many cases, it's quite true, that Gates and Jobs both freely copied, cloned, and modified other people's stuff, got stupendously wealthy off of it, but somehow, it's wrong for us to want to practice their methods?
My question was about how the current ecosystem will be disrupted. Now, with WINE -- I agree, but I don't think it's in widespread use, and I don't think Microsoft will go after them. AFAIK, Samba implements a networking protocol, not an API (but I may be mistaken).
It really all comes down to Linux. If Linux is in danger, then obviously the ecosystem can be disrupted by this ruling; if not -- then probably not. I must say I don't know enough about the current legal status of Linux, and whether or not it's in real danger.
In other words, "I got mine". People who profited and got stupendously rich, get off scott free, and are free to deploy lawyers to interfere with the next wave of participants. Not unlike immigrants who settle in, and then want to slam the door on the next group of immigrants.
>Samba implements a networking protocol, not an API
Protocols and APIs are another distinction without a different. If the sequence, structure, and organization of an API can be copyrighted, then surely, the sequence, structure, and organization of a wire protocol or file format can, after all, the only real different is the invocation mechanism.
While it might be easy to analogize between an API and a wire protocol in terms of technology, that doesn't mean that analogy holds within the framework of copyright law. The Fed. Cir. opinion was expressly couched in terms of the "sequence, structure, and organization" of the names in the API. Indeed, the opinion concedes that if Google had chosen different names, then things would be fine. Putting the same bytes at the same offsets is not at all the same as naming things the same way.
We live in a world of protocols that are increasingly RPC/REST based which as others have mentioned are really just APIs you happen to access over a network connection.
If I recall correctly, the SMB networking protocol is a RPC protocol. In other words, it's an API, just invoked remotely.
On the web front, AWS APIs are significant, proprietary, arguably in widespread use, and cloned by FOSS (Eucalyptus).
In a lot of ways the situation being defined by this ruling is way worse than patents given that copyright is essentially infinite these days (pseudo-time-limited, but constantly being extended due to the lobbying efforts of Disney, et al) whereas at least patents, as harmful as they are to overall software industry progress, run out after a couple of decades.
NFS is a corporative API developed by SUN, LDAP and Kerberos were also created by a corportaion (IBM), UNIX is a set of APIs created by Bell Labs, just like C.
If you grew up writing assembly code for 8-bit computers, all your APIs were BIOS firmware calls via traps, interrupts, or jumps.
No one said copyright is the same as patents, I'm just bashing both. I don't believe in copyrights or patents as applied to software.
But copyrighting APIs goes too far.
Au contraire, I think it clearly solves the economic problem of free-riding in this particular case. Consider:
1) Sun (and now by proxy, Oracle) made a huge investment in engineering to make Java, and a big part of its success was a API for the standard lib that maintained a coherence across disparate domains ranging from file systems to networking to databases to cryptography to UIs.
2) Sun made an even more massive investment in marketing to make Java as prevalent as it is today. Without marketing a language goes nowhere, and yet Java is ubiquitous. Along with 1), this represents a massive economic investment.
3) Google had no inclination of investing its own time, money and resources to build its own ecosystem and build developer mindshare for it, not when it was trying to compete with the iPhone and wanted warm bodies to build apps for their platform. To make it worse, Google's engineers and executives knew that a) they had no better alternatives and would require a license (google "Lindholm email"), and b) that they were not going to be complying with Sun's terms (Ctrl-F "Rubin" on this page). Yet they went ahead and re-used Java for their purposes without permission or recompense to Sun.
I don't see how that's not "economic free-riding" in the most literal sense.
In fact the only thing the clean room reimplementations of the IBM PC BIOS had in common with the original was exposing the same API.
Ideally this goes to the Supreme court and gets knocked flat. Doubly ideally someone amends to the Copyright act to specifically disallow this sort of argument for Copyright.
EDIT in response to @crashandburn4: Oracle still hasn't won the case, because the appeals court ordered a retrial of Google's fair-use defense, as to which the jury deadlocked in the first trial. See the slip opinion at pages 60-62 (and preceding pages if you want the legal background).
I sincerely hope we look back at this dark time and laugh at it like we do with powdered wigs. Unfortunately I just don't see any change on the horizon, so it's just as likely things will only get worse and worse, and innovation will be stifled even more.
Not copyright of API's
Copyright on actual implementation, not copyright on headers
This is absolutely and demonstrably incorrect.
(international court of justice)
Not that they aren't laughable and shouldn't go away. Likewise the black robes IMHOP.
The point is... we likely are going to be stuck with bad cultural remnants for a long long time which is why it is so important to get it right the first time. This ruling is a bad deal but Google certainly has the resources to fight further and I bet they do. Hopefully they scrap Java in the end.
Software Patents are a great sell for developers with an inflated sense of self-importance (and their bosses) thinking that everything they created is wonderful and unique.
Lawyers just played on that, and of course, they get their share of it
> "Under the Act, society is free to exploit facts, ideas, processes, or methods of operation in a copyrighted work. To protect processes or methods of operation, a creator must look to patent laws."
> It's there in black and white that methods of operation are not protected by copyright. So what is Oracle thinking?
Seems pretty clear to me!
I really wish Google had invested in the "nuclear" option and pursued a parallel development strategy to move Android entirely away from dependency on Java. If they had started 3 years ago and offered an alternative API (say, for example, based on Go, but it could be anything relatively efficient, even a brand new language), by now there would be a significant base of users and Google would be able to threaten Oracle with a wholesale migration away from Java. Even in their most delusional moments Oracle must know that losing Android would be a huge loss in terms of the mindshare and userbase. I think it's unlikely we'd be seeing Oracle pursuing this to the death if Google hadn't left themselves in such a weak position. (I have a secret hope that they have been doing this and will astonish us all by taking the wraps off it at Google I/O one day ...)
Also, how does this impact things like Wine, as the MS API set has never been open source (to my knowledge)
Actually in a wider perspective, I wonder how this will impact emulators in general.
Give someone dominion and that person takes on the role of the overlord.
Are they shooting themselves in the foot? I sure hope so.
Of course, back in the late 1970s when Oracle was just starting out by building a database based on a query language developed at IBM it would have been another matter entirely...
The fair use/enforceability side of things is where the interesting questions lie and that is the place for a messy compromise to allow some forms of interoperability. I would be most in favour for attempts at drop in compatibility and actually find Google's incompatible embrace and extend commercial manoeuvre quite unsympathetic.
But not everything that meets those criteria are, legally, things that can be copyrighted. Until Oracle, nobody assumed that an API (as opposed to the text describing it) could be copyrighted, since it is legally settled that a single function declaration (that is, not implementation) cannot be copyrighted, and an API is just a collection of function declarations.
We intend that this specification should sufficiently document the Java virtual machine to make possible compatible clean-room implementations.
IANAL, but isn't the "clean-room" giving permission or at least encouraging others to reimplement the VM without Sun/Oracle's involvement? Or is this a non-legally-binding statement and all bets are off with respect to the VM specification? (Or something else?)
> Would it be Supreme Court in such case?
Probably. In theory, I think they could first ask for en banc review by the Federal Circuit.
The Android VM - Dalvik - uses Dalvik not JVM byte code.
Now ART - the new Android runtime replacing Dalvik - is native - no more byte code.
There's not much Java left apart from the (poor) syntax. Why doesn't Google bless one of the alt-Java's, like Kotlin, and cut out Java entirely.
Dalvik and JVM bytecode map 1:1 with one or two exceptions for initializing arrays with data instead of a sequence of instructions. Even if you want to pretend that Dalvik isn't a JVM then you must accept that it is a derivative work, as even the names of the bytecode instructions are the same.
Google killed Sun and if they end up paying for it by APIs being copyrightable that may be a disaster for the tech industry, but it's karma for Google.
Java wasn't going to power a Sun-sized company by itself, but having this income dry up while already trying to save the company from linux is a death blow.
So the issue of fair use would need to be re-tried, and there's a good chance they'd win - the deadlocked jury was 9-3 in favor of Google. That may even be overstating Oracle's support. According to some reports, only one juror was a holdout for Oracle on the fair use question .
The problem isn't Google's, it's everyone else's. If this decision holds up on appeal, the legality of a compatible re-implementation of an existing API will often be a question of fair use that needs to go to a jury. Practically speaking, that means API re-implementation (a previously standard, commonly-used part of the interoperability toolbox) is dead for anyone who doesn't have the millions required to try this sort of case. I can't even begin to comprehend how that will change software development.
Getting a case to summary judgment isn't cheap, but the fair-use factors aren't super fact intensive: http://fairuse.stanford.edu/overview/fair-use/four-factors. They center around the nature of the work itself, which can be described in pleadings, rather than specific facts about the creative process that might require extensive discovery.
So now Oracle has an (effectively) infinite length patent (it's technically a copyright which at this point is eternal as long as Disney keeps lobbying) on the shape of the Java API. Perfect.
If Google doesn't have something like that started, they should. If they didn't start it immediately after this ruling, they are far dumber than I think they are.
But realistically, I can't see much except federal corruption in the decision to hold the copyrightable SSO higher than the functional requirements. In this digital age, that is a boot-licking verdict.
Alsup got it right.
How does Android compete with Java? Wasn't it supposed to be a good thing for the whole language to have Android out there especially in times when many other languages emerged that have been touted as "the new Java" or "the next C++"?
Instead of Google, let's use Microsoft, and say we're in the 90's and it's Sun's Java, not Oracle.
Oh wait. That happened, and Sun and Microsoft settled out of court to the tune of some $2 Billion.
"Android provides a rich application framework that allows you to build innovative apps and games for mobile devices in a Java language environment."
Java the language is not Java the platform
Using a library i akin to put a engine into a car. One could argue that the engine would still be a separate piece and thus not "part of the car", but its a tough sell to do in court. The line that separate "a thing" with "other things" is determined by judges, juries (and in some cases, common sense). In 23 years, no one has dared yet to do so.
Using an API however is like putting your own engine into the car, but it happens to use the same input/output of similar car engines. The GPL do not have a dog in that fight, but FSF argues against such stretching of copyright.
No, for a couple reasons:
1. Those programs aren't distributing the material in question. You, the user, will have independently acquired the JRE. This will have most likely been through non-infringing means, given that Sun/Oracle lets you have it for free, and even if it were infringing, you'd be the one at fault, not the program author.
2. Even if that weren't true, there would still be a couple of options to create a non-infringing program. Only programs that are neither non-GPL, nor those from authors who have some other valid commercial license would be infringing. Not "every Java program".
The designer in me says, yes this is the right decision, but my pragmatist is worried.
Processor instruction sets are no less API's than are the means of accessing a software product. Can they be copyrighted?
If you don't like what licenses are available to you, then you negotiate a new one or you don't use it. Every vendor knows that when they modify Linux and embed it, their changes to Linux must be available. No vendor has done more than pay lip service to challenging this aspect of the GPL, the reason being, is the strength of copyright.
The whole game is rigged to consolidate power & dominion. The only way to get away from the game is to stop playing.
Software free of, or successfully loopholed from, this system are viable alternatives that deserve more mindshare.
To fail to summarize ;P, this nuance stems from separating the question of whether Oracle's APIs are copyrightable from whether Google can claim "fair use" in copying them for their purposes. Much like with trademarks (where people get really uptight that someone "trademarked a word", ignoring context restrictions), I think people lose these nuances while talking about situations like this, and presume that if something is protected in some way then it is an ironclad protection that applies even in ludicrous circumstances.
Keeping this difference in mind, if the court said "APIs are copyrightable, but what Google did was a clear example of fair use: creating interoperable implementations is allowed", some people might still be angry, but I think many fewer people would be bothered: it changes what the opinion means. And, in fact, this is closer to what this opinion is saying than many people seem to be reading from it: they talk a lot about whether what Google is doing might be fair use, but they essentially punt that call back to the lower court.
> Because the jury deadlocked on fair use, we remand for further consideration of Google’s fair use defense in light of this decision.
We then have to ask "what happened" with this fair use argument, as we would hope that in the situation that APIs are copyrightable that interoperating with those APIs would be considered fair use: "something went wrong here". I think we can actually see some disappointing mistakes in Google's argument from reading this opinion: even though it wasn't trying to decide this matter directly, it talks a lot about fair use and models of interoperability. It frankly seems like Google just did a really really bad job of arguing the case :(.
If we go back to the beginning of this, most of Sun's core arguments about Java surround the idea that code written against Java should run on anything claiming to support Java. Microsoft was really excited about Java, but because they wanted to add a few extra features--some classes that would exist for UI purposes on their implementation of Java but on no other--the Internet has ever since considered them horribly evil people and were happy when Sun won in court against them (which is why Microsoft decided to build C#, btw).
Google seriously did not want to build something interoperable with Java under this definition: they have their own class libraries for handling large regions of the platform, including basic things absolutely any application would be using a lot of, such as UI and RPC. Given this, Google trying to claim "we want to be interoperable with Java" is horribly confusing. You find the opinion trying to understand Google's position on interoperability and failing: it almost makes Google look like they are lying about "interoperability".
> Indeed, given the record evidence that Google designed Android so that it would not be compatible with the Java platform, or the JVM specifically, we find Google's interoperability argument confusing. While Google repeatedly cites to the district court's finding that Google had to copy the packages so that an app written in Java could run on Android, it cites to no evidence in the record that any such app exists and points to no Java apps that either pre-dated or post-dated Android that could run on the Android platform.
> During oral argument, Google's counsel stated that "a program written in the Java language can run on Android if it's only using packages within the 37. So if I'm a developer and I have written a program, I've written it in Java, I can stick an Android header on it and it will run in Android because it is using the identical names of the classes, methods, and packages." Counsel did not identify any programs that use only the 37 API packages at issue, however, and did not attest that any such program would be useful. Nor did Google cite to any record evidence to support this claim.
Now, I have certainly seen many Java libraries that manage to only use this subset of features; and to me, being able to use those libraries is an interesting aspect of "interoperability". Sadly, however, Google's lawyers seem to have not bothered making that argument: they were probably doing the important thing where they simplify the kinds of words and ideas they are using for the jury to quickly understand, but the difference between applications and libraries needs to not be understated and left to implicit context :(.
The result is that rather than seeing what Google was doing as building an interoperable implementation of an API, the panel sees Google as instead building their own non-interoperable platform that happens to share striking similarities to Oracle's Java. They feel like Google is just copying a bunch of effort and work and even creative expression that Sun had put into Java in the construction of Google's competing way of developing applications for the seemingly-purposely unrelated platform that they are using on Android.
> The compatibility Google sought to foster was not with Oracle's Java platform or with the JVM central to that platform. Instead, Google wanted to capitalize on the fact that software developers were already trained and experienced in using the Java API packages at issue. The district court agreed, finding that, as to the 37 Java API packages, "Google believed Java application programmers would want to find the same 37 sets of functionalities in the new Android system callable by the same names as used in Java."
Let's say that Microsoft's C# happened to have a programming library that had large regions of API that were "directly copied" from the standard library of Java, even if there were no way to even attempt to run a Java class/jar on the .NET Virtual Machine. While many people would still say "that clearly should be allowed", I think that changes the character of the discussion quite a bit: I think many of the same people angry at Samsung about copying things off Apple would find themselves angry at Microsoft for copying things off Sun.
Again, I want to stress that I am not saying this should sit well with everyone: I can easily appreciate the arguments of people who feel that APIs should simply fundamentally not be subject to copyright. (That said, I can also appreciate the arguments of people who feel that software in general should not be subject to copyright, and I appreciate the arguments of people who believe that absolutely nothing should be subject to copyright as they think the idea of copyright is flawed. These are all somewhat reasonable positions to me.)
Instead, I point this stuff out as I think people are extrapolating too much from this decision and are taking it to mean things that it doesn't: in particular, it doesn't mean that you can't build systems that interoperate with an API designed by another party. It is then unfortunate that people are extrapolating this decision all the way up to hyperbole like "the PC revolution wouldn't have happened under this ruling". It just doesn't help when people make these kinds of grandiose statements: everything becomes emotional :/.
Really, what we are looking at (and I think grellas is saying something similar, though from a different direction) is an opinion that leaves an area of law in a state where it is not entirely clear: that is a problem, as it leads to individuals having to make horrible and oft-flawed decisions as to whether specific actions they want to perform are or are not allowed. But this uncertainty is not the same as saying "this is not allowed"; and even if Google's usage was not allowed, maybe a intended-to-be-fully-interoperable Java is.
So, you can either have Java on 800 million devices where the APIs are subsetted and retargeted towards modern smartphones, or you can have a hopelessly bloated, too-many-cooks-in-the-kitchen JDK on devices no one wants to use, but they, they'd be capable of running Java apps from the 90s.
This is like saying, I won't let you subset the Win32 APIs unless you guarantee that DOS 3.0 apps will still run.
Are they saying you need a license to use the API? For example something like java.util?
2) They are saying that the java header files are copyrightable. It would be challenging to create a compatible java implementation that didn't include something awfully close to the java header files (and it appears that google copied them verbatim). Depending on future rulings, it make make it hard or impossible to create a java-compatible implementation without violating Oracle's copyrights.
There is nothing fundamentally copyright-able about an API. It's just a bunch of methods and descriptions. The implementation is the secret sauce. By finding for Oracle the courts have essentially said that you're not allowed to reverse-engineer a library.
On the other hand, this ruling says that there is something inherently copyrightable about the declarations.
"Sun hereby grants you a fully-paid, non-exclusive, non-transferable, worldwide, limited license (without the right to sublicense), under Sun's intellectual property rights that are essential to practice the Specification, to internally practice the Specification for the purpose of designing and developing your Java applets and applications intended to run on the Java platform or creating a clean room implementation of the Specification that: (i) includes a complete implementation of the current version of the Specification, without subsetting or supersetting; (ii) implements all of the interfaces and functionality of the Specification without subsetting or supersetting; (iii) includes a complete implementation of any optional components (as defined by the Specification) which you choose to implement, without subsetting or supersetting; (iv) implements all of the interfaces and functionality of such optional components, without subsetting or supersetting; (v) does not add any additional packages, classes or interfaces to the "java." or "javax." packages or subpackages or other packages defined by the Specification; (vi) satisfies all testing requirements available from Sun relating to the most recently published version of the Specification six (6) months prior to any release of the clean room implementation or upgrade thereto; (vii) does not derive from any Sun source code or binary code materials; and (viii) does not include any Sun source code or binary code materials without an appropriate and separate license from Sun. The Specification contains the proprietary information of Sun and may only be used in accordance with the license terms set forth herein. This license will terminate immediately without notice from Sun if you fail to comply with any provision of this license. Upon termination or expiration of this license, you must cease use of or destroy the Specification."
"My take is [APIs] would be found copyrightable, but Google may probably prevail on fair use." 
Unlike most here, I think this is the right decision given the current framework of copyright protection. This is because what copyright protects is the creative expression of a work. APIs, after all, are just another form of code, and requires the same (if not more) amount of creativity to design properly .
I see a lot of people here seemingly conflating this with patents (which protect functionality) or patent-like scope of protection. Copyright does not protect functionality, only the exact expression thereof. There are an unlimited number of ways to design an API for the same functionality. For instance, the file system APIs for Posix, Java, C# and Python are all completely distinct in their expression.
The arguments against API copyrightability, taken to their logical conclusion, would remove copyright protection for all code. I'd like to see cogent arguments as to why copyright as it currently exists should apply to all other code but not API. ("Because we should be able to re-implement APIs" is not a valid answer, as that is begging the question. Without justification, you may well say that about any code.)
I suspect that any valid arguments would indicate that copyright is not an appropriate means of protection for software. That would be unsurprising; code was shoehorned into copyright because it was a close enough approximation and didn't require formulating a whole new framework from the ground up . Many others [4, 5, 6, 7] have explored the weird interplay of copyright protection and code, which at its heart, is functional (which copyright does not protect) yet is also creative (which copyright does protect).
 Even if Google prevails on fair use, I still think that is unfair to Sun (and by proxy, Oracle). People ignore the massive investment, not only in engineering, but in marketing that Sun undertook to make Java as prevalent as it is today. I don't think it's fair to let another party hijack a hard-earned ecosystem without permission from its creators.
 Some may argue the Java APIs are poorly designed. All I can say is, even the Twilight series gets copyright protection.
 "The Uneasy Case for Software Copyright", http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2171451
 "The Strange Odyssey of Software Interfaces and Intellectual Property Law", http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1323818
 "Sum Greater than its Parts?: Copyright Protection for Application Program Interfaces", http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1325104
 "Copyright Protection of Computer Program Structure", http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1438164
 "IP's Problem Child: Shifting the Paradigms for Software Protection", http://papers.ssrn.com/sol3/papers.cfm?abstract_id=901604
For the same reason a textbook publisher shouldn't be able to copyright the table of contents of a calculus textbook:
1) It is merely a guidepost to the rest of the work and doesn't rise to the level of creativity of the meat of the text.
2) over time the structure becomes standardized because of the nature of the information it attempts to organize suggests that standard.
For example: imagine an API for accessing student information. You have certain common characteristics for those students: Name, Address, Contacts, Schedule, Grades, Absences etc. I'd be willing to bet that if you put 10 people in separate rooms and asked them to create an API, 80% or more would be so close to one another that if someone studied one, they could find their way in another. And if showed a person who had studied the different APIs some specific part of a particular API they wouldn't be able to tell you which one it came from. They would not differ enough in 'style' to be readily distinguishable.
Now imagine Strings. Or authentication or routes or any number of other aspects of computing that we have to deal with every day.
Now, can the same thing be said of ten different authors of say a writing prompt that says "Write about a student who is having an altercation with a gym coach"?
I'd argue that you'd get some very different and and easily distinguishable stories and styles.
As anyone who has designed enough APIs will tell you (including engineers testifying on Google's behalf during the trial, and many commenters here who disagree with the decision), an API often requires more creativity than the implementation. Sure, the implementation is also difficult to do well, but making that implementation usable by others is no less a creative task. The "table of contents" analogy is backwards: you don't write the code first and then extract the functions into an API. That's how you get poor APIs. For a well designed API it's always the other way around. With enough creativity and forethought put into an API, the implementation flows naturally, and in practice, it's exactly the opposite of the table of contents analogy.
(Not to mention that a ToC may also be copyrightable.)
> 2) over time the structure becomes standardized because of the nature of the information it attempts to organize suggests that standard.
The "nature of information being organized" sounds like "functionality" to me. As before, it is distinct from expression.
> I'd be willing to bet that if you put 10 people in separate rooms and asked them to create an API, 80% or more would be so close to one another that if someone studied one, they could find their way in another.
Consider the corollary of your argument. If you asked those same people to write actual implementations for that same problem. I'd bet you get the same "80% or more would be so close" results. Do you mean that their resulting code would not be covered by copyright? Consider whatever arguments you apply to defend copyrightability of the implementation, and try to differentiate them from the API case.
Unless you provide a detailed spec and enforce some conventions, I'm willing to bet nobody will have an exact duplicate of another, either for implementation or for API. An API for the same functionality, say for getting the number of absentees, may be labeled getAbsenteeCount() or nAbsentees() or NumNotPresent(). Or even absenteeList().length(). Or a poorly defined API may require something like classSize() - numPresent(). Or a really badly defined API would require iterating over each member of the class and checking the "present" flag. And that is the point: each expression of the same functionality can be unique, and hence a candidate for copyright.
"Difficult to do well" and "creativity" does not equal "copyrightable". Mathematical proofs are hard to do well and require creativity but are not copyrightable.
If the form is necessary for practical application, it belongs to the public.
>The "table of contents" analogy is backwards: you don't write the code first and then extract the functions into an API. That's how you get poor APIs.
You generally don't start writing prose before you have the overall structure fleshed out, either.
>Do you mean that their resulting code would not be covered by copyright? Consider whatever arguments you apply to defend copyrightability of the implementation, and try to differentiate them from the API case.
Perhaps you are right. Copyright may be the wrong tool for code. Patents may be the wrong tool for code. It may be time to set aside these grossly imperfect abstractions that were built for wildly different purposes hundreds of years before programming was conceived and think through something that fits this type of intellectual property better.
But how you express it is covered by copyright. A mathematical proof is not, but if you write it out so that it rhymes, that specific expression is. You can now state the same proof a thousand different ways, even those that rhyme differently. But all those original those of the same proof remain protected.
I would tend to agree that copyright and patents are probably not a good fit for protecting software, and maybe a new framework is needed. But given the current means at hand, this decision is internally consistent.