Leading items

MySQL stops distributing Enterprise Server source code

In announcing 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 trying to make is: paying vs. non-paying.

At the time of that split, there was talk that MySQL AB was turning its back on 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 sin, 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 ftp.mysql.com 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:

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 are released.

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 customers (who are more likely to pay for support) and the rest of the universe of MySQL 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 confused 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 packages) 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 exception 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 right, 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 does 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 to their users, paying or non-paying, the ability to keep using and extending the software even if the company fails.

Comments (3 posted)

A bad day for the SCO Group

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 Unix 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 community.

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)

Getting started with Git

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
Next page: Security>>