Stuff Michael Meeks is doing

This is my (in)activity log. You might like to visit Collabora Productivity a subsidiary of Collabora focusing on LibreOffice support and services for whom I work. Also if you have the time to read this sort of stuff you could enlighten yourself by going to Unraveling Wittgenstein's net or if you are feeling objectionable perhaps here. Failing that, there are all manner of interesting things to read on the LibreOffice Planet news feed.

Older items: 2021: ( J F M A M J J A S O N D ), 2019, 2019, 2018, 2017, 2016, 2015, 2014, 2013, 2012, 2011, 2010, 2009, 2009, 2008, 2007, 2006, 2005, 2004, 2003, 2002, 2001, 2000, 1999, legacy html


Why Oracle's Java Copyrights Might Matter

What Copyrights

By now so many, apparently well informed, commentators have noticed and written off the Oracle Java Copyright claims as applying to the open-source implementation, documentation etc. That of course seems weak: how likely is it that Google would have cut/pasted code or documentation into their Davlik implementation, given the intense scrutiny they knew would come eventually. Page 2, Clause 11 of the complaint gives some background:

Oracle America owns copyrights in the code, documentation, specifications, libraries, and other materials that comprise the Java platform. Oracle America's Java-related copyrights are registered with the United States Copyright Office, including those attached as Exhibit H.
And as we go on (Page 8, clause 38) we get to the real grist:

38. The Java platform contains a substantial amount of original material (including without limitation code, specifications, documentation and other materials) that is copyrightable subject matter under the Copyright Act, 17 U.S.C. ยง 101 et seq.

39. Without consent, authorization, approval, or license, Google knowingly, willingly, and unlawfully copied, prepared, published, and distributed Oracle America's copyrighted work, portions thereof, or derivative works and continues to do so. Google's Android infringes Oracle America's copyrights in Java and Google is not licensed to do so.

40. On information and belief, users of Android, including device manufacturers, must obtain and use copyrightable portions of the Java platform or works derived therefrom to manufacture and use functioning Android devices. Such use is not licensed. Google has thus induced, caused, and materially contributed to the infringing acts of others by encouraging, inducing, allowing and assisting others to use, copy, and distribute Oracle America's copyrightable works, and works derived therefrom.

'Code' is to my mind only an insignifiant and pointless piece of the picture here. An interesting piece to me is the specifications: is it possible that by simply implementing (and perhaps documenting) a new implementation of parts of the Java spec - you infringe Oracle's copyright ?

A bit of History

Despite all the interest (or apathy) stirred up by the standards wars of yesterday (OpenXML vs. ODF) etc. There are plenty of older, interesting pieces that have perhaps been forgotten. Looking back to before the dawn of time itself (1997), some interesting things crawl out:

Java ISO standards battle rages

Sun Microsystems achieved one thing of note - it was the first ever, and only corporate submitter to the ISO PAS process (this is rather like the quick-on-ramp 'fast track' that ECMA enjoys eg.). There is a great contemporary write-up from b-net here which seems surreal in its contemporary flavour:

Last November Sun Microsystems won the right to become a standards submitter over the fierce, and sometimes mud-slinging protests of competitors such as Microsoft, Intel and Digital Equipment Corp. Microsoft, in particular, challenged the right of one company to serve as the submitter of an international standard, claiming that this approach offered unfair market advantage. ... if the Java platform is accepted as the international norm ... it will become tied into the government procurement process.

Despite the opposition ISO accepted the first ever, and only corporate PAS submitter (Sun Microsystems) to ISO. During the process we got all these great quotes from a Microsoft standards strategist consultant Mr. Willingmyre, that could have been written about OpenXML / ODF only with some company names swapped:

Mr. Willingmyre wants to see Sun Microsystems "follow the rules of the international system. If they will not, they undermine the credibility of the system."
Or try Microsoft Program Manager (Charles Fitzgerald):
The problem with the Java process, to date, as Mr. Fitzgerald sees it, is that "Sun has been clever in using the PAS process to get the sanction of ISO (for its product), while keeping full proprietary control. Why do we care? There is a potential marketing advantage for a competitor. ISO is getting in the business of endorsing proprietary technology."... "If Sun is really the generous, altruistic charity they present themselves to be, then why are they not playing by the process?" Mr. Fitzgerald asks. "Sun has done more to clinically exploit the standards process than any company alive."

