On 20 December 2007, the Dutch Ministry of Economic Affairs published (pdf) an English translation of its 17 September 2007 plan entitled “The Netherlands Open in Connection” announcing the steps that the Dutch government will take in the coming years to further the adoption of open standards and open source for software in use in the Dutch public sector.

In this month’s post, TLC will highlight some key points from the plan, but not before adding a little background on its history.

History: 2002 Lower House Motion on Open Standards and Open Source
The plan currently before us is the follow-up from the Ministry of Economic Affairs to a motion adopted by the lower house of the Dutch parliament in November 2002, requesting that the government (the executive) make (paraphrased) a maximum effort to ameliorate the situation that, since the supply-side of software is highly concentrated, sub-optimal use is made of the potential benefits of software to society and that high switching costs exist; and furthermore requesting that the government ensure that by 2006 all software in use in the public sector complies with open standards; and finally requesting that the government pro-actively stimulate the dissemination of open source software in the public sector, and to this end formulate concrete and ambitious goals.

The 2006 deadline from the motion not having been met, last summer the (new) government was prompted by a lower house committee to formulate steps to further the motion adopted, which resulted in the plan now before us. Most importantly, the plan contains obligations for the public sector to, going forward, use software that supports open standards. In addition, the plan contains the requirement that government bodies formulate a strategy for the adoption of open source software.

Part 1, Open Standards: “Comply-or-explain and commit”
Pursuant to the plan, the Dutch government will promote the use of open standards for use within the public sector. From the report:

“The Cabinet intends to encourage the use of open standards within the public and semi-public sector. The key focus here is: use open standards, or come up with a very good reason why this is not possible, and indicate when open standards will indeed be implemented. This is the principle of ‘comply or explain, and commit’. Through this the use of open standards will be given a firm foundation.”

What is, and what is not, an open standard is often a point of debate. Perhaps for this reason, for purposes of furthering the goals of the Dutch government, a body of it will:

“publish a basic list of open standards (checklist) in January 2008 for the benefit of citizens, businesses and government bodies. This list will then be maintained and further supplemented.”

Those who have in one capacity or another dealt with standard setting bodies may welcome this particular part of the plan.

Further to furthering open standards in general, one standard in particular is supported, whereas government bodies will be required to support the ISO standard ODF by 2008, in advance of switching to ODF altogether in 2013:

“Central Government Departments will from April 2008 support ODF alongside existing file formats for reading, writing and exchange of documents.”

(See also Brenno de Winter here on Macworld, via Slashdot.)

Part 2, Open Source: Preferred When Equally Suitable
Further to concrete goals of furthering the use of open standards within Dutch government operations, the 2007 plan also mentions a number of actions to be taken as regards open source software. More concretely, the plan dictates that:

“All ministries will have developed an implementation strategy by January 2009 for tendering and purchase and the use of open source software – by June 2008 more than half of the ministries.”

And, part of the reason for doing so is that:

“By using more open source software itself, the Dutch government can stimulate activity in the field of open source software. This provides social and economic benefits.”

These are possibly the more important parts of the 2007 report from the Dutch government on the adaptation of open standards and open source. TLC will report on its progress. In the meantime, I would like to invite you to the report (pdf) itself.

(And, off-topic: many thanks again to Arnoud Engelfriet for guest blogging last month. Yay!)

‡‡ [This is a post from Technology Law Culture: http://tlc.oosterbaan.net/. Olivier Oosterbaan, IT and media lawyer in Rotterdam, the Netherlands, maintains this blog.]

(Picture: Dutch Minister for Foreign Trade Mr. Van Heemskerk on the phone, used under permission.)

An extra post on Technology Law Culture (Netherlands!) this Sunday, on the legal workshop IP, Software Patents and Copyright Law: Avoiding the Legal Pitfalls of Open Source, held in Amsterdam Thursday, 9 November 2006. The format was a free-form panel discussion, without prepared presentations or slides from the panelists. Instead, Larry Rosen, of the U.S. law firm Rosenlaw & Einschlag, of OSI fame, and the person who wrote the book on open source licensing, moderated all three panels, with the audience contributing questions and answers as well. I’ll try and catch some of the comments below. Errors are all mine -^_^-.

Copyright and Derivative Work Analysis

Larry Rosen, David Rickerby of the U.S. law firm Choate, Dr. Till Jaeger of JBB Law in Germany and one of the driving forces behind the Institut für Rechtsfragen der Freien und Open Source Software, Walter van Holst of Dutch IT consultancy firm Mitopics, and Eric Tjong Tjin Tai of the Dutch law firm of Pels Rijcken discussed what constitutes a derivative work, and why and whether we should care about this question.

On this, David Rickerby noted that the GPL is brilliantly ambiguous and allows different projects to flavor it differently. According to Dr. Till Jaeger, since software works together, it is important to look at this question whereas you have to deal with copyleft and incompatible licenses. Also, while you have to keep in mind that it is ultimately for the courts to decide what a derivative work is (see Dan Ravicher on how the U.S. courts do this here), you can look at the interpretation of the steward of the license (see Laura Majerus, in connection with the Progress v MySQL case, discuss on how the FSF does that for the GPL here) and, perhaps more importantly, at how the copyright holder looks at it. (See for example, Linus Torvalds in relation to Linux and linking here.) In the end, after all, it is the copyright holder who will or will not sue.

How do you deal with this in practice? David Rickerby gave the example of a PVR player, using the Linux kernel as the embedded OS, with a proprietary (differentiating and value-adding) interface on top, whereby access to the underlying UI of Linux is locked out. Does this create a derivative work, in the sense that the manufacturer would be required to release the source to its proprietary interface? According to Eric Tjong Tjin Tai, not releasing it should be o.k., since, although you might create a derivative work under the law since it’s a different embodiment, you could argue that you do not create a derivative work in the technical sense, whereas you use the kernel as it was intended. (See in that sense also Arnoud Engelfriet here on how to deal with this issue of mixed source development for embedded code.)

On how to move forward with this issue, Eric Tjong Tjin Tai noted that with ambiguous terms in a license, you might end up poisoning your own wells, as future contributors shy away from either using such a license, or contributing to a project that uses such a license. Dr. Till Jaeger added that you should not only look at the language of the license when interpreting it, but also at what might have been the intent of the persons applying it.

According to Eric Tjong Tjin Tai, it makes sense to use a definition, so that you know what you are up to. Dr. Till Jaeger pointed out that you are then likely to move the discussion to what the definition means, whereby the definition could also be used as instructions to circumvent the limitations in the license.

Patents and Open Source

In the second session, Carlo Piana of Italian law firm Studio Legale Tamos Piana & Partners and counsel to FSF Europe, Steve Davidson of U.S. law firm Leonard, Street and Deinard, Mark Lange, policy counsel with Microsoft, and Larry Rosen talked about Patents and Open Source. (I have to admit my notes are a little thin here.)

Today, in the EU, you cannot ignore software patents, as they exist to a point. (See on that for example a recent Bird & Bird bulletin on the U.K. Aerotel case here.) And although the validity of these patents have not been tested in court, you might at one point have to litigate in relation to it.
According to Carlo Piana, software patents (as they exist today) are not so much of a problem of OSS, as they are a reason for deep concern. In that sense, Steve Davidson mentioned that if the OSS community is going to push hard on copyright, then there might be some pushing back from patent holders. Right now, there is room for a spirit of detente. Carlo Piana used another cold war era term, M.A.D., noting that smaller companies are not likely to benefit from a patent war, as they may only be able to support claims with a limited number of patents, whereas a larger party can counterclaim with a much larger body of patents. Claims that the smaller party does not have to resources to refute. In that sense, the only winning move is not to play.

Such an understanding disregards trolls (at which point someone in the audience mentioned SCO) but is also disregards legitimate claims. For the latter, Steve Davidson gave the examples of Kodak v. Sun (ZDNet on the ruling and on the settlement that followed) and the current IBM v. Amazon (ZDNet on the filing of that case) cases.

At another point in the discussion, Mark Lange remarked that little guys can benefit from access to the patent system, and that little guys become big. The system should be more accessible than it currently is for some, not inaccessible for all.

Larry Rosen asked whether users, that incorporate patented software technology, and redistribute it [as part of their product] risk being sued, and perhaps being enjoined from distributing (selling) their products. According to Steve Davidson, this is not very likely in the U.S., as injunctive relief is not a readily available remedy if monetary compensation is possible, whereby the effect on the installed user base is also taken into account. (In this light, see also the NTP v. RIM case, and perhaps NTP v. Palm as well. Also, the same principle is true for the Netherlands.) An injunction should not be the cloud hanging over your head.

Best Practices for Open Source Development

Closing the day, Karen Copenhaver of U.S. law firm Choate, Cathrine Bore of Trolltech, Kat McCabe of Black Duck Software, yours truly, Mark Lange and Larry Rosen, looked at a number of best practices for open source development. (Notes are even more thin here, as I participated in the panel itself.)

All participants stressed that educating developers on basic copyright tenets is a valuable exercise. Kat McCabe mentioned in this respect that lawyers should also be educated, whereas “we don not use open source software” [in our product] is not a very well-informed answer, and very likely not true either.

In the context of controlling the pedigree of code from outside contributors (the source of the source so you will), Karen Copenhaver mentioned taking a look at IBM’s approach with their Certificates of Originality.

Cathrine Bore shared the great tip that you should not have non-competes in your external development work contracts, as it is next to impossible to ensure compliance if you allow or even encourage your developers to participate in open source programs.

Shownotes / Open Source Conversations

The live-blogging style of this post does not do full justice to the engaging discussion that took place on 9 November 2006 in Amsterdam. Hopefully, audio from the day will be submitted to Open Source Conversations on GigaVox. This post will be updated if audio of the workshop becomes available.

‡‡
[This is a post from Technology Law Culture: http://tlc.oosterbaan.net. Olivier Oosterbaan, ICT and media lawyer in Rotterdam, the Netherlands, maintains this blog. Some rights reserved.]

(Picture from: Yogi, under a by-sa Creative Commons license, found through Flickr Creative Commons search.)

If you’re really quick (and happen to be in Amsterdam) you can still join the 9 November 2006 workshop: IP, Software Patents and Copyright Law: Avoiding the Legal Pitfalls of Open Source in Amsterdam. It follows a two-day conference on The Business Models and Technology Choices for Monetising Open Source in Mobile.

Workshop leader is Larry Rosen of the U.S. law firm Rosenlaw & Einschlag (and of OSI fame). Participants include David Rickerby of the U.S. law firm Choate, Dr. Till Jaeger of JBB Law in Germany, Steve Mutkoski of Microsoft, Walter van Holst of Dutch IT consultancy firm Mitopics, and Eric Tjong Tjin Tai of the Dutch law firm of Pels Rijcken. They will talk about Copyright and derivative work analysis.

Following them, Carlo Piana of Studio Legale Tamos Piana & Partners, Steve Davidson of U.S. law firm Leonard, Street and Deinard, Ron Zink of Microsoft (or try Google for more results :P), and Larry Rosen will discuss Patents and Open Source.

Closing the day, Karen Copenhaver of U.S. law firm Choate, Cathrine Bore of Trolltech, Kat McCabe of Black Duck Software, yours truly, and Steve Mutkoski and Larry Rosen, will together look at Best practices for open source development.

Associated reading materials can be found under the del.icio.us tag OSiM2006LegalWorkshop. (I have to admit that as of today over half of these were added by me, so the usefulness is unconfirmed.)

I look forward to it greatly. TLC will of course report on it in due course.

‡‡
[This is a post from Technology Law Culture: http://tlc.oosterbaan.net. Olivier Oosterbaan, ICT and media lawyer in Rotterdam, the Netherlands, maintains this blog.]

(Picture from: Found through Yahoo Creative Commons Search. I have to admit I relied on that and did not further check the license on the site it pointed to.)