Archive for the 'Legal' Category

UK Appeal Court Decision Significantly Strengthens Software Patentability

Published by Rowan Wilson on October 12, 2008 in Legal. 1 Comment

On Thursday the England and Wales Court of Appeal delivered a decision that will significantly strengthen the patentability of software in the UK. As I’ve mentioned before on this blog, the UK Intellectual Property Office(IPO) has been struggling to find a consistent method for examining patent applications that involve software. As an EU member, the UK is supposed to have the same rules on patentability of inventions as the European Patent Office (EPO), and to this end the European Patent Convention of 1973 was ‘imported’ into UK law in the from of the UK Patents Act 1977. Both the Convention and the Act state fairly plainly that software is excluded from patentability. Of course, having the same ruleset is only half the battle – you also have to interpret the rules in the same way and therefore produce decisions that are consistent with one another…

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).

Covenants or Conditions? Federal Circuit Clarifies Important FOSS Licensing Question

Published by Rowan Wilson on August 14, 2008 in Legal. 0 Comments

In this blog we’ve talked before about the vexed question of whether free and open source software (FOSS) licences should be primarily considered as contracts or bare licences. A useful tool for considering this question (in the US at least) became available today in the form of a decision by the US  Federal Circuit Court of Appeals (pdf). To briefly sketch the complex background to this decision, Robert Jacobsen, one of the authors of the JMRI Project – a set of java tools for controlling model trains – tried to get an injunction in the California court against Matthew Katzer, an owner of a model train software business for infringement of copyright. The entire vexed and ugly history of the dispute can be read on the JMRI project Sourceforge page; it includes accusations of patent infringement, libel, unfair competition and price-fixing. Our concern here though is just with the copyright claim. Jacobsen had asked the California court to stop Katzer ever again distributing JNRI code without copyright notices (Katzer admitted doing so but had already pulled the distribution by the time the court came to consider the question).

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.

Thanks For The (Copy In) Memory

Published by Rowan Wilson on May 7, 2008 in Community and Legal. 0 Comments

Recently Google was served with a takedown notice under the US’ Digital Millennium Copyright Act (DMCA) alleging that the free software project CoreAVC-for-linux contained code owned by the company CoreCodec:

Re: Illegal Materials Hosted on and/or Linked To From Site Hosted by Google

To Whom It May Concem:

I represent CoreCodec, Inc. (“CoreCodec”), which owns the copyrights in CoreAVC, (“Software”). It has come to my attention that a web site hosted by Google Inc., http://code.google.com/p/coreavc-for-linux/ (“Site”), hosts and/or contains links to material that infringes CoreCodec’s copyrights in the Software. This correspondence is a formal takedown notice being sent to you pursuant to Tile 17 United States Code Section 512, et seq.

The details are as follows:
Infringing Materials Hosted on and/or Linked To From the Site. The Site hosts and/or contains one or more links to CoreAVC, which contains CoreCodec’s copyrighted Software. We have directly verified by downloading the file from the Site provided by Google Inc. that the file does include CoreCodec’s copyrighted Software…

As with any legal action against an free or open source software project, the story soon appeared on Slashdot accompanied by the usual voluble booing from the commenting community. The dust had barely had time to settle when CoreCodec backed down, apologised to the project’s author and asked Google Code to reinstate the project. Some of the thought processes behind this can be examined by reading the relevant thread on Core Codec’s community web forum. The representative of the company (posting as betaboy) starts by defending CoreCodec’s actions then gradually backs away from them until he has agreed to get the project reinstated and even to help the project overcome some technical difficulties they had been having with interlacing (the project’s function is to make a commercial video decoding component written for windows by CoreCodec function under Linux).

So what caused this extreme turnaround? Well it certainly seems that the takedown notice itself was faulty, and that (by CoreCodec’s own admission) the CoreAVC-for-linux distribution did not in fact contain any code belonging to CoreCodec. Potentially the author of CoreAVC-for-linux could have taken action against CoreCodec for stating incorrect information in the takedown notice. As for the issue of reverse engineering that betaboy brings up in the forum thread, it is certainly true that the DMCA contains limited exemptions for certain kinds of reverse engineering conducted purely for the purposes of interoperability. Still, as is so often the case these days, what the bare law permits the End User License Agreement (EULA) takes away:

(III) You are also expressly prohibited from reverse engineering, decompiling, translating, disassembling, deciphering, decrypting, or otherwise attempting to discover the source code of the Licensed Works as the Licensed Works contain proprietary material of Licensor. You may not otherwise modify, alter, adapt, port, or merge the Licensed Works.

(from the EULA for CoreAVC)

So the author of CoreAVC-for-linux may have been in violation of this license agreement when they created the software, and so were not covered by the grant of licence in the same document. This would make certain actions that are necessary for running the program – such as copying it into memory – violations of the code owner’s copyright. Of course, in the end CoreCodec decided to permit the project to continue despite any possible claims relating to EULA violation, and it seems likely that the publicity backlash generated by the original takedown may have had something to do with this.

In a related story, Blizzard Entertainment, astonishingly successful producers of the networked fantasy game World of Warcraft (WoW) are trying to suppress a ‘cheating’ tool by arguing that running a program once you’ve violated the EULA is copyright infringement. WoW involves building up an online character by fighting monsters and completing quests. To achieve the highest levels a very large amount of time is required. To ease the burden of this so-called ‘grinding’ (repetitive monster-slaying and treasure-seizure) third party application developers have created tools that will run alongside the WoW program and interact with it as though they were the player themselves, allowing the player to accrue in-game goodies while they sleep or are otherwise engaged. Now while there’s very little doubt that these programs unbalance the game, allowing large returns for minimal effort, it is less clear that they are actually illegal. Blizzard are arguing that – because their EULA forbids the use of automated tools for playing – any user who employs one is infringing on their copyright when the game is copied into memory to be run. After all, the EULA is the agreement which permits this action and if the end user is in violation of it then their rights granted under it will lapse. The Electronic Frontier Foundation, a not-for-profit organisation that promotes freedom in the digital sphere has warned that this case risks setting a dangerous precedent – that buyers of software have no rights as owners but merely rights as licensees, to be terminated if they do not use the software as envisaged by its owners. While the decision itself – whatever it is – will be of no legal moment here in Europe, there are good reasons for watching the treatment of this case closely. Software is a global market, and software manufacturers exert strong pressure on national governments to legislate in line with the decisions most favourable to their business wherever they may be.

Google and the Affero GPL

Published by Rowan Wilson on April 29, 2008 in Business, Community, Development and Legal. 3 Comments

