Archive for the 'Legal' Category

Version 2.0 of the Mozilla Public License

Published by Gabriel Hanganu on January 17, 2012 in Community and Legal. 0 Comments

Following a two-year revision process based on feedback from Mozilla and the broader open source legal community, version 2.0 of the Mozilla Public License (MPL) was recently released. The licence encourage contributors to share modifications they make to MPL-licensed code, while still allowing them to create projects that combine MPL-licensed code with code under other licenses (either open or proprietary).

Like its previous version, MPL2 has been acknowledged as a free software license by the Free Software Foundation and as an Open Source license by the Open Software Initiative.

The most important changes from the previous version include:

  • MPL2 is simpler and shorter;
  • addresses the recent changes in copyright law and incorporates feedback from lawyers outside the United States;
  • offer patent protections aligned with other open source licenses, which allow communities to protect contributors if these are sued;
  • provides compatibility with the Apache and GPL licenses, making code reuse and redistribution easier.

Carmack’s Reverse: a FOSS patent case study

Published by Rowan Wilson on November 18, 2011 in Business and Legal. 2 Comments

Just a quick one on the subject of open source and patents. John Carmack is well known in gaming circles as the lead programmer behind such classic PC and console games as Castle Wolfenstein, Doom (and sequels) and Quake (and most of its sequels). Carmack and his company id software are the originators of the ‘First Person Shooter’ genre of game which has in turn spawned such gigantic franchises as Call of Duty and Halo. As well as being technical pioneers, id has an interesting policy of releasing their old engine technology (the software which renders the game’s video and audio) as open source under the GNU GPL v2. This allows students of gaming software development to look at how real commercial games software is written, and also allows the games to be ported to new hardware platforms by volunteers. As the art and sound assets are not included with the code, this also generates a small market for licences to old id games – games which may well not run on more modern operating systems – in order to get the game data for use with the aforementioned ports.

Rage, the id game which uses version five of the id rendering engine (id tech 5, as it is known) has just been released. This is the point at which the source to the previous engine would usually be released as open source. However in this case there is a problem. Back when id tech 4 was being written for the game Doom 3 over the period 2000-2004, many games developers were looking into what were then cutting edge graphical technologies for inclusion in their games. One such technology was stencil shadowing, which accurately projects shadows from moving objects onto surrounding surfaces based upon the light sources which are illuminating them. This is hard work even for the specialist graphics hardware in PCs and consoles, and so any algorithmic optimisations that are possible are highly valued by the industry. So, various developers hit upon the same optimisation around the year 2000. This optimisation has come to be known as Carmack’s Reverse, even though it was first presented by William Bilodeau and Michael Songy of Creative Labs back in 1998. John Carmack discovered it independently some time later, and was perturbed to discover that Creative had already patented the process.

Faced with a choice between licensing the patent from Creative or making his code sub-optimal, Carmack decided to strike a deal with Creative that allowed him to use the technology at no cost. Perhaps coincidentally, id also agreed to use sound rendering technology by Creative in their game.

So the game was shipped and everyone was happy, until half a decade later when it came time to ship the code as open source. Obviously whatever deal was agreed between Creative and id did not involve making code available that embodied Creative’s patent under an open source licence for the whole world to use. In a tweet on the subject Carmack explained:

Lawyers are still skittish about the patent issue around “Carmack’s reverse”, so I am going to write some new code for the doom3 release.

It will be interesting to see how Carmack replaces the code, but the issue is also of interest because it illustrates the importance of keeping good records of the inbound IP in a software project. id’s lawyers caught what could have been an expensive potential infringement of Creative’s rights when they ’skittishly’ requested that Carmack rewrite the code.

SaaS – Who shares wins?

Published by Rowan Wilson on September 28, 2011 in Legal and Software. 0 Comments

Fairly often we are asked by projects we advise whether they can make an open source release of their code while controlling whether others can make money from it. In fact, we get asked it so often that it now has a place in our FAQ document:

3.8. Can I restrain commercial reuse of my code using an open source licence?

Not directly, no. Point 6 of the Open Source Definition states that a pre-requisite for any licence to be considered open source is that it should make ‘No Discrimination Against Fields of Endeavor’. Commercial exploitation is a field of endeavour.

