decoration decoration

When you want to know more...
For layout only
Site Map
About Groklaw
Legal Research
ApplevSamsung p.2
Cast: Lawyers
Comes v. MS
Gordon v MS
IV v. Google
Legal Docs
MS Litigations
News Picks
Novell v. MS
Novell-MS Deal
OOXML Appeals
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v Novell
Sean Daly
Software Patents
Switch to Linux
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.

To read comments to this article, go here
Some Good News from New Zealand - Updated
Monday, March 13 2006 @ 06:09 PM EST

Remember the Guide to Legal Issues in Using Open Source Software, commissed by New Zealand's State Services Commission, which we researched and discovered was written by a law firm with a connection to Microsoft? I called it New Zealand's "Get the Facts" style report.

I just heard from Peter Morgan, who tells me he wrote to the SSC, and he's gotten a very nice email back with some good news. It seems quite a few people wrote to them, actually, pointing out various inaccuracies, and they are planning to revise the document as a result. ComputerWorld has some reactions to the report in an article titled Proprietary software also has legal hurdles, including some words from the author of the New Zealand report:

“We didn’t use the word ‘viral’,” said John Elwood, author of the New Zealand report, at Govis. “That was one term we deliberately avoided. ‘Infection’ was just the most convenient shorthand way of describing the way the terms of an open source licence could shift to a derived product which might include some commercial code that the developer wanted to keep confidential. No negative implication was intended.”

Right. Nothing negative in that FUD. I get it. He meant "infectious" in a good sense, like an infectious smile. Not.

Peter has placed the email here, and here's the meat of it:

The State Services Commission has provided consistent advice since 2003 encouraging government agencies to consider open source software where appropriate. The SSC stands by this advice.

The Legal Issues document was only ever intended to address the legal risks, not the wider benefits, of using open source software. The guide did not contrast open source risks with the risks of using commercial software, as these risks are well understood. The document's focus on open source risk, in the narrow and specific circumstances in which that risk may arise, should not give the impression that SSC has changed its commitment to the New Zealand government using open source software. On the contrary, SSC believes the guide will help government agencies use open source software with confidence.

However, as a result of feedback from the New Zealand and international open source communities, SSC will review the document and - with input from members of the New Zealand open source community - issue in the very near future a revised version that more clearly positions the document in its correct context. We trust that this revised version will address the bulk of the feedback received.

As you can see, it's true that New Zealand has had a positive view of Open Source since at least 2003. How that particular law firm was chosen, wolf-in-the-hen-house, to write a report on Open Source legal issues is unknown but hilarious. Anyway, it didn't work in the end. When the revised document is finished, it will be posted, the email says, on New Zealand's E-Government website.

That is the thing about FUD. Once again we see, it only works in the dark.


I just heard from Peter Harrison, the President of New Zealand Open Source Society, who says I may share with you the letter [PDF] they sent to the SSC regarding the report. The PDF includes the report, but here is the letter, which will form the basis of discussions:


New Zealand Open Source Society
C/:Unit A6, 400 Rosedale Road
Albany 13 March, 2006,

Edwin Bruce
State Services Commission
PO Box 329

Dear Sir,

The New Zealand Open Source Society (NZOSS) would like to take the opportunity to offer comment on the recently published guide entitled “Guide to Legal Issues in Using Open Source Software”. Our society is a voluntary membership organisation with over 200 members drawn from around New Zealand, including many of the leading figures of the Open Source and Free Software communities.

We believe that the current policy on the use of Open Source Software by government departments is positive and we are eager to support the State Services Commission in addressing any issues that have the potential to hinder the uptake of Open Source Software.

However we believe that the Guide to Legal Issues could be a more helpful and accurate portrayal of the situation and the legal implications that would be faced by departments who are considering Open Source Software. The report does contain helpful information, and is a starting point to addressing implications although we have several concerns that we believe need to be addressed. We outline our concerns in more detail below.

In this document we will address the following issues with the Report's recommendations:

1. Prohibition of Use
1.1.This recommendation is unsupported by evidence.

2. Warranties and indemnities.
2.1.This advice is directed solely at Open Source providers but should apply to all.
2.2.It is easier for local software companies to offer to warrant and support FOSS tools and products.

3. Incorrect Factual Information
Inaccuracies when comparing Proprietary and Open Source Software

3.1. Increased risk of faults
Risk of faults is not exclusive to Open Source Software

3.2.Exposure to intellectual property claims
There is no more exposure to IP claims with Open Source Software than Proprietary software.

3.3.Obligation to distribute due to “Network Clause”
No such “Network clause” exists

4. No comparison to commercial risks to provide context
4.1.The report fails to provide adequate comparison between Open Source and Proprietary Software

5. Emotive Language
5.1.A reader of the document who was previously unfamiliar with Open Source Software would be left with a unduly negative impression of the implications associated with its use.
5.2.We note that the use of this terminology is explained by a reference to a paper by Greg Vetter 1, however we do not feel that this is an adequate justification.
5.3.The word “infect” it is not an accurate portrayal of the effects of Open Source licenses such the GPL.
5.4.We believe that there are other terms that can more accurately portray the effects of Open Source licenses without attaching overt emotional connotations.

