Last year, 2011, was one of the most active years in legal developments in FOSS. This activity reflects the increase in FOSS use: Laura Wurster of Gartner, noted in the Harvard Business Review blog that open source has hit a “strategic tipping point” this year with companies increasingly focused on using “open source” software for competitive rather than cost reasons http://lawandlifesiliconvalley.com/blog/?p=619.   

Continuing the tradition of looking back over top ten legal developments in FOSS, http://lawandlifesiliconvalley.com/blog/?s=top+10+2008&x=40&y=6,  my selection of the top ten issues for 2011 are as follows: 

1.         Android Patent Litigation.   One of the most widely reported legal developments in FOSS has been the patent wars surrounding the Android operating system.  Over 40 patent cases are pending between a wide variety of parties, including Motorola Mobility, Inc., HTC, Samsung Electronics, Inc. and Apple Computer, Inc.  This year saw several decisions in these suits.  In Australia, Apple won a trial court decision which enjoined the distribution of Samsung’s Android tablets based on a claim that the Samsung tablet violated Apple’s design patents. However, after a series of appeals, Australia’s High Court overturned the injunction and Samsung can now distribute its tablets. Apple was more successful in Germany where it was successful in obtaining an injunction based on Apple’s design patents which prevents the distribution of Samsung’s Galaxy Tab 10.1 (however, Samsung has released a revised version named the Galaxy Tab 10.1N).  Apple was not successful in obtaining an injunction against distribution of Samsung’s Galaxy Tab in the United States, although the judge stated that Apple’s design patents might be infringed. More recently, on December 19, the ITC ruled that HTC’s Android phones violated two claims of an Apple utility patent and issued an “exclusion order” for HTC Android phones which would take effect on April 19, 2012. HTC has announced that it will provide a workaround.  Google has been handicapped by its lack of patents to assert in defense of Android (it started with only 600 patents, but is aggressively buying new patents and has agreed to purchase Motorola Mobility, Inc., primarily for its patent portfolio).  

2.         Oracle v. Google.   A separate but related case is Oracle’s suit against Google for the alleged infringement of Oracle’s copyrights in the Java software (which it acquired from Sun Microsystems, Inc.) and certain Oracle patents by Android.  Oracle is asserting that the Android operating system infringes the copyrights in “twelve code files and 37 specifications for application programming interface packages”.  The decision on this claim could have a significant impact well beyond this case: most software lawyers have viewed APIs (and their specifications) as either having no copyright protection or very limited copyright protection. These views govern the interpretation of both FOSS and proprietary licenses.  The court described APIs as follows:   

Conceptually, an API is what allows software programs to communicate with one another. It is a set of definitions governing how the services of a particular program can be called upon, including what types of input the program must be given and what kind of output will be returned. APIs make it possible for programs (and programmers) to use the services of a given program without knowing how the service is performed. APIs also insulate programs from one another, making it possible to change the way a given program performs a service without disrupting other programs that use the service. 

If Oracle prevails and the court finds that APIs are copyrightable, lawyers will need to rethink how they interpret both FOSS and proprietary licenses. The issue could be particularly important in determining whether interactions between software programs licensed under GPLv2 or GPLv3 create, respectively, “derivative works” or a “modified version” and, thus, impose the license terms of GPLv2 or GPLv3 on the software modules with which they interact. The first significant decision in the case rejected Google’s attempt to eliminate the claims through summary judgment (Google won only on a single minor point). http://www.scribd.com/doc/65143317/Oracle-v-Google-Denial-of-Google-s-Summary-Judgment-Motion.  However, this decision is not surprising because summary judgment is generally used for settled issues of law; the copyright issues in this case are on the cutting edge of the law. 

3.         Perfect 10 v. Google.   Although this case was not strictly about open source software, it established a critical principle for remedies for copyright infringement. These remedies also apply to enforcement of copyright licenses in certain situations. For decades prior to this decision, the presumption was that the remedy for copyright infringement was always “injunctive relief”.   Injunctive relief means that a court orders an “infringer” to comply with the terms of the license. The Perfect 10 decision in the Ninth Circuit Court of Appeals made clear that “injunctive relief” is no longer a remedy which is always available for copyright infringement.  Instead, the court stated that : We therefore conclude that the propriety of injunctive relief in cases arising under the Copyright Act must be evaluated on a case-by-case basis in accord with traditional equitable principles and without the aid of presumptions or a “thumb on the scale” in favor of issuing such relief. 