Having said this, some open source licences make code that they cover less appealing for commercial entities to include in their products. In general, licences with some element of ‘copyleft’ such as the GNU GPLv2 or the Mozilla Public License will compel commercial reusers to make some or all of their own code open source. Permissive licences such as the BSD License and the Apache License v2 on the other hand allow the code they cover to be added to a closed source project without compelling any other code to be open source.

Recently we received a novel variation on this query, and I have adapted my answer to be a post for this blog. It’s not yet a frequently asked question, but it may well become so. The questioner had written some code which implements a network service, and wanted to know if they could make an open source release while simultaneously discouraging others from selling hosted services based upon the code…

There are free and open source software (FOSS) licences which make conditions about this kind of use of the software that they cover. The Open Software License v3 and the GNU Affero GPL v3 are examples. There is a brief explanation of this kind of licence condition on the OSS Watch site.

All that these licences require, however, is that licensees who deliver functionality of the software over the network must make the source code to their version of the code available to users. This ensures that improvements to the software are released back to the community, but it may not act as a strong disincentive to those providing the service; after all, it does not compromise their core offering of network services. Contrast this with the more traditional model of distributing the software itself, where basing a product on (for example) GPL v2 code would mean that your own product must also be GPL v2 licensed, compromising the ability to charge for licences;  after all, customers could onwardly distribute the product to other potential customers, undermining the business model.

The second – more traditional – example there is the basis for the common dual licensing FOSS business model. The project provides a ’community’ version under a copyleft FOSS licence and a commercial licence for businesses wanting to build a product on the code base for which they charge a licence fee. The model works because the copyleft licence has conditions that the business will pay to avoid. In the ‘application service provider’ model we are discussing here however, the condition that source code must be provided may well not be onerous enough for the application service provider to pay to avoid, particularly if they have not invested in improving the code in any way.

The upshot of this is that – if one wants to restrain competing businesses from using the software to provide a network service – a FOSS licence may not be the optimal choice. Having said that, it might be worth examining the motivation behind restraining competitive network service provision in the first place. In the worst case, where the competitor uses the code unmodified and therefore sacrifices nothing by making that source available freely, they are also necessarily behind the project maintainers in terms of consideration of improvements and new features. Given a choice between buying hosting from the originators of the software and a copy-cat business which makes no contribution to the code base, customers may well choose the former. Conversely, if the competing business is actively improving the code and making those improvements available as a result of the conditions of the licence for the initial project, this could be seen as a positive outcome that benefits the entire ecosystem and leaves businesses to compete on quality of service rather than code quality.

Top 10 IP and licensing tips when licensing open data and open content

Published by Elena Blanco on August 8, 2011 in Guest and Legal. 0 Comments

This guest post has been contributed by Naomi Korn and is based on a series of 10 Minute Blog entries that Naomi has written for the JISC funded OER IPR Support project, for which she is the Project Director. Naomi is the co-author, together with Charles Oppenheim of Licensing Open Data: A Practical Guide.

Editor’s note: This post addresses IP issues surrounding open data and open content rather than open source software. Whilst open data and content is outside OSS Watch’s remit it is, of course, pertinent to the world of open source software and we welcome Naomi’s thoughts and expertise.

1.    Identify the IPR and other legal issues which maybe associated with the data and content you wish to license. For example, even if there are no underlying IPR issues in your data and content, you may be constrained by contractual terms and conditions underpinning the supply of data etc. from third parties to you. You can read more about this at http://www.jisclegal.ac.uk/Projects/TransferandUseofBibliographicRecords.aspx

2. Don’t forget to identify all the layers of rights. There may be more than one layer of copyright materials, other types of IP (such as Performers’ rights) as well as other legal issues (such as Data Protection etc) which will need identifying and managing.

3. Decide how ‘open’ you wish to license your data and content. Issues that may need to be addressed include: – controlling use for non commercial uses only vs. allowing commercial exploitation by third parties and encouraging BCE etc – requirements for attribution vs. the resulting possibility of attribution stacking – controlling reuse and repurposing but sacrificing potential interoperability when blending with content, data as well as software licensed under more open terms.

4. Remember that the more ‘open’ the use and repurposing of your content and data, the greater the risk if you have not cleared all the rights.  This is particularly pertinent for in copyright materials for which the rights holders are either unknown or cannot be traced (so called ‘orphan works’). In these situations, the OER IPR Support Risk Management Calculator can be used to establish an indicative risk score which can be used to help inform decisions relating to risk management.

5. Risk Management is increasingly important in the provision of access to open content where it may not be clear who created what and who owns what rights (if any). An organisation’s relationship to risk management should be supported from the bottom-up, by a realistic understanding of the nature of the work and its proposed use, and by the top-down recognition that an organisation’s understanding and acceptance of necessary risks, needs to be agreed, captured in policies and where possible, mitigated. This is an important component in the development of an appropriate corporate governance framework to support the delivery of open content and open data.

6. Consider how the licensing of your data and content relates to the licensing of other types of materials such as open source software, and whether one broader licence, such as the Open Government Licence which covers data, software, content etc might be more beneficial than multiple licences.

7. Clear permissions with any third parties (as per 1 above), making sure that permissions that are sought are either the same or more than the permissions that you then grant under your selected open licence – never less! The support video profiled on the OER IPR Support webpages can provide more insight about this issue.

8. Remember, open licences are often irrevocable, global and in perpetuity, so make sure that you are happy with what you intend to do with your data and content before you licence it out. Worst case, openly licensed resources can be removed from the web etc., but permissions granted up to that point cannot be revoked.

9. Get permissions in writing, such as emails etc from any third party rights holders. Verbal permission is not adequate.

10. Extract key information relating to third party permissions and store in a suitable system which is centrally accessible to prevent the ’siloing’ of core rights management information. This is particularly important if projects are funded for a specific period time, such as JISC Projects, but where the permissions to use the materials may be subject to certain limitations and/or crediting requirements etc, as well as ensuring that there is a place to record rights holders contact details in case further contact is required.

i4i and the law of retaliation

Published by Rowan Wilson on April 28, 2011 in Business and Legal. 0 Comments

The legal troubles of Microsoft with Canadian technology firm i4i may seem far removed from the world of open source, but in fact this legal battle – which has just reached its final stages in the Supreme Court of the United States (SCOTUS) – will have repercussions that are bound to change the environment in which open source survives and grows. To sum up the issue: i4i have a software patent that – they have successfully argued – Microsoft infringes upon in their ubiquitous Office package. As a result Microsoft had to pull Office from the shelves 18 months ago and alter it to ensure that the patent was not infringed going forward. Microsoft appealed the decision, arguing that the patent was invalid as a result of ‘prior art’ (meaning that someone else had had the idea first) and that it was not fair to expect litigants who were trying to invalidate patents – such as themselves – to meet the very high standard of proof that is currently necessary. The chief problem, from Microsoft’s point of view, is that the US courts have got used to applying the so-called ‘clear and convincing evidence‘ standard to arguments that patents are invalid as a result of judicial precedent, but that in fact Congress never approved this standard, and that the less stringent ‘preponderance of evidence‘ standard – the default for civil litigation – should apply.

Specifically in the i4i SCOTUS case this would mean that Microsoft could use circumstantial evidence that i4i in fact invalidated their own patent by selling a product based upon the technology over a year before they applied to patent it. Unfortunately for Microsoft, the source code to this late-90s product  - which would have been direct evidence of invalidity and therefore met the ‘clear and convincing evidence’ standard – no longer exists. All Microsoft has are manuals that imply that the technology was present in the product. So if SCOTUS agrees to Microsoft’s arguments, Microsoft will be able to bring this weaker evidence back to the court and will have a much better chance of invalidating i4i’s patent.

While this would to be cathartic for Microsoft who have been losing heavily every step of the way in this chain of cases, the implications of a Microsoft win here would be profound indeed, and perhaps surprisingly, they would benefit open source software a great deal. Lowering the standard of proof needed to invalidate a patent would – inevitably – lead to the value and effectiveness of patents themselves dropping. Generally open source software is on the receiving end of patent litigation; there is little motivation for open source developers to apply for patents as the licence they plan to use on their software makes the patent rights available at no cost to everyone. If that’s the effect you wish to achieve, just releasing the software does the job without any additional patent attorney fees. So – arguably – any weakening of the defensibility of patents benefits open source developers and users.

When a case gets to SCOTUS there tend to be many briefs submitted from interested parties not directly involved in the action. These ‘Amicus Curiae’ (friend of the courts) briefs describe the view of these external parties who feel they might be affected by a decision one way or the other. In this case, i4i’s argument is backed by a very wide range of patent-obtaining entities from Universities to pharmaceutical companies. Even the US government has submitted a brief arguing that the current standard should stand. Submitting briefs backing Microsoft are – among others – Apple, Google and Apache. It’s an interesting sign of how – despite the endless rounds of suing and retaliatory counter-suing over software patents in the IT industry – the big players see the current system as flawed and damaging. The contrast with the Pharmaceutical industry in this case couldn’t be more striking. For Pharma, patents are unequivocally a good thing, serving their need to underwrite investment in research with strong IP protection of their products. In IT it seems, even those with the largest patent portfolios see them as too powerful a weapon. When even the owners of software patents want them weakened, it’s hard to argue that the current law strikes the correct balance.

Of course, the problem here is that Microsoft’s argument, if successful, would reduce the enforceability of every kind of patent in the US, software or otherwise, and for that reason it could be argued that even if the IT industry is being hamstrung by endless patent wars, that is an evil we must tolerate for the good of innovation across the economy. Having lost the opportunity to reduce the protection of software patents on their own during Bilski it may be overly optimistic to hope that SCOTUS will address this even wider issue with anything like clarity. The court is expected to deliver its conclusions in June.

The Novell Deal

Published by Rowan Wilson on December 3, 2010 in Business and Legal. 0 Comments

The web has been aflutter with the news that Novell – owners of the SUSE Linux distribution – have been sold to Attachmate, and that futhermore a bundle of 882 patents belonging to Novell have been sold to CPTN Holding, a somewhat mysterious proxy for a group of tech companies organised by Microsoft. Whenever the words Microsoft and Linux get mentioned together there is extensive internet drama. In this case the concerns raised were chiefly

  1. that Microsoft might somehow use the 882 patents to destroy Linux
  2. that Attachmate might kill the openSUSE project

Point 2 was answered quickly by a statement from Atachmate shortly after the deal was announced:

“The openSUSE project is an important part of the SUSE business… As noted in the agreement announced today, Attachmate plans to operate SUSE as a stand-alone business unit after the transaction closes. If this transaction closes, then after closing, Attachmate Corporation anticipates no change to the relationship between the SUSE business and the openSUSE project as a result of this transaction.”

That leaves the suspicion that CPTN Holding might be a lynching posse for Linux. An interesting post on the FOSSPatents blog argues convincingly against panic on this score, but I think there are also other reasons for delaying any effigy burning or widespread acts of civil disobedience.  Novell was a member of the Open Invention Network, an organisation that holds a group of patents and licences these to tech companies on condition that they commit not to use their own patents against Linux. The OIN is criticised on occasion for seeming to be inert (in fact the blog post I linked above does just that) but it’s quite possible to argue that for a body like the OIN success looks an awful lot like inertia. After all, if it were constantly having to ride to the rescue of Linux, it would be failing in at least its intended deterrent effect.

In any case, OIN is kind enough to publish the standard agreement that tech companies sign up to when joining.  This agreement covers what happens when a signatory wants to sell (assign) the patents that they have agreed not to use against Linux:

5.1 No patents subject to this Agreement shall be assigned or any rights granted hereunder unless such assignment or grant is made subject to the terms of this Agreement. Neither OIN nor You shall assign this Agreement, assign any of its rights under this Agreement, or delegate any of its obligations hereunder, unless otherwise agreed in writing by the other party. Any attempt to do any of the foregoing shall be void.

I am not a lawyer, but my reading of this clause is that – assuming this agreement was in force between them – Novell needed OIN’s agreement to sell their patents and the patents themselves remain subject to the agreement at their new home. If this is the case, it seems extremely unlikely that they can be used against Linux.

IP dust-up round-up

Published by Rowan Wilson on November 8, 2010 in Legal. 0 Comments

In a world where the most recent arguments over IP are almost impossible to track effectively (although I’m grateful to the The Guardian for providing this handy diagram on who is suing whom in the world of mobile phone technologies) it’s nice to be able to catch an argument that is going to be huge in its early stages. David Willetts, Minister of State for Universities and Science in the Coalition Government, has praised the US patent system and suggested that in the UK we are too reluctant to allow the patenting of wide areas of invention:

“In the US, it’s easier to obtain software patents, and Google was able to patent some work – using a federal grant, I might add – that it might not have been able to patent in the UK. The US rule is that ‘anything man has invented under the sun you should be able to patent’. That’s something we do wish to investigate.”