1. Prohibition of Use. “As its standard position, all Development Agreements should prohibit the use of any open source code in the supplied software."

We believe the recommendation is unwarranted and unsupported by the evidence cited.

1.1.This recommendation should at the very least address the appropriate risks. The clause should only apply to Open Source Software that is licensed under the GPL or other license in which there is an obligation to release the source code. The clause should also only be added when the project will be released beyond Government. Even with GPL software there is no obligation to release source code to anyone except those you release binaries to.

1.2.Since the Government is not in the business of writing software for profit the potential limitations of GPL licensed code will only affect a very small percentage of Government software projects, and will have no impact on software released under one of the many nonGPL Open Source licenses. To apply a general clause which prohibits Open Source in order to mitigate a risk that applies to a small percentage of projects is not warranted.

1.3.The remaining risk faced in the event of distribution of GPL code inside a confidential project is still very low. Previous GPL enforcement lawsuits taken by The FSF (Free Software Foundation) and others have made a point of being cooperative with GPL violators. The usual remedies sought are either complying with the GPL and releasing source code, or removing the GPL source code from the project. There is very little risk of large fines or punitive enforcement actions 2.

1.4.It is therefore difficult, given the low risk of severe consequences for unintentional GPL violations, to understand why there should be a blanket ban on use of all Open Source in external contracts. Clauses which exclude Open Source Software would unquestionably be included with Request for Information and Request for Tender documents as currently occurs on the GETS procurement system. Companies reading the standard contract will believe that the standard contract is not negotiable, or at the very least will be unwilling to ask for this point to be negotiated. They will instead simply not apply for those contracts. The likely effects of this clause being included in standard contracts would be to restrict the suppliers of government contracts to nonOpen Source companies, in direct opposition to the stated aims of the State Services Commission.

2.Warranties and indemnities

"The warranties and indemnities that an agency should seek from external suppliers, where appropriate and available, include the following: A warranty that the software conforms to the supplier's specification and the agency's requirements. Suppliers will generally be unwilling to provide a more openended "fitness for purpose" warranty. A warranty that the agency's use of the software in accordance with the agreement will not breach the intellectual property rights of any third party. An indemnity from any third party's claim that its intellectual property rights have been infringed by the agency using the software in accordance with the agreement."

2.1.We agree that when procuring software that the purchasing entity seeks warranties and indemnities where appropriate. However, this advice should apply to all software providers, not just Open Source providers. This creates a secondary issue around indemnity; few if any New Zealand companies have sufficient capital to defend themselves against patent infringement claims. Since it is impossible in practice to ensure a piece of software does not infringe on any patents it means that all New Zealand software companies are in effect risking their business every time they indemnify. This is an issue for all software producers in New Zealand, not only Open Source developers. It is a failure of the patent system in New Zealand and world wide rather than an issue with Open Source Software.

2.2. It is easier for local software companies to offer to warrant and support FOSS tools and products. It is easier for us to build up an in depth understanding of these products and, as we have access to the code and documentation, to warrant that we will fix any defects. This is a major benefit to using FOSS.

3. Incorrect factual information.

We do not believe that the guide accurately deals with the relationship between Open Source and proprietary software. The second introductory paragraph states that the guide is intended to cover a “number of legal risks not posed by proprietary or commercial software”. Unfortunately the guide continues on to identify risks which are not unique to Open Source Software at all.

3.1.Increased risk of faults: The guide suggests that Open Source Software presents unique legal risk to departments and is susceptible to unique fault rates not present in proprietary software. Faults in software are not unique to Open Source Software 3. The guide does not provide any evidence to substantiate this claim, and the only studies the NZOSS is aware of suggest that Open Source Software is as good, if not better than proprietary software in terms of software bugs 4. Even assuming that some Open Source Software did have a higher fault rate than the equivalent proprietary option we do not understand how this is a legal risk.

3.2 Exposure to intellectual property claims: The guide suggests that users of Open Source Software are at unique risk of intellectual property infringement claims. The guide assumes that this is due to the lack of warranty protection available in licenses from Open Source vendors compared with the protection typically offered by proprietary licenses. We do not believe this is an accurate portrayal of the risks involved. Large Open Source providers such as Novell and IBM offer intellectual protection to their Open Source customers 5. A large number of proprietary software licenses do not offer intellectual property protection 6. In addition there are examples of patent infringement action directly affecting proprietary software users 7, while there have been no successful actions taken against Open Source projects 8.

3.3. Obligation to distribute due to “Network Clause”: The guide suggests that there are common Open Source licenses which have “Network Clauses” which will form an obligation for a organisation to distribute source code to users who use an application over the Internet. This would mean that software projects to provide services to citizens would form an obligation on the government organisation to distribute the source code to those citizens. It also suggests that there may be a “Network Clause” in the next version of the GPL. No known current Open Source license has a "Network Clause" as stated. It's currently speculation that the next version of the GPL will have an optional clause for use in remote APIs, not web sites. The concept that software licensing could force an immediate disclosure of confidential information is unheard of in the industry, and is not backed by any legal precedent that the NZOSS is aware of.