Of course in 1997, the whole right-thinking world was on Sun's side - clearly Microsoft had some embrace and extend wheeze going, which was per-se 'A bad thing'. Why should another company be able to get changes into Java that benefited their platform ? After all - in those days - Software Freedom was an idea with far less traction than it deserved: the concept of being allowed to hack about the code as you wished without getting strangled was alien. Anyhow, this struggle set an interesting precedent. As CNET of the time wrote Sun wins Java ISO approval:

Giving a single company submitter status is unusual for ISO. Normally. such status is given to trade groups or consortia. Similar status has been given to X-Open, DAVIC (Digital Audio Visual Industry Council), VESA (Video Electronics Standards Association), and IrDA (Infrared Data Association).

The real question is Why ? - why go to all that effort and fight to get something that no-other company has ever wanted or needed ? What was the purpose ? why not form a Java trade association, or use an existing submitter ? What was going on ?

Now we have it, lets not use it: abandoning PAS

My grasp of the details are sketchier here; but by May 1999 they had abandoned the PAS submission process:

As expected, Sun Microsystems Inc. will use ECMA as its route to the standardization of Java at ISO. In this way Sun hopes to be able to retain control over the future development of Java which it would have had to give up under new rules adopted by ISO's JTC1 committee and applied to the PAS process that Sun has now abandoned.

So - because they couldn't retain ownership, control, and make it an ISO standard they switched track to ECMA. Interestingly (in the same article), the year before Microsoft had shot down another ECMA standard, the Public Windows Inititaive (PWI) - preventing it from becoming an ISO standard - why ? was there some amount of loss of property ownership implied by making it a true standard ?

"The PWI was a Sun effort to get Windows APIs put into the public domain...

And, thus we see in another parallel sphere these (strange) ideas of ownership of APIs (the hot currency of the era) being protected. Thus it was odd that Sun - who fought at length to become the first ever corporate PAS submitter, never submitted a standard, and let that capability lapse; such that they lost it. The good news of May 1999 was this:

"Sun's already submitted a Java 1.2.2 specification to ECMA which will be presented to a meeting of the group's general assembly in Kyoto, Japan on June 24. ECMA is expected to vote on the spec in December. Then it goes to ISO for fast track adoption."

There are still optimistic sounding traces of this around -

This announcement ... fulfills the company's pledge to achieve ISO standardization of the Java technology.

Sun drops ISO Java Standards Effort for good

Unfortunately, the fulfillment of that pledge never actually happened. CRN has a nice write-up from Dec 1999 here

During a meeting last month with an ECMA technical committee, Sun pulled specifications for Java off the table after copyright issues surfaced but was scheduled to resubmit last week.

What !? - copyright issues ? how can you have copyright issues around an open specification ? Who would want to retain copyright to an open specification ? and why ?

The speculation bit

My suspicion is that Java is protected by fairly weak patent protection. Ultimately Java - though it is some nice mixing pot of features, bundled up with a lot of tech marketing with great deployment, is perhaps not incredibly innovative. Those who see parallels between Java and .Net and run around like headless chicken proclaiming immediate patent death around Microsoft and Mono - take note.

Why fight so hard to get Java standardised, and then withdraw it, just before it has to be submitted ? the official answer is obvious, summarised: Only Sun is brave and good enough to create the perfect Java - a standards body would just kill it, or worse let Microsoft, HP, Intel and others have some real say in its development. Of course - there is some truth here, sole control of it means Java could move quickly, comittees tend not to produce beauty etc. We have some great quotes from the time from Scott McNeally (as above)

"There are times when . . . things have to be moved at the speed of light and there are times when we need flexibility. We're not moving Java forward in a secret way, in a non-participative way." ... The company is actually losing money on Java, he said.
The idea of Java moving at the speed of light seems slightly laughable now, but perhaps a nugget of a hint as to why they really don't want an open standard is there. Personally I get a bit sick of this generic "pauper's defense": We are not making money, therefore ... anything goes here ... whether it is not contributing to the engineering or adopting malevolent legal approaches - it is sadly still popular today.