from http://www.guardian.co.uk/commentisfree/2010/nov/06/google-david-cameron-copyright

Knowing the vehemence of the European anti-software patent lobby, this seems likely to be a controversial course, should the government decide to pursue it. It was also somewhat in contradiction to the themes in David Cameron the Prime Minister’s speech at the same event which talked about widening fair dealing exceptions to copyright law to better mirror those in US law (the document underpinning the PM’s speech also trailed a ‘peer to patent’ system of vigorous crowd-sourced patent application testing specifically for the UK, which might work against the ‘everything under the sun’ approach that Willetts advocated).

Argument number 2: GPL-licensed media player VLC has been converted to run on iOS, the operating system used on Apple’s portable devices the iPod Touch, the iPhone and the iPad with the blessing of the managers of the project. Unfortunately a contributor to the project has taken exception to this and believes that distributing his work under the GPL via Apple’s App Store is an infringement of his copyright. This is an extremely interesting example of why IP management in projects is a sticky, potentially ugly but essential issue. Project managers need to be sure they have the rights necessary to do what they want to do. Discussions of this issue on the VLC mailing list (including one thread started by the Licence Compliance Officer at the Free Software Foundation explaining why they are supporting the complaining developer and which quickly degenerates into abuse) are ongoing, and it is not yet clear if Apple will remove the app from their store in response to the complaint.

Argument 3: Oracle has responded to Google’s response to their complaint over Java on Android. Despite doubts over whether Oracle could make the copyright infringement accusations stick, Oracle have come back strongly with alleged actual code borrowings between Oracle’s Java and Android’s Dalvik virtual machines. The Register has reported that – although Google’s code is based on the Apache Software Foundation project Harmony, the alleged borrowings are not present in the Harmony code base, and so must have found their way into Android through Google’s downstream customisation work. This is good news for Apache, but potentially awful news for Google and the Android ecosystem.

Google responds to Oracle: ‘Unclean Hands’

Published by Rowan Wilson on October 8, 2010 in Legal. 0 Comments

Almost two months after Oracle filed suit against Google over the use of Java technologies in Android, Google has responded – somewhat angrily. The gist of Google’s responses are as follows:

  1. Google has not infringed Oracle’s patents
  2. …which are invalid anyway
  3. …and unenforceable because Oracle have waited too long to enforce them
  4. Also, Google’s Android code can be used in many ways that do not infringe on Oracle’s patents
  5. Also, we believe that Oracle already made these patents public domain
  6. In any case, damages should be limited because any infringement was long time  and Oracle only just told us… oh and because the patents are invalid anyway
  7. Did we mention that Oracle are misusing their patents?
  8. We definitely think that Oracle should pay Google’s attorney fees because Oracle knew they had no case but went ahead anyway
  9. Also, the US government uses this code so take (some of) this up with them
  10. Oracle certainly shouldn’t be able to stop Google distributing Android as other less harsh remedies could sort this whole problem out
  11. …and anyway, Google already has a licence for all this stuff
  12. …or at least Oracle implied Google had a licence by the way they acted
  13. Oracle is not trying to right a wrong here; they are trying to commit a wrong

Reading these lists of defences can often be confusing, or amusing, or both. It’s important to remember that these arguments are allowed to be somewhat contradictory; they are designed to stand individually even if some or all of their compatriots are struck down. Thus saying “I wasn’t there, but if I was I didn’t kill him, but if I did he was threatening me and therefore asking for it” is perfectly normal when defending accusations in court.

In addition to this response Google is responding to the claims of copyright infringement that I found so interesting in the previous post by arguing that Oracle’s pleas are just not specific enough to amount to anything at all. Google is asking that these claims therefore be dismissed entirely. Now, with any luck, Oracle will have to respond with specifics on the copyright infringement issue. This is perhaps the most important aspect of the claim from  the point of view of the open source community. In asking for the claim to be dismissed, Google point out that Oracle’s vagueness on this issue is unaccountable. After all, this is not an accusation leveled at a closed source program, where there might be some justification for not producing specific examples of code copying; here the source is available to all, and Oracle could easily reproduce or cite the sections which it feels are duplicative of their property. Perhaps Oracle will respond with a more general claim that Android infringes on its copyright in specifications; although as I pointed out in my last post, that can be a hard argument to make successfully.

