A Brief, Opinionated History of the API [pdf]
drive.google.com
drive.google.com
Why is it that we are offered snake oil like UML, RUP, GoF patterns and other cargo cult or just otherwise trite nonsense when these basic ingredients of proper programming - simplicity, understandability, minimization of labour, difficulty of reusability - seem to come as great surprise and revelation only after working quite some time.
I find the reusability fallacy particularly offensive as a trumpeted design paradigm since it's so hard to get it right, especially since it is often sold as a project feature based on the hypothesis of cost savings. If one achieves practical reusability in ones components, that is a thing to be celebrated, truly. But you cannot say, we shall write this generic domain specific widget _ and make it reusable _ without the understading that this will probably need a lot more design and research than just implementing the domain widget as a stand alone module.
The prospect of not having to do work is always attractive, whereas simplicity and understandability require thinking carefully about what you're doing, which few people like (or have time to) do.
He also says that they'd implemented higher-order functions on that same machine by 1952. That's astonishing. Can anybody tell us what form they took?
The EDSAC was pipped by the Manchester "Baby" prototype, which was activated and ran a test program in 1948: http://www.computer50.org/mark1/firstprog.html .
Really, really well done. I still think that Oracle has a pretty strong legal leg to stand on, unfortunately. And they have the legal team to pretty much guarantee victory. API specs deserve the same copyright protections we provide for other forms of intellectual property.
The bigger problem that needs to be confronted is the ridiculous scope and corporate bias of US copyright law, which is the ultimate root of the maladies that strangle creativity and punish artists and working engineers in this country. I believe that API specs deserve the same legal protections as song lyrics, plot devices, and poetry. But I think those legal protections, buttressed by lawyers from Disney and Oracle, have gotten out of control and now penalize the people they were supposed to protect.
Um, Google's got a pretty good legal team, too...
1. "We've always had the right to re-implement interfaces" is a red herring. At one point one could have as well said "we've always had a right to own slaves." Also, re-implementing APIs may be valuable, but there may be even more value in re-inventing APIs instead, many of the reasons for which are mentioned in TFA itself. Case in point, being locked out of Java, Microsoft went ahead and built (by most accounts) a superior programming ecosystem, including a better API.
2. Not a lawyer, but from my limited understanding: Copyright law as currently defined is, IMO, not a good protection mechanism for code, resulting in cases like this. Whatever arguments you could make to exempt APIs from protection applies equally to code. In general copyright cannot protect anything "functional" in nature, but all code is functional! For instance, the exemption from 102(b) highlighted in TFA for "methods of operation" applies equally well to code. What is code if not a method of operation of the hardware it runs on?
Copyright only applies to the creative aspect of anything, including written code, and as such APIs can have as much (or more) creative input as any implementation. In fact, often (and hinted at in TFA), if the API, or indeed any spec, is defined well enough, it's implementation becomes straightforward and requires little inherent creativity! Yet that code automatically qualifies for copyright.
(Note that copyright will only protect the expression of an idea, not the idea itself. So when discussing copyrighting of APIs, remember that we are not discussing protecting, say, the concept of opening a file, but protecting the specific expression "new File(fileName)" or "File.open(fileName)" or "open(fname, 'r')". While this is a simplistic example, think of how this permeates the rest of the APIs.)
3. The case law for exemptions for interoperability in interfaces (Sega etc,) is, as far as I can tell, for systems to interoperate with each other. APIs on the other hand, are mainly for humans to communicate with each other when building systems that interoperate. Bloch even calls it out multiple times when he harps on the importance of documentation. As such, APIs are primarily a means of expression between humans - from those who provide the interface, to those who use it. So from a copyright perspective, I don't see how binary interoperability between systems, which is purely functional, can compare to textual expression between humans.
In my mind, points 2 - 3 mean that Judge Alsup got it wrong and the Federal Circuit got it right. If this is something to be fixed, I'd say the real problem is the use of copyright law to protect code.
Was this really the case? As I understood it, Microsoft created C# because Java was too open and wouldn't keep people locked in to Windows. Especially since even GNU got Java, I don't see how Microsoft was "locked out" of it.
They ended up severely burned after that, none the less because they got the anti-monopolty demand during the browser wars.
C# is the salvage of that wasted effort, plus a number of lessons learned and improvements that MS was able to implement and market under a different name.
I think APIs are not like other specs in this regard. Take, for example, Amazon S3: it has a simple, obvious API that makes guarantees that have completely non-obvious implementation constraints, and no "one true path" toward satisfying them.
Many, many, many C# API elements were the equivalent Java elements with the case of one letter changed. That's not "a better API". That's cloning the API incompatibly.
linked from an eff.org article : https://www.eff.org/deeplinks/2014/05/dangerous-ruling-oracl...
i read the slides, then the decision, and then i got confused.. so i read alsup's ruling: https://www.scribd.com/doc/95480891/Oracle-v-Google-API-Orde...
and now i'm really confused
alsup's ruling ::
> This order does not hold that Java API packages are free for all to use without license.It does not hold that the structure, sequence and organization of all computer programs may be stolen. Rather, it holds on the specific facts of this case, the particular elements replicated by Google were free for all to use under the Copyright Act. Therefore, Oracle’s claim based on Google’s copying of the 37 API packages, including their structure, sequence and organization is DISMISSED
which seems to contradict this from the eff.org article:
>In May 2012, Judge William Alsup of the Northern District of California ruled that APIs are not subject to copyright
it seems instead that alsup is saying that current understandings of code copyright stand but goog's use fell under fair use
federal circuit's decision ::
>Ultimately, we conclude that this is not a case in which the record contains sufficient factual findings upon which we could base a de novo assessment of Google’s affirmative defense of fair use.
which reinforces that this is moreso an issue of fair use :
> Section 107 contains a list of the various purposes for which the reproduction of a particular work may be considered fair, such as criticism, comment, news reporting, teaching, scholarship, and research. Section 107 also sets out four factors to be considered in determining whether or not a particular use is fair.
The purpose and character of the use, including whether such use is of commercial nature or is for nonprofit educational purposes The nature of the copyrighted work The amount and substantiality of the portion used in relation to the copyrighted work as a whole The effect of the use upon the potential market for, or value of, the copyrighted work >> http://www.copyright.gov/fls/fl102.html
fair use is only applicable on copyrighted material, if something were uncopyrightable then examining it's derivatives for fair use would be unnecessary, but here alsup is using fair use to excuse goog's use of the java api, implying the api is subject to copyright
so regardless of what an api is or whomever thinks whatever thae think an api is is moot to this legal hearing
to argue this decision in favor of your opinion you'd have to focus on the referenced snippets and analyse them for fair use, because that is what alsup ruled it
if the code oversteps fair use then you have to agree with the decision
at this point, in all honesty, this whole thing seems so beyond me..
just makes me wonder why goog wrote android in java
why would anyone write anything in java?
is that oracle's goal?
I don't think Oracle cares that much about independent developer goodwill. I don't see how they would have to. Oracle and along the same vein, SAP and their ilk are giants in the corporate world. They operate in space were corporate credibility is much more important than developer goodwill.
Note: I might be totally wrong, please correct me.