Friday Aug 21, 2009

☞ Monkey Business

Wednesday Aug 05, 2009

☞ Two Games

Thursday Feb 12, 2009

Old Code and Old Licenses

Brussels Cathedral towers and moon

I was in Brussels at the weekend to attend FOSDEM, one of the handful of "real" Free software developer conferences I attend each year (another is LCA which I went to in Hobart two weeks ago). I was once again honoured to be able to briefly speak to the assembled audience as I did two years ago. This time I announced a small license change to some obscure code, written before the GPL was finalised, to fix a problem for Linux.

Why would that interest anyone? Well, the code in question is the original implementation of Sun RPC, which went on to become RFC 1057 and today is a core part of every UNIX-family operating system. Including Debian GNU/Linux.

The way the code was originally licensed was exceptionally liberal. Written in 1984 or earlier (before the GPL existed), it allowed unfettered use of the Sun RPC implementation in any program for any purpose. The only significant restriction imposed, entirely reasonable to most eyes then, was to say that the module itself could not be sold as-is, only as part of a larger work.

What was liberal is now conservative

Times change. During the 80s, Richard Stallman's Free Software movement established the four freedoms. During the 90s (1994-7), the Debian Free Software Guidelines established a need for the code in their distribution of GNU/Linux to be fully Free software. By the beginning of this decade, Debian maintainers were making a serious effort to audit the millions of lines of code in Debian for true DFSG compliance. And in 2002, they found the old Sun RPC code in core Linux files glibc and portmap.

Reading the history for Debian bug 181493 tells the next part of the story. Inside Sun, the challenge of finding the code in question was Just Too Hard, and the things reached an uneasy impasse.

The issue came back to life last year when the bug was re-asserted as part of the run-up to the Lenny release. I was contacted both by folk at Debian - notably my friend Ean Schuessler - and at Fedora asking if there was anything I could do to accelerate licensing of the old code. Both projects had decided to take a hard line and removing the code from glibc and portmap was going to be a real headache, especially for the stability of glibc.

Challenging

The task of relicensing old code can be pretty time consuming and involves people who are already much in demand.

  • First, the old code is often very old. The people who wrote it are no longer with the company, it is no longer part of a current product, we sometimes can't even be sure it ever came from Sun. We have to find the original code if we're to make any progress at all. Doing so might mean retrieving crates of paper from long-term storage and crawling through them.
  • Second, once the code is located, a legal expert has to look at the origins of the code and maybe once again crawl through retrieved paperwork to find the contracts behind the code. Their job is to determine if Sun actually has the right to change the license at all.
  • Third, someone has to believe it is their job with respect to the code in question to act on Sun's behalf to evaluate the change, authorise it and bind the company officially.
All this is time-consuming and expensive, and without a current code owner inside Sun it's touch-and-go whether anyone can find either the staff time or the budget to run a license change through to completion.

With help both from Ean and friends at Debian and from the Fedora team at Red Hat, we managed to identify some modern OpenSolaris code that matched the code in Linux. This was a key step. It meant we could trace ownership through the comprehensive records for OpenSolaris and start the process moving. By last week, we finally reached the point where we felt comfortable to relicense the Sun code involved.

Relicensed

On Saturday I was able to tell Europe's Free Software developers that the licenses on the RPC code are no longer a barrier to Free software - we'll change the license to Sun's copyrights in the RPC code to a standard 3-clause BSD license, allowing inheritance of that licensing by both Debian and Fedora. I'm delighted to have been able to fix this problem, which arose not because of failure but because of the success of software freedom over many years and becuase of Sun's early commitment to it.

Wednesday Sep 10, 2008

Project Kenai and Supporting OSI

As part of a series of open source activities around Software Freedom Day, Sun quietly rolled out a cool new open source facility this week. Before I tell you about it, I should mention I've been part of the revived discussion considering open source license proliferation and the Open Source Initiative (OSI). As you may recall, I am keen to fix the problem of the proliferation of open source licenses, even to the extent to asking OSI to regard two Sun-created licenses (SISSL and SPL) as no longer for active use.

License Choice

One of the approaches advocated in that discussion is to run open source hosting facilities that only allow a subset of licenses, making most licenses unavailable to new projects. While the ideology behind the selection may appear sound, I think that's the wrong direction to take. If OSI is to have any relevance in the future, we all need to respect its decisions and strengthen its authority. If we think they were or are now wrong decisions, we need to help OSI put its house in order and not usurp its authority and put ourselves unilaterally in the place of arbiters of what is a "true" open source license.

Project Kenai License Selection

That's why I'm pleased to say that the new community hosting system Sun opened for beta this week, Project Kenai, uses the OSI License (Anti-)Proliferation Committee's report as the basis for license selection for new communities. Expanded list of Kenai licenses

When you create a new hosted project, Kenai offers first of all the "recommended" licenses ("Licenses that are popular and widely used or with strong communities"). If you're looking for a specific license, you can "grow" the list to show the rest of the OSI-approved licenses. Finally the deprecated/retired licenses are available if you specifically request to use them (since OSI doesn't un-approve licenses). Hopefully this approach will cause new projects which don't have a specific license in mind to choose from the small pool of common licenses, while at the same time allowing existing communities to use the licenses they already prefer.