Some of the uncertainty over the specification issue springs from the history of the so-called Java Community Process, of which Google gives its own account in its response. This is an ugly, contentious and long-running story that I have touched on before and which I don’t propose to fully detail here. In essence, despite nominally releasing Java as open source and creating a process whereby other implementations of Java technologies could get accreditation and necessary IP licences, Sun never really made Java technology open for all potential uses. Their keenness to profit from the mobile sector in particular meant that they set up obstacles to the creation of mobile Java implementations that enjoyed all (potentially) necessary IP licences from Sun. The result of this was that Sun’s Java Micro Edition was somewhat protected from competition by the lack of clarity over whether open source versions of Java could be run on mobile devices without infringing on some of Sun’s intellectual property. Google points out that – when they did not own the Sun IP in question – Oracle repeatedly attacked Sun’s position on this issue and called for Sun to create a simple process whereby any Java implementation could be tested and obtain all necessary licences from Sun. However once Oracle itself acquired the Java IP, they went curiously silent on the issue. In some ways Oracle is in an awkward position here (if their copyright claim relates to specifications). Having loudly called for all Java implementations – regardless of whether they are mobile or not – to be licensed by Sun in the past, they would now find themselves relying on the fact that Sun refused to do as they asked.

The 13th point above is – in the response itself – detailed in this way:

13. All of Oracle’s claims are barred because Oracle has come to this Court with unclean hands.

This essentially means that Google believes that Oracle is using the Court system – whose intended purpose is to create greater fairness and justice – to perpetrate an injustice and achieve an unfair outcome. Whether this accusation is based upon Oracle’s u-turn Java openness remains to be seen.

Oracle vs Google: Triple Damage!

Published by Rowan Wilson on August 19, 2010 in Legal. 6 Comments

In Norse mythology it’s predicted that the final days of the world will see a supernatural wolf called Sköll swallow the sun before helping to kill Odin, the mightiest of the Gods. In a move that will surprise no ancient Vikings, Oracle – the gigantic database corporation that up swallowed Sun Microsystems – has made a wide-ranging patent and copyright infringement complaint (pdf) against the mighty Google Inc. that may or may not indicate that the world will soon end.

The complaint concerns the use of Java-related technologies in Google’s Android mobile Linux platform, and the details are ugly indeed. Ever since Sun released Java back in 1995, they (and now new owners of the Java IP Oracle) have been looking for ways to make some money off it. Java was intended to provide a solution to the problem of platform fragmentation – the unfortunate situation that means software developers have to write many differing versions of their code to cater for all the different varieties of computing environment out there (Macs, Windows, Unix etc). Sun’s Java provided a layer of virtualisation, so that in theory you could write your Java code once and have it run anywhere, confident that the virtualisation layer (or ‘virtual machine’) on each system would handle the complexities of translating your program for use on the local hardware.

It didn’t help that the technology grew in ways that Sun had not really predicted – seeing far more adoption on the server than in the client area at which it was initially targeted. When mobile phones and set top boxes began to become more powerful and able to run consumer software, Sun launched a ‘Micro Edition’ (ME) of Java that was intended to coalesce this massively fragmented market. This ought to have given Sun a strong, commercialisable position as gatekeeper between software developers and a wide spectrum of hardware platforms, but in the event the technology was not equal to the vision and developers still needed to tweak Java ME software to run efficiently on each platform, causing much woe and despondency. Nevertheless, the mobile market remained Sun’s core focus in the struggle to wring money out of Java. At the same time, Sun was positioning itself as an open source-friendly company, and was therefore receiving quite a lot of pressure from the open source community to put its money where its mouth was and release Java under an open source licence. In 2006, when Sun finally did release Java as free software, the strategy to monetise mobile was still very clear in their licensing choices.

The standard edition of Java – designed to run on desktop computers and servers – was released under the GNU GPL with the so-called ‘Classpath Exception’. This was a licence created by the Free Software Foundation’s GNU project to cover their own free software implementation of the core Java-compatible class libraries (essentially toolkits of functionality for building complex applications). The exception meant that you could use the GPL-licensed libraries to build your applications without having the copyleft requirements of the GPL transmit to your own code. However for the ‘Micro’ edition of Java, Sun used a dual licensing model, leaving out the exception from the GPL version and selling commercial licences for device manufacturers and developers who wanted to write mobile software which was not compelled to be GPL.

Thus, when Google decided it wished to use Java as the development language for software on their eagerly anticipated mobile Linux platform Android, one could argue that it should – finally – have been a huge payday for Sun. However it was not to be. For whatever reason, Google did not want to go down the road of licensing and mandating the use of Java ME. Instead, they took an open source implementation of Java called Apache Harmony and made some variations to it of their own. First they created their own virtual machine called Dalvik, which ran a different kind of code to a standard Java virtual machine (a tool in the Android development kit converts standard Java ‘byte-code’ to the new Android format). They also added many new libraries to support more modern functionality such as Bluetooth and the 3D graphical acceleration technology OpenGL. Everyone – except Sun – was happy. Developers did not need to buy commercial Java ME licences from Sun but could still use the Java skills they had developed over the last decade. Google did not have to rely on another company to mediate their relationship with developers and handset manufacturers. Sun had lost out again. Perhaps their previous highly-publicised love affair with open source meant that they could not easily start suing a competitor over a piece of open source software? Finally in early 2010 a financially embarrassed Sun was acquired by Oracle.

Oracle itself has some open source credentials – they run a proprietary/open dual licensing model for the product Berkeley DB. However the majority of their business is unashamedly closed source and therefore ever since they acquired the Java IP with Sun there has been much speculation that they would come after Google over Android and Dalvik. The complaint that has finally emerged is a wrathful document indeed, accusing Google of wilfully infringing on Sun/Oracle’s patents and copyright and seeking the seizure of all infringing devices, code and even advertising materials. Due to what they see as the egregious cheekiness of the infringement, Oracle want punitive triple damages.

What makes this case interesting – apart from the enormity of the two combatants – is the range of the counts. Along with seven fairly generic technology patents dealing with program compilation and execution, Oracle are also alleging copyright infringement. This would normally imply – in the case of software – that Oracle believes that Google (and quite possibly Apache Harmony) have incorporated verbatim sections of their code in their own products. Here, though, it’s hard to see how that could be the case. As an open source project Harmony’s source has been available for the world to see for many years, and one might have expected any literal code inclusion to have been noticed and acted upon a long time ago. As for the parts added by Google, it seems extremely unlikely that a company with Google’s resources would risk any kind of ‘code contamination’. Dalvik has been widely reported to have used ‘clean room’ reimplementation in its creation – meaning that no-one with any experience of (in this case) Java’s internals would be allowed to contribute any code to the project. The only point of connection between the original and the new code in a clean room reimplementation is the specification – the detailed but high-level description of how the software should operate. Could Oracle be suing over the use of the specification?

Oracle’s complaint says this:

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.

…so specifications are explicitly listed as a variety of copyright work Oracle considers itself to hold in Java. This is of course true – specifications are copyright works as they are original and complex. The documents themselves are clearly ownable and their owners rightly get peeved if people copy and distribute them without permission. Here’s another quote from the Java Specification Participation Agreement – the agreement which allows third parties to get involved with defining and implementing new parts of Java:

For any Specification produced under a new JSR, the Spec Lead for such JSR shall offer to grant a perpetual, non-exclusive, worldwide, fully paid-up, royalty free, irrevocable license under its licensable copyrights in and patent claims covering the Specification (including rights licensed to the Spec Lead pursuant to Section 4.A and 4.C) to anyone who wishes to create and/or distribute an Independent Implementation of the Spec.

(JSRs are Java Specification Requests – basically descriptions of new features). Taking the language of the complaint along with the language of the participation agreement, it seems quite possible that Oracle are going to argue that any implementation of their specification is a derivative work of that specification and therefore needs a licence from them. This kind of copyright action – essentially claiming a high-level copyright in the design of the technology – is controversial and difficult to win. The more abstract the entity for which you are trying to claim copyright ownership, the harder it is to show indisputable infringement. Verbatim code copying is fairly easy to spot and demonstrate; the duplication of structures and interfaces is harder to demonstrate and is always open to arguments that there is no substantial relationship between the design and the implementation.

