Combining freedoms and copyleft in the Gnu GPL license (invented by Richard Stallman) was the cornerstone of free software. This is now questioned due to the proliferation of incompatible copyleft licenses.

After counting 1,800 free software licenses used in hundreds of thousands of projects, the Black Duck company patented (Patent US 7,552,093 B2) the technology for controlling the use of open source licensing in a multi-source development process (meaning combined works, elaborated from multiple free components under different licenses).

No need to say that patenting proprietary technology to solve copyleft licenses incompatibility may not be seen by everyone as a major achievement!

Lamenting on license proliferation or blaming new license authors – who all call upon the best reasons of the world, looks useless. It would certainly be reasonable, as recommended by Bruce Perens, to deal with only four permissive and copyleft licenses, but this is wishful thinking. New licenses are presented every week by FLOSS authors and communities, and no benevolent dictator will limit human innovation regarding licensing.

The heart of the problem does not lie in the number of licenses, but in their incompatibility. I do not think that license proliferation is a failure of the FLOSS movement, it is rather the entire contrary: a testimony of the attractiveness of FLOSS models. In reality, license proliferation illustrates the failure of a certain model of strong copyleft, as it was initiated by the GPL in the 80’ and – unfortunately - reproduced by nearly all subsequent copyleft licenses. Once necessary and successful, this model looks not adapted anymore because it was copied and - seeing the Black Duck patent - one may question (like Ernest Park has done) if the way copyleft is applied does not generate today more jails than freedom.

According to my first study for the European Commission, the Gnu GPL v2 was used in 85% of the FLOSS projects in 2001. With a copyleft that was – maliciously – said “viral” by some, meaning that compatibility is always “upstream” (to itself) and never “downstream” (to other licenses), the adoption rate of the GPL should have been universal in 2010, confirming analysts’ assumption that “it is good for the community if people use a single copyleft license [1]”. However, the exact reverse happened: the GPLv2 (reducing) is still used in 50% of projects, the new GPLv3 reaches little more than 5% and other licenses are proliferating.

The fact a dozen of licenses are used by 90% of the FLOSS projects does not help very much, as the implementation of free solutions (which are often combined works) is done through integrating many components. It is enough to find only one incompatible license to compromise the distribution of these solutions.

The current situation is damaging for other reasons: it creates endless discussions on what could be considered as integration in combined works (dynamic or static linking) and it feeds disputes. To preserve their communities from schisms, gurus and acolytes urge followers not to use any other copyleft licenses, whatever their specific merits or advantages could be. It is time to admit that the strategy of keeping a “captive asset” of license users was not successful for avoiding proliferation, and that it is not the most appropriate way to reinforce the freedom, collaboration spirit and consistency within the fragmented FLOSS world.

In Europe, the recent - OSI approved and copyleft - European Union Public License (EUPL) meets some initial successes due to its compliance with Member States’ law and because it has equal value in the 22 languages of the Union. It has been selected by the German Federal Agency for Information Technologies, it is the license of choice in schemes published by the Dutch NOiV (see on the www.OSOR.eu site an English version of this scheme, translated by a member of the Swiss administration), a dedicated EUPL site was created in Italy, etc. In Spain, the Ministry of Industry, Tourism and Commerce (where the public agency Red.es is located, in charge of information technology) provides the following in call for tenders (software specifications):

“In case the contractor integrates in the development that is the object of the contract with modules or elements owned by third parties, he must first obtain from the legal owners the licenses and rights necessary to transfer the ownership of the development to , which will submit it, including the elements that are performed under the contract (such as fonts, dll, scripts, etc..) to the public license EUPL. In any case the total and final result of the development and the overall project will be subject to a license EUPL.”

Applying such provisions excludes strong copyleft components from the delivered combined work: all original developments are allowed; all “permissive” components are allowed (BSD, MIT, etc.); all “weak copyleft” components are allowed (i.e. LGPL), but no Gnu GPLv2 (or V3) components (except if the copyright owner is entitled to dual license the component under LGPL-like terms, for the purpose of addressing the contractual specifications).