Injunctive relief is an unusual remedy for breach of license agreements, because under Anglo Saxon law, the standard remedy for breach of contract is monetary payment. However, a remedy of monetary damages has little value for breach of open source licenses because the open source software is generally distributed at no cost. The Perfect 10 decision undercuts the value of the Jacobsen decision to the open source community.  In Jacobsen, the Court of Appeals of the Federal Circuit decision found that injunctive relief was available for open source licenses if the relevant obligations were drafted to make them a “restriction” on the scope of the license rather than just a contractual obligation (a “covenant”) http://lawandlifesiliconvalley.com/blog/?p=65.  However, the other standard copyright law remedies such as attorneys fees, actual damages and, potentially, statutory damages remain available. However, injunctive relief, the most valuable of remedies, may be more difficult to obtain to enforce open source licenses. 

4.         Publication of Software Package Data Exchange (“SPDX”) Specification.  The management of open source software in the supply chain has been a continuing problem. However, the open source community has been working to find a solution to this problem.  The work has been guided by the SPDX Group (the SPDX Group is a working group of the Linux Foundation and is associated with FOSSBazaar) which has developed the SPDX specification as a standard format for describing the components, licenses and copyrights associated with a software package. For example, SPDX Group has identified seven versions of the General Public License version 2, the most commonly used open source license. If widely adopted, SPDX will be critical to effectively manage open source software as it becomes more widely used in the supply chain. As noted in the Harvard Business Review blog by Gartner Group, the ubiquity of the use of open source software has not been matched by effective management of its use  http://blogs.hbr.org/cs/2011/03/open_source_software_hits_a_st.html.

5.         Revision of Mozilla Public License.   The Mozilla Public License is one of the most popular open source licenses.  After eighteen months of work, Mozilla has announced a new version. The Mozilla Public License version 2 (“MPLv2”) is a much simpler, shorter and more usable license. The new license has adopted approaches (and sometimes the terms themselves) from other open source licenses: the patent license provision was adopted from the Apache license and the termination provision from the General Public License version 3. In addition, Mozilla has made the MPLv2 compatible with the Apache license. And MPLv2 has also included a provision to make the license “compatible” with other licenses. For example, MPLv2 permits distribution of code under the MPLv2 with other modules licensed under GPL variants (GPLv2, GPLv3, APGL and LPGL) if such modules are part of a “Larger Work” (unless the notice in the software states that the software is “Incompatible with Secondary Licenses”).  However, these differences mean that the transition to the MPLv2 for existing projects will require careful thought.

6.         Cybits Decision in Germany.  This decision makes clear that companies cannot alter the terms of software licensed under GPLv2.  AVM is a manufacturer of FRITZ!Box router, a digital subscriber line DSL terminal, which uses the Linux Kernel as a part of their production firmware (which is licensed under GPLv2). Cybits, a software producer, distributes the Internet filtering software “Surf-Sitter DSL”, which is intended to protect children. The Surf-Sitter application downloads FRITZ!Box software to the user’s computer, modifies it and then reinstalls it back on the FRITZ!Box.

AVM claimed that Cybits did not have the right to modify the part of the FRITZ!Box firmware which was licensed under GPLv2. The court rejected AVM´s claims that Cybits should not be permitted to alter the firmware of AVM and denied that Cybits had infringed AVM´s copyright by distributing Surf-Sitter. The court found that the firmware is a collective work, which contains modules licensed under GPLv2. Cybits or any third party may modify the GPLv2 licensed software. Thus, AVM is not able to control any modifications to the GPL licensed components of the FRITZ!Box firmware.

7.         Project Harmony Publishes Standardized Contributor Agreements.   Many commentators have complained about the problems raised by the number of licenses approved as “open source”, a problem frequently referred to as “license proliferation”.  Yet a similar problem is lurking in the development of open source software: the contribution agreements which govern the rights provided by contributors to a project. Project Harmony was a community effort to resolve this problem in advance by developing a set of standard agreements which can be adopted by open source projects http://www.harmonyagreements.org/about.html.

Many open source projects use the “license” for the project as a contribution agreement, but a variety of separate open source contribution agreements have developed over time, from the Apache Contributor Agreement to the Joomla Contributor Agreement http://community.joomla.org/images/JCA_General_Draft.pdf. Although many open source projects can use their standard open source license (i.e. GPLv2 for Linux or Mozilla Public License for the Mozilla browser) as the “contribution agreement”, this approach “locks in” the open source project to that license.  If the open source project wishes to change the license (such as the change of OpenOffice project from GPLv2 to Apache), this approach would require that each contributor agree to the change.  A good example of the potential for problems with this approach is the Open Street Map Project (“OSM Project”). The OSM Project has been struggling with shifting from a Creative Commons license to a more appropriate Open Database License http://wiki.openstreetmap.org/wiki/Open_Data_License_FAQ. After three years, the transition is still not complete. Finally, the OSM Foundation has given up on obtaining agreement from the remaining contributors and will probably delete contributions from  contributors that have not agreed to shift to the new license http://en.wikipedia.org/wiki/Open_street_map#Licensing. In addition, open source licenses do not deal with a number of other issues which should be addressed by contribution agreements, such as contributions by minors and changes of license. Project Harmony also makes it easier for corporations to contribute to open source projects by avoiding the complexities of managing the differing terms of these new contribution agreements. The Project Harmony standard contribution agreements permit projects to make a choice between a license or assignment approach and, then, select among several options to change licenses in the future (without obtaining permission from each contributor.

8.         Dispute over Koha Trademark.   The importance of the protection of trademarks to open source projects was illustrated by the recent dispute over the Koha trademark between Horowhenua Library Trust (“HLT”) and a commercial company,  PTFS, http://koha-community.org/update-2/.  HLT manages the Koha open source project. PTFS filed for trademark protection for Koha in New Zealand after it had acquired a company which used the trademark and the trademark was, then, registered by the New Zealand government. Upon registration of the Koha trademark, HLT complained and appealed for help.  Subsequently, PTFS agreed not to enforce the trademark and even to transfer the trademark to HLT http://patentbuff.com/2011/11/koha-alls-well-that-ends-well_28.html?spref=tw.

9.         The Meaning of Open Source.  The power of the community to police the misuse of “open” was demonstrated by Nokia’s attempt to claim that the Symbian mobile operating system was “open” for business http://www.groklaw.net/article.php?story=20110402143136766.  However, the Symbian license is not consistent with the Open Source Definition. The copyright license in the Symbian license is as follows:

Subject to the terms and conditions of this Agreement, Nokia hereby grants to You a personal, non-exclusive, non-transferable, irrevocable (except as set forth in Clause 7.1 and 7.2 below), royalty-free and worldwide license under Copyrights licensable by Nokia to: i) reproduce and modify Source Code Components; ii) reproduce Binary Components and Documentation; iii) use and reproduce Utility Software, and iv) publicly display, distribute and make available (a) the Source Code Components to third parties that have acquired a valid source code license from Nokia; and (b) Utility Software, Binary Components and Source Code Components in binary form to third parties, (c) Documentation in unmodified form in all cases i)-iv) solely as part of the Symbian Platform or for use with the Symbian Platform, under the terms and conditions of this Agreement.

The agreement requires a separate license for source code from Nokia and limits the use to the “Symbian Platform.” Nokia was forced to “correct” their original statement to “open for business” rather open source http://symbian.nokia.com/blog/2011/04/04/not-open-source-just-open-for-business.

10.        Open Hardware License.   The open hardware movement received a boost when CERN published an Open Hardware License (“CERN OHL”). The CERN OHL is drafted as a documentation license which is careful to distinguish between documentation and software (which is not licensed under the CERN OHL) http://www.ohwr.org/documents/88. The license is “copyleft” and, thus, similar to GPLv2 because it requires that all modifications be made available under the terms of the CERN OHL. However, the license to patents, particularly important for hardware products, is ambiguous. This license is likely to the first of a number of open hardware licenses, but, hopefully, the open hardware movement will keep the number low and avoid “license proliferation” which has been such a problem for open source software.

The recent Intellectual Property Business Congress in San Francisco was very interesting and demonstrated the increasing importance of intellectual property of business http://www.ipbusinesscongress.com/2011. The speakers ranged from Judge Rader (Chief Judge of the Court of Appeals of the Federal Circuit) to Ruud Peters (Chief Innovation Officers of Philips NV).   Many speakers emphasized the critical nature of intellectual property in developing products because most new products are the result of collaboration among many parties.  The rise of the need for collaboration in developing products ranges across all industries, from smartphones to automobiles.

Smartphones are a dramatic example of collaboration: the bill of materials for the iPhone shows that Apple only provides the operating system for the device.  Android represents another step in this evolution where even the operating system is provided by a third party. The disruptive nature of these new reality is demonstrated by the dramatic fall of Nokia’s market share in smartphones (I discussed these issues in more detail in my presentation on the new rules of innovation at the IBF Corporate Venture and Innovation conference in February http://www.docstoc.com/docs/83629007/Managing-Innovation-for-Global-Entrepeneurs-and-Large-Companies). 

At the conference, Frank MacKenzie, IP Counsel from Ford Global Technologies, stated directly that intellectual property at Ford has a much higher profile.  He described how the automobile industry has changed dramatically recently because of the integration of a much greater  amount of third party technology into new cars; he mentioned Sync and Mytouch as technologies which Ford has licensed from third parties. Even in the traditional automobile business, he noted that intellectual property is very important: he described how the sale of Volvo was initially viewed as the transfer of “hard” assets and a brand, but it became clear during the negotiations that intellectual property relating to the car manufacturing was a critical element of the deal for the buyer.

The most interesting presentation was by Ruud Peters, the Chief Innovation Officer of Philips NV, who described that evolution of the integration of intellectual property into business at Philips over the last twelve years.  At the beginning,   intellectual property was viewed as a “defensive” asset, but intellectual property is now a key part of all business strategies developed at Philips.  His summary of the new attitude was:  “Business strategy without an IP strategy is not a business strategy”.

 

The use of the Android operating system continues to grow. Gartner recently reported that Android had become the leading operating smartphone operating system in the world in the first quarter of 2011. http://www.computerworld.com/s/article/9216848/Gartner_Android_and_Apple_win_big_globally_in_Q1. Android grew from 9.6% to 36% of the market in the last year. Its lead over smartphones running Symbian is now almost 10 million units per quarter. During the first quarter of 2011, manufacturers distributed 36.3 million smartphones running Android while only 27.6 million smartphones running Symbian were distributed. 

Yet Android continues to be a very complicated product from a licensing point of view http://lawandlifesiliconvalley.com/blog/?p=635.  Peter Vescuso of Black Duck and I worked to provide a summary of the issues in managing licenses in software development based on the Android operating system http://www.law.com/jsp/lawtechnologynews/PubArticleLTN.jsp?id=1202495469387 .  I have included a more detailed legal perspective http://www.law.com/jsp/lawtechnologynews/PubArticleLTN.jsp?id=1202495473435.

The recent Android Builder’s Summit in San Francisco demonstrated the breadth of products using Android and the dynamic nature of the operating system. In her keynote, Christy Wyatt of Motorola described the challenges of managing the launch of 700 products based on Android in countries around the world.  She was followed by Mark Charlebois (Director of Open Source Strategy at Qualcomm Innovation Center) and he predicted that their Android releases would grow from 241 in 2010 to more than 365 in 2011. 

Karim Yaghmour of Opersys provided a great overview of Android and its critical subsystems http://www.opersys.com/blog/abs-march2011. However, his presentation brought home the challenges of managing Android: he mentioned in passing that he was unhappy with the performance of the Android Toolbox, the component which Google substituted for BusyBox for Toolbox. He regularly substitutes BusyBox for Toolbox (one Android site had more than 25,000 downloads of BusyBox). BusyBox is described as follows;           

a software application that provides many standard Unix tools, much like the larger (but more capable) GNU Core Utilities. BusyBox is designed to be a small executable for use with the Linux kernel, which makes it ideal for use with embedded devices. It has been self-dubbed “The Swiss Army Knife of Embedded Linux”. 

According to Black Duck, Android Toolbox is a collection of 66 files, 52 are under the Apache 2.0 license and 14 are under BSD.  Both the Apache 2.0 and BSD licenses are very permissive. However, BusyBox is licensed under the GPLv2, a copyleft license,  which has very different and  much more significant obligations, particularly the obligation to make the source code available either with the object code or through a written promise. More importantly, the license to BusyBox is the most actively enforced license in open source. The Software Freedom Conservancy and the Software Freedom Law Center have filed at least seven lawsuits (with many other disputes settled with ligitation) to enforce the GPLv2 license on BusyBox. Last year, they won $90,000 in damages from Best Buy.  

Thus, a reasonable technical decision can dramatically change the obligations of the distributor. Since the GPLv2 is a “conditional” license, the failure to comply with these terms means that the license terminates automatically without a cure period. Thus, the distributor would be a copyright infringer.  Since products including Android are frequently mass market products, the consequences could be significant liability arising from millions of unlicensed units. This reality demonstrates once again the need for careful management of the use of Android and clear communication between the developers and the relevant counsel.

I have just returned from the Open Source Think Tank in Sonoma http://thinktank.olliancegroup.com/agenda_public.php. We had a great time and the discussion was vigorous! The last year has continued the expansion of open source use, confirmed recently by Laurie Wurster’s March 2011 article in the Harvard Business Review http://lawandlifesiliconvalley.com/blog/?p=619.  In particular, Android has been spectacularly successful and was a significant factor in Nokia’s recent failures in the handset market.  The new Nokia CEO, Stephen Elop, described Nokia as being on a “burning platform”  and identified Android as one of the major sources of their problems.

I provided my traditional Legal Update on Thursday (which you can see at http://www.docstoc.com/docs/76174077/Open-Source-Think-Tank-2011-Legal-Update).  The success of open source has had consequences: it has focused attention of rights holders on the industry and made some open source companies targets for legal action.  For example, Android’s success has been undercut by a tidal wave of litigation (with more than thirty eight lawsuits filed to date).  I believe that these challenges (and its modest existing patent portfolio) are the motive for Google’s decision to bid $900,000,000 to purchase Nortel’s patent portfolio. 

The ubiquity of the use of free and open source software has also resulted in many companies are demanding that their suppliers provide information on their use of free and open source software and how they comply with their licenses.  Yet as recently noted by Laurie Wurster in her Harvard Business Review article, many companies have yet to adopt a formal approach to managing their use of free and open source software http://lawandlifesiliconvalley.com/blog/?p=619.  At the request of our attendees, we addressed this management issue in a separate workshop.

The most interesting discussions were about the effect of cloud computing on open source.  It was the subject of two panels and a brainstorming session.  Nine out of ten groups in the brainstorming session believed that cloud computing was good for open source. However, attendees generally agreed that cloud computing undercuts two of the traditional advantages of open source: (1) low cost and (2) ease of use.  Yet the flexibility of open source development techniques continue to provide significant advantages. 

The attendees also agreed that open source companies (like all software companies) need to review their business models as customers in the cloud begin to expect “pay as you go” pricing. The tools in the cloud also permit very granular information on the use and interest in various features of a software program and the contributors who have provided those features: this capability may permit open source projects and companies to reward contributors directly for the success of their contributions.

The workshop led by AOL provided a great opportunity to work together to apply our cumulative experience in open source to real world problems. The conference works under Chatham House rules so you will need to see the results of those discussion.

As in the past, we included plenty of time to socialize with the other attendees. First Republic Bank put on a great cocktail party on Thursday, including tasting Araujo cabernet in their tasting (one of the cult cabs).  The shift in venue from Napa to Sonoma enabled us to experience a new region of the wine country:  Friday afternoon included tours at Chateau St Jean and Ledson (although Andrew somehow found wineries in Sonoma, the heart of Pinot Noir country, which focused on cabernet sauvignon).  A hardier group went for a bike ride, but they split into the “wine group” who tasted and rode 12 miles;  the hard core cyclists led by Peter Vescuso of Black Duck rode 30 miles.  I think that the combination of topics and attendees made this Think Tank the best one to date.

We are already planning for next year, so please provide us with your suggetsions. As in the past, Andrew is working on a white paper which will provide more detail about our discussions.  I look forward to the white paper to continue the dialog!

Recently Laurie Wurster of Gartner wrote an article in the Harvard Business Review which confirms that the free and open source software (“FOSS”) has reached a “tipping point” in adoption by companies which confirms a trend she noted in her 2008 report (Accenture and IDG have reached similar conclusions). http://blogs.hbr.org/cs/2011/03/open_source_software_hits_a_st.html

Yet she notes that this increase in adoption has not been matched by implementing processes to manage such use. She raised the same issue in her 2008 report. http://lawandlifesiliconvalley.com/blog/?p=107. In the Harvard Business Review in March 2011, she states: 

Even as our survey painted a rosy picture of the future of enterprise use of open source software, it also surfaced a concern. Most organizations, it revealed, have not established a policy framework to guide decision-making on the use of open source software. A proper framework would outline types of licenses acceptable to the organization, guidelines pertaining to intellectual property, regulations governing contributions to external projects, and an approved vendor/project list. Just a third of respondents claimed their organizations have anything like this kind of policy structure; the rest rely on ad hoc or informal processes

In fact, this problem is sufficiently important that we are having a specific breakout session on FOSS management at the Open Source Think Tank this week. http://lawandlifesiliconvalley.com/blog/?p=600.

I am looking forward to the upcoming Open Source Think Tank 2011 which we are co hosting with Olliance Group/Black Duck. Andrew Aitken has prepared a great agenda and we are going to have a case study by AOL which they describes as follows: AOL is planning two related open source initiatives: employing open source technologies and practices to improve the innovation and efficiency of their developers and releasing elements of their software portfolio as open source to enrich their ability to deliver content and encourage community contributions. 

This year the Open Source Think Tank will be particularly interesting because of the dramatic expansion in the use and importance of Freedom and Open Source Software (”FOSS”).  We will be discussing the recent completion of many important industry initiatives to make FOSS easier to use: Project Harmony (contributor agreement), SPDX (assisting management of the supply chain by providing a common vocabulary for describing licenses), new Mozilla license and Open Web Foundation (contributor agreements).

The Open Source Think Tank is unique because of the breadth and seniority of those who attend, from CEOs such as Larry Augustin (SugarCRM) and Tim Yeaton (Black Duck) to counsel such as John Noerenberg (Chief IP Counsel, Qualcomm) and Marissa Aufox (Compliance Counsel, Go Daddy Group) to CTOs such as Shawn Douglass (EMC) and Paul Daugherty (Chief Technology Architect, Accenture).

We will also be discussing the recent government initiatives which could dramatically increase the market for FOSS.  I have mentioned these government initiatives in an earlier post. http://lawandlifesiliconvalley.com/blog/?p=607.

We have a few more spaces left for the Open Source Think Tank, but if you are interested you will have to move quickly. http://thinktank.olliancegroup.com/

This year has seen an increasing focus on the use by free and open source software (“FOSS”) by governments with recent announcements by the UK, the Australian Federal Government and NASA.  FOSS projects and companies need to be aware of these efforts because of the scope of the opportunity to transform government and provide less expensive software infrastructure to government. Governments are also a very large market for software. Yet governments continue to be hampered by their habits of using proprietary software as demonstrated by the recent decision by an administrative court in Lille, France. http://lawandlifesiliconvalley.com/blog/?p=584 .

The UK Government recently provided a very broad endorsement of FOSS and open standards in UK government procurement. The UK government described its new policy for the next 24 months recently:  http://www.cabinetoffice.gov.uk/resource-library/uk-government-ict-strategy-resources.  The approach to FOSS is described below:

To assist with the deployment of agile solutions using open source technology, the Government will establish an Open Source Implementation Group, a System Integrator Forum and an Open Source Advisory Panel. These will aim to educate, promote and facilitate the technical and cultural change needed to increase the use of open source across government.

This encouragement is similar to the approach of the Department of Defense in the United States several years ago. http://lawandlifesiliconvalley.com/blog/?p=314.  The UK government describes its goals in broader terms as follows:

The Government is taking a different approach to deliver this strategy, characterised by a strong centre and continued commitment to greater transparency through regular and open reporting. The approach includes:

mandatory open standards;

spending controls to ensure that new ICT solutions comply with strategy objectives;

transparency to ensure the continued comparison of common ICT services so that government gets the best price;

increased standardisation and modularisation of business processes and supporting technologies to create a platform from which government can deliver new models of open and innovative public services;

a new, strengthened governance structure; and

greater engagement with departments and suppliers to remove cultural as well as technical barriers.

The FSF Europe provides additional information on the approach in the UK.  http://fsfe.org/uk/mapping-uk.en.html

This UK policy announcement follows a similar one by the Australian Government earlier this year which requires “covered procurements”, those procurements for over $80,000 AUS must comply with the Open Source Policy in procurement.  http://www.finance.gov.au/e-government/infrastructure/open-source-software.html.  The principles are summarized below:

Principle 1:  Australian Government ICT procurement processes must actively and fairly consider all types of available software.

Australian Government agencies must actively and fairly consider all types of available software (including but not limited to open source software and proprietary software) through their ICT procurement processes.  It is recognised there may be areas where open source software is not yet available for consideration.  Procurement decisions must be made based on ‘value for money’.  Procurement decisions should take into account whole-of-life costs, capability, security, scalability, transferability, support and manageability requirements. 

For a covered procurement (over $80K), agencies are required to include in their procurement plan that open source software will be considered equally alongside proprietary software. Agencies will be required to insert a statement into any Request for Tender that they will consider open source software equally alongside proprietary software.  Tender responses will be evaluated under the normal requirements of the Commonwealth Procurement Guidelines (CPGs).  For a non-covered procurement (below $80K), agencies are required to document all key decisions, as required by the CPGs.  This includes how they considered open source software suppliers when selecting suppliers to respond to the Select Tender or Request for Quotation.

Principle 2: Suppliers must consider all types of available software when dealing with Australian Government agencies.

Australian Government agencies will require suppliers to consider all types of available software (including but not limited to open source software and proprietary software) when responding to agencies’ procurement requests. 

Agencies are required to insert this requirement into their tender documentation.  Suppliers will need to provide justification outlining their consideration and/or exclusion of open source software in their response to the tender.  Agencies will determine compliance with this requirement when assessing tender responses.

Principle 3:  Australian Government agencies will actively participate in open source software communities and contribute back where appropriate.

The Australian Government, through AGIMO, will actively seek to keep up-to-date with international best practice in the open source software arena, through engaging with other countries and organisations. Australian Government agencies should also actively participate in open source software communities and contribute back where appropriate.

In the United States, NASA recently held an Open Source Summit where it described how it is using open source and how it intends to use it in the future. http://www.nasa.gov/open/source/live.html. Although I was not able to attend, the presentation by David Wheeler from the Institute of Defense Analysis of the Department of Defense was very interesting, both for his criticism for NASA’s approach to using FOSS as well as his discussion of how FOSS fits into the regime of government contracting. http://www.slideshare.net/ckleclerc/2011-nasa-open-source-summit-david-wheeler. The Federal Government has an elaborate set of procurement regulations (which differ between different agencies and which are very different from traditional “commercial arrangements” and set up a “unique” infrastructure for software licenses.  Wheeler’s presentation describes how FOSS can be used in this system. I don’t agree with Wheeler’s complaints about the use of “intellectual property” but his summary can be very useful for persons trying to understand the fit between government regulations and FOSS.

Governments offer an enormous potential market for FOSS and the community needs to moniter government decisions on procurement, both at the policy level and on decisions about individual procurements.

Recently, Edward Naughton, a lawyer with Brown Rudnick, raised concerns about Google’s potential violation of the license for the Linux kernel (the General Public License Version 2, “GPLv2”) in developing the Android operating system: 

“I have serious doubts that Google’s approach to the Bionic Library works under U.S. copyright law. At a minimum, Google has taken a significant gamble. While that may be fine for Google, because it knows about and understands the risks, many Android developers and device manufacturers are taking that same risk unknowingly. If Google is wrong, the repercussions are significant for the Android ecosystem: the manufacturers and developers working with Android would be incorporating GPLv2-licensed code into applications and components and taking on the copyleft obligations of that license”

However, his statements are based on a fundamentally flawed analysis of the application of the GPLv2 to Linux: he ignores the modification to GPLv2 found in the  “Note” (see below) which fundamentally limits the scope of “derived works” under the GPLv2 as it applies to Linux (as a matter of transparency, neither I nor my law firm, DLA Piper, represents Google and this opinion is my own and may not reflect the views of DLA Piper or its clients). The Note is found at the top of the GPLv2 on the license page of the website of the Linux kernel: 

NOTE! This copyright does *not* cover user programs that use kernel  services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of “derived work”.  Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the linux kernel) is copyrighted by me and others who actually wrote it. http://www.kernel.org/pub/linux/kernel/COPYING 

This flawed analysis is coupled with a basic misunderstanding of the intentions of Linus Torvalds and contributors to Linux:  Naughton suggests that Linus and other contributors are interested in having GPLv2 apply to “user space” and that the common program used with Linux kernel files, glibc, enjoys a special informal blessing which permits its use without extending the effect of the GPLv2 to programs in  “user space”.   In fact, the reverse is true.  Linus and the contributors to Linux want to avoid the application of GPLv2 to programs in “user space” as a fundamental basis of the development of Linux.  This intention has been clear since the initial development of Linux as evidenced by Linus Torvald’s adoption of the “clarification” to the GPLv2 in the form of the Note.

Naughton argues that the GPLv2 requires that any program which reproduces and distributes Google’s “cleaned” Linux header files is subject to GPLv2.  It is undisputable that the unmodified GPLv2 requires that programs that are “based on” the GPLv2 licensed software must be distributed under the GPLv2.  However, Naughton ignores the critical difference about the scope of the GPLv2 as modified by the Note. The effect of the Note on this issue is substantial. 

Naughton mentions this “Note” but only in passing when discussing glibc:

The preferred option in the industry is to build the application against a different set of kernel header files that accompany the GNU C library (“glibc”). The headers in glibc are different from the “raw” header files, because they’ve been created, with the apparent blessing of the Linux kernel maintainers, from a subset of the raw files by means of a standard process. Within the industry, these header files are referred to as “sanitized” header files. Linus Torvalds and the kernel maintainers have publicly declared that applications can use these sanitized header files without becoming subject to GPLv2 because these sanitized header files are “normal system calls” http://lkml.org/lkml/2003/12/4/239.

However, the creation of the “sanitized” header files are not subject to an informal “blessing” with kernel maintainers (in fact, they don’t have the authority to provide such a blessing which can only be done by the copyright owners of the contributions to Linux): the Note, which is part of the legal framework adopted by Linus and agreed to by all contributors, limits the scope of works “based on” under the GPLv2 for the kernel.  In fact, Naughton’s description of the Bionic’s Library modification of the Linux header files is very similar to the manner in which he describes the operation of glibc. Thus, it is difficult to understand the difference between the analysis of the scope of the modified GPLv2 with glibc and with the Bionic program. The key issue is whether the interaction of the Bionic Library with the kernel uses  “normal system calls” and, thus, it is not a “derived work”.  It appears that the Bionic program uses normal system calls. These facts explain why none of the Linux committers (a notably outspoken group) has chosen to challenge the use of the Bionic program. 

Naughton makes much of the expressed desire of certain Google programmers to ensure that Android “keep GPL out of user space”.  Yet this goal is fundamental to the Linux community. Linus Torvalds stated: “User programs are _clearly_ not derived works of the kernel, and as such whatever the kernel license is just doesn’t matter.”  http://lkml.org/lkml/2003/12/3/228.  In fact, Linus Torvalds recently stated about Naughton’s article that “It seems totally bogus,” Torvalds told IT World’s Brian Proffitt. “We’ve always made it very clear that the kernel system call interfaces do not in any way result in a derived work as per the GPL.” http://www.networkworld.com/community/node/72428. 

Nonetheless,  his concluding paragraph focuses on the risks arising under copyright law, a focus which is misplaced: the critical issue, is whether the scope of the modified GPLv2 applied to Linux rather than US copyright law. In fact, his risk of application of the copyleft provisions of the GPLv2 only arises if (i) the Linux header files (as “cleaned” by the Google development scripts) are copyrightable and (ii) the Bionic software reproducing and distributing are “based on” the Linux kernel and, thus, are not exempted by the limitations on “derived works” in the Note.  The “copyright” part of his analysis also has flaws although the result is considerably less clear for this analysis than the analysis of the interpretation of the modified GPLv2 (and we may not have all of the relevant facts). For example, one factual error in his discussion is his reference to the Linux header files as part of an “Application Programming Interface”: these files are part of an Application Binary Interface”.  It is not clear whether this programming difference has legal consequences, but it is critical for this type of analysis to ensure that the underlying facts are correct.  

Even the copyright argument has problems:  the copyrightability of the Linux header files is subject to serious doubt. Copyright law protects “works of authorship fixed in a tangible medium of expression.”  However, software programs are functional (unlike books and movies) and the scope of protection is limited.  The most widely used legal test for determining copyright infringement in software programs expressly limits the scope of protection for certain parts of software program (the “filtration” step):  

Professor Nimmer points out that “in many instances it is virtually impossible to write a program to perform particular functions in a specific computing environment without employing standard techniques.” 3 Nimmer § 13.03[F][3], at 13-65. This is a result of the fact that a programmer’s freedom of design choice is often circumscribed by extrinsic considerations such as (1) the mechanical specifications of the computer on which a particular program 710*710 is intended to run; (2) compatibility requirements of other programs with which a program is designed to operate in conjunction; (3) computer manufacturers’ design standards; (4) demands of the industry being serviced; and (5) widely accepted programming practices within the computer industry. Id. at 13-66-71.  http://scholar.google.com/scholar_case?case=6976925648486076739.

Steven J. Vaughan-Nichols noted recently that he interviewed Eric Raymond, then president of the Open Source Initiative, during the SCO litigation and “Eric told him that there was a “reason why Unix and Linux’s header files looked the same: “Do you know that there is not one bit of executable code in those files? They’re pretty much all macros and declarations forced by POSIX and other technical standards.”   http://www.zdnet.com/blog/open-source/does-googles-android-violate-linuxs-copyright/8497.  Linus Torvald in a statement on March 22, 2011 made the point even more strongly, calling Naughton’s claims “bogus”.  These statements are helpful in analyzing the copyrightability of the Linux header files, but only a court can provide a final answer. However, it is interesting that all of the cases cited by Naughton relating to “interfaces” found that the interfaces are not copyrightable.  

This dispute reflects the challenges of the analysis of open source legal issues: the law in this area is uncertain and the analysis is very fact dependent.  However, the statement that the law is uncertain regarding software is not unusual: this uncertainty has existed from the date that Congress debated whether to apply copyright to software under the Copyright Act of 1976 (they set up a special group to review the issue among others after the adoption of the 1976 Act, the National Commission on New Technological Uses of Copyright Works)   Although the violation of the GPLv2 does not appear to be a problem for Android, Android has more than its share of lawsuits on both patent and copyright claims.  Anyone who is using Android in their products needs to ensure that they understand these risks and monitor the progress of these suits.

 

My French partner, Sandrine Rambaud, brought to my attention a decision dated December 29, 2010, that leveled the playing field for open source vendors: the Administrative Court of Lille, France cancelled a public procurement procedure because the procedure excluded the possibility of proposing open source software in bid responses. Instead, the municipalities that put out the bid expressly required  bidders to propose an Oracle database and Business Objects environments for the generation of reports. 

The French company, Nexedi, which offers open source solutions, alleged that the tendering of the public procurement under such terms does not comply with the principles of equal treatment and non-discrimination, and in particular with Article 6 of the French Public Procurement Code. Article 6 provides that technical specifications included in a public bid cannot include the reference to a trademark or a patent, as such reference could favor or exclude some bidders or products. Such reference is only possible in very specific cases. 

Nexedi challenged the validity of such procedure before the Administrative Court of Lille, which ruled to cancel the procedure. This decision is great news for open source companies and open procurement!