Thank you for referencing this outstanding historical presentation. Perhaps one day we shall get out of this strange amnesia software engineering seems to have as a field (or pop culture as Alan Kay poignantly put it). I find it odd I discover the good stuff only when I have practiced programming over ten years while I consider myself a fairly voracious autodidact.
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.
Wasn't sure I'd want to read an opinionated history til I realized this was by Josh Bloch - an opinion worth paying attention to. As one useful reference point, he was responsible for the Java Collections API.
This is so good. Among many things I didn't know: the first stored program computer (EDSAC) was programmed in assembly language. So for programs that were actually executed, assembler predates binary.
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?
Here's a nice and working (on 64-bit Win7) emulator of the 1949-51 EDSAC, by the way: http://www.dcs.warwick.ac.uk/~edsac/ It comes with a good tutorial and lots of code written in 1949-51 for the real EDSAC.
This is a fantastic presentation, and if I were developing a history of software class, I'd reuse this presentation for a unit on API's and libraries, given the author's permission. I've never seen such a concise and informative presentation on the history of any aspect of software development (languages, methodologies, human interface, etc...)
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.
Man, if you thought there were too many lawyers in programming already... just wait until we have retroactive protection of (corporate owned) APIs (and instruction sets?). Talk about a 'submarine' attack.
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.
> Microsoft went ahead and built (by most accounts) a superior programming ecosystem, including a better API.
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.
> if the API ... is defined well enough, it's implementation becomes straightforward and requires little inherent creativity!
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.
Case in point, being locked out of Java, Microsoft
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.
Back in the 90's Microsoft tried it's "embrace and extend" dirty trick on the nascent Java environment (have a look at Wikipedia's entry on the infamous J++: http://en.wikipedia.org/wiki/Visual_J%2B%2B
They ended up severely burned after that, none the less because they got the anti-monopolty demand during the browser wars.
But that's not being locked out of Java. On the contrary, it's the exact opposite and business as usual for Microsoft: take a perfectly good cross-platform, open standard, and mess with it until it locks out everyone else, so your customers are stuck with using your inferior products.
The locking out came when Sun sued Microsoft on copyright infringement (or trademark infringement, I don't recall), then they were forbidden from continuing to enhance and offer the product, but end up still providing minimum (security) support to the existing use base.
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.
> 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
Ellison probably just thought they were stealing his shiny IP which he had bought and wanted a sweet share of all those handset profits. Which, by all accounts, he had all the right to test in court no matter how infuriating it was.
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.
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.