Archive for April, 2008

WebPA get more traction

Why is it I only ever seem to blog about WebPA and its successes? Surely there are other JISC funded projects out there that have similar levels of success in engaging with a user and developer community? I suspect the difference is that Nicola Wilkinson, systems developer on the WebPA project, puts the effort into informing the wider community of what is happening, thus I get to hear about it (other projects that have equally vocal team members should let us know via a comment here).
This time Nic posted the following on the projects mailing list:

Today, the WebPA team have received some really good news from Dr Bob Cherry
at Manchester Metropolitan University (MMU). WebPA has been piloted there
with one of Bob's modules. From this pilot Bob has been able to report that...

"WebPA is now embedded in our first year and will be for the next five
years. Typically 180-200 students will be subjected to.. [WebPA] ..every
year." (Dr Bob Cherry, MMU)

Further more "Another Head of Department suggested that if it was successful
then it would find further deployment at MMU (everyone has issues with
student group work)."

This is a great success for MMU, the WebPA team and JISC, showing the real
need for the WebPA tool in Higher Education.

Well done to the WebPA team. As I’ve said many times before, more users means more people willing to pay for services around the software and more people willing to contribute to its development.

Google and the Affero GPL

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

    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

    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?

    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.