Community Hosting

Project Kenai is pretty interesting in all sorts of other ways, of course, not least that it's a Ruby on Rails application. Tim has some of the technical details on his blog. We created it because we realised that, with Sun involved in upwards of 750 different open source projects, acting as host for some reasonable number of them, we needed to have some hosting infrastructure of our own. It also gave us an opportunity to build a large-scale site using modern techniques, as well as to offer the facility as a service to the open source community at large.

It's more than just a "forge" offering Subversion and Mercurial - it includes infrastructure for social networking within and between communities as well, and the development team is continuing to enhance these. They're not quite ready to open the doors to new projects yet, but if you have a project you would like to host there, please contact me for an invitation to the beta programme and get in on the ground floor. And of course you are invited to explore the system and to join in with existing projects if you want - no invitation is needed to do either of those things. Take a look especially at the new xVM Server project, launched yesterday.

Sunday Mar 16, 2008

Software Freedom: More Than Copyright

New Forest Reflection

I was surprised last week to see a posting from Michael Tiemann, the President of the Open Source Initiative and a VP at Red Hat. Any posting with a subject of line of "Simon Phipps Was Right" is bound to catch my eye, but this one was especially unexpected because in the original discussion I had thought that Michael was largely right! Michael's posting graciously said:

Simon, I'm beginning to think that you were right and I was wrong. You said a standard's process is a crucial aspect of the standard's product, and a process that is not open cannot be trusted to produce a product that can be considered open. I maintained that I had seen and used many wonderful standards that took absolutely zero input from me, and therefore I didn't see my participation as a necessary prerequisite for assuring quality in the future. I believed that no matter what the process, a standard should be judged by the product. Watching the fallout settle from the [ISO ballot resolution meeting] in Geneva, I'm beginning to think that you were right and I was wrong.

I've been thinking about the posting for a week or so now and I've tried to respond thoughtfully. Here is the response I sent to Michael (still awaiting moderation):

Thank-you, Michael - it's not often I see a posting like this. Actually, when we spoke about this at OSCON I found I agreed with many of your arguments, even if that doesn't show in the on-list discussion. The problem is that standards are orthogonal to open source, and attempting to define them in a way that promotes and protects software freedom may be impossible. It's been said that when we create any system we create the game that plays it. The standards system is fully mature and as such is fully gamed, as the DIS29500 debacle you reference is proving.

Maybe a more productive approach going forward is to try to do for the other kinds of so-called intellectual property what the Open Source Definition (OSD) currently does for copyright licensing. Perhaps we need to rename OSD to "Open Source Copyright Definition" and then work on an "Open Source Patent Definition", so that we can avoid the kind of entrapment that software patents can threaten? And as you know I am convinced we need an "Open Source Trademark Definition" to help us as a community of communities to avoid the IceWeasel problem.

If these are interesting, I'd be pleased to spend time exploring them together. Let me know.

New Definitions

The current Open Source Definition doesn't actually define Open Source - rather, it defines a subset of the requirements that protect software freedom, in this case the copyright license. I actually think renaming it ("Open Source Copyright Definition"?) would be good since there's more to Open Source than just the copyright license. I then suggest we explore creating an "Open Source Patent Definition" and an "Open Source Trademark Definition".

What would be in these two new definitions? Both would need to define what promotes software freedom and how it can be protected. Both would need to be pragmatically principled.

  • An Open Source Patent Definition would do for patents what the OS(C)D does for copyrights. I've posted a lot on this subject before, notably in Protecting Developers from Patents and Ten Reasons The World Needs Patent Covenants, so I'd go mining there for my contributions to the discussion. But it may also be that in addition there needs to be a call for patent law reform, maybe as I outlined in Seven Patent Reforms While We Wait For Nirvana.
  • When it comes to an Open Source Trademark Definition, we would need to similarly define the signs that a developer or user needs to know whether software freedom is being promoted in a trademark policy. I've not written about this yet, but I do believe we need to collectively understand the bounds trademark law places on people who have responsibility for trademarks (read: all developers and open source communities as well as all vendors). We then need to construct a path that promotes software freedom without placing impossible demands on trademark owners to behave in ways that are contrary to their responsibilities.

This is not easy stuff. But I do believe that certain recent events between the open and proprietary software worlds mean that it's time for software freedom fighters to get together and work on these things. I'm ready to work on it. What do you say, Michael?

Thursday Mar 06, 2008

OpenOffice.org goes to LGPLv3

Slipstreaming Gull

You may recall that a team from Sun devoted a great deal of time to the process of drafting the GPLv3. Our engagement was not just the monitoring exercise that I suspect it was for many of the corporate participants. It was always my hope that Sun would use the license for significant software projects.

Since then, the FSF has made some welcome clarifications to the license and Sun released its first project, Openxvm, as GPLv3. The next step for us has been to review the licensing for OpenOffice.org. We consulted widely in the community and received an overwhelming response on a number of proposed modifications to the project, starting with the license. The LGPL has served OpenOffice.org well, so the move to LGPL v3 seemed very logical. LGPLv3 is actually almost identical to GPLv3, but with an additional clause limiting the scope of the requirement to release source code under the same license.