The EUPL itself has an innovative approach to solve copyleft licenses conflicts: it publishes a downstream compatibility list (to other licenses). It is allowed to integrate EUPL components in a combined work that will be distributed under a compatible license. The concept is not new, as the FSF applied it with the LGPL a long time ago. The LGPL (now LGPLv3) is convenient for software libraries aimed to produce combined or derivative works: if the library is propagated on its own, it must be under the provision of its original license (LGPL), but if the library components are part of a derivative work, this work can be licensed under another license, while the original library remains LGPL. The EUPL compatibility is exactly the same, but its copyleft effect is stronger than in the LGPL (because compatibility is restricted to a limited and published list of other copyleft F/OSS licenses). Therefore it is not a weak but – say, a “tolerant copyleft”.

Such flexibility removes incompatibility barriers and restores developers’ freedom, while keeping it in the limits of the desired copyleft effect.

While the EUPL solution may be considered as a conceptual progress, its tangible impact will stay very limited as long other copyleft licenses will not give some reciprocity: the quantity of available EUPL-ed material is quite small today, compared to the mass of components that are already available under the GPL terms. Extending the list of EUPL compatible licenses (i.e. by adding the still missing GPLv3) will not change the issue resulting from the Spanish specifications, where the government requires the facility to distribute the received combined work under the single license of its choice (the EUPL in this case).

Solving problems related to the proliferation of copyleft licenses requires setting up interoperability provisions between these main licenses. It will create, and focus attention, on a kind of “circle of trust” where the original copyleft licensing condition of a software will never be changed, but where – just to take an example – a GPL component could be part of a combined work that the recipient (let’s say the French or the Spanish government) could distribute as a whole under the provision of the copyleft license of its choice (i.e. CeCILL or the EUPL) provide these licenses are allowed in the compatibility list.

The Gnu GPLv3 includes (in its section 13) the exact provision corresponding to the above need, but it is directed to the AGPLv3 only. The intellectual effort to extend this provision in direction of a small list of interoperable licenses seems easy to deliver. The reciprocal condition must be added: in the example above, the combined work could be also (as the need may be) distributed under the provisions of the GPLv3.

This could be a way out to the deadlock where we are, due to the proliferation of incompatible licenses.

Looking for alternative? Pay a Black Duck patent license!

Patrice-Emmanuel Schmitz – www.OSOR.eu

[1] R.T. Nimmer, Legal issues in Open Source and Free Software distribution, The Law of Computer technology, Ch. 11 (1997, 2005 Supp.) (“Two different copyleft licenses are usually “incompatible”, which means it is illegal to merge the code using one license with the code using the other license; therefore it is good for the community if people use a single copyleft license (GPL)”).

The International Free and Open Source Software Law Review (IFOSS L. Rev.) is a collaborative legal publication aiming to increase knowledge and understanding among lawyers about Free and Open Source Software issues. Topics covered include copyright, licence implementation, licence interpretation, software patents, open standards, case law and statutory changes.

In the first issue there are discussions of the Jacobsen vs Katzer case in the US and its repercussions for both in the US and the UK, the peer-to-patent programme and a proposal to help organisations procuring  free and open source software understand and manage their risks. It’s good if slightly technical stuff, and I highly recommend it.

If, as a consequence of a court judgment or allegation of patent infringement or

for any other reason (not limited to patent issues), conditions are imposed on

you (whether by court order, agreement or otherwise)that contradict the

conditions of this License, they do not excuse you from the conditions of this

License. If you cannot distribute so as to satisfy simultaneously your obligations

under this License and any other pertinent obligations, then as a consequence you

may not distribute the Library at all.  For example, if a patent license would

not permit royalty-free redistribution of the Library by all those who receive copies

directly or indirectly through you, then the only way you could satisfy both it

and this License would be to refrain entirely from distribution of the Library.

This clause is generally understood to mean that paying for patent licences to distribute LGPLv2.1-licensed code is impossible; once you pay for the licence you lose your right to distribute, so it’s never worth doing (and this in turn acts as a deterrent to patent owners looking to get per-copy royalties on LGPLv2.1- and GPLv2-licensed software - even if you win the case against the distributor, you kill the product and will get no royalties going forward). Nevertheless, Google’s lawyers seemed to have found a way through waters which had previously been thought unnavigable. As the argument on the thread continued, it emerged that Google’s approach had been to seek a patent licence for Chrome itself, not the ffmpeg library that was actually doing the video decoding. The LGPLv2.1 is designed to allow code it covers to co-exist in an uneasy peace with code covered by any other kind of licence, including patent licences. In this was free software libraries could be used with proprietary software in a way that would be impossible if they were covered by the full GPLv2. Google argued that as long as they never sought patent rights to use ffmpeg, no-one could accuse them of not passing on those rights to others in a way that ffmpeg’s licence mandated. All their permissions to use patents rested with Chrome itself - however it chose to do the decoding. 

 Now this is a sly move, and not one that has been attempted in as high-profile a piece of software as Chrome up to now. Will Google get away with it? Well that question really reduces to the question: Who might try to stop them? In this case Google Chrome is relying on licences from the MPEG-LA for the patents used to decode MPEG4 (and possibly theora if they want to rule out any future challenges from MPEG-LA on that score) and a software licence from the ffmpeg project. The likelihood is that Google have paid well for complete coverage from the MPEG-LA, and so a challenge from that quarter seems unlikely. What about the ffmpeg project?  Well they clearly explain that they have no specific knowledge of any patents infringed by distributing ffmpeg. Of course, everyone is aware that the project very likely infringes on many patents in the H.264 patent pool at the very least, but time and experience has taught programmers operating in patent-rich problem domains to never read the relevant patents. It only increases the likelihood that you will infringe upon them and increase the damages if it can be shown that you knowingly infringed. What this means for ffmpeg is that it would be very difficult for them to argue that Google is not in compliance with the LGPLv2.1 for ffmpeg because they have licensed some patents ostensibly for use in Chrome. To do so they would have to explain exactly which of the patents licensed were in reality embodied in ffmpeg, and would therefore trigger Google’s responsibilities inder the LGPLv2.1. This could be seen as an unwise move for ffmpeg. With neither the MPEG-LA or ffmpeg likely to question Google’s actions, it seems likely they will get no substantial challenge to their actions. 

7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues),conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you,  the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.

What this meant for Tomtom was that if they settled with Microsoft by - say - agreeing to pay them 1p for each copy of GNU/Linux they distributed, then they would in fact have invalidated their licence to distribute GNU/Linux at all. The GPL v2 insists that either the code it covers goes out with no additional encumbrances or it doe not go out at all. Now Microsoft is very aware of this provision. Their cross-licensing deal with Novell - detailed in an OSS Watch blog post here - was structured precisely so as to avoid this consequence. Many in the free and open source community feared that Tomtom would strike a similar deal with Microsoft, and fans of the lastest version of the GPL, v3, announced Microsoft’s actions in this case should act as a ‘wake-up call’ for developers to begin using the licence, as it includes changes designed to make such deals apply to the entire community if they exist at all. In the event, it would seem from the information we have that Tomtom has avoided emulating Novell, and has instead agreed to remove the FAT components from the version GNU/Linux they distribute on their devices within two years. This strongly indicates that Tomtom have accepted no licence from Microsoft relating to GNU/Linux itself, and Microsoft have agreed to just give them breathing space to remove allegedly infringing components, rather than insisting they take a licence.  So - a happy ending for all concerned? Not really. Microsoft must be pleased, as they have managed to give the appearance of winning a battle in which they were accusing GNU/Linux of infringing on their patents while not actually having to suffer examination of the validity of their patents in court. The free and open source software community is left wondering whether the FAT patents could be used against other distributors of GNU/Linux. Jim Zemlin, Executive Director of the Linux Foundation, seemed to be calling on developers to cut FAT implementations out of their software altogether. A couple of days ago, OIN announced the following:

…the patents used in the recent TomTom patent action have been posted by OIN for review and submission of prior art by the Linux community. Submissions may be made by visiting http://www.post-issue.org, clicking on the appropriate patent and selecting “Submit Prior Art”.

The Peer to Patent web site that OIN cite in that link is an initiative designed to allow the technology community at large to pool their collective expertise and thereby perhaps invalidate patents that ought not to have been granted. One way to invalidate a patent is to show that it was not innovative at the time the patent was applied for, that there was in the jargon ‘prior art’. The Peer to Patent site acts as a clearing-house for evidence of prior art on specific patents. In fact one of the FAT patents in question, 5,597,517,  has already been re-examined, provisionally invalidated, amended and then declared valid again after the Public Patent Foundation  or ‘PubPat’ (tagline: ‘representing the public’s interest in the patent system’) asked for the US Patent Office to take another look back in 2004. It will be interesting to see how far this pillorying of the Microsoft’s FAT patents will go towards their invalidation, given that this is their second re-examination.So another Microsoft patent case goes by and we are still no closer to knowing how justified Microsoft’s patent threats against Linux really are. Tomtom clearly found the effort involved in engineering out the FAT patents a worthwhile expense, but only tells us that it was likely to work out cheaper than the lawyer’s fees, and that Tomtom understandably had no interest in acting as a vanguard for the community on the issue. Perhaps the most reassuring thing for the community is that - so far - Microsoft has only claimed ownership of technologies which can be engineered out of GNU/Linux without breaking it.

1. too many different licenses makes it difficult for licensors to choose
   Some people use “license proliferation” to mean that there are just too many licenses and that someone needs to take steps to reduce the number. While this would be great, the OSI cannot make anyone use or not use a particular license. All we can do is educate and urge people to use a smaller subset of licenses. This comment generally came from individuals and small companies.
2. some licenses do not play well together
   Some people use “license proliferation” to refer to the fact that some open source licenses do not inter-operate well with other open source licenses. While we can urge people not to mix non-mixable licenses, we cannot keep people from doing so. This comment generally came from larger companies.
3. too many licenses makes it difficult to understand what you are agreeing to in a multi-license distribution
   This is related to the previous comment, but is somewhat different since it doesn’t complain about how the licenses interact, just that there are too many different individual licenses covering certain distributions and that it takes a lot of time to read and understand them all. This comment usually came from larger companies.

The OSI has, since the publication of this report, grouped licences as either “popular and widely used”, “special purpose”, “redundant”, “non-reusable”, “superseded” or “other”. OSS Watch encourage everyone to use one of the “popular and widely used” licences as these cover the major needs of most community and business models (the special purpose licences do have their place, but they are minority licences).

Today it was announced that the number of licences in the recommended group has been reduced from nine to eight since the Eclipse Foundation, along with IBM, have taken the steps necessary to supersede the Common Public License 1.0 (CPL) with the Eclipse Public License 1.0  (EPL).

Hurrah!!!

“Yes, well, three of the eight patents in this dispute read on the Linux kernel as implemented by TomTom. The other five relate to car navigation proprietary software used by TomTom.”                   

Words like these bring back terrible memories of Microsoft’s - and particularly Microsoft CEO Steve Ballmer’s -  past statements in this area. Back in 2004  Ballmer told the Asian Government Leaders Forum in Singapore that Linux infringed on “over 228″ software patents and that

“somebody will come and look for money owing to the rights for that intellectual property…”              

Journalists seeking clarification of Ballmer’s comments at the time from Microsoft’s PR department were told that Ballmer was referring to a 2004 study by Dan Ravicher  that identified 283 potential software patent infringements within Linux. Ravicher responded that Ballmer was misreporting the essence of the report, which was that any operating system would necessarily infringe the 283 patents in question (Ravicher did not list them) and that therefore Linux was in no greater danger of infringement than any other operating system. The report was commissioned and published by a firm called Open Source Risk Management, who coincidentally were just about to start selling insurance for users of Linux who feared being hit with unexpected patent fees. Ravicher is now Legal Director of the Software Freedom Law Center, a law firm that specialises in helping authors of FOSS.

Of course this was not the only piece of horse-spooking that Microsoft has engaged in over the years. In May 2007 senior Microsoft lawyers Brad Smith and Horacio Gutierrez (sound familiar?) told Fortune Magazine that Linux infringes on 235 Microsoft-owned software patents and that:

“This is not a case of some accidental, unknowing infringement… There is an overwhelming number of patents being infringed.”       

Shortly after this Microsoft announced a deal with Novell that would protect customers using Novell’s SUSE Linux distribution from patent action by Microsoft - the obvious implication being that customers of all other Linux distributions must therefore be at risk (OSS Watch covered this issue and the Free Software Foundation’s reaction in our description of the GNU GPL v3 here).

So is the current climate of fear really warranted? Probably not. For a start, Gutierrez himself is at pains to say that this is not the beginning of the earth-shattering IP showdown that Linux users have been fearing for years:

I should say, Microsoft respects and appreciates the important role that open-source software plays in our industry, and we respect and appreciate the passion and the great contribution that open-source developers make in our industry. That appreciation and respect is not inconsistent with our respect for intellectual-property rights. Partnership with all technology companies, including those that adopt a mixed-source model, must be built on mutual respect for IP rights — rights that we all rely on for driving innovation and opportunity.Now, this case is against TomTom, and it involves infringement of Microsoft patents by TomTom devices. Each case is different, and this one is specifically about the use of software by TomTom in its devices.        

(from here.) In the past it has clearly been a strategic aim of Microsoft’s to cast doubt on the legality of Linux. The Microsoft quotes mentioned above were without doubt intended to make potential Linux users think twice about where they should spend their money. With the Tomtom case - in contrast - Microsoft seems to be at pains to go further than it needs to in calming Linux users about the potential for broad litigation against their chosen operating system. Just note the contrast between the Gutierrez of 2007’s Fortune article and the Gutierrez of 2009’s Tomtom-related interview. There seems to be a genuine movement towards playing down the implied threats of the past.

 Why has this happened? It’s almost impossible for an outsider to say.It is clear that Microsoft’s former strategy of implying that Linux was about to disappear under storm of patent infringement suits did not significantly affect Linux uptake. The Linux community adapted through initiatives like the Open Invention Network - a patent-holding organisation supported by Sony, Novell, Red Hat, IBM, NEC and Philips that licenses its IP at no cost to anyone who agrees not to assert their own patent rights against Linux. Of course, if you choose to assert your rights against Linux, the OIN will closely examine your products to make sure that none of their patents are embodied in them. In practice it’s this kind of ’sue-me-and-i’ll-sue-you’ standoffs that prevent all-out patent war in the IT sector, and the number of patent-holding corporations with a stake in Linux now makes it potentially as risky to sue as any other single large technology player - maybe riskier given the added liability of blogosphere backlash and community hatred for any moves against FOSS. 

When OSS Watch spoke to OIN’s then-CEO Jerry Rosenthal in 2007 he believed that they would probably never have to actually sue a big player like Microsoft. So while the Microsoft-Tomtom case probably does not herald the the final Microsoft campaign against FOSS, it will be interesting to see whether OIN sees it as sufficient reason to look into enforcing their own patents against Microsoft. Tomtom must be hoping that they do. 

“We like competition, as long as they don’t rip off our IP… I don’t want to talk about any particular company. However, we will not stand for having our IP ripped off. And we will use whatever weapons we have at our disposal.”

(from here)

Palm’s Pre had been receiving extremely positive press attention after being shown off at the Consumer Electronics Show 2009 in early January. Like the iPhone, the Pre features a large touchscreen interface that responds to taps and gestures from one or more fingers. Many commentators remarked on how like the iPhone Palm’s new product was, hence the analyst’s question to Cook.

Now both the Palm Pre and the Apple iPhone are driven largely by closed source software, so how does this all relate to open source? Well up until now the most prominent ‘feature competitor’ to Apple’s iPhone was the G1, a touchscreen phone developed for network provider T-Mobile by Taiwan’s HTC (an acronym, charmingly, for High Tech Corporation). The G1 was notable not only because it was the first iPhone-a-like to market, but also because it was the first phone to run Google’s Linux-based open source smartphone operating system Android. The G1 also sports a touchscreen of almost identical specification to the screen used in the iPhone, including the ability to detect and track contact from more than one finger simultaneously. However Android itself is not capable of tracking multiple simultaneous touches, and so for example relies on visual ‘+’ and ‘-’ buttons to enable zooming into an image or web page, as opposed to the iPhone’s intuitive ‘pinch’ and ‘de-pinch’ gestures.

Now as Android is open source, it did not take long for enthusiastic users to track down why the operating system did not make information about the location of additional simultaneous touches available for applications to use, thus enabling sexy iPhone like gestures. Apparently the relevant code in the touchscreen driver (software which acts as the intermediary between the touchscreen hardware and the phone’s main processor) had been purposefully ‘commented out’ or rendered inoperative. While many in the Android community remain hopeful that their G1’s - or possibly some successor Android phone - will one day feature multi-touch gestures, it seems likely that Google has deliberately suppressed this functionality for fear that Apple lawyers might demand royalties or cessation of distribution over infringement of their multitouch patent.

Surely, you might think, Google are a big enough corporation to be able to afford to license Apple’s patent? They are indeed. However, licensing a patent for incorporation into a piece of open source software means opening oneself up to entirely unquantifiable costs. The Apache Software License 2.0 under which Google’s portion of the Android platform is distributed, has this to say about any patents that might be embodied in the software it covers:

“3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted…“

Google sees Android as an open platform on which to deliver their services, and therefore wants as many handset manufacturers as possible to build devices that run it. In order to license the multitouch patent from Apple for use in Android, Google would have to commit to paying the patent licensing fees for an unknowable number of potential devices from manufacturers all over the globe. Even if Apple were prepared to license their patent on such a basis, it would be an immensely risky financial commitment for Google. For the moment, it seems that T-Mobile, HTC and Google are happy to wait for someone else to test Apple’s resolve and the robustness of their patents.

Of course, individual device manufacturers are at liberty to license patents just for use on their phones, and this may indeed happen with Android devices in the future. The problem with this approach is that, while it gives a valuable selling point to the manufacturer in question, it results in a fragmented platform, with application developers having to decide whether to adapt their programs to take advantage of manufacturer x’s special multouch Android phone, or just stick with implementing functionality that is present on the majority of standard Android phones. In the same way, Palm may choose to license Apple’s patent for the Pre, or they may take the other popular approach to patent disputes between high-tech companies - threaten back. Palm has a long history in mobile computing and it is quite possible that, if motivated to look, they could find patents in their own portfolio that are implemented in Apple’s devices, and thereby force some kind of mutual accommodation.

None of this will help free and open source implementations of multi-touch patents, however. For these to truly flourish, it will be necessary for the patent (and many others that exist) to be invalidated. This could happen if it is re-examined and found to be an obvious progression of previous technologies, or perhaps if it is shown that the idea was published before the patent was applied for. It may even happen that the recent infamous US Federal Circuit decision in re Bilski (as discussed in this blog previously) will make technology firms less willing to litigate expensively in support of computer-implemented method patents such as this one. Either way, it seems it will be a while before our open source programs will understand what we mean when we pinch them.

A couple of weeks ago I had the pleasure of hearing Shane Coughlan speak about - among other things - the patentability of software in Europe. Mr Coughlan is Freedom Task Force Coordinator for the European wing of the Free Software Foundation. In response to a question about software patents, Coughlan stated flatly that they do not exist in Europe. When the audience seemed a little confused by this, he elaborated by saying that although the EPO had granted many applications for software, there was no statutory basis for their existence or enforceability - given the exclusion of software from patentability in the European Patent Convention. The audience were clearly a little confused by this - many came from large software firms with holdings of European patents on software inventions. A member of the audience asked about Coughlan’s opinion on the patentability of software in the UK. The questioner turned out to be David Wood of Symbian - a mobile operating system company based in the UK and now wholly owned by Nokia. It was Symbian who had brought the case we are discussing here, after the UK IPO had turned down a software patent application of theirs for a layer of indirection in library function lookups. Recognising a Symbian representative, Coughlan acknowledged that - yes - the UK might be considered separately as Wood’s own company had managed to get the UK courts to invalidate the rejection of their patent. Coughlan also pointed out that - as a Common Law system - UK legislation is effectively ‘updated’ by court decisions on its meaning and application. In the rest of Europe, Coughlan pointed out, a Civil Law system predominates, and prior court decisions are generally not taken to form part of the body of applicable law. Thus while arguably (and Coughlan did argue it) the activities of the EPO and European courts had no effect whatsoever on the fundamental unpatentability of software, actions like Symbian’s in the UK had real effects on the UK’s legislative approach to patentability.

Now that Symbian have conclusively won their case (and leave to appeal to the House of Lords has been denied) the resulting changes must be examined. The judgement examines previous rulings on software patentability, both at the European and UK level, and recognises the essential impossibility of reconciling all views. Once again the issue of what a ‘technical effect’ is becomes central, an issue we have discussed before on this blog. In practice no-one quite knows what a ‘technical effect’ is - all that is certain is that without one a piece of software is just a piece of software and thus cannot be patented due to the statutory exclusion in the European Patent Convention. In this case, the Court of Appeal has decided that the software in question has a

knock-on effect of the computer working better

and that this ‘technical effect’ is all that is required for the software to be more than mere software and therefore patentable. This is essentially the argument advanced by Symbian’s lawyers - that the functioning of a computer in itself can be seen as a technical problem, and that therefore software which makes a computer ‘work… better’ is software which has an additional ‘technical effect’ . You might ask what software would not qualify as patentable under this scheme, and you would have a good point. The judgement points out that software which embodies other kinds of unpatentable inventions could still not be patented:

the program in this case does not embody any of the items specifically excluded by the other categories in art 52; thus, it is not a method of doing business…  or a mathematical method…  or a method for performing mental acts…

So - to summarise briefly - the new element in this judgement is an extremely broad definition of what a technical effect can be, and thus a radical widening of range of patentable software. Provided that your software does not embody anything that is otherwise disqualified from patentability, you can patent it in the UK (subject to all the other normal requirements that it is novel, involves an inventive step and has an industrial application).

The California court had refused to grant an injunction on the basis that the Artistic License (under which JMRI is distributed) was in their view a complete copyright licence, permitting the licensee to exercise all rights usually reserved to the copyright owner. While the court recognised that the Artistic License included some statements about what a licensee must do in order to obtain these rights (things like keeping copyright statements intact),  it characterised these as essentially contractual responsibilities, promises (or ‘covenants’ ) made by the licensee in order to obtain a complete copyright licence. As such, the California district court found, Jacobsen might have a claim in contract law, but could not argue that his copyright had been infringed upon.

This decision was an extremely unpleasant shock for the public licensing community at large. If applied as a general principle across all public licences such as Creative Commons, open source and free software varieties, it would have catastrophic effects, at least in the US. “Why?” you might ask “Surely as long as you can take legal action in some form then the licensed materials are still protected?” There are a couple of answers to that. Firstly, suing for breach of contract is more complex and expensive than seeking injunction for infringement of copyright. Contract law varies alarmingly between countries, while copyright law is fairly standard thanks to international treaties like the Berne Convention. Secondly, the normal remedy granted for breach of contract is financial damages, generally calculated according to the economic loss suffered by the plaintiff. In the case of publicly licensed software or content, it could be hard to make an argument for significant damages, and as a result their stipulations may become widely ignored.

Jacobsen appealed this decision to the Federal Circuit. A posse of public-licensing superstars (Wikimedia, Creative Commons, the Linux Foundation, the Perl Foundation, the Open Source Initiative, the Software Freedom Law Center) submitted a joint Amicus brief (pdf) to the appeal court, which makes interesting reading. Their argument was that the district court had made a mistake when they characterised the Artistic License as a complete copyright licence with contractual riders. Instead, the super-posse argued, it was a limited copyright licence, granting some rights under copyright under certain limited circumstances (such as the licensee behaving themselves and sticking to the conditions). They also argued that the district court had failed to understand the precedents that they cited (including a case in which American Monty Python star Terry Gilliam had succeeded in stopping US television company ABC editing old Python shows in ways that their licence from the BBC did not allow). The amicus brief is also noteworthy for its continual stressing of the innovatory power of public licensing, its ability to facilitate contribution from anyone and assessment by all. This could be read as a counter argument to the oft-quoted dubious accusations that public licensing is in fact non-innovatory, devalues the effort needed to create copyright material and encourages plagiarism.

The appeal court’s decision (pdf) agreed with Jacobsen (and the super-posse). Rather than being a complete copyright licence with accompanying covenants, the appellate court ruled, Artistic Licence was a grant of certain rights under copyright subject to certain conditions. If you did not abide by the conditions, you didn’t get the grant. The decision also praised the principle of public licensing and rubbishes claims that public licensors suffered no economic loss if licensees broke their imposed conditions:

Open source licensing has become a widely used method of creative collaboration that serves to advance the arts and sciences in a manner and at a pace that few could have imagined just a few decades ago. For example, the Massachusetts Institute of Technology (MIT) uses a Creative Commons public license for an OpenCourseWare project that licenses all 1800 MIT courses. Other public licenses support the GNU/Linux operating system, the Perl programming language, the Apache web server programs, the Firefox web browser, and a collaborative web-based encyclopedia called Wikipedia. Creative Commons notes that, by some estimates, there are close to 100,000,000 works licensed under various Creative Commons licenses. The Wikimedia Foundation, another of the amici curiae, estimates that the Wikipedia website has more than 75,000 active contributors working on some 9,000,000 articles in more than 250 languages.

Open Source software projects invite computer programmers from around the world to view software code and make changes and improvements to it. Through such collaboration, software programs can often be written and debugged faster and at lower cost than if the copyright holder were required to do all of the work independently. In exchange and in consideration for this collaborative work, the copyright holder permits users to copy, modify and distribute the software code subject to conditions that serve to protect downstream users and to keep the code accessible. By requiring that users copy and restate the license and attribution information, a copyright holder can ensure that recipients of the redistributed computer code know the identity of the owner as well as the scope of the license granted by the original owner. The Artistic License in this case also requires that changes to the computer code be tracked so that downstream users know what part of the computer code is the original code created by the copyright holder and what part has been newly added or altered by another collaborator.

Traditionally, copyright owners sold their copyrighted material in exchange for money. The lack of money changing hands in open source licensing should not be presumed to mean that there is no economic consideration, however. There are substantial benefits, including economic benefits, to the creation and distribution of copyrighted works under public licenses that range far beyond traditional license royalties. For example, program creators may generate market share for their programs by providing certain components free of charge. Similarly, a programmer or company may increase its national or international reputation by incubating open source projects. Improvement to a product can come rapidly and free of charge from an expert not even known to the copyright holder.

The case will now return to the California district court to be re-considered in the light of these findings.