back to article Happy as Larry: Why Oracle won the Google Java Android case

One piece of paper. Just one lousy piece of paper. That's the difference between success and a potential $8.8bn payout. Google's lucky streak finally ran out this week. Its defense for using Oracle's copyrighted Java code in Android – without paying the database giant a penny in royalties – collapsed in a US Federal appeals …

Page:

  1. Anonymous Coward
    Anonymous Coward

    "Google clearly had the choice of making a cool new OS, or getting a Java license and building on that."

    Google didn't need to licence the Java code, it wrote its own implementation from scratch.

    The bits it copied - the API header files - could hardly be described as "a cool new OS". Let's leave aside that a programming language and its libraries are not an OS. The header files are at best described as "the definition of how the OS/language should interact with the world", not the implementation of that behaviour.

    But all right, let's assume that API definitions are as copyrightable as the code that implements them.

    What we're left with is one big confidence trick. You announce to the world that your platform is open and free, and espouse the benefits in great detail:

    "Sun has chosen a GPL v2 license ... Open sourcing Java ME should help reduce fragmentation and benefit application developers and service providers. For example, the adoption of a common implementation across handsets will significantly reduce the development, testing, porting, and maintenance costs associated with the creation and deployment of mobile applications over a wide range of mobile handsets." -- Shannon Lynch, Sun's senior director of Mobile & Embedded platforms.

    But then due to some legal nonsense which I don't begin to understand, somehow Sun (and hence Oracle) actually retained all rights to using Java on mobile platform. Anybody who took their declaration that Java was open and free was taken for a mug.

    And that's the big risk here: it means more anti-open-source FUD from commercial vendors. "You use GPL software? Think you can't be sued? Just look at Google and Java"

    1. Dave 126 Silver badge

      > The bits it copied - the API header files - could hardly be described as "a cool new OS".

      AO was making the point that Google didn't make a wholly new cool OS. They are now though, it's called Fuschia, though it's only in the early stages.b

      1. Anonymous Coward
        Anonymous Coward

        "AO was making the point that Google didn't make a wholly new cool OS."

        The OP was making the point that Java has nothing to do with the OS, which for Android is Linux, not Java. Java is a runtime providing the language and API for Android development, which then compiles to run in Google's implementation of the Java runtime (Dalvik/ART).

        At no point have Google copied the JVM used on desktops or Java mobile applications, their runtime is compatible with the Java API definition, nothing more.

        My question is this: if you extend a standard Java class, adding functionality to it by overriding methods, could that not be considered breaching the API copyright? It's essentially your own implementation using their (copyrightable) API definition.

    2. Anonymous Coward
      Anonymous Coward

      The Register reported here in 2016:

      Java SE is free for what Oracle defines as “general purpose computing” – devices that in the words of its licence cover desktops, notebooks, smartphones and tablets. It is not free for what Oracle’s licence defines as “specialized embedded computers used in intelligent systems”, which Oracle further defines as – among other things – mobile phones, handheld devices, networking switches and Blu-Ray players. [emphasis added]

      Seems even El Reg can't draw the line between "smartphones" and "mobile phones".

    3. Robert Halloran

      If API declarations are in fact copyrightable...

      Consider this, folks: if the API declarations can be copyrighted, even if you create new code underneath to implement the actual functionality, then

      a) all those developers creating clean-room BIOS' for the IBM PC market back in the early 80s would be subject to penalties and the compatibles market would have been stillborn

      b) a certain Finnish grad student would have been in trouble for creating an O/S kernel mimicking the UNIX docs (Ghod, don't let the SCOX zombies hear about this...)

      c) Hell, *ANY* reverse-engineering effort where you take spec XYZ and create a call-compatible version is doomed.

      The potential hit to the engineering & software industries here is tremendous; trying to replicate *ANY* existing functionality with new code is a potential legal minefield for the developers. Do these feckwit judges understand the impact of their ruling, or are they too busy slipping on their kneepads as they step into Ellison's secret island lair?

    4. Ian Michael Gumby
      Boffin

      @AC

      "Google didn't need to licence the Java code, it wrote its own implementation from scratch."

      No it didn't. As Andrew points out, they raised an affirmative defense of 'Fair Use'.

      What Andrew got wrong is that Google wasn't going to get that piece of paper for free from Sun.

      Remember that Sun had a mobile version of Java that required that the company needs to buy a license while the desktop version was free. It was their way of monetizing Java.

      Could Google have bought a license from Sun? Sure.

      Most likely a cash payment and then a royalty per phone. Would have been much cheaper than what they now owe Larry. But it wouldn't have been free or cheap.

      1. Anonymous Coward
        Anonymous Coward

        @Ian Michael Gumby

        > "As Andrew points out, they raised an affirmative defense of 'Fair Use'."

        The "copyright infringement" which Google was accused of was for independently implementing a publicly documented API. In no version of Android was any code from Sun's or Oracle's Java ever used.

        Of course, you wouldn't understand that from AO's opinion-piece which disingenuously claims, or the very least uses ambiguous language to suggest, that Google used Oracle's Java code.

    5. Anonymous Coward
      Anonymous Coward

      "What we're left with is one big confidence trick"

      That is exactly right. Sun has such a convoluted relationship with Java that I am surprised that anyone ever used Java. It is open source and completely free, even for enterprises.... except when it is OEM embedded, then, sometimes, you need to buy a license depending on the definition of OEM.

      Either make a free and open software program or make a proprietary program... but it is a joke to go advertise Java as free and open everywhere, except for a few occasionally enforced exceptions.

      1. Jason Bloomberg Silver badge
        Facepalm

        I am surprised that anyone ever used Java. It is open source and completely free, even for enterprises.... except when it is OEM embedded, then, sometimes, you need to buy a license depending on the definition of OEM.

        Ah yes; the fun of figuring out what the licensing situation was in using Java on a Raspberry Pi for a commercial application.

        Best option, last time I looked, was to use something else.

    6. Oh Homer
      Mushroom

      Unqualified to judge

      Anyone who thinks something as simple as a header file should rightly qualify as a creative work deserving of copyright protection, clearly doesn't have the first clue about programming, and should not be allowed to make legal judgements about something they don't understand.

      For those, like this judge, who apparently don't understand, it'd be like claiming that the definition of sodium chloride as a salt is copyrightable, the sole intellectual property of Premier Foods, and as a result nobody else is allowed to produce and sell salt that is described as "sodium chloride", because Premier Foods has monopoly control of that definition.

      Note, we're not talking about a patent, since Premier Foods didn't invent sodium chloride, and we're not even talking about a trademark, as "sodium chloride" is merely a chemical formula, not a commercial brand name. The simple act of stating the definition of salt is, in itself, prohibited, unless you hand big wads of cash over to Premier Foods.

      That's header files. They're simple definitions, and something that simple, and not even remotely "creative" in either the scientific or artistic sense, should never, ever be copyrightable. Period.

      Next up, Bertrand Russell copyrights "1 + 1 = 2". Everyone is forced by lunatic copyright laws to stop using mathematics. Chaos ensues. Civilisation ends. "IP" laws prevail, but it doesn't matter, as no one can read any more. And the lawyers lived happily ever after.

    7. TVU Silver badge

      "And that's the big risk here: it means more anti-open-source FUD from commercial vendors. "You use GPL software? Think you can't be sued? Just look at Google and Java""

      That this case has gone on so long and has swung back and forth in different courts indicates that there is merit to Google's arguments.

      Furthermore, this is not a definitive verdict. That can only be effectively handed down by the US Supreme Court and, given the principles that are at stake here, I sincerely hope that Google contests this case all the way to the Supreme Court.

      I frankly detest Oracle these days because they are using litigation to extract money instead of innovating and providing a good service to customers. They have, in effect, become the new SCO Group.

  2. Anonymous Coward
    Anonymous Coward

    I knew from the beginning that Java would bite Google in the ass. If only because of its shit performance.

    Should've gone with C++ and HTML for their App needs.

    1. Anonymous Coward
      Anonymous Coward

      That's right, swap performance on the CPU, or reduced developer performance.

    2. Anonymous Coward
      Anonymous Coward

      "Should've gone with C++ and HTML for their App needs."

      Yup. There was zero reason to use java given that Android is just a worked over version of Linux with an alternative display system. They could easily have simply present the standard Posix API along with new sound and visual APIs for app developers to work with , but no, they decided to go with the Kool Kids and Java. AFAIK they don't even use a JVM or java bytecode anyway - it gets compiled down to something else (too lazy to search) so they can't even say it was to use a sandboxed JVM for app security. Not that you need that anyway if the kernel has been modified properly for extra process security and protection which no doubt they've done.

      1. Andy 73 Silver badge

        Haha

        Yes, because we see thousands of C++ and HTML based apps don't we - clearly that's the better technology... *sigh*

        OK, sarcasm over. When Android was just starting, you had next to no consistency of hardware between vendors, and manufacturers actively attempting to create walled gardens by building in 'special' (and incompatible) features into both their hardware and the O/S running on top. HTML at the time was purely a presentation layer, with pitiful performance and a complete inability to deal with many UI concepts (multi-touch, 3D rendering, real time processes etc). HTML is still a stupid place to start if you want an immersive UI and to retain your sanity. That's why the cool kids are using Unity.

        A VM that abstracted both the hardware features and the user interface was *exactly* what was needed to avoid going the Nokia route. The moment devs could be tricked (or willingly leap) into using device specific APIs, the 'universal' nature of the platform would be lost - and it needed to be universal to match the monolithic and well managed walled garden that Apple had created.

        The usual moronic nonsense about Java performance simply didn't apply. It was *good enough* (and still is - VM technology is very smart these days) and provided a development environment that was accessible, consistent, neatly sandboxed and supported by tools that were an order of magnitude better than the command line torture inflicted on C++ devs.

        "Android is just..." - it's not 'just' anything - it's the largest mobile platform globally, despite many attempts to offer alternatives. Many. Attempts. Some using C++ and HTML...

        1. Anonymous Coward
          Anonymous Coward

          Re: Haha

          "It was *good enough* (and still is - VM technology is very smart these days) "

          Pfft, sure, thats why on the last java project I was involved in the VM reserved over 100MB just to start up and load the program.

          "consistent, neatly sandboxed and supported by tools that were an order of magnitude better than the command line torture inflicted on C++ devs."

          Have you ever actually programmed in C++? I have my doubts. And there was nothing stopping google creating a C++ sound and visual API specifically for android plus an IDE. Which they had to do anyway for java. So none of your arguments stack up.

          1. PerlyKing

            Re: Java IDE

            @boltar

            there was nothing stopping google creating a C++ sound and visual API specifically for android plus an IDE. Which they had to do anyway for java.

            Which IDE did Google create for Java? I know that they made an Eclipse plugin and they now package IntelliJ IDEA as "Android Studio", have I missed something?

          2. Andy 73 Silver badge

            Re: Haha

            I have programmed in C++ and C and Javascript, and Pascal and x86 and Scala and.. it's a long list. I'm old. The tooling for C/C++ at the time was poor, with second rate refactoring, unit testing, code coverage, and even simple things like autocompletion. Build tools were inconsistent and setting up 'an environment' a dice game unless you happen to live in happy Visual Studio land (welcome to the Hotel California). In comparison, the same set of Java tools ran consistently on your machine, regardless of whether it was a Windows, OSX or Linux box.

            Do tell me how you sandbox a C++ executable? Or perform static analysis on it without symbol tables you hope are consistent with the binary. Or ensure that your arbitrary third party library (hint: there are thousands of those freely available for Java and hence Android) is safe to run on any of the thousands of phones out there?

            And if you think that all Android is is a 'sound and visual API', you've really missed the point by a country mile.

            1. Anonymous Coward
              Anonymous Coward

              Re: Haha

              "In comparison, the same set of Java tools ran consistently on your machine, regardless of whether it was a Windows, OSX or Linux box."

              Actually they didn't always, at least not in look and feel though thats improved in recent years.

              "Do tell me how you sandbox a C++ executable?"

              "Or ensure that your arbitrary third party library (hint: there are thousands of those freely available for Java and hence Android) is safe to run on any of the thousands of phones out there?"

              Hmm, I wonder how apple do the above with objective-C binaries from itunes. It must be woowoo magic!

              "And if you think that all Android is is a 'sound and visual API', you've really missed the point by a country mile."

              Feel free to fill me in on what else Android has over a standard linux installation. Sure , it has phone and touch support but thats just drivers. BFD.

            2. Anonymous Coward
              Anonymous Coward

              Re: Haha

              In some ways it is a pity that Google went with Java and not Qt... they could always have bought Trolltech for a lot less than $8 billion (as Nokia did a few years later). In practice, the application memory and CPU requirements are so much higher, and the Java build tools (and the coding style, and the library dependency hell) - have always felt so kludged, fragile, and bloated - to me - compared to what's available on Qt.

              1. keithzg

                Re: Haha

                It really is a pity, isn't it? Anecdotal evidence time!

                When I first got a smartphone, it was a Nokia N900, which allowed me to write Qt apps for my phone. On the desktop, people generally pair Qt with C++, but you don't have to, and I personally used Python. It was ludicrous how easy it was to program apps that way; I literally programmed an app for my city's public transit *on the phone itself* (or "tablet" as that division of Nokia was calling them, perhaps to avoid other areas of Nokia from taking Maemo away from them).

                When I finally had to admit that Android was winning rather than Nokia's more standard Linux stack, I gave Android programming a shot. I did make a few basic apps, but dear lord, just all the extra nonsense and faffing about you have to do, the additional baseline complexity at work, it's ludicrous. I found it way harder than writing Python Qt apps (or later, I tried C++ and Qt's QML and it similarly blows Android development out of the water), and I'm someone whose only formal training in computer programming *is* Java!

              2. Andy 73 Silver badge

                Re: Haha

                QT - The point here is that Java wasn't just chosen as a convenient hardware abstraction layer (though yes, it is that). It was chosen as an extensive ecosystem, with decent tooling, vast amounts of documentation and many libraries that can be pulled in to do... well, pretty much anything. The problem Symbian had, and QT still has is that, outside of the core development community, there is nothing comparable to the amount of support and development activity that there is with Java.

                What feels kludged, fragile and bloated to you feels consistent, predictable and unremarkable to most Java devs - it just works. Like any language, the quality of the output depends on the consideration that goes into its development and the understanding of the platform. Sure you can create your own hell, pulling in the entire universe, but dependency management on Java is incredibly robust and the ecosystems that have built up around it are simply not matched in other platforms. I've got ancient projects that still build and run consistently on an O/S that has since had five major revisions (and a whole bunch of point releases).

                And application memory and CPU requirements have never had the impact devs believe it should on platform penetration. What is important is that the users can get their hands on thousands of apps that do whatever is cool right now - and guess what? They can. That's why people buy Android phones not Windows Phones or Blackberry Phones and so on.

                None of this is to say Java is better than *insert language here* from a technical standpoint. The thing is, it's not those technical details that drove the adoption of Android.

            3. Flounder

              Re: Haha

              You forgot to point out that Java allows multiple programs to run concurrently, without memory mapping hardware or even an OS, because it is impossible to create a "pointer" in Java. A "reference" is a very controlled notion of "pointer", and you cannot access the memory of one Java program from another which is cohabiting the processor, in the same address space, because of these references. Do that in C or C++! (There are many other languages that do not embody the concept of "pointer", Java is only one of them. C and C++ are not).

          3. Flounder

            Re: Haha

            What are "command line tortures"? I have been using C and C++ for decades, and not once have I had to do anything on a "command line" to compile, execute, and/or debug my code. What alternate reality are you living in?

    3. Anonymous Coward
      Anonymous Coward

      "Should've gone with C++ and HTML for their App needs."

      Google wanted the easiest path. HTML is bad for mobile UIs.. C++ is hard, and have far fewer developers. Also, less friendly tooling, especially under Linux. Java came with IDEs, libraries, developers, etc. etc.

      Google is greed - just this time it may pay its greed dearly.

      1. Anonymous Coward
        Anonymous Coward

        Re: "Should've gone with C++ and HTML for their App needs."

        "C++ is hard, and have far fewer developers"

        C++ has a fuckton of developers, you just don't hear much from us since we're busy working and getting the job done rather than making a big noise about how we're so cool for using [insert trendy language of the month here].

        1. Ian Michael Gumby

          @Boltar Re: "Should've gone with C++ and HTML for their App needs."

          I stopped coding in C++ because I was sick and tired of fixing other people's obvious mistakes and piss poor code.

          I prefer C over C++, but in terms of coding today... SCALA.

        2. Someone Else Silver badge

          Re: "Should've gone with C++ and HTML for their App needs."

          C++ has a fuckton of developers, you just don't hear much from us since we're busy working and getting the job done rather than making a big noise about how we're so cool for using [insert trendy language of the month here].

          I wanted to put up the beer icon for this comment, but for some reason, the icons are missing. No matter; this one's for you (it's just very pale today...)!

        3. JohnFen

          Re: "Should've gone with C++ and HTML for their App needs."

          This.

          Also, C++ isn't "hard" -- and I have to wonder about developers who think that it is...

        4. JMcL

          Re: "Should've gone with C++ and HTML for their App needs."

          "C++ has a fuckton of developers, you just don't hear much from us since we're busy working and getting the job done rather than making a big noise about how we're so cool for using [insert trendy language of the month here]."

          I wouldn't deny that at all,speaking as somebody who spent a considerable part of their career programming in C and assembly of various shades.C/C++ IS hard for most developers (ability to easily shoot oneself in the foot, different architectures, endianness etc). To illustrate, you only have to look at the horrorshow that was Windows software until they handed out the blunt scissors in the form of C# to the more plebian masses (there were other reasons of course, but Imho, this was a major one). Unfortunately from my experience, a lot of blame must fall at the feet of educational curiculums. Graduates more often than not have no meaningful exposure to C/C++, often only scripting languages, because this is what "industry" demands.

          I'm firmly of the opinion that if you have gone through the experience of freezing the machine solid a few times through uninitialized pointers, buffer overruns, etc., you'll (hopefully) have a better grasp of the underlying architecture and fundamental computer science concepts, and this understanding will better inform any software you develop even in the Java, Node or whatever you're having yourself world.

    4. Blank Reg

      No, Java was the only sensible choice. At the time Java was by far the most popular language for mobile development. For most mobile developers it was the only language they had ever used for app development. So the path of least resistance was to base their new platform on what everyone was already using.

      But despite warnings from their own staff that they needed to negotiate a license, they just went ahead and used Java anyway rather than have to pay a few pennies per phone in royalties.

  3. Dan 55 Silver badge
    Stop

    "Get a licence or build something new. It's really that simple."

    No, no it's not. Every new language that appears is inspired by or built on the previous languages that came before it, if only for developer familiarity which reduces learning time and helps speed up development time.

    If you think otherwise, you might as well bin Java in its entirity because half of it is copied from C and C++ (trollface: and the other half is done wrong).

    However there are limits. You can't argue that Java's API was the sole reason for Android's success because Java ME got absolutely nowhere.

    1. Anonymous Coward
      Anonymous Coward

      Re: "Get a licence or build something new. It's really that simple."

      "If you think otherwise, you might as well bin Java in its entirity because half of it is copied from C and C++"

      Java is a poor mans C++. Its less powerful, is generally slower (though improving) and the JVM uses up far more memory than a C++ binary would for the same program. The upside? Its easier for beginners to learn and use, is sandboxed when running as bytecode and has cutesy IDEs.

      Your pays your money....

      1. JohnFen

        Re: "Get a licence or build something new. It's really that simple."

        "Its easier for beginners to learn and use, is sandboxed when running as bytecode and has cutesy IDEs."

        All of which I've come to think of as downsides, as they make it far too easy to write code that is borderline unintelligible and incredibly hard to maintain -- much worse than C++ (or even C) could aspire to.

    2. Blank Reg

      Re: "Get a licence or build something new. It's really that simple."

      "Java ME got absolutely nowhere"

      Um, it was deployed on nearly every phone on the planet, from nearly every phone maker. 100's of millions of devices per year, and millions of apps. And it was quite capable as well, giving you APIs for everything from the mundane like Bluetooth up to opengl and GIS.

      The problem was that Sun tried to play nice and let manufacturers pick and choose which optional API's to use. This did make sense since there was a huge difference in capabilities between the lowest and highest end phones. But it meant you had to be more careful when coding as you couldn't assume what API's would be there.

      Apple went their own way (or course) and inflicted the abomination that is Objective-c upon us poor developers. Android rightly chose Java since the majority of the worlds mobile developers were already using Java ME. But Google didn't want to pay those few pennies of royalties per device and so instead took Java SE and started adding and removing APIs, against the advice of their own staff.

      And now they owe billions in damages, as I expected they would all along.

      1. Colin Wilson 2

        Re: "Get a licence or build something new. It's really that simple."

        "Apple went their own way (or course) and inflicted the abomination that is Objective-c upon us poor developers."

        At least they've redeemed themselves by giving us the delectable Swift

    3. Blank Reg

      Re: "Get a licence or build something new. It's really that simple."

      That's BS. Java ME was on pretty much every phone in existence, over a billion of them. Even on Symbian and Brew based devices where the platform owners were pushing their own native development platforms.

  4. Graham Dawson Silver badge

    Andrew, in your haste to celebrate thus outcome, you are overlooking the key fact: they copied the api. Not code. Not software. A list of function names.

    APIs are now subject to copyright. The means by which software interacts with other siftware is now subject to copyright. The ability to develop an api-compatible implementation of a piece if software, in order to compete in an open market, is now subject to copyright licensing.

    If i wanted to make an os to compete with windows, that was compatible with windows api calls so that windows exrcutables could run on it, i would now require a license from microsoft.

    If i want to build a phone os that can run android aps, i now have to license the list of function names.

    I would require a license from my competitor in order to compete with them.

    I really don't think you have grasped what is at stake here.

    1. Blank Reg

      Why do you think you have the right to copy someone else's work? Do you think API design is a trivial exercise? The implementation of an API is largely grunt work, yes there are often some hard bits, but most of it isn't.

      Designing a good, consistent and usable API of any substantial size is hard, and that work should be protected.

      1. JulieM Silver badge

        Bollocks

        Just because something was hard work, doesn't mean you deserve to get paid for it.

        There is no way on Earth that an API should be copyrightable.

        1. Blank Reg

          Re: Bollocks

          Just because you don't want something to be copywritable doesn't mean it isn't.

          As a non-obvious, non-trivial original work, an API should be copywritable. Any potential implications on the industry are not really relevant to the issue of copywritability.

          If APIs were obvious and trivial then there wouldn't be so many different APIs to accomplish the exact same goals. And they would all be well designed, but in fact many or not.

          1. Anonymous Coward
            Anonymous Coward

            @Blank Reg

            "As a non-obvious, non-trivial original work, an API should be copywritable"

            If APIs were copywritable the Wine project (and probably a dozen others) would be dead in the water and its doubtful Unix would have become as popular as it was since AT&T would have kept the API to themselves and BSD and Linux would never have existed.

            How do naive, historically clueless idiots like you get into IT? FFS.

            1. Blank Reg

              Re: @Blank Reg

              As I said, the implications are not relevant here. The judge only has to go by the law, not by whether it causes you some grief. If it's a problem then it is up to those making the laws to change things.

              And I'm well aware of the history, I started programming on a PDP-11.

      2. doublelayer Silver badge

        I disagree

        An API is a list of commands. All of them had to be implemented in the first place, and so the design of the API could be considered secondary to the design of the original implementation, as otherwise it's useless. There are so many things that could be considered API-ish enough, but copyrighting them is ridiculous.

        For example, imagine that SQL was a copyrighted language. Instead of having a lot of possible database systems, which you could choose with the knowledge that your core app will keep working because basically all of your SQL statements are identical from one to another, you'd have one or two products. The open source one might have tried to get the rights to use SQL, but the company would have said no way, so things would work differently on that one. What's the big deal, you say? The big deal is that people start working on those products that are free so they don't have to pay to learn. I started to program with languages that required no commercial components. My first server was a linux one, because I could try and fail with it as many times as I needed without having to worry that microsoft would make my license not work because of something I messed up. Admittedly, I'm still using linux servers, so that might be a point in favor of the alternative. However, going back to the SQL example, people who you were hiring to deal with databases would have two options. Either use the open source one they know, which might be brilliant or might be inefficient, or learn the other one with no guarantee that they will ever use it again. SQL fixed that--I have a website with MySQL running on the databases. I needed to write a client-side program in C to deal with the same type of data. I migrated the relevant database to SQLite so the program had its copy of it. If MySQL breaks, I remove it and put a different one in. I'll have to change a few parts where I use modules only designed for MySQL, but the statements are the same. That is what API agreement can do.

        Back to programming languages. Python is a language that has an implementation. It's fine, and people use it often. There is another implementation, pypy, which is more efficient and is also used often on different systems. They adhere to the same standards, so I don't have to rewrite my code if I intend to run it on other devices. I don't even have to recompile to byte code. Would that have happened if python was run by a company that decided to copyright __name__=='__main__'? No, it wouldn't. Python would be dying. It isn't now. Guess how they managed that.

      3. Brewster's Angle Grinder Silver badge

        As, I've said before, an API is like the index to a book. So "copying" the API is like arranging for your book to have an index which has all the entries that are present in the book you're "copying". (Although you can throw in a few extras.)

        1. Anonymous Coward
          Anonymous Coward

          It's like the table of contents. A list of chapters, divided into sections, talking points, themes, major ideas, that you sketch out when planning your book, before you write it. The index is generated from the content after you've written it.

          If you wrote a 1000 page book on, say, the history of the Roman empire.

          Then discovered someone else has written a near identical book, that touched on every single point and idea you made, in the same order, but using slightly different wording (because they 'reimplented' each paragraph) do you think you'd have a claim for copyright infringement? Would a university consider the work plagiarism?

          Of course a non-trivial API is copyrightable. It takes effort and skill to get it right. As an example, the original Java date and time api is a pile of shit. JODA isn't. The intellectual effort and energy invested in turning a pile of shit into something that works well deserves protection.

          Google didn't want to put in that effort, they wanted in effect to parasitise other people's work, and they're discovering courts don't like parasites.

      4. JulieM Silver badge

        Turning it around

        I could just as easily throw your question right back at you. Where do you get the idea that your work should be "protected" against copying by other people?

        An API absolutely must be free for anyone to implementate, with their own code behind it. Exactly what your implementation does is your own business (especially if you have chosen not to share that work with the world at large; some would even regard such failure to share as a form of theft) but anyone else has a natural right to create their own competing, interchangeable code which behaves identically when given identical commands.

        An API, as a collection of names and definitions, is really just an emergent property of a software program. Even if you don't sit down in advance and plan an API in detail, one will spring into existence all by itself anyway, as a direct consequence of the existence of the program.

        Your creative work is in deciding precisely how you will deal with the mechanics of rendering data into a particular form and passing the results to a stream, not in deciding that the command to do so is going to be called printf . Anyone else can make their own implementation of a language with a printf command that behaves exactly as yours. You might want to bully people into having to write their own code, but you absolutely don't get to tell them that they can't call their own implementation of a command to format data and print it to a stream printf . In fact, they have to call it printf , in order for other people to be able to take a program written in your implementation of a language and run it using their implementation of the same language. That way, the users can decide fairly whose particular implementation they prefer. They compete on their various merits -- some users might be prepared to put up with a slightly slower implementation than yours, if it's free; others will prefer the devil they know. Nobody with a sense of fairness could disagree with that.

        1. Roml0k

          Re: Turning it around

          > Where do you get the idea that your work should be "protected" against copying by other people?

          Perhaps because of the amount of creative thought necessary to craft an intuitive, consistent, thorough, and future-proof interface to a system or application?

          > An API, as a collection of names and definitions, is really just an emergent property of a software program. Even if you don't sit down in advance and plan an API in detail, one will spring into existence all by itself anyway, as a direct consequence of the existence of the program.

          That's the kind of thinking that gives us unplanned, undesigned, agglomerated nightmares like PHP, or anything from Microsoft.

          If that's your attitude to API design, then I can see why you'd think they can't be copyrighted, and perhaps some APIs shouldn't be. But I certainly hope to never again have to develop against such a thoughtlessly assembled API.

    2. John G Imrie

      Summary

      Yesterday API's where not copyrightable. Today they are.

      1. DZ-Jay

        Re: Summary

        Wrong. As Mr. Orlowski has mentioned in the past, APIs were *always* copyrightable. Google's defense does not even contradict this; it just says that it fell under fair use. In other words, "we did infringe, your honour, but we had a very good reason for it, so we're OK."

        dZ.

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like