Upgrading to the LGPLv3 brings important new protections to the OpenOffice.org community, most notably through the new language concerning software patents. You may know that I am personally an opponent of software patents, and that Sun has already taken steps in this area with a patent non-assert covenant for ODF. But the most important protection for developers comes from creating mutual patent grants between developers. LGPLv3 does this.

So it's a pleasure to be able to say that Sun supports the community's input. OpenOffice.org's license will change to LGPLv3 as part of a broader set of changes intended to improve the OpenOffice.org community for everyone. Those changes also include a switch to the latest version of the standard Sun contributor agreement, with an addendum specifically tailored to the needs of the OpenOffice.org community. There's increased latitude for documentation writers to publish their work on OpenOffice.org. And in future, plugins for OpenOffice.org may host their source code directly on the community site without copyright being shared, helping collaboration within the community.

There's more news about OpenOffice.org's infrastructure as well as the project's governance - see Jim's blog for more detail as well as Louis' community announcement. For all the details, you can listen to a discussion Barton George had with Michael Bemmer, the development director of OpenOffice.org at Sun, his boss Jim Parkinson, and with Peter Brown, Executive Director of the Free Software Foundation, on this podcast: [MP3]-[Ogg].

Wednesday Mar 28, 2007

GPLv3 Third Draft

Quince flowers

The third draft of the GPLv3 came out this morning. There's a lot of text there, and obviously I've not had time to read it all yet (especially the long explanatory document). I took a quick look at the 'redline' over breakfast and there are some welcome enhancements, such as the explicit explanation about software-as-a-service:

To “convey” a work means any kind of propagation that enables other parties to make or receive copies, excluding sublicensing. Mere inter- action with a user through a computer network, with no transfer of a copy, is not conveying.

The language concerning DRM has also changed substantially and now sits in section 6 and relates to the use of the code in "User Products", which could really change the implications of that mechanism:

A “User Product” is either (1) a “consumer product”, which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling.

There's been a substantial rework to the stuff about exceptions in section 7. In its previous form, this section provided a basis for various different license to be mixed, but the new version seems to provide less opportunity for that. I wish we could work out mechanisms to allow the various FOSS communities to mix their work more easily.

I'm also not clear on the implications of the new language added to section 11 to affect patents, which is intended to close the loophole Microsoft and Novell used to get round the GPLv2. I need to read it several times before coming to a conclusion.

Over and above the actual license terms, there's a big change to the time-line. I'd been expecting the final draft; this is now an extra interim draft, and we'll not see the final version until the summer. And there are several signs that we'll see more frequent updates to the license - there are indications that the DRM stuff might be extended to different kinds of devices, for example. All very interesting, I know there will be a lot of discussion about this inside Sun over the next few weeks.

Monday Feb 26, 2007

LiveMink: Freedom Task Force

At FOSDEM last weekend, I met up with Shane Coughlan, a long-time Free software advocate and now full-time staff for the Free Software Foundation Europe. Shane told me all about the new initiative FSFE is starting, the Freedom Task Force, which aims to provide a legal focus for Free software in Europe. Listen on!

[MP3][Ogg][iTunes]

Monday Nov 20, 2006

Simple Is Better

Leaf-fall at City Hall

In a fine article yesterday whose title I have appropriated for this posting, Frank Hayes exactly captures the thoughts I was thinking as we were going through the license selection discussion for the Java platform inside Sun. I don't agree with his comments on obsolescence, but when it comes to licensing:

Anyone knowing that history would have expected Sun to open-source Java on Sun’s own terms ... Amazingly, Sun didn’t do any of that. The Java open-source license is identical to the Linux license. No specialized terms. No strings. Nothing new. Sun actually did keep it simple.

Licensing simplicity was one of the goals of the Open Source Initiative. By having licenses pre-approved as "freedom promoting" by a group of experts, the plan was to save developers from having to make decisions about which licenses were OK and which were a problem. I regard it as a huge irony that this approach was so successful that the number of approved licenses has proliferated to the point where one needs legal advice to choose between them. So one of the very first things we did when I became Sun's Chief Open Source Officer in 2005 was to start the process of simplifying Sun's approach to licensing by retiring an old open source license, SISSL, which I assume no responsible company will now choose to use.

Following the OSI's lead, the time has come to further simplify, and I'm pleased to be able to announce that Sun has contacted OSI again and informed them that another license Sun created - the Sun Public License, or SPL - is no longer required by Sun and requested that they consider it "retired". We migrated the last large codebase from it last spring - NetBeans - and it's now a historical artefact.

It was a good thing in its day, but it was one of many licenses created from the Mozilla license out of necessity and now we have CDDL it's not needed - that license has provided the whole community with a long-term alternative to "vanity" licenses. I'd encourage the (many) other creators of Mozilla-derived licenses to take the same step. We owe it to our colleagues in the open source community to keep things simple.

About

Thoughts and pointers on digital freedoms and technology markets. With a few photos too.

Search

Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today