Linus's request for discussion
Some of you may have heard of this crazy company called SCO (aka
"Smoking Crack Organization") who seem to have a hard time
believing that open source works better than their five engineers
do. They've apparently made a couple of outlandish claims about
where our source code comes from, including claiming to own code
that was clearly written by me over a decade ago.
He notes that the process of debunking these claims, while highly
effective, has not been entirely fun. As a way of making life easier when
the next SCO comes along, Linus is proposing a lightweight mechanism which
would document how each patch finds its way into the kernel. In essence,
this scheme would require each patch to contain at least one line like:
Signed-off-by: Some kernel hacker <email@example.com>
One such line would be added by each person who handles the patch on its
way to the mainline kernel. Together, these lines would document the
originator of the patch and the path it took before it was merged. Each
developer, by "signing off" on the patch in this way, would indicate that
he or she has the right to submit it to the kernel under a free license -
either by virtue of having written the code, or by having obtained it from
a source which allows this form of redistribution. Companies which require
review of code contributed to external projects can designate a person who
must sign off on patches before they go out.
This procedure is a far cry from, for example, the full-blown copyright assignment
required from contributors to GNU projects. Contributions to the kernel
will still require no physical, signed papers, no assignment of copyright,
no indemnification, and no documented permission from the contributor's
employer. The Free Software Foundation, with its assignment policy, is
trying to set itself up as the owner and custodian of the GNU system, with
clear title to the code,
the ability to specify the license under which that code will be released and to
enforce the terms of that license. The kernel hackers, instead, seem to
feel that they can get by without such a custodian, wish to retain
ownership of their code, and, as the netfilter team has demonstrated,
they feel entirely capable of enforcing their own licenses.
The kernel system is, instead, aimed entirely at documentation. The next
time somebody questions the legitimacy of code in the kernel, it would be
nice to be able to point out, quickly, exactly where the code came from.
In this way, perhaps, people can spend less time digging through ancient
mail archives and more time developing. For this reason,
suggestions varying from GPG-signing of patches to the (poorly
received) idea of adopting an ISO-9000
process will probably not be implemented. Some tweaking will probably
happen, but whatever system finally gets adopted will remain a simple,
lightweight documentation mechanism.
While the new kernel contribution scheme is aimed at documenting future
contributions, the just-launched Grokline project is trying to document
the past. From the site:
This is an open, community-based, collaborative research project, a
living history, designed to carefully trace the ownership history
of UNIX and UNIX-like code with the goal of reducing, or
eliminating, the amount of software subject to superficially
plausible but ultimately invalid copyright, patent and trade secret
claims against Linux or other free and open source software.
The project has put together a basic Unix timeline, and is soliciting input
from anybody who can help document where all this code came from.
Grokline will, without doubt, yield no end of interesting historical
information. One can't help wondering, however, if the community isn't
gearing up to fight last year's war. The SCO Group has done us a
tremendous favor by showing that (1) finding copyright infringements
in free software (and the Linux kernel in particular) really is hard, and
(2) the community will unite with devastating effect
against anybody who seeks to profit from baseless attacks on free
software. It is hard to imagine another company wanting to be the next
SCO. The next time a copyright claim is raised against free software, the
claimants will be well advised to have their evidence in place from the
beginning - and to be right.
If there is another SCO-scale war in our near future, it will probably not
involve copyrights. It will be, instead, a patent fight. Unless it serves
to establish prior art, documentation of the provenance of code will not be
helpful in a patent case. It is also worth noting that the SCO case has
forced a remarkable alignment of interests between many large,
deep-pocketed companies and the broader free software community. That
alignment of interests may well be absent in a patent battle. Next year's
patent war may not be fought off as easily as this year's copyright and
(formerly) trade secret suit. By all means, we should be documenting where
our code comes from, and, in general, doing our best to ensure that it has been
contributed legitimately. But it would be a mistake to believe that this
documentation alone will be sufficient to defend us from all "intellectual
Comments (10 posted)
With the final release of Fedora Core 2 out the door, and on schedule no
less, now might be a good time to take stock of the project and where it's
going. Unfortunately, that's not as clear as one might hope.
It's easy to see where the project is now, but the future is a bit more
murky -- at least for those outside the project. For the most part, the
Fedora Project seems to be meeting its goals. A quick glance at the objectives for
Fedora Core shows that the project is meeting nearly all of its
objectives. Fedora Core 2 contains a wide range of open source packages on
the "leading edge" of development. The project has done well at sticking to
release schedules, and at putting together a fine Linux distribution that
more or less picks up where Red Hat Linux left off.
What Fedora has not yet achieved, however, is a significant level of
community involvement beyond simple testing of releases.
The situation has not been helped by the project's recent change in
leadership; Cristian Gafton assumed
the position of Technical Lead in January, but some have
complained about a lack of communication from Gafton about the
project. A quick search of the Fedora devel archives gives some credence to
this complaint: Gafton has only posted twelve messages to the Fedora devel
lists since he assumed the Technical Lead position -- six in January, and
six in May.
We contacted Gafton to see if we could get a glimpse at the roadmap and
find out whether the community will have an opportunity to become more
involved in the development of Fedora Core 3 (FC3) and future
releases. Here's what we learned.
LWN: How long will FC1 remain "supported" now that FC2 is being released?
Our current plans are calling for issuing security updates for FC1 for
two-three months after Fedora Core 2 has been released. Realistically, once
the Fedora Core 3 test1 is out (or shortly after) I would expect the
development interest in the Fedora Core 1 to diminish and we will take a
formal look at declaring the End of Life for Fedora Core 1.
LWN: It looks like the project managed to stick to the schedule set for FC2
pretty well. In retrospect, was the schedule too aggressive or just right?
Will the schedule for FC3 be as aggressive as this one? Any breathing room
between FC2 and starting FC3?
We're all very happy with the fact that we have not run into any major
issues in our quest to incorporate the features we have planned for the
Fedora Core 2. Of course, the desire for more development time will always
be there, but I think that we have managed to put together a very good
schedule and we have managed to stick successfully to it. This is one of
those times where we come to appreciate the Red Hat developers' experience
and leadership in planning and managing an OS release, as well as the
resourcefullness demonstrated by Fedora development community.
LWN: Speaking of FC3, what can we expect to see in the next release? Do you
have a clear picture of what the next release will include?
We will start having a public debate about what we will plan for FC3 pretty
shortly. As far as I am concerned, I will pay attention to the deployment,
testing and migration to the new GCC 3.4 SSE compiler base, further
refining of the SELinux techonlogy, and - of course - the new versions of
Gnome, Evolution, KDE that are planned for release in the next few
months. As of right now we have encouraged every developer to build up the
wish list for the next round, and through a public debate process we will
get a clearer picture of a feature list in the next couple of weeks.
Planning the release will require us to figure out what will be reasonable
to expect to include and what would be our stretch goals. We will start
this process in very short order, because we want to get a tentative
schedule out as soon as possible, so that developers around the world will
know what to expect. For the Fedora Core 2 release I have been happy to
notice that some projects have attempted to syncronize their release
schedules so that we will have an easier time integrating their new code
bases in the Fedora Core. It is my sincere hope that this trend will
continue, and we are aware of the fact that we have to give people plenty
of time to plan ahead.
LWN: According to the FC2 schedule, the SELinux functionality was
considered "stop-ship" -- but it was disabled by default in the last test
release. Is SELinux ready for mass consumption in the final FC2 release, or
does it still require some polish before it's ready for prime time?
I think the SELinux functionality is pretty well cooked and I encourage the
seasoned users and developers to play with it. Unfortunately at this stage,
the implementation and management of the SELinux security policies are
complex tasks that require an advanced degree of familiarity with the inner
workings of the operating system.
The challenge we face in developing a default security policy is the
balance one needs to strike between the level of security barriers deployed
and the functionality people would reasonably expect out of this
release. For example, can we subject third party applications, that are not
aware of the security contexts, to a paranoid policy that most likely will
prevent them from functioning correctly, or do we provide a more relaxed
policy at which point the security advantages of SELinux are not so readily
apparent? Also, the legacy of the discretionary access control setups will
be a tough nut to crack - we found out that a lot of users still expected
that the root account will be able to do and fix everything - an
assumption no longer valid when running under SELinux.
So, for the Fedora Core 2 we have decided to court the experienced users
and developers to help us figure out the lines of compromise between the
challenges posed by the SELinux policy - a sort of a continued beta program
for refining what would be an acceptable set of defaults. Of course, this
does not preclude the development of very strict or more relaxed policies
as alternatives to the balanced default set.
LWN: No doubt you've seen the parody published by Konstantin
Ryabitsev about Fedora/Red Hat's interaction with the community. Though
it's a bit over the top, it has raised quite a bit of discussion. Is it
likely that RH will seek more involvement from the community in terms of
setting the direction of Fedora? Will there be any changes in the way
Fedora is managed in the near future?
This is and continues to be one of the challenges Red Hat faces - how do we
build an effective way of engaging more of the external development
community and how do we enable them to participate in this project. The
parody you are referring to, while an entertaining read, assumes a
political conflict out of the current state, when in fact the challenges we
are facing are logistical. We are talking about deploying a parallel
development process for the Red Hat developers, geared and built to support
external parties contributing code on various sections of the operating
system. This means planning and executing a huge change in everything
infrastructure-related inside Red Hat engineering, which has the potential
of causing big impacts in the other corners of our business, like support,
professional services and even sales. We are working hard on opening up our
infrastructure, but we have to do it responsibly and we have to be mindful
of the business impact we are going to cause on the commitments Red Hat
needs to fullfill as a publicly traded company. Oftentimes we internally
compare this process to working on a jet engine while it is running...
Our short-term plans include the opening of a source code management
repository where the interested developers can follow closely the
development activity of the Red Hat engineering team. We will also be
revamping the fedora.redhat.com website, adding dynamic content to it and
allowing people to start participating in forums and start oganizing
according to their common interests. These are steps that are going to
happen in the very few next weeks, in time for the start of the Fedora Core
3 development process.
LWN: On the same topic, a lot of discussion has been comparing Fedora to
Debian -- obviously, there are some serious differences in the way that
both distros are put together. Would you say that the Fedora approach is
better, or just different? Why?
Well, some things are better, some things are "different." The Red Hat
engineering team is more experienced at putting together high-quality,
commercial distributions. The planning, scheduling and focus we bring to
the process are superior, and by transforming the Fedora Project into a
community-focused release we now also have the flexibility of doing more of
what is right when it comes to setting up a schedule.
In the software development process there are always three factors that are
at play: features, quality and development speed. In commercial software
development one can always have only two of those three. I believe that the
community focus of the Fedora Project allows us to seek a more reasonable
balance between those three objectives. Our background in commercial
releases will allow us to keep focus on the fact that we need to have
timely releases and we need to manage aggressively against the schedules we
set. As far as Debian goes, they have been more successful at engaging the
open source development community and there is a lot we can and will learn
from their experiences. There is no question that as of now Fedora and
Debian are very different in the way we put things together - but I think
in the near future we will start to look more and more alike as far as the
level of involvement with the development community.
That may yet happen, but the Fedora project is going to have to open up
significantly before it can begin to shake off its image (in some quarters,
at least) as a beta test program for Red Hat's enterprise products. With
luck and work, perhaps Fedora can begin to approach Debian's level of
community involvement. If this can be done while retaining Fedora's rather
more predictable release schedule, so much the better.
Comments (5 posted)
is a highly popular
and capable content management system oriented toward the publication of
weblogs. It is written in Perl, and is necessarily distributed in source
form. It has never, however, been free software. Its license did not
allow distribution of modified versions, though patches could be
distributed. As a whole, the license was "free enough," and Movable Type
developed a large, happy user base.
That user base is rather less pleased now. With the announcement
of Movable Type 3.0 came the news that, for all but the smallest,
personal sites, use of the new version would require a paid license. Six
Apart Ltd., the company which owns Movable Type, has since learned what
happens when you upset thousands of people, each of whom has a personal
printing press. Many online commenters have expended countless electrons
on criticism of Six Apart and its new license.
We'll not join them. Six Apart owns its code, and sets the terms for its
use. The company is behaving no worse than any other proprietary software
vendor, and better than many. One might argue it should have made its new
licensing plans clear before inviting beta testers to help them finish 3.0,
but that's about it.
What Six Apart has done is to provide an object lesson in the perils of
"almost free" software. If you do not have the right to run, modify, and
redistribute a program, you will, eventually, find yourself in a situation
where that program loses its value to you. If its owner fails to maintain
it, nobody else can. If its owner imposes an onerous license, your only
options are to take it or leave it. Source-available proprietary software
can be deceptive; it feels much like free software. But every such package
is another MT 3.0 waiting to happen.
Consider, for example, the case of qmail. It is, beyond doubt, a
powerful and secure mail transfer agent. It is distributed in source form.
But it also comes with a non-free license which forbids distribution of
modified versions, and which makes the distribution of binary packages
difficult. There has not been a new qmail release since June, 1998.
Patches are required to get it to build on a modern Linux distribution, and
others are needed to bring it up to the level of functionality needed by
many sites. But, due to the redistribution restrictions, nobody can take
over qmail maintenance and release a new version.
That notwithstanding, many sites (LWN included, it should be said) have
chosen to run qmail. But all such users should bear in mind that qmail's
license terms are, at best, vague; the software itself comes with no
explicit license. If qmail's author were ever to proclaim a new license,
it would be hard for users to prove that any other terms had ever been in
force. Even without that sort of problem, it seems pretty clear that
qmail's author has long since lost interest in working on the code; the
chances of there ever being another qmail release appear small.
The Movable Type episode has shown, once again, that licenses really do
matter. A free software license represents a sort of gift from a developer
to users: those users will never be deprived of the right to use, modify,
and distribute the covered software. Developers are not (and should not
be) required to offer such a gift. But if the author of software you use
has not given you those rights, you should not be surprised when the terms
change in the future.
Comments (34 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Did they read it?; New vulnerabilities in firebird, the kernel, SquirrelMail, and xpcd.
- Kernel: The merging of anon_vma and 4G/4G; The Big Kernel Lock lives on; The new Debian kernel team.
- Distributions: The RULE Project; new: Debian From Scratch, YES Linux; reviewed: Fedora Core 2, CRUX, Sun JDS
- Development: Interview with Audacity developer Dominic Mazzoni,
new versions of Common C++, Back-End CMS, phpWebSite, Ardour, KDE,
Compiere, Gimp-Perl, JGraphAddons, OpenOffice.org, AbiWord,
VXL, python-ldap, GPICD, Prothon.
- Press: ADTI study followup, Grokline, Stallman on software patents, Server sales
stats, Ethereal tricks, ONJava reader survey results.
- Announcements: CA Open Source Strategy, BEA and Apache's Project Beehive,
New Creative Commons licenses, Plone Foundation, OSIA paper on SCO vs IBM,
Open Source Competence Workshop at LinuxTag, GNOME devel-announce-list.