4. No comparison to commercial risks to provide context.

4.1.One of the failures of the document was to not provide context of the risks in comparison to closed source proprietary software. For example, proprietary software customers risk imprisonment and large fines in the event they break the copying and distribution infringement provisions of the Copyright Act. These penalties can occur even in the event the violation is not intentional. Government Departments may face action from proprietary vendors if they violate licenses which may include substantial financial penalties.

4.2.Using Open Source by comparison presents a much smaller scope for license violation, limited only to a specific licence, the GPL, and even then is limited to a rare set of circumstances. Violation of proprietary software licenses by comparison can result in severe penalties. By concentrating on a very specific and rare risk of GPL violation the document fails to provide that information in context: that all of the risks associated with proprietary licenses by in large do not exist for Open Source software at all.

5. Emotive Language

We believe that the language used in the document is not conducive to objective decision making. Our concern is that a reader of the document who was previously unfamiliar with Open Source Software will be left with a unduly negative impression of the legal implications associated with its use.

5.1.Our first area of concern is the language used to describe the effects of Open Source Software when it is modified or integrated with other software (either proprietary or Open Source). In particular the word “infect” 9 and the associated vocabulary of “quarantine” 10 are not appropriate choices for a document intending to offer unbiased advice to the reader.

5.2.We note that the use of this terminology is explained by a reference to a paper by Greg Vetter 11, however we do not feel that this is an adequate justification. The Vetter paper is critical of the “infectious” nature of some Open Source licenses and it is not entirely surprising that the author has chosen a word with emotive connotations to support this conclusion. The paper attempts to justify the choice of “infectious” on the basis that there are good infections such as that of “infectious laughter”. We do not agree with this premise and believe that the average reader of either the Vetter paper or the Guide would consider the negative connotations of the word “infect” such as human disease or computer viruses long before laughter came to mind. The term “quarantine” suggests the intended context is that of a disease.

5.3.The word “infect” it is not an accurate portrayal of the effects of Open Source licenses such the GPL. Infectious agents (such as viruses) are capable of replicating and infecting a host without the intervention of the host itself. By contrast, a piece of software licensed under the GPL requires human intervention in that software be deliberately copied. Furthermore, the obligation to distribute source code is limited to a few special conditions such as redistribution of GPL binaries. If you replace GPL components in software development with inhouse, commercially licensed, BSD licensed, or even in many cases, LGPLlicensed components then the obligation no longer exists for subsequently distributed works. Infectious agents are also associated strongly with the negative effects on the host. This is again in contrast to Open Source Software which are always beneficial to the host application in that it provides additional functionality.

5.4.We believe that there are other terms that can more accurately portray the effects of Open Source licenses without attaching overt emotional connotations. For example the Australian Government Information Management office uses the term “share and share alike” in its “Guide to Open Source Software for Australian Government Agencies” 12. A widely referenced paper by Larry Rosen seeks to address the use of the term 'infectious' suggesting instead the term 'inherits' to describe the effects of Open Source licenses 13.

In Summary:

To mitigate the issues the NZOSS has with the document we respectfully submit these courses of action

1. The Prohibition of use should be reworded in a less empirical fashion that better reflects the SSC's support for Open Source Software
2. The document should state that Warranties for fitness of purpose should be obtained from all Software suppliers no matter whether proprietary or Open Source.
3. Remove those factually incorrect statements in the document that specifically assign risk to Open Source Software where those same risk are shared by Proprietary. Also define the level of real risk as much as is possible.
4. Produce a similar document that makes fair comparisons with proprietary software.
5. Reword the the document with less emotive language more in the style of the Australian model using “share and share alike” and/or “inheritable” rather than infectious.

In conclusion,

The NZOSS has consulted with its membership in order to present a unified reply to the document and this document is the result of that collaboration.

NZOSS agrees that integrating Open Source Software into a typical business IT environment containing proprietary software will present legal implications and we agree that these issues need addressing.

The NZOSS sees this response as the beginning of an open ended dialogue between the SSC and the NZOSS. In the spirit of collaboration that is the hallmark of Open Source we invite the State Services Commission to engage in a constructive dialogue with the NZOSS to address these concerns now and in the future and so improve the guide so that it can be a useful and valuable resource to the departments served by the State Services Commission.

The NZOSS would like to affirm our support of the stated position of the State Services Commission towards the use of Open Source software in Government departments. We also remain willing to assist the State Services Commission in any way possible in removing further barriers to Open Source adoption.

We look forward to working with you further to smooth the way for greater adoption of Open Source technologies in Government Enterprises.


Matt Brown,
Graham Lauder,
David Lane,
Peter Harrison, President

12 (Accessed 8 Mar 2006)
13 (Accessed 8 Mar 2006)

  View Printable Version

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )