Posts by sbt 594 posts • joined 9 Aug 2017
That's why in my hypothetical example, they'd have had to call it something different. I was trying to establish a long term understanding in the software realm that copyright can apply to APIs, because Microsoft *didn't* do what Google did 10+ years later.
But look, since this is just muddying the waters, forget MS.
Well I'm only trying to correct the record on what the status quo is. I'm not trying to convince people the law is wrong, or the judgements were wrong. I could cite the precedents noted by the judgements in support of the rulings (but why duplicate?). I could cite amici for either side, but I'm clearly not going to change your opinion on what the law should be (or how it should be interpreted).
Given the Supreme Court denied petition on Google's first appeal with regard to the JAVA API they copied was subject to copyright, I don't expect a win for them on that leg, seemingly unchanged. Now the Supremes could have denied it the first time around simply because the "fair use" alternative defence was unresolved.
Whether Google prevails on "fair use" probably hinges on whether interoperability somehow comes into it, despite not being a clear legal point of law or precedent. Without Congressional intervention, I see just as much danger in a win for either side, given folks will stretch the boundaries and litigate around them. Ambiguity is opportunity.
The precedent you cite concern a case where people held a yoga session following the steps in a published book. The plantiff sued not on the basis that the book was copied (the expression) but the steps (the idea(s)). The plaintiff appealed that the sequence was worthy of copyright. But as the instructors were not copying it, but using the sequence, the appeal failed. This is good law, but not at all applicable to Google's having *copied* the Java API. It's more akin to trying to assert copyright on an algorithm like quicksort.
It was conceded at trial that java.lang, java.io, and java.util were essential to the JAVA language. The example chosen is poor in that respect, but it only favours Google's use of those three "core" packages, assuming a "fair use" defence can then be made out, noting again that interoperability is not a "fair use" defence. An illustrative sample making the same point could easily have been drawn from any of the other 34 copied. In any event, Google did not attempt to shift focus to the three.
I think O'Malley was pretty careful to frame their appellate rulings according to the 9th's precedents. I doubt things will get overturned on the basis of some incompetence on the judge's part.
Congress could make compatibility/interoperability a fair use defence. It might clear things up a bit more than the Supreme Court ruling for either party will in this particular case, except it would be helpful to resolve the inconsistencies between the circuits on copyrightability and fair use defences.
The rangeCheck function and security files were still in dispute, since the first jury found infringement for rangeCheck, and the district court found for infringement on the 8 security files "because the trial testimony was that Google's use of the decompiled files was significant — and there was no testimony to the contrary". Google argued for de minimis on appeal, but lost; the copying was not found to be de minimis. In the event, no damages were awarded in respect of the function and security files, but Google appealed anyway.
Sure, the more interesting part concerns the API. But as I've argued elsewhere, Google's particular conduct here is not typical and the rulings in this case against them don't really represent a disaster for software users or makers. It might steer folks away from reimplementing proprietary APIs, and accepting them as de facto standards worthy of re-implementation on other platforms; I think that is a good thing.
Your constant references to the appellate decision doesn't make you right either. If it did, the supreme court wouldn't have accepted this case.
The appellate decisions are the status quo. It's worth remembering that Google's petition to the Supreme Court after the first appellate decision found for Oracle on the applicability of copyright issue was denied in 2015. Given that Google offered no new argument at its second appeal on this point (other than, in their words, to "preserv[e] its claim that the declarations/SSO are not protected by copyright law,"), it's unclear what they'll argue on this leg at the Supreme Court, or even how much shrift they'll get given their petition on this was earlier denied.
It is my opinion,...
That's quite a climbdown from your more definitive factual assertions about API copyright earlier. Thanks.
But you're still trying to draw some artificial and universal boundary between an API and source code, where no such clear boundary exists. I doubt the Supreme Court will go so far, in either direction. Considering your view that I don't believe source code should be copyrightable either," why bother to make the distinction?
GPL/Apache makes no difference (the OpenJDK was GPL); the code in dispute wasn't licenced to Google under any licence; they didn't agree one. I don't know why you keep raising Apache/Harmony; Google's claim it had copied from Harmony was whittled down in the early days when ASF denied some of the files were from Harmony, as reported on this very site. At this stage, those early claims don't rate a mention in the case judgements. The district court's first ruling against copyrightability for the 37 included this:
In particular, the Android platform replicated the same package, method and class names, definitions and parameters of the 37 Java API packages from the Java 2SE 5.0 platform.The only specific versioned reference I can find an appeal ruling comes in the second:
By 2008, Java SE included 166 API packages divided into 3,000 classes containing more than 30,000 methods. At issue in this appeal are 37 API packages from Java SE Version 1.4 and Version 5.0. We have already concluded that the declaring code and the SSO of the 37 Java API packages at issue are entitled to copyright protection.
Google may have wanted devs to use the language, but at trial, even Oracle conceded that 3 of the 37 API packages copied were really "core" to the Java language (java.lang, java.io, and java.util). Google choose not to re-frame their defence and focus on these, probably because they'd still be on the hook for 34. They continued to maintain the fair-use argument for all 37, because "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." This goes beyond just wanting to support the language, which they were free to do.
In any case, 'compatibility' doesn't create a fair-use defence. The precedents cited in the district court in support of this (relating to video games) were tossed on appeal as not being parallel to Google's conduct. They didn't copy in order to reverse-engineer, they copied to distribute.
In discussing the applicability of Section 120(b) of the copyright act that excludes protection for "any idea, procedure, process, system, method of operation, concept, etc." the appeals court found that (citations omitted):
It is well established that copyright protection can extend to both literal and non-literal elements of a computer program. ... Google nowhere disputes that premise.There follows a detailed analysis of a three-part test to assess whether the copied work embodies an expression of an idea, or mere idea. Too long to quote, refer here.The non-literal components of a computer program include, among other things, the program's sequence, structure, and organization, as well as the program's user interface. ... As discussed below, whether the non-literal elements of a program "are protected depends on whether, on the particular facts of each case, the component in question qualifies as an expression of an idea, or an idea itself."
At this stage, it is undisputed that the declaring code and the structure and organization of the Java API packages are original. The testimony at trial revealed that designing the Java API packages was a creative process and that the Sun/Oracle developers had a vast range of options for the structure and organization. In its copyrightability decision, the district court specifically found that the API packages are both creative and original, and Google concedes on appeal that the originality requirements are met. ... The [district] court found, however, that neither the declaring code nor the SSO was entitled to copyright protection under the Copyright Act.
Congress emphasized that Section 102(b) "in no way enlarges or contracts the scope of copyright protection" and that its "purpose is to restate ... that the basic dichotomy between expression and idea remains unchanged."
After that, this para:
Oracle asserts that all of the trial court's conclusions regarding copyrightability are erroneous. Oracle argues that its Java API packages are entitled to protection under the Copyright Act because they are expressive and could have been written and organized in any number of ways to achieve the same functions. Specifically, Oracle argues that the district court erred when it: (1) concluded that each line of declaring code is uncopyrightable because the idea and expression have merged; (2) found the declaring code uncopyrightable because it employs short phrases; (3) found all aspects of the SSO devoid of protection as a "method of operation" under 17 U.S.C. § 102(b); and (4) invoked Google's "interoperability" concerns in the copyrightability analysis. For the reasons explained below, we agree with Oracle on each point.Again, see the link for the detailed reasoning.
Plenty of people think an API is trivial, as far as copyright is concerned.
Maybe, but not the appeals court in this case. The Supreme court may overturn either leg, but I think Oracle is on safer ground with their 'Java SE has a copyrightable API' win than their 'Google's infringement wasn't fair use' win, because of the legal approach the court took to overturning the jury findings in the 2nd appeal. The first appeal result seems pretty solid.
On the other hand, I think there is more a risk to license integrity (including the GPL 'taint', not that I'm a fan) if APIs are excluded from copyright protection based on a precedent. Where does that leave in-lined function definitions in C++, for example? They're implementation, not interface, but they're in the interface files. Much messier than the current arrangements where source is copyrightable and licenses apply.
To clean up that mess, you'd have to amend the copyright law in order to define what an API is made of.
Consider what the basis for the licence was; no API copyright, no license enforceability. I excluded the trademark question by hypothesising 'Motlin'. As MS were writing their own implementation for their JVM, the APIs were all they needed to reproduce for 'compatibility'. But the license applied, because the copyright applied to what they reproduced, viz. the API. They settled.
What I've been trying to illustrate mentioning the MS vs. Sun case is that the copyright treatment of APIs in the case between Google and Oracle is not some new, revolutionary approach that will bring the sky crashing down. The appeals court upheld copyright protection for the Java SE API based on law and precedent (in the 9th and other circuits). Don't take my word for it; read the judgements.
You might disagree that APIs should get any protection in U.S. copyright law, but changing that will most likely be a job for Congress.
They deal with all the mistakes you make in understanding how copyright applies; what it applies to; how defences to copyright violations are established, and weighed up. Really worthwhile.
Here, I'll even link the appeal judgements for you:
Judgement in the second appeal
Worth a read just for the introductions, alone. These stand, unless the Supremes overrule. I can see them weighing in because they often do when circuits differ on precedent (as applies here). But it's worth pointing out only the 1st circuit favours Google's position here. These rulings are according the 9th's, but a few others conform.
This is misleading, if not flat-out wrong. Google and Oracle agreed at trial that the materials copied in dispute were part of the Sun Java SEs (1.4 and 5). That the code was out there under a different licence is irrelevant. Google did not try to claim their use was legit on the basis of Harmony (maybe because that licence didn't suit their purposes, either).
The case was not about the language, which Google was free to use. Again, stipulated by both sides at trial. It concerned only the 37 packages, the rangeCheck function, and the 8 security files.
Read the appeals judgements, in full, before replying, please.
the interfaces aren't subject to protection (nor should they be) and so it doesn't matter if Google copied a single interface, or all of them. It's still perfectly legal.
This is flat out wrong. Repeating it does not make it true. Read the judgements in the appeals; the appeal court found Oracle's API worthy of copyright protection as embodying the expression of an idea, not just the idea. The first appeal allowed fair-use might apply and reverted it for re-hearing. The second appeal took the evidence from the re-hearing and overruled the jury that Google could claim fair-use. The copyright ship has sailed.
Copyright has clearly applied to software source and code in the US since at least 1980. This ruling for Oracle threatens little, except the casual ripping off of other people's development efforts. If you want to copy an API, get a licence. Google could have done the right thing from day 1, but they wanted to fragment the Java platform, but not play under the GPL.
But, but, you said you can't license an API?
If there were no copyrights in APIs, Microsoft could have made their incompatible version without a licence, incompatible or otherwise. They just couldn't have called it Java. That would be a trademark issue.
APIs are not just a method or procedure. Read the judgements on appeal in this case. Oracle has prevailed on the legal question that their Java API code was copyrightable. Google is continuing this fight on the question of fair-use, although the second appeal denied them this defence.
If not, the licence would have been un-enforceable. MS could have argued they were free to write their own incompatible implementation of the API and didn't need to comply with Sun's licence. They could have called it something else, I don't know, like "Motlin".
By your analysis, copyright protection wouldn't apply to any software source code, since that is clearly procedure, process, etc.
Clearly, that's not the case. You can't use this clause to shave off the API from source code and leave one protected and not the other.
In fact, this clause just says you can't use copyright to protect the idea or process or procedure. That others are free to implement the process or procedure expressed, just not in the same or substantially similar words. It's the same as the test for plagarism. It doesn't exclude the form of words used from protection. Google copied the form of words because they copied the files, not just the idea.
By trivialities, I was referring to single keywords. It's the originality, arrangement of the words, the similarity of the expression as a whole that forms the test for 'copy' vs. 'derivative work' in copyright law. Google just copied, and they copied not just a list of common and widely used words in technology contexts. They could have made their own API with a similar set of functions and Oracle would have nothing to say, but they didn't. There are already dozens of APIs in different languages all providing the same essential services, but you don't get copyright lawsuits because they're different expressions of the same idea.
German dogs could be trained with a different set of words. But as I said, that's not the point, the copyright wouldn't be in the idea of training dogs, the command words, or even just the list of words, it would be in the training manual, which any number of people could write a version of, describing the same techniques, and still have copyright protection. You don't see the first person who wrote a "hammering nails for dummies" book start legal action against everyone else who describes carpentry techniques.
The dispute here is whether an API definition is just a list of words (no copyright) or the expression of an idea worthy of copyright protection. I think the latter, under current US law. So do the DoJ, apparently.
You have confused my argument. I'm suggesting the opposite; that there's a danger to GPL protected code if APIs aren't protected by copyright. For example, the GPL is no stronger than the LGPL in that case, since if copyright doesn't protect the API of a GPL'd library, I can simply copy it into my code base and ship my binaries with dynamic linking. The GPL library authors can't complain. No copyright, no basis for license enforcement. It would be bad faith, but what's to stop OpenZFS shipping a substitute kernel API file that puts the symbol back (for interoperbility!). It was part of the API, wasn't it?
I know the difference between interface and implementation. Google were doing their own implementation. The issue was they copied the interface files en masse.
Yes, you need a copy of the header files to compile. You don't need to distribute them, to use the API. Any files you do get a copy of can be copyrighted and licensed to you for the purposes of compilation. There doesn't need to be a blanket exclusion on API copyrights for this system to work. As I said elsewhere, people have been placing copyright notices on header files from the earliest days of C, with no ill effects. This is because licensing is generally liberal, or vendors of libraries by necessity have to allow you to #include if they want you to buy their code.
This is not what Google/Android, Inc. was doing. They copied files to create their own product, and distributed them.
Call me cynical if you want, but I'd say one amici, Microsoft, might be looking for ruling to help them avoid future claims like the one they were forced to settle for similar behaviour with JVM.
Worth noting that the settlement of that case didn't bring software development to a grinding halt. It was almost 20 years ago.
No, copyright is not in plugs. Patents or registered designs, maybe. APIs fell under copyright by virtue of being published like books. Different jurisdictions have applied fair-use exemptions or compilation exclusions, but it's the applicability or not of copyright law at issue here.
This is not analogous to the Java API case. Just as common words and phrases are hard to trademark, copyright doesn't subsist in trivialities. In any case, German dogs aren't trained with "sit", "stay", etc. Other words could be used, but regardless a court wouldn't grant copyrights over "print" in one programming language over another; even a complex set of keywords wouldn't be considered for copyright, as mere compilations or lists generally don't get protection, either. (c.f. phone books).
The API isn't just the keywords; it's the signatures, types and defined constants that make up the whole work. Ironically, Google only needed 170 lines of the 11kloc they copied to provide the compatibility.
Sorry, yes I mixed that up. It was the appeals process that knocked out copying as fair use. It still wasn't a win for Oracle against clean-room re-implementation, the essence of my question. That's why I asked if Flocke Kroes was referring to another Oracle win.
And since copyright isn't in ideas, but their expression, that's according to how copyright works. Some may argue that creative ideas should be protected like patents for inventions or designs, but originally it was created to provide the necessary but not overly generous incentives to invent or create, without eliminating the public domain.
Yes, and they acknowledged as such. Clearly Oracle waited until they had a big fish wriggling on the hook and they've been trying to reel Google in ever since. But in turn Google can argue some bad faith, since they offered to license and were turned down.
I didn't ignore it; unlike trademarks, a failure to enforce rights under copyright doesn't invalidate them if later asserted. 'Squatters' rights' don't apply.
It's a stretch of imagination for some, but it's possible to believe that one party to a case should win on the particular merits while thinking they should lose on legal principle.
A win for Oracle in this case doesn't mean their point-of-view about CRIs or fair-use interop prevails. The precedent value would relate to Google's (Android, Inc.'s) conduct in re-implementing an API without a license.
There are plenty of orgs (W3C, ECMA, ISO, etc.) doing standards work providing for platforms. It's not the end of the world as we know it if either party wins.
Interface code has shipped with copyright notices from earliest days of shared source. Just ask AT&T or the Regents of the University of California. If everyone 'knew' APIs were uncopyrightable, we'd be living in a different world.
The precedent risks from this particular case are overstated given the agreed facts of Google's conduct. The other amici like Microsoft are piling in for a win, either in the court of public opinion, or because their model around Embrace, Extend, Extinguish works more easily when they're free to eat a smaller dev's lunch library via API copying regardless of license terms.
... that makes a clean room implementation copyright infringement unless it is somehow shown to be fair use.
Not in this case, surely? The lower courts ruled/juries dismissed Google's fair use claim based on their admission to copying for convenience, not that they'd done a CRI. If you're referring to another case with judgement for Oracle, please cite.
If 'fair use' even with copying for interop turns out to be legally cloudy/high risk after this case, there's a longer term win all 'round, where open standards set by foundations/industry bodies/standards orgs are in the ascendant due to cost / risk factors, rather than vendor proprietary, monopoly solutions (even if freely provided, for now).
This seems to hinge on whether a "clean-room" re-implementation would, by necessity, be a derivative work in order to be compatible, even if not an actual copy. Then the question of 'fair use' for the purposes of interoperability apply. Congress could make the law explicit on this point.
I thought Google (or the co it bought Android to obtain) admitted copying the files, so the clean-room factor not directly at play in this case?
If companies want monopolies on proprietary APIs, we can all switch elsewhere if we don't want to pay or they don't want to charge (although why publish an API if you're not looking for others to use it?); I don't see any legal problems with the standard C++ library (or Boost).
Well, the original source files would be, if the API were published in the form of source code. You could still do a clean-room reimplementation, or choose one of the many that are freely licenced. Or write your own. The APIs that are locked up get ignored. Or, like the Win32 API, flourish anyway.
Or if you're Google, you could buy a license.
I agree copyright terms are far too long (thanks, Disney!), but I don't think that affects the principles at stake here.
A win for Oracle here just hastens Java's demise, and any other API definitions not liberally licensed.
When people (and organisations) show you who they are, believe them. A vendor willing to publish an API but not licence it on FRAND terms deserves the reputational hit and neglect that entails.
On the other hand, there may be some utility in being able to control via licensing access to an API. A copyright free-for-all removes that possibility. For example, couldn't the OpenZFS devs could copy the GPL'd kernel API code they need for performance so as get around the GPL? Copyright protections cut both ways, surely.
As I understand it, Google copied and shipped copyrighted source code to implement the Java API, not merely referenced it/included it in order to consume it, the typical use-case most devs would be concerned with.
I'm not sure which line of thought you're referring to; the worthy employer or the 25% benefits threshold.
If you treat recruitment of TAs as a form of internship, where you have a program to recruit into academia from the student body and give students an opportunity to experience the challenges and rewards of teaching and decide whether to pursue it as a career, that's fine. Proper unpaid internships need to follow some program and be limited in scope to avoid issues of exploitation.
As these students were being paid (but allegedly under-compensated), this situation appears to have been more exploitative and designed to cope with teaching loads for minimum outlay. Referring to practices at other institutions risks the trap of "whataboutism".
This post has been deleted by a moderator
On the legal case question, I'll just add that if you're truly a minnow, the big fish won't bother you. If you're big enough to notice, get a proper lawyer. Start a legal defense fund with the first dollar your code makes.
On the EULA point, I read these too. I've never been a Hotmail user, but I would be extremely surprised if the license actually assigned copyrights in material transmitted. I expect you've misread this and the relevant clauses permit them to read the material, to check for viruses, gather marketing information, etc. Normally EULAs for services like Linked In provide for a Use licence grant so that the service can store user generated material, and transmit it to Web users, etc. It's a necessary protection for them, but it doesn't diminish your rights to own, sell or otherwise deal in the same material; you retain the copyright.
There are more egregious examples of Big Web exploiting orphaned works and ripping off content makers (e.g. YouTube's policy on automated infringement detection being conditional on agreeing to licence works).
I'll accept a view as evidence of someone's opinion. So I accept that it is your opinion that Danese's version is the correct one, and Simon's is false. You've acknowledged Simon and Danese have different narratives. You must therefore also accept my initial claim there's a disagreement.
But unless you're willing to offer some facts (and evidence for same) and not mere assertions, I'm going with my follow-up, as well. I think the Phipps narrative is more credible in explaining Sun's decision on the CDDL license, and the motive Danese claims about the CDDL being selected for deliberate incompatibility with GPL don't make sense, because the expectation at the time (e.g. as explained by Bryan Cantrill) that CDDL code would be accepted in Linux. Without another corroborating source in support, I find it hard to accept Danese's version as the more likely one.
Facts, please. Otherwise, we'll be going around in circles.
I never claimed he did. But since you wouldn't accept the statements of Sun employees like Simon Phipps as proof of a disagreement, I offered a third-party source instead, with at least some claim to contact with the Solaris contributor group.
Working at Sun seems irrelevant, since not even Sun employees agree on this. Well, at least Danese vs. the rest that I could find.
If you are prepared to accept Sun employees' views on this, look at the rest of the thread I originally linked containing Simon's comment; there are more Sun employees than just Simon disputing Danese's version of events. However, I didn't spot any, not one, agreeing with her claims about the reasons for CDDL being chosen rather than GPL.
It certainly demonstrates there's a disagreement; my original contention, QEFD. Frankly the more these comments go on, the more I'm convinced the facts support the Phipps position altogether.
I know where you were not. That is, you were not present during the CDDL discussions inside Sun...
Certain of that, you seem. Yet...
There is a slight possibility that you were, indeed, present during these discussions.
Come on, you can't have it both ways. Unless you're prepared to de-cloak and identify yourself as a known Solaris contributor or Sun employee, let's stick to public statements by the people involved. Here's another one contradicting Danese, this time from Jörg Schilling.
I'm not misrepresenting. I'm saying there's a disagreement about the reasons behind ZFS being open-sourced with the CDDL. It's not a slam-dunk, as you claim, based on the public statements provided. For what it's worth, I think Linus' caution is reasonable.
Well, if you're being sued, I believe the burden works the other way. The provenance is more relevant than say, the presence of your name in the code (which can be easily modified). But if you've previously published it, backed it up, kept it in a SCS, these all create a digital trail which strengthens your defence.
An opponent trying to assert primary authorship would have to produce similar evidence that somehow pre-dates or contradicts yours, including maybe inducing some other coder to perjure themselves and claim they wrote it first. It's an unlikely scenario that I haven't ever seen; in any case, the particular license the code is published with makes no difference here (if the claim is about copyright authorship, not license compliance).
If you're using other folks' code, you want to be damn sure you've got the correct license with it and comply. I've seen a couple of repos online with GPL files replaced with MIT (possibly not deliberate, e.g. where code bases were combined, but still wrong). "See LICENSE" in the code makes this change too easy; every file should name the explicit license and version that applies.
Or, the required surgery and happy pills are probably still way cheaper than buying your own ticket. Even if you don't get picked, you're still a 20-something Japanese woman. Some might call that a win.
London to a brick the 'winning' contestant is closer to 20 than 30.
Mine's the one with the Hello Kitty picture on the back and pink fluffy hood fringe. -->
I prefer the idea of a pop-up camera rather than stupid notches in the screen. I'd be happy with just a rear camera, but I get that's not most people's preference.
Anyway, glad there's still some folks trying to innovate in this space. I'd still like a smaller screen so it'd still fit in my pocket, though. This screen size war is as pointless as the SUV height war.
Thumbs up; this is exactly my concern. Particularly when the charity sector (at least down here) is notoriously poorly operated, with waste and duplication. There should be standards for funds raised disbursement vs. consumption in internal expenses in order to maintain charity status. And the religious organisations running profitable services tax-free ought to be reigned in as well.
Then there's the exploits where the wealthy set up their own charitable foundations, launder in their tax deductable contributions and then take themselves out to expensive lunches on the foundation's dime. There should at least be some 'arm's length' rules to prevent this kind of self-dealing.
That's interesting. I don't know about the US, but here down under, donations to registered charities are tax deductable, but the taxpayer claims the deduction from the ATO (local Revenue equivalent). The charity doesn't get the break, only the benefit of the incentive.
UK 'gift aid' arrangements seem better, except that they're still a distortion of the tax system. I'd rather see these deductions abolished, along with a lot of other loopholes, like family trusts.
The Register - Independent news and views for the tech community. Part of Situation Publishing
Biting the hand that feeds IT © 1998–2020