Of course, it may be that Oracle does have evidence of more concrete low-level copyright infringement, despite my personal instinct that that is unlikely. However if they will be arguing on the difficult basis of ’specification infringement’ I have to wonder why. Is it a plan to bolster a set of patents they are unsure about? Somewhat selfishly part of me hopes that the case will play out publicly and not be settled behind closed doors, if only to clarify this controversial area of copyright.

My pacemaker will not be tweeting just yet

Published by Rowan Wilson on July 23, 2010 in Legal. 0 Comments

June 2007:the Free Software Foundation (FSF) publish their third ‘discussion draft’ of their proposed new licence, the GPL version 3. Alongside this new draft is published a so-called ‘rationale’, which helpfully explain the changes made since the last draft. Originally the FSF had planned to require all forms of encrypted GPL software to be accompanied by appropriate decryption keys, to prevent device manufacturers from putting GPL software in their products but making it impossible to end users to modify it. Many people had complained about this however, saying that it undermined a lot of legitimate uses of cryptography on software code. The FSF responded by limiting the requirement only to ‘User Products’ in its next draft, and went to a lot of trouble to define this subset of GPL-containing items. In the rationale document(pdf), they commented:

We considered including medical devices for implantation in the human body in the User Product definition. We decided against this, however, because there may be legitimate health and safety regulations concerning inexpert and reckless modifications of medical devices. In any case, it will probably be necessary to convince medical device regulators to allow user-modifiable implantable medical devices. We plan to begin a campaign to address this issue.
Some commentators made fun of this aspiration. Ed Burnette of ZDNet commented:
This paragraph demonstrates both the pragmatism that is creeping into the FSF (concerns for ‘reckless modifications’) and the ‘tin-foil hat’ eccentricity that has always been a part of Stallman’s free software movement. If nothing else, the activities of the FSF and its colorful leader will continue to give us plenty to talk about in the years to come.
Well, years passed and there was little public evidence of this campaign… until this week. On Wednesday the Software Freedom Law Center (SFLC) published research which argues that the US Food and Drug Administration (FDA) should require all manufacturers of Implantable Medical Devices (IMDs) to publish the source to the code in their products. The paper cites many chilling examples of software reliability and security problems with IMDs:
While there has yet to be a documented incident in which the source code of a medical device was breached for malicious purposes, a 2008-study led by software engineer and security expert Kevin Fu proved that it is possible to interfere with an ICD (implantable cardioverter defibrillator) that had passed the FDA’s premarket approval process and been implanted in hundreds of thousands of patients. A team of researchers from three universities partially reverse-engineered the communications protocol of a 2003-model ICD and launched several radio-based software attacks from a short distance. Using low-cost, commercially available equipment to bypass the device programmer, the researchers were able to extract private data stored inside the ICD such as patients’ vital signs and medical history; “eavesdrop” on wireless communication with the device programmer; reprogram the therapy settings that detect and treat abnormal heart rhythms; and keep the device in “awake” mode in order to deplete its battery, which can only be replaced with invasive surgery.
In one experimental attack conducted in the study, researchers were able to disable the ICD to prevent it from delivering a life-saving shock and then direct the same device to deliver multiple shocks averaging 137.7 volts that would induce ventricular fibrillation in a patient. The study concluded that there were no “technological mechanisms in place to ensure that programmers can only be operated by authorized personnel.” Fu’s findings show that almost anyone could use store-bought tools to build a device that could “be easily miniaturized to the size of an iPhone and carried through a crowded mall or subway, sending its heart-attack command to random victims.”
Chilling stuff indeed. The paper goes on to argue that FOSS is inherently more secure than closed source, and that source code for IMDs ought to be available for all to see both for greater security and to avoid problems if a device manufacturer goes bankrupt and disappears.
This is not quite the campaign promised back in 2007, however. Notable by its absence is a call for IMDs to actually be user-modifiable:

Specifically, we call on the FDA to require manufacturers of life-critical IMDs to publish the source code of medical device software so the public and regulators can examine and evaluate it.

The paper uses the argument that FOSS is more secure to underpin a request for publication, not full FOSS-licensing. Presumably any errors detected in the code would have to be notified to the manufacturer for actual repair. This is, of course, not particularly surprising. Calling for the FDA to allow individuals to flash their pacemakers to tweet their heart rate would probably attract the same kind of ridicule that Ed Burnette engaged in three years ago. While some activists – including possibly Stallman himself – may regret this reticence, it is probably necessary in order for the request to be taken seriously.