Since its launch just over three years ago Google Code has become a widely used repository for the code of free and open source projects (OSS Watch have a briefing note on how to start a Google Code project here). Unlike its venerable competitor Sourceforge, Google Code permits only a small subset of the Open Source Initiative’s approved licence list. At the time of writing you must distribute under one of the following licences if you want your project to be hosted on Google Code:

  • Apache License 2.0
  • Artistic License
  • GNU General Public License v2
  • GNU General Public License v3
  • GNU Lesser General Public License
  • MIT License
  • Mozilla Public License 1.1
  • New BSD License

    • Why do Google only allow this subset? The answer is given in this FAQ answer:

    Why do you only offer a small set of licenses?

    The open source community has been flooded with lots of nearly identical licenses. We’d like to see projects standardize on the most popular, time-tested ones. The selected licenses offer diversity to meet most developer needs.

    The phenomenon described there, licence proliferation, has been recognised as a thorny problem for many years. Back in 2004 the Open Source Initiative kicked off a project aimed at making the dozens of free and open source licences more readily comprehensible and easier to assess. The final report of the project recommended the strategy of grouping the licences by function and drawing up a menu of ‘licenses that are popular and widely used or with strong communities’ to help people choose.

    Despite the imperative to keep the number of licences manageable, the Open Source Initiative keeps approving new ones where they accord with the Open Source Definition and clearly provide new features over the current stable. Recently they approved the GNU Affero General Public License v3 (AGPL), a close cousin of the GNU General Public License v3. In fact the AGPL’s provisions are identical to those of the GPLv3 except for one additional clause:

    Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.

    This clause is intended to close what has become the ‘ASP Loophole’ present in most current open source licences. As networked computers have become more and more common, it was noted by the free and open source community that many ‘Application Service Provider’ (ASP) companies were setting up selling services over the internet that were based upon tweaked and improved versions of free and open source software. If these companies had been distributing the software itself, many of them would have been obliged by the licence under which they received the software to make the source code to their improved versions available to all. However as they were merely making the service based on the software available they had no such responsibilities. Under the AGPL, however, an ASP who used APGL’d software as the basis of a service would have to share their source code as a consequence of allowing people to interact with it over a network.

    Now in fact during the drafting of the GPL version 3 itself, many had argued that such a provision be included. In the event the authors of the GPLv3 decided that they did not wish to make such a provision mandatory, and instead chose to help draw up the AGPLv3 and add a clause to the GPLv3 that ensures compatibility between codebases released under the two licences. In this way developers could choose whether they wanted to enforce source distribution as a result of network interaction with their code and its derivatives.

    Now some developers who use Google Code have started wanting to choose the AGPL for their code, and indeed some have already done so, simply by selecting ‘GNU General Public License v3′ on the form when they create the project then adding a note to the project itself which states that it is in fact under the AGPL. Google, in the shape of their Open Source Programs Manager, Chris Di Bona, responded initially by saying that they would not include the AGPL as it was not OSI-approved and would exacerbate proflieration. Once it was OSI-approved, the issue arose again and Di Bona argued on his personal blog that the terms of the AGPL were unclear and that time was needed to see how the licence was used and construed. Thus AGPL-licensed projects are moving away from Google Code.

    Of course, some chose to see Google’s rejection of the AGPL for Google Code as a self-interested act. After all, Google’s own business is built on services implemented using adapted free and open source software. If free and open source software licences had always contained AGPL-like provisions, the source to many of Google’s popular services and adaptations (including potentially the code used to implement many aspects of Google’s core search business) would be available for the world to see and use. While it’s tempting to speculate on conspiracies, particularly those that involve enormous corporations, I can’t see that Google’s opposition to the AGPL is based on a perceived threat to their business model. Having achieved their ascendancy already, they can simply refuse to adapt any AGPL’d code; it’s not as though there is anything likely to be under the AGPL that Google could not afford to re-engineer themselves.

    What these events do point to, though, is the ability of large organisations like Google to potentially change the open source landscape. By limiting the licence choices on Google Code, Google openly acknowledge that they are trying to change the profile of selected licences within the community. At the moment their aim is to suppress proliferation, a common goal with the OSI. When asked in the thread linked above what would persuade Google to allow AGPL on Google Code, Chris Di Bona replies that once it is as widely used as the BSD license, it would naturally find a place there. While this seems reasonable, I have to wonder how such a benchmark would work if Google Code becomes even more widely used. Eventually exclusion from Google Code could become a major obstacle to uptake of a licence, and thus a Google-excluded licence could have real difficulties meeting the popularity conditions necessary for subsequent inclusion. Even with the best of intentions, an organisation the size of Google needs to tread carefully.

    Software Patents: Follow The Leader

    Published by Rowan Wilson on April 21, 2008 in Legal. 4 Comments

    Enterprise Linux distributor Red Hat has entered what is called an ‘amicus’ brief in a patent appeal case on the US Federal Circuit. A man named Bernard Bilski had applied for a patent on a method for controlling risk in the energy commodity market. The US Patent and Trademark Office rejected the claim as being ‘directed to non-statutory subject matter’ (pdf link), which means that it attempted to gain patent control over something that is excluded from being patented by law. So what does the US law say about what can and cannot be patented?

    Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.

    from here.

    The US legal code is not much more forthcoming than that on precisely what can be patented. Nuclear weapons are specifically excluded, but otherwise is has been the courts role to flesh out the precise meaning of the sentence quoted above. Certain categories seem to have emerged as uncontroversially outside the range of patentability: laws of nature, abstract ideas and mental processes. Other categories have fluctuated, such as business processes and computer software. Both of these latter have been excluded in the past but have edged into patentability through successive court decisions and artful claim drafting. So Mr Bilski is now in the process of arguing in the Court of Appeals of the Federal Circuit (CAFC) that his business process is in fact eligible for patent protection. The CAFC has decided that the issue underlying this appeal is important enough for them to consider it en banc, meaning that the matter will be decided by all the judges of that court, rather than the usual three judge panel. In order to make up their minds, the CAFC judges have asked for submissions from every interested party (or Amicus Curiae or “friend of the court” ) on what ought and ought not to be patentable in this area. It is in response to this invitation that Red Hat have filed their brief. Red Hat argues that its stock-in-trade – free and open source software – contributes greatly to the American economy but has achieved its current level of success despite a background of uncertainty over potential software patent infringement. This uncertainty, the brief argues, needs to be allayed by a solid decision that software in itself and abstract business processes cannot be patented, and that they can only form part of a patented invention if there is a separate innovative physical process involved. This argument, if accepted, would provide potential means of invalidation against many, many software patents and nearly all business process patents. It will be interesting to see how this develops. The Patently-O blog provides this useful tabulation of all the briefs from interested parties in the case.

    While the US is re-examining the wisdom of software patents and business processes, the UK has moved a step closer to approving pure software patents. Back in January the High Court upheld an appeal from a posse of patent applicants (Astron Clinica, Surf Kitchen, Software 2000, Inrotis, Cyan Technology) against the UK Intellectual Property Office’s rejection of their claims. All said that the UKIPO had misapplied a four-step patentability test that arose from the last time this argument was aired in the Aerotel/Macrossan decision (pdf link). Strange though it is to say, that decision is a genuinely entertaining read and provides a marvellous overview of the troubled history of software patentability in the UK and EU. In it Lord Justices Chadwick, Jacob and Neuberger conclude that the test – which was in fact proposed by the UKIPO – should be the basis for establishing patentability. In the case of Astron Clinica et al, the rejected applicants successfully argued that the UKIPO had effectively decided that the outcome of the four step test would always be that pure software was unpatentable, and was therefore simply applying that conclusion to all cases without first actually evaluating the steps of the test. Of course many would argue that the UKIPO were quite justified in doing this, given that the wellspring of governing law for this area, the European Patent Convention 1973 (at article 52) says the following:

    (1) European patents shall be granted for any inventions which are susceptible of industrial application, which are new and which involve an inventive step.

    (2) The following in particular shall not be regarded as inventions within the meaning of paragraph 1:

    (a) discoveries, scientific theories and mathematical methods;

    (b) aesthetic creations;

    (c) schemes, rules and methods for performing mental acts, playing games or doing business, and programs for computers;

    …

    Nevertheless in his judgement on Astron Clinica et al Mr Justice Kitchin concluded (in part) as follows:

    In all these circumstances I have reached the conclusion that claims to computer programs are not necessarily excluded by Article 52. In a case where claims to a method performed by running a suitably programmed computer or to a computer programmed to carry out the method are allowable, then, in principle, a claim to the program itself should also be allowable.

    While this may seem flatly contradictory, it makes slightly more sense against the background of European Patent Office decisions over the last twenty five years. Effectively the exclusion has been eroded away to nothing by crafty drafting of applications and complex rethinking of the nature of what constitutes a ‘technical effect’. Mr Justice Kitchin’s judgement effectively says that if we are going to accept something like a ’suitably programmed computer’ as the subject of a patent (one of the crafty drafting tactics used to gain software patents in the EU) then we might as well just admit that we are granting software patents and stop the pretense.

    With the UK coming more into line with the EU on this issue, and the EU historically trying to come into line with US standards of patentability, it would be ironic if the US decided that actually they now want to reign in the patentability of software.

    Microsoft, POI and odd distinctions

    Published by Rowan Wilson on April 9, 2008 in Development, Legal and Standards. 0 Comments

    In the run-up to the ISO vote on the controversial OOXML specification, Microsoft – OOXML’s creator – announced that they would be funding development of the open source Java API to access Microsoft Office formats Apache POI to support the new standard. Information Week reported on this announcement, and made the following statement:

    For patented protocols, Microsoft said it would offer licenses on “reasonable and non-discriminatory terms.” Open source developers can access the protocols for free for noncommercial use without fear of lawsuits, Microsoft said.

    Now, as we mentioned a week ago Microsoft accompanied their submission of the OOXML standard to the OSI with an ‘Open Specification Promise‘ in the following words:

    Microsoft irrevocably promises not to assert any Microsoft Necessary Claims against you for making, using, selling, offering for sale, importing or distributing any implementation to the extent it conforms to a Covered Specification (“Covered Implementation”), subject to the following. This is a personal promise directly from Microsoft to you, and you acknowledge as a condition of benefiting from it that no Microsoft rights are received from suppliers, distributors, or otherwise in connection with this promise. If you file, maintain or voluntarily participate in a patent infringement lawsuit against a Microsoft implementation of such Covered Specification, then this personal promise does not apply with respect to any Covered Implementation of the same Covered Specification made or used by you. To clarify, “Microsoft Necessary Claims” are those claims of Microsoft-owned or Microsoft-controlled patents that are necessary to implement only the required portions of the Covered Specification that are described in detail and not merely referenced in such Specification. “Covered Specifications” are listed below.

    This promise is not an assurance either (i) that any of Microsoft’s issued patent claims covers a Covered Implementation or are enforceable or (ii) that a Covered Implementation would not infringe patents or other intellectual property rights of any third party. No other rights except those expressly stated in this promise shall be deemed granted, waived or received by implication, exhaustion, estoppel, or otherwise.

    This would seem to be a blanket promise (or covenant) to avoid taking patent infringement action against anyone implementing the current OOXML standard or using such an implementation – for example Sourcesense and the users of POI who will be receiving their Microsoft-sponsored OOXML code. There is no mention of a different deal for commercial use of open source implementations, as the Information Week story seemed to imply. Does this discrepancy matter? Well it has certainly caused anger and confusion among some in the free and open source community. Michael Tiemann President of the Open Source Initiative (OSI) and Vice President of Open Source Affairs at Red Hat Inc. quickly responded to the article with a blog post on the OSI site entitled ‘Microsoft’s new weapon against open source: stupidity‘. In it, Tiemann laments the unquestioning attitude of the media in reporting Microsoft’s seemingly discriminatory attitude to open source as cosy non-discriminatory affection. Trouble also kicked off on the Apache developer mailing list for POI, with a quotation of the Information Week article and a call for the Sourcesense code to be rejected from the project as it was ‘encumbered’ by Microsoft’s seeming insistence that patent licenses must be obtained for commercial use.

    The mismatch between the Information Week article and the Open Specification Promise puzzled me, so I contacted Microsoft here in the UK to see what the truth of the matter was. The query found its way to Microsoft US’ Public Relations firm Waggener Edstrom who replied as follows:

    Apache libraries are open source code, and available through broad licensing. Any required Microsoft patent rights relative to Office Open XML are available on a royalty-free, perpetual basis to all implementers, as outlined within the Microsoft Open Specification Promise.

    So it would seem that the indirect quote from Microsoft in the Information Week article was either misreported or inaccurate, and the dismay in the free and open source community is the inevitable mistaken result of this mistaken account.

    The question remains, though, how did the error occur? Certainly it could have been a typo somewhere, but I wonder if it is perhaps a result of the phraseology Microsoft adopts when discussing free and open source. To return for a moment to the web page of Microsoft’s ‘Open Specification Promise‘ we find that there is also a lengthy FAQ to elucidate the effects of the covenant. In this FAQ, Microsoft twice draws a distinction between ‘commercial’ and ‘open source’ software:

    The Open Specification Promise is a simple and clear way to assure that the broadest audience of developers and customers working with commercial or open source software can implement specifications through a simplified method of sharing of technical assets, while recognizing the legitimacy of intellectual property.

    and later

    The Open Specification Promise is a simple and clear way to assure that the broadest audience of developers and customers working with commercial or open source software can implement the covered specification(s).

    This is an odd way to speak, given that there are large commercial open source companies out there of whom Microsoft must be aware. While one can only speculate about Microsoft’s reasons for giving the impression that open source and commerciality are mutually exclusive, it certainly seems possible that this odd linguistic tic is the root cause of the confusion in Information Week and the resulting screams of protest from the free and open source community.

    Notice: Sourcesense have provided speakers for OSS Watch events in the past, and a member of Sourcesense sits on our Advisory Committee.

    What is Zoto’s Business Model?

    Published by Rowan Wilson on April 4, 2008 in Business and Legal. 3 Comments

    Zoto is a photo-sharing web site that – while initially free to use – switched to a paid model late last year. There was speculation then that this move might have been triggered by money troubles. Then on March 22nd, Zoto’s CEO Kord Campbell announced on his blog that the software that drives the Zoto web site would be made available under the new BSD license from Google’s open source repository Google Code. In his blog entry Campbell wrote:

    Open Source software isn’t necessarily free to use – it’s free as in to view and modify the source. The Zoto Server software will be free to use for some users. I’ll figure out what to do later with you big profitable people. Maybe we’ll do Paypal donations, or revenue share like PHPGallery.

    Campbell expanded on this view in a comment on a ReadWriteWeb story covering his decision to release the Zoto software under an open source licence:

    The BSD license is one of the few licenses that actually allows a separate license to be placed on the same code. That means I could put a separate commercial license on Zoto later, as I mention on the page.FWIW, it makes sense for someone to license the code from me if they are going to be using it in a commercial application. They might need install services, support, extra features added, etc., and it would be a requirement for them to use it.

    Now it seems clear from these posts that Mr Campbell was expecting that a certain category of his users would need to buy a licence from him if they intended to use his Zoto software – specifically commercial or ‘big profitable people’. The problem is that the licence he has selected does not really give any incentive to commercial users to pay for a different licence as it provides all permissions necessary to use the software commercially. He also seems a little confused about the issue of licence exclusivity. The BSD license is not ‘one of the few’ licences to allow differing licences on the same code; all free and open source licences are non-exclusive, and as the copyright owner Mr Campbell is at liberty to license the code out under as many non-exclusive licences as he likes. The problem, as mentioned above, is that when the BSD licence is one of them, any more restrictive licences may seem unappealing to potential users, particularly if they also require the payment of a licensing fee.

    News of this licensing puzzle spread quickly to the License-Discuss list of the Open Source Initiative:

    It’s hosted on Google Code (http://code.google.com/p/zoto-server/) and is allegedly made available under the New BSD License. However, the description of the project contains this: “The server and the rest of the Zoto code base is now free for non-commercial use. If you want to use Zoto’s software in a commercial, for-profit environment, you can contact Kord Campbell at kordless@gmail.com, to inquire about licensing options for commercial applications.”

    Doesn’t sound like they intend it to be open source to me. I wonder if Google will allow Zoto to continue to use their code hosting service under these terms?

    Now as anyone who has followed the link to the Google Code site for Zoto will know, it no longer features the text quoted in the above post. Campbell responded to a query as to what he meant in the following way:

    It was 5:30AM, and I wanted a way of addressing licensing the product to companies that may require an additional license to run the software. For example, last year we licensed the software to a company that required a support license be provided along with the original source code.

    So whatever the original intention, it seems that now the business model Campbell is now describing is the one more traditionally associated with BSD-licensed software – services, warranties and training as a side-channel.

    So what lessons can we learn from the confusion surrounding Zoto’s open source release? Firstly, it is an area of technology that remains deeply politicised, and as such it is extremely important to have both a clear understanding and a clear expression of your intentions available right from the start. Secondly, business models cannot be retrofitted easily. Now that the code is out there under a BSD license there is no way of suppressing its distribution under those terms.

    Without knowing what Campbell’s intention is it is hard to say if he made the right licence choice. If he wants people to build businesses using this code whilst buying services and warranties from him then this licence is as at least as good as any (some people claim permissive licences like this are better for community development models). However, if he was planning to have people modifying and distributing his code it may well be that a more copyleft licence would have suited his purposes better, giving commercial users a clear reason to pay for a non-free licence to avoid the responsibility to distribute source with any modified derivative. In fact, given the inherently network-based functionality of Zoto’s software, it might be a prime candidate for application of the Affero GPL v3, which mandates that downstream adapters must cause their versions of the software to serve up their source code when requested, even if the software itself is not distributed. The Affero GPL v3 has been submitted to the OSI and is currently awaiting approval.

    Microsoft’s OOXML Wins ISO Approval

    Published by Rowan Wilson on April 2, 2008 in Community, Development, Legal, Software, Standards, Strategy and Policy, e-Administration, e-Learning and e-Resources. 3 Comments

    Perhaps wary that the date might detract from the news, ISO – the International Organization for Standards – waited until today before announcing that Microsoft’s Office Open XML (OOXML) document description schema has finally been accepted as an ISO standard as of April 1, 2008. There has been a long and bitter battle over whether this schema should be adopted. For one thing, an ISO-approved XML standard for describing office documents already exists in the form of OpenDocument created in association with Sun Microsystems by the Organization for the Advancement of Structured Information Standards or OASIS. Many argue that having multiple standards for the same objects defeats the purpose of establishing standards in the first place. While this is on the face of it a reasonable argument, it seems a little Utopian to expect complete global unanimity on these subjects, particularly where such valuable commercial interests are at stake. After all, the world has not even managed to agree on a standard standards body, so expecting agreement at any lower level seems over-optimistic. Microsoft’s OOXML has been a standard according to ECMA International since 2006, while OASIS approved OpenDocument back in 2005.

    So why is there such bitterness over this issue? Well, some of it comes from the perception that OOXML is in itself an inadequate standard which has triumphed through Microsoft’s expertise at lobbying ISO member bodies for their votes. Critics point out that the standard is itself is incredibly long and complex – over six thousand pages. It has also been widely observed that rather than trying to select a set of characteristics that need to be described in order to define a document minimally and efficiently, OOXML instead describes a huge set of overlapping characteristics that define the many different ways Microsoft has described documents over the almost twenty year life of the Microsoft Office product. It is easy to see why they have done this; it greatly facilitates conversion of all legacy documents into the new format. Still, it also results in a swollen specification that competitors will find very difficult to implement in their products. For example, OOXML defines many functions such as shapeLayoutLikeWW8, which instructs a rendering application to arrange text around a shape in the same way as Microsoft’s Word 97. Clearly Microsoft will have an advantage over competitors in making their products reliably behave in these ways.

    Back in September 2007 OOXML lost an adoption vote at ISO, partly as a result of muscular lobbying from the free and open source communities, and hundreds of changes to the standard were requested by the voting members. While many of these were implemented by Microsoft and ECMA, the majority remained unimplemented at the time of OOXML’s approval.

    Another controversial aspect of the OOXML standard is Microsoft’s patent non-enforcement promise that accompanies it. International standards must at the very least include fair and non-discriminatory terms for the licensing of patents that their use might infringe. Generally the standards bodies prefer that associated patents are licensed at no cost, and this is essentially what Microsoft has done with their Open Specification Promise. It promises that Microsoft will not enforce their patents against anyone as a result of their activities implementing OOXML readers, writers or renderers. However Microsoft make no explicit promise that subsequent versions of OOXML will also be covered by such a promise, merely saying that they aim to continue the promise in areas where they continue to engage with open standards bodies. This has alarmed many people, pointing to a possible future where everyone has adopted OOXML only to find that Microsoft withdraw from engagement with standards bodies and also withdraw their patent promise for subsequent versions. In comparison, Sun’s Non-Assertion Covenant for OpenDocument offers a perpetual promise not to sue for both version 1.0 and all subsequent versions. In the run-up to ISO’s decision, the Software Freedom Law Center (SFLC), a free-and-open-source-supporting public interest legal practice, released a document filled with dire warnings about Microsoft’s Patent Promise, and telling anyone writing software under the GNU General Public License to shun it. SFLC’s argument is twofold. Firstly they argue that, despite the promise, a piece of multi-purpose code might be protected when used to implement the standard but infringing when used for something else. Secondly, they argue that Microsoft’s failure to extend the promise to future revisions of OOXML means that projects attempting to progressively implement newer and newer versions of the standard may hit a legal brick wall down the line.

    Are these worries justified? Certainly the SFLC’s first point is well taken, given the propensity of free and open source developers to repurpose code. The second point is less persuasive, I think, and a little opaquely worded in their document. To be clear, implementations of the current version of OOXML will always be protected from patent action by Microsoft, whether they withdraw the promise from future versions or not (provided the code in question is actually used to implement the standard). As to whether Microsoft will actually withdraw the promise from future versions, it is a difficult issue to predict. Microsoft got into the open standards game in the first place in order to win procurement contracts – often in the public sector – where open standards are listed as pre-requisites. While it may be notionally possible for Microsoft to partially re-enclose their format by either withdrawing the promise from a future version or withdrawing from the open standards process altogether, the practicality of such a move would depend heavily on how Microsoft’s users would respond to it. Thus the future of the standard really depends less of Microsoft’s whim and more on ourselves and the organisations for which we work.

    Blackboard VLE Patent Claims Rejected (For Now)

    Published by Rowan Wilson on April 1, 2008 in Legal. 1 Comment

    Back in February dominant VLE vendor Blackboardwon its patent infringement case against commercial rival Desire2Learn and were awarded $3.1 million in damages. Last week, however, it emerged that as a result of requests for re-examination by both Desire2Learn and the Software Freedom Law Center (SFLC), all 44 claims of the Blackboard VLE patent have been provisionally rejected.

    Excerpt from interrim reexamination

    (the pdf of full judgement can be accessed on Desire2Learn’s site)

    The claims were rejected both on the basis of prior art and of obviousness. Blackboard have two months to appeal the decision.

    It is interesting to note that Blackboard tried to reassure the free and open source world that it had not intention of using its patent against them by (very unusually) issuing a patent non-enforcement pledge. Despite this the free and open source community, primarily through the intervention of the SFLC, has played a substantial role in opposition to the Blackboard patents.

    Rosen’s “Patentleft” Spin-Out

    Published by Rowan Wilson on March 30, 2008 in Business, Community and Legal. 0 Comments

    International Characters (IC) is an open source ’spin-out’ company formed around work done by Dr Rob Cameron of Simon Fraser University in Vancouver, Canada. Professor Popowich has a software patent pending on the core technology that is embodied in their software, which aims to accelerate the processing of XML bitstreams.

    For example, our open source u8u16 software achieves 3X to 25X speed-ups for conversion of UTF-8 character data to UTF-16, depending on platform and input data characteristics. Download u8u16 from Prof. Cameron’s development website at u8u16.costar.sfu.ca. Note that the performance improvements cited even include the cost of conversion to and from parallel bit stream form.

    Our Parabix (TM) software is the core high-speed XML processing engine based on parallel bit stream technology and available from its development website at parabix.costar.sfu.ca.

    (quoted from http://www.international-characters.com/node/7)

    Now traditionally there has been a strong affiliation between the free and open source software community and the groups which oppose the granting of patents on software. Software patents tend to be viewed in these circles as a cudgel in the arsenal of proprietary software vendors who wish to control competition from their rivals in both the closed and open source worlds. It does not help that there is a universally acknowledged worldwide problem with the examination of software patents, caused by the lack of good prior art databases and examiners familiar with the topic. Thus many software patents are granted which seem – at least superficially – to be non-innovative or overbroad. So is SFU’s company unaware of these tensions between the worlds of open source and software patents?

    It seems unlikely given that IC’s legal thinking is provided by Larry Rosen. Rosen is a grandfather of the open source community, and has been general counsel for the Open Source Initiative (OSI). He also wrote two of the licences on the OSI’s approved list – the Academic Free License (a permissive licence) and the Open Source License (a copyleft license). IC uses these licences in combination with their (pending) patent to implement a novel open source business model. Essentially the deal is this: IC make their software available under the Open Source License 3.0, which obliges derivative works to be released under the same licence. In addition to this licence, IC provide a Covenant Not To Assert their patent rights against any open source software that implements their patent, with certain interesting provisos. The covenant defines an ‘open source licence’ as any licence approved by either the Open Source Initiative or the Free Software Foundation, but narrows the generally understood definition of ‘open source software’:

    The term “open source software” in this covenant shall mean software actually distributed to the public under software licenses that have been expressly approved by Open Source Initiative or the Free Software Foundation as of the date of this covenant, and that provide that every licensee is free to make copies of the software or derivative works thereof, to distribute them without payment of royalties or other consideration, and to access and use the complete source code of the software.

    By inserting the phrase ‘actually distributed to the public’, Rosen excludes from the covenant adaptations made and kept in-house. Companies and institutions must either distribute to all or pay a patent licensing fee to IC. The covenant also draws a distinction between the software in itself and the software when distributed in combination with hardware. End users who put the software on their computer themselves are covered by the covenant, but distributors who wish to sell hardware with the software pre-installed are not, and must pay up. (It’s worth remembering that here ‘the software’ does not refer to IC’s actual code, which is under the OSL and thus has its own patent grant, but any and all other software which implements IC’s patent).

    So what we have here is a novel form of dual-licensing that realises value from the monopoly granted by a software patent while granting wide-ranging no-cost usage and distribution rights to the open source and academic communities. It is almost certain to be controversial in some areas of the community, both for its implicit acceptance of the appropriateness of software patents and its shaving down of some of the communities (internal adapters, hardware vendors) who have up to now been able to avoid payment of licence fees for their use of open source.

    You can see Rosen discuss IC here.