changes to the way it does its releases, MySQL AB, the company behind
the MySQL database, probably knew what
element would be the most controversial. Listed last of five changes was
the plan to no longer be distribute Enterprise Server source code.
Very quickly noticed by members of the MySQL community, then by
the wider free software community, it caused a bit of an uproar.
A Slashdot headline,
later reworded, proclaimed "MySQL Closing Off Its Source", which was easily
enough to fan the flames. A closer look reveals that not all that much has
changed, MySQL is trying to find ways to have a free software product that
generates revenue – a difficult balancing act.
The roots of the problem go back to the split of MySQL into two products:
Enterprise Server and Community Server. That change was
announced in October
2006 and was an attempt by MySQL AB
to separate the needs of the
"community" from those of their commercial, "enterprise" customers. The
words chosen were, perhaps, a bit distasteful; one would think that all
MySQL users are members of the community, the real distinction they were
to make is: paying vs. non-paying.
At the time of that split, there was talk that MySQL AB was turning its
free software, "going corporate" as it were. In fact, the company
has kept up its side of the bargain, releasing its code under the GPL. It
has also worked with the Free Software Foundation on GPLv3; upcoming
MySQL releases might very well be covered by that license. Its biggest
in some eyes, has been the unwillingness to forgo making a profit.
The change that caused the latest stink is more subtle,
as it just changes the Community Server development process. But, as
a seemingly unnecessary part of that change, the Enterprise Server
source tarballs will no longer be available on the the
site. The source will be distributed to customers who buy the Enterprise
Server, but will no longer be accessible – from MySQL AB –
by the community at large.
The company evidently wants to make a sharp distinction between the two
releases, which is what led them to restrict the source code. Various
Linux distributions have been using the Enterprise source, rather than the
the Community source, to build MySQL
packages and the company would rather not
see that. Kaj Arnö, VP of Community
Relations for MySQL AB, puts it this way:
What we do intend is related to positioning: MySQL Community
Server is for
our users, MySQL Enterprise Server is for our paying customers. We want
people to associate MySQL Enterprise Server with a commercial
to MySQL as a company.
It seems a rather drastic step, likely to induce community annoyance, for
very little gain. The marginal cost of maintaining
another copy of the tarball should be nearly zero. In addition,
Arnö has acknowledged that the source will still be
available to anyone who truly wants it. Folks like DorsalSource are already planning
to provide source and binary versions of the Enterprise products as they
GPL compliance, always a confusing topic, was at the heart of a lot of the
complaints about withdrawing the source. The company is complying with the
license by providing the source code to their Enterprise customers with the
binary distribution. Given that they hold the copyright for the entire
package, by requiring contributors to assign their copyrights, they could
make other license arrangements with their customers, but choose to stick
with the GPL.
The other, less controversial changes announced were largely codifying the
current Community release practices. One of those practices, leaving new
features and bug fixes out of the community releases, at least until the
next major release, seems contrary to the intent for the Community Server.
When it was set up, it was to be the testbed for the Enterprise Server, but
that role has clearly fallen by the wayside.
There are legitimate differences between large, enterprise-class
(who are more likely to pay for support) and the rest of the universe of
users. One wants stable releases, on a fixed schedule, that have been
extensively tested in real-world installations. The other wants new
features and bug fixes more quickly, even if they have not yet had
extensive testing. Unfortunately, it seems like MySQL AB may be
about which group of users needs each style of release.
A parallel is often drawn between the split that Red Hat made between
Fedora and Red Hat Enterprise Linux (RHEL), but while the original
reasoning seems to be the same, the implementation
is rather different. For reasons that are not entirely clear,
Enterprise Server gets monthly "hotfix" releases that often seem to contain
fixes that are out of place for a stable
release. Often, the changes have not yet been released in a community
version, so they have only
been tested in MySQL AB's labs.
This is very different from the
Fedora/RHEL model as the frequency of releases between community and
enterprise has been reversed. In the Red Hat model, features (new
are released first in Fedora, vetted by the community, then released in an
RHEL release sometime later, typically much later. It is hard to
see what benefit monthly releases provide to a "stable" product. An
must be made for security fixes, but those should not wait until the next
scheduled release anyway.
MySQL AB seems to see things differently, one must hope that they are
and that they understand precisely what their customers want. It would be
a tragedy for MySQL AB to falter; they are a free software company that
an enormous amount of work on the database software that is
used freely by millions. Thankfully, even if that did happen, MySQL the
software package, would continue, perhaps at a slower pace. That, in many
ways, sums up what MySQL AB, or any company that uses a free license, gives
their users, paying or
non-paying, the ability to keep using and extending the software even if
Comments (3 posted)
Sometimes, a little reminiscing is called for. Think back to March 7,
2003, when the SCO Group, once a Linux distributor named Caldera, filed its initial
complaint against IBM
Prior to IBM's involvement, Linux was the software equivalent of a
bicycle. UNIX was the software equivalent of a luxury car. To make
Linux of necessary quality for use by enterprise customers, it must
be re-designed so that Linux also becomes the software equivalent
of a luxury car. This re-design is not technologically feasible or
even possible at the enterprise level without (1) a high degree of
design coordination, (2) access to expensive and sophisticated
design and testing equipment; (3) access to UNIX code, methods and
concepts; (4) UNIX architectural experience; and (5) a very
significant financial investment.
IBM, by providing those things, was alleged to have misappropriated SCO's
property, breached contracts, and generally ruined SCO's day. At the core
of these allegations was the claim that IBM had funneled SCO's Unix code
into Linux - up to one million lines' worth. IBM fought back strongly,
and, over time, it became clear that no large-scale copying of Unix code
into Linux had happened - in fact, almost no copying had happened at all.
IBM continues to argue its case, but an interesting thing happened in May,
2003, when Novell issued a
press release claiming that it, rather than SCO, was the owner of the
Importantly, and contrary to SCO's assertions, SCO is not the owner
of the UNIX copyrights. Not only would a quick check of
U.S. Copyright Office records reveal this fact, but a review of the
asset transfer agreement between Novell and SCO confirms it. To
Novell's knowledge, the 1995 agreement governing SCO's purchase of
UNIX from Novell does not convey to SCO the associated copyrights.
We believe it unlikely that SCO can demonstrate that it has any
ownership interest whatsoever in those copyrights.
According to Novell, all of SCO's attempts to sell "Linux
licenses," and the lawsuit too, were built on a false foundation. SCO was
suing over copyrights it did not even own. An interesting little detail
that came out later on was that Novell, in selling the Unix licensing
business to the Santa Cruz Operation ("old SCO"), had retained the right to
waive any claims against Unix licensees; Novell proceeded to exercise that
right by requiring SCO to drop its claims against IBM.
SCO, of course, responded by suing Novell. Over the years, the suit grew
into a complicated mess of claims and counterclaims upon which was built a
series of motions for summary judgments. On August 11, the court,
under Judge Dale Kimball, ruled on those motions
[PDF]. The result was almost certainly the end of the SCO saga.
In short, Judge Kimball ruled on several issues:
- Novell never transferred the copyrights to Unix to the Santa Cruz
Operation or anybody else. The reasoning which leads to this
conclusion is quite long, involving sifting through a great deal of
evidence and testimony. But the end result is straightforward: the
SCO Group does not own the Unix copyrights. SCO had been asking for a
"slander of title" judgment against Novell and an injunction requiring
Novell to effect the actual transfer of copyrights; both of those motions were
dismissed as a result of this ruling.
- SCO claimed that Novell had acted outside of "good faith and fair
dealing" by acting to waive the claims against IBM. But the
relevant law says that, if you sign a contract with another party
which explicitly empowers you to perform a specific action, you cannot
be acting in bad faith if you do what the contract says you can do.
So this claim, too, was dismissed.
- Novell filed its own slander-of-title claims, which SCO had tried to
dispose of via a summary judgment motion. That motion was denied,
and Novell still has an open case which it can argue at trial.
- SCO argues that some of the language in the original asset purchase
agreement constitutes a non-compete agreement on Novell's part. Yet
another motion from Novell asked to dismiss SCO's claims that Novell
is violating its non-compete agreements by selling Linux. Several
approaches were taken, but Judge Kimball ruled against them all,
keeping SCO's non-compete claims alive: "The court also
concludes that, to the extent that SCO has a copyright to enforce, SCO
can simultaneously pursue both a copyright infringement claim and a
breach of contract claim based on the non-compete restrictions in the
license back of the Licensed Technology under APA and the TLA."
- SCO had tried to argue that Novell was not empowered to waive its
claims against IBM (and Sequent, which was purchased by IBM) because
the specific licenses at issue were not covered by the agreement. The
court disagreed. In short: "...SCO is obligated to recognized
Novell's waiver of SCO's claims against IBM and Sequent."
- The (complex) deal with old SCO required that all Unix license
revenues be passed back to Novell; Novell would then tip 5% of those
revenues back to SCO as an administrative fee. When Sun and Microsoft
bought their high-profile licenses, however, SCO kept the cash. So
Novell asked for a judgment to the effect that SCO owed money. Novell
also expressed the reasonable fear that SCO might just blow its remaining
cash before Novell could get its hands on it, so it asked the court to
seize the money immediately.
Here, the court decided that the licenses sold to Sun and Microsoft
did indeed come, at least partially, under the agreement and that SCO
should have paid Novell. "Because SCO failed to do so, it
breached its fiduciary duty to Novell under the APA and is liable for
conversion." In U.S. legal talk, "conversion" means something
very close to "theft." The court refused to set up a "constructive
trust" establishing Novell's rights to SCO's funds, though, because it
did not know how much money is owed. It seems that a portion of the
licensing fees might relate SCO's own work and thus would not fall
under the agreement
with Novell. Until that portion is quantified, there is "a question
of fact" on how much Novell is entitled to, and summary judgments
cannot be made when there are questions of fact.
This judgment changes the entire game. Much of SCO's case against IBM is
now gone - before IBM really even got a chance to defend itself. There has
been no copying of SCO's "valuable intellectual property" - it would appear
that SCO does not have much of that. SCO's claims that IBM had violated
its Unix license agreements have always been tenuous, but they may now
become moot, since Novell has exercised its now-clear right to waive any
claims based on that agreement. SCO might still be able to push forward
its claims that IBM treated it badly with regard to the Monterey
initiative. That's far removed from the $5 billion jackpot the
company had gone for, though - and it is totally irrelevant to the Linux
It is worth remembering that there is a large pile of summary judgment
motions pending in SCO v. IBM as well - and that they are before the same
judge. It makes sense for Judge Kimball to have resolved the copyright
ownership issue first. But the IBM motions have been outstanding for many
months and are due for action. What happens there will be interesting;
Judge Kimball may settle or moot many of them based on the Novell ruling.
That would be a welcome result, but it would fail to provide a definitive
answer to some interesting questions - like whether the Unix license
agreements, prior to being waived by Novell, truly prohibited IBM from
contributing work like read-copy-update or the JFS filesystem to Linux.
Even so, IBM has some interesting motions - the GPL violation charges, for
example - which will still need to be resolved in their own merits.
SCO might just file an appeal as an attempt to stay any judgments which
would bring an end to the IBM case. It is hard to see such an appeal as
anything more than (yet another) delaying tactic, though. Given that SCO's
lawyers have already seen all the revenue they will earn from this case,
their enthusiasm for such a course might just be a little bit low.
Meanwhile, Red Hat had filed suit in August, 2003, seeking to clear the
title to its own products and to put an end to the SCO campaign. That case
was put on hold pending the results of the IBM case. If Red Hat wanted to,
it would appear that a case could now be made for moving that suit forward:
Red Hat's products clearly are not infringing upon any intellectual
property rights that SCO might own. At this point, though, that would be
mostly an exercise in tying up loose ends. Few people have worried about
the propriety of the Linux code base for some time, and SCO's anti-Linux
campaign was effectively stopped some time ago.
It may take a while to see where all the pieces land, but the SCO affair
is, for all practical purposes, over. We, the Linux community, were
incredibly lucky here, as painful and expensive as this whole series of events
was. Given the success of Linux, it was certain that somebody, somewhere,
was going to try to make a grab for it. What happened was that we were
attacked by an opponent which was so inept, so lacking in any sort of real
cause, and so misguided in its choice of targets that we would have been
hard-put to lose. In the process, we took a hard look at where our code
comes from, found that we have what must be one of the most legitimate code
bases around, and tightened up our procedures anyway. The chances of there
being another copyright-based attack of any note have dropped to almost
zero. SCO has left us stronger than we were before.
As we put the SCO case behind us, there remains one interesting question:
now that Novell is unquestionably the owner of the Unix copyrights, what
will it do with them? The commercial value of those copyrights must be
near zero at this point - Linux and the BSDs have free code which is
better. About the only value left is FUD value - and the SCO case has
shown that those copyrights are not worth much in that area either. Still,
Novell could provide a more than fitting end to this episode, and perhaps
begin to rebuild its standing in the free software community, by releasing
the Unix code under a free license - probably a permissive license - and
closing the proprietary Unix era forevermore.
Comments (39 posted)
New jobs always come with learning "opportunities"; this one was no
different in that respect. Once this long-time vi bigot learned enough
emacs to create a daily security update, the big learning challenge was Git. I have used many different revision
control systems along the way, starting with sccs, through RCS and CVS, to
subversion – and a dash of mercurial. Git is fundamentally different
than all of those – though mercurial is close – its learning curve
is steep, its usage model is radically different.
One of the major differences is that Git is a distributed revision (or
version) control system, while most of the others are centralized. In a
distributed system there is no central repository that everyone uses to put
their changes into, there are, instead, numerous repositories, each
residing on a developer's machine. Typically, those developer repositories
have been "cloned" from a master repository somewhere. Each developer then
owns their repository; they can make changes, commit them, make branches,
tag releases, etc. – all without ever contacting the master
repository. When they are ready to share their changes, they either "push"
them into a repository, or, more likely, ask a repository owner to
"pull" changes from a specific branch of their repository.
Another reason for the steep learning curve is that Git started out as a
fairly low-level tool, just providing the
"plumbing" for version control. The intent was to add more user-friendly
interfaces to the plumbing, so-called porcelain, as time went on. As Git
matured, the porcelain has moved in with the plumbing, so the core Git package
has had many of the rough edges filed off, but it is still lower-level than
most other revision control systems. In my Git learning journey, I found
a number of helpful sites, that can help get users up to speed rather quickly.
For users who want to learn Git so they can look at Linux kernel
source, the best starting point is Jeff Garzik's "The Kernel Hackers' Guide to
Git". It provides a quick overview of the commands needed to grab a
copy of Linus's kernel tree, make branches from it, commit to it, and keep
it up to date. The main missing
piece is on using tags, which is how different versions of the kernel are
represented in the repository.
If managing a project with Git is in the cards, the right starting point
is: "A tutorial
introduction to git". This covers the basics of setting up a
repository to hold a project and importing the project's code. It also has
sections on many of the tasks that a repository user will need to commit
their changes, create branches for parallel lines of development, follow
the history of changes, and collaborate with others. The second part
of the tutorial covers some of the internal workings of Git: the object
database and the index file.
Those coming to Git from another version control system may want to look at
the tutorials specific to their tool. CVS and subversion have their
own tutorials, each geared towards users converting from those centralized
version control systems. The "git
for CVS users" page is a bit terse, often referring to the tutorial
above, but it does provide some of the basics a CVS user will need. The
"Git - SVN Crash Course" on
the other hand is fairly in-depth coverage, presenting the exact Git
equivalents for a large number of svn commands and concepts.
Once the basics have been mastered, it is time for the serious reference
material, which is where the Git
User's Manual comes into play. It contains multiple chapters covering
every facet of Git, including a detailed look at the internals of Git, its
storage formats and the like.
When trying to do something more complicated than is covered in the
narrowly focused tutorials, the User's Manual is the place to go.
Git commands are typically invoked from the command line as subcommands of
the git command: git commit for example. When trying to track
down the most serious reference material of all, though, using an alternate
syntax to refer to the Git subcommands is required: man git-commit
for example. From the command line, man
git is a good starting point; the same information, with nice clicky
links, is also available here.
With these reference materials at hand, it should be fairly straightforward
to get up and running with Git. For me, at least, there is still a lot to
learn, but with these sites available, I am mastering more of it each time
I dive in. If still more information is needed, the GitWiki and its documentation page are
the next places to try.
Comments (10 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Exploiting races in system call wrappers; New vulnerabilities in dovecot, libarchive, squirrelmail, xvid...
- Kernel: Smarter write throttling; timerfd() and system call review; Kernel markers.
- Distributions: The anatomy of a Linux distribution; new releases: Linux From Scratch 6.3-rc2, openSUSE 10.3 Beta 1, Ubuntu Gutsy Gibbon Tribe 4; Fedora Electronic Lab
- Development: Buddi - Personal finance software for the rest of us,
GCC 4.3.0 status report, using Python distutils,
new versions of UNICORE, SQLite, SpamAssassin, GNU SASL, CUPS, SNARE,
KnowledgeTree, LimeSurvey, Smartweb, Ardour, Ecasound, Mammut, JasperReports,
Compiz Fusion, Buddi, FreeCol, G3D engine, Wine, nova, PHASEX, UFRaw,
Jmol, GPE for Maemo, Ctalk.
- Press: Linus explains why open source works, Shuttleworth on ISO OpenXML,
LinuxWorld coverage, FOSS and the philosophers, SCO loses to Novell,
Dell Linux Inspirons in EU, MySQL Enterprise distribution change,
Linux Foundation hires attourneys, Stephan Kulow interview,
Linux compatible hardware, Mono Progress Report, Linux networking stack
overview, reviews of LyX, KDE4, Miro, Mylyn, OLPC XO, Nokia's N800.
- Announcements: FSFE protests BBC iPlayer, EFF on NSA surveillance, FiveRuns rails stack,
Microsoft licenses submitted to OSI, Oracle 11g, Sun's OpenJDK TCK license,
final AGPL draft, Linux Platform Weather Forecast, Desktop Linux Survey
voting, OSCON report, ETech cfp, Summercon Atlanta, Von Conference Boston.