Oracle v Google recently captured headlines with the US District Court verdict in favor of Google, giving it fair use of Oracle’s Java API. Two years ago, on appeal of an earlier decision in this series of litigation, US Federal Circuit court sided in favor of Oracle, giving it the right to copyright the Java API. As it now stands in US law, a company has the right to copyright its API, but a user can successfully argue fair use. This outcome could be beneficial to GDC in its lawsuit against Dolby.
Readers may recall the history behind the Oracle v Google case. Oracle is now the owner of Java, through its acquisition of Sun Microsystems. Oracle makes Java available to users through a free license, but it controls compliance of the underlying code. From Oracle’s point-of-view, this a necessary step to insure that Java’s portability goal is met: “write once, run anywhere.” Open source advocates, whose goals tend to be less commercial, don’t like the compliance bit. Google, whose intentions are fully commercial, takes the open source view: it used the Java API without license to develop the non-compliant Android OS. The decisions handed down to date in this case dictate that Oracle has the right to copyright its Java API, but Google still has the right to copy it for non-compliant Android. Which raises the issue of what good is copyright?
Explained in this manner, it may seem incomprehensible that such a decision can be made. Certainly Oracle thinks so, and will once again appeal a decision of this District Court to the Federal Circuit. It appears that missteps taken by the Court will give Oracle plenty of room to have its appeal heard. Given that the Federal Circuit strongly criticized this Court before, knowledgable observers say that Oracle’s chances of winning on appeal is high. But in the meantime, there is this new judgement that will hang around.
In GDC v Dolby, the issue of copyright is raised. Dolby claims copyright to the API of its media blocks. GDC claims it has the right to use it. However, GDC v Dolby is substantially different from Oracle v Google, in that GDC didn’t apply Dolby’s API to its own products, but simply uses the API in the manner for which it was intended: to communicate with Dolby media blocks. This is a fair use case.
Addressing the issue of fair use, Section 107 of US Copyright law states, in its entirety:
§ 107 . Limitations on exclusive rights: Fair use
Notwithstanding the provisions of sections 106 and 106A, the fair use of a copyrighted work, including such use by reproduction in copies or phonorecords or by any other means specified by that section, for purposes such as criticism, comment, news reporting, teaching (including multiple copies for classroom use), scholarship, or research, is not an infringement of copyright. In determining whether the use made of a work in any particular case is a fair use the factors to be considered shall include—
(1) the purpose and character of the use, including whether such use is of a commercial nature or is for nonprofit educational purposes;
(2) the nature of the copyrighted work;
(3) the amount and substantiality of the portion used in relation to the copyrighted work as a whole; and
(4) the effect of the use upon the potential market for or value of the copyrighted work.
The fact that a work is unpublished shall not itself bar a finding of fair use if such finding is made upon consideration of all the above factors.
Studying the application of copyright law in ad hoc fashion, the use case clearly doesn’t fall into the category of “criticism, comment, news reporting, teaching (including multiple copies for classroom use), scholarship, or research,” any of which would exclude the use case from copyright infringement. Evaluating the prescribed factors, the use case is commercial, so does not pass (1). In Dolby’s case, the nature of the copyrighted work is to allow external devices to communicate with Dolby products. Hmmm. Maybe a case can be made using (2). There is a strong likelihood that Dolby’s API is substantial in capability, such that GDC’s theatre management system only uses a subset, and not the full API. Perhaps a case can be made using (3) as well. It would also appear that the effect of GDC’s use on the market for Dolby’s API is inconsequential. After all, Dolby’s media block API is intended for other devices to communicate with it. The impact, of course, is on the exclusivity of Dolby’s theatre management system and the use case where both GDC and Dolby media blocks are to be controlled from a single theatre management system. But this is a competition issue, which would be a slippery slope for Dolby to go down. So it would also appear that a case can be made based on (4).
A fair use case that argues three of the four factors prescribed in copyright law could be quite strong. In an earlier report, it was pointed out that the wording of GDC’s lawsuit first frames the case as a copyright issue. Notably, Oracle v Google illustrates that the law distinguishes between copyright-ability, and fair use. Not to be overlooked, GDC also asks the court to determine if GDC’s use case violates copyright, which allows GDC to frame its argument in terms of fair use. The fact that Google won its case arguing the four fair use factors of copyright law, and that GDC is likely to follow in its footsteps, may not auger well for Dolby.
DCI Digging A Deeper Hole for Itself
No group has made a more honest effort to bring SMPTE DCP into production than ISDCF. One of the reasons ISDCF has been popular and successful is its pragmatic, incremental approach to introducing new features and updates. Having established, through its many plugfests, a baseline for SMPTE DCP interoperability across the most up-to-date versions of manufacturer media blocks, ISDCF sent a suggestion to DCI to include its curated test materials in future DCI testing. That would set the stage for an interoperability specification for SMPTE DCP that actually works, as opposed to the multiple versions of SMPTE DCP published in years 2009, 2011, and 2013, none of which ISDCF has been successful in establishing full compliance with. But instead of taking the practical, pragmatic suggestion of ISDCF, DCI took the high road, stating it would only support full compliance with the 2013 version of SMPTE DCP. <! READ ME > This stirred a reaction in the community. DCI’s response could send ISDCF’s SMPTE DCP work over the cliff, or DCI itself over the cliff, or possibly both.
The industry has yet come to come to grips with the fact that the digital rollout is over. The historic standards work of the last decade, requiring invention in lieu of existing practice, was a funded effort, to the tune of several billion dollars secured by the underlying requirement for DCI compliance. That party is long over. But the hangover persists. The addiction for using standards committees to invent new methods for cinema is proving hard to shake, in spite of the fact that there is no longer funding to support it.
SMPTE DCP is both a casualty and a poster child of the hangover. It is a casualty due to the success of Interop DCP, which is nothing more than a pre-2009 version of SMPTE DCP. Its a poster child as, rather than standardize the DCP as in use with real deployments, engineers continued to tweak it on paper. The result was the standardized SMPTE DCP that is not backwards compatible with Interop, and just as damaging, can’t play a movie any better. Having had a hand in its creation, your author now finds it hard to justify the effort to bring SMPTE DCP into use. But it’s also important to recognize the ongoing efforts to bring it into use, which will not succeed without a lot of help. ISDCF has been providing that help.
To establish a presence worldwide, a starting point is needed. ISDCF provided that starting point by working with manufacturers to find a baseline for interoperability. That baseline does not meet the full 2009 version of SMPTE DCP. But it’s good enough. In fact, it’s not only good enough, but it probably passes the existing DCI test plan, which does not test for full SMPTE DCP compliance, but instead tests to a limited level of compliance that can be reliably met in products which must also be compliant with Interop DCP. ISDCF’s proposal to set a new but practical baseline for testing would give SMPTE DCP a much needed foot in the door.
It’s for this reason that DCI’s “high road” response regarding SMPTE DCP is simply impossible. If DCI’s member studios were funding a SMPTE DCP rollout, then its response would be warranted. But there is no money behind its words. One might wonder if DCI understands its own limited test plan. If DCI expects others to pay for its wishes, it will be a formula for failure. Not only failure for SMPTE DCP, but potentially DCI itself.
The community response to DCI’s position is a warning sign. At least one manufacturer vocally expressed its exasperation at DCI’s response to ISDCF, pointing to the fact that none of its customers were asking for the features built into SMPTE DCP 2013. SMPTE DCP requires a degree of smarts and the independent routing of audio channels inside the media block, while Interop DCP’s approach to audio handling is dead simple. At a time when object-based sound is emerging, introducing a completely new manner of handling audio, many of the audio features of SMPTE DCP are simply not needed. Why push manufacturers to comply now?
DCI’s substantial credibility was built 10 years ago through its specification and the equipment subsidies that backed it. Manufacturers strove to be compliant so that sales would quality for financing. Today, manufacturers continue to test new designs out of respect for the values that the DCI specification represents. But the organization is no longer what it once was, and its credibility is beginning to unravel. If the unraveling carries into the respect manufacturers have for testing, it would be quite damaging.
It’s time for change. The best move Hollywood studios could make today is to hand off the management of its specification and test plan to an independent organization, whose members consist of stakeholders across the industry, worldwide, including manufacturers and exhibitors, and not just Hollywood studios. It would not only put the specification and test plan on solid footing for the foreseeable future, but it would inject much needed new blood and perspective into the process. Of course, larger organizations move slowly, but that would be welcomed. The DCI specification is the baseline for digital cinema, not the leading edge.
If such an organization were to be formed, and should SMPTE DCP prove to be the direction in which stakeholders want to move, then hopefully ISDCF’s suggestion will be heard. But this author isn’t holding his breath.