Some alternative explanations might be more convincing; with Java's weak patent protection, and general lack of novelty - a really important piece to allow control (ie. so you can't implement, and then extend this specification), and more importantly to allow monetisation of Java by Sun was, perhaps, copyright. Copyright around the API specifications and associated implementation choices (also, conveniently, critical to compatibility). Surrending Java to be a full ECMA / ISO standard - would mean that the opportunity was lost to monetise all the fairly random decisions Sun made in the Java API via copyright licensing. Thus - the submissions were pulled at the last minute. Oh, and bad luck if you travelled to a standards meeting half way around the world, at which no standard arrived. My suspicion is that this plays into the reason that today we have a copyright and patent lawsuit against Google by Oracle.

Copyright assignment and the 'community' process

Normally companies don't like to actually look that bad, so they come up with some twisted process to 'improve the optics', and thus we do (apparently) get a standards body in the Java Community Process (JCP). Clearly it is necessary to put feel-good terms in the name: 'Community' eg. Nothing could be bad with such a friendly name right ? One notable feature of the JCP (apart from its relative dysfunction) is that you need to sign a hefty assignment before you can take part (oh, and pay money to Sun if you are a company). This of course has heavy-duty copyright assignment language (cf. the toxicity of such things in general). There is also out-bound copyright licensing conditioned on passing the TCK (which is itself tightly tied up with proprietary bailer twine).

Interestingly for those that point to percieved weaknesses in the Microsoft Community Promise around .Net (incidentally big chunks of .Net are ECMA standardized, thus reducing the potential for standard / copyright licensing based aggression) - there are great clauses in the JSPA2 around patents that do the CP's necessary claims language to shame:

"For the purposes of this Section 5.B, patent claims covering the Specification shall mean any claims for which there is no technically feasible way of avoiding infringement in the course of implementing the Specification."

But you can't copyright APIs

Indeed, hopefully not. Having said that, the Java API docs that you can see eg. here have a license that is rather similar to the other terms floating out there - particularly those necessary to join the JCP, and the outbound Java licensing text. Hopefully Sun have published their APIs without a similar license at some stage in the past, but presumably lots of care and thought has been put into this out-bound licensing. Is there anyone that hasn't accepted those terms ?

Conclusion

Quite possibly I am deranged; copyrights around Java APIs, specifications, and documentation are not a real issue, they cannot be enforced, and the Sun drive to retain copyright ownership, and impose onerous out-bound licenses on their specifications was a pointless exercise, unrelated to Java's commercial exploitation. Quite possibly Oracle just wants to go on a wide fishing expedition inside Google with their copyright claims - who knows.

Ultimately though, closed-ness doesn't pay. It seems Oracle are now reaping the harvest of the lack of trust and open-ness that sadly characterised Sun's approach to most of its 'Community' engagement. That of tryingto have your cake, and eat it too. To have an ISO standard, but not surrrender ownership and control to others. To open source something but go around spreading license FUD and demanding proprietary licenses behind the scenes, and so on. Sadly this sort of attitude continues today, and not just in Oracle but many other companies. Would it have been so terrible if some of Microsoft's weirdo extensions to Java had become part of the Java standard, and been implemented / deployed everywhere ? would they even have won a vote in a TC if they were that bad ? Having said that - I have deep sympathy with the view that the political and semi-technical sphere of a standards TC is not a great way to drive product direction.

Of course - many in the Free software community approach problems based on their love of the underlying technology - de-coupled from a love of its current commercial owner. As such, we would advocate decisions that were good for the product, potentially at the expense of its current owner. So - what does this mean for people like us ? Guard your heart ! - try not to fall in love with a technology, and give yourself to developing and improving it, if a single company owns, and controls it. As a corrolary - try to avoid assigning your copyright to companies that might use it to harm you later. And finally - try to choose to support, and use good Free Software that grants wide patent and re-use rights under licenses like the GPL.


My content in this blog and associated images / data under images/ and data/ directories are (usually) created by me and (unless obviously labelled otherwise) are licensed under the public domain, and/or if that doesn't float your boat a CC0 license. I encourage linking back (of course) to help people decide for themselves, in context, in the battle for ideas, and I love fixes / improvements / corrections by private mail.

In case it's not painfully obvious: the reflections reflected here are my own; mine, all mine ! and don't reflect the views of Collabora, SUSE, Novell, The Document Foundation, Spaghetti Hurlers (International), or anyone else. It's also important to realise that I'm not in on the Swedish Conspiracy. Occasionally people ask for formal photos for conferences or fun.

Michael Meeks (michael.meeks@collabora.com)

pyblosxom