Caught in the crosshairs

On March 8, 2010, Linux was caught in the crosshairs once again when the SCO Group went to court against Novell. Both software companies had used Linux, but this so-called "slander of title" lawsuit asserted that Novell was taking the credit for SCO's work. In other words, Linux was successful because of Novell—even though SCO allegedly purchased the copyrights from them in 1995.¹

How can an open-source program get in the crosshairs of something like this? It's a wonder that this sort of mess hasn't happened more often. It's true that Linux falls under the GNU General Public License, which allows anything registered under it to remain in the public domain. In other words, it protects a product from users who want to make money off it by making it a brand name (like Windows or Mac OS). But Linux is loosely based on Unix, which Novell bought from AT&T in 1993. ² Whoever owns Unix ultimately cashes in on Linux's success. So the questions are as follows:

1: Who owns the copyrights?
2: Who owns the intellectual property (IP) rights?

This isn't the first time that SCO took a corporate giant to court. In 2003, they filed a three-billion-dollar suit against IBM for plagiarizing SCO's Unix code. But according to Eric Raymond—programmer and author of Cathedral and the Bazaar—SCO had put its code into the public domain, much of which was already obsolete and incompatible with Linux. Interestingly, IBM filed a suit against SCO that same year.³

Four years went by, during which SCO took Novell to court. But on August 12, 2007, Judge Dale Kimball ruled that Unix was Novell's intellectual property.⁴ This damaged SCO's case on the first major front: by removing their IP rights, the court essentially put the remaining rights into Novell's hands. IP rights are critical in a case like this; if someone's property is his own invention and idea, it makes sense that his copyrights would be his own, too.

That is, unless he sold them and confirmed the sale in writing.

This was the basis for the March 2010 case, in which SCO testified that Novell wanted to sell the Unix copyrights. If SCO were right, then they would cash in on Linux's success. Novell asserted that they didn't actually sell them, and the lawyers who wrote the original agreement specified that Novell would sell Unix and keep the copyrights.⁵

The case ended three weeks later, on March 30, 2010. By unanimous vote, the jury found that Novell never transferred the copyrights.⁶ Both the copyrights and IP rights remain in Novell's hands, and Linux is out of the crosshairs of a messy lawsuit. A case like this demonstrates the differences between truth and lies: Truth stands up to scrutiny, but lies will always fall apart under pressure.

--

Works Cited

1. SCO versus novell trial opens.

2, 5. Groklaw - Day 2 of the SCO v. Novell Trial.

3. Linux Lawsuit.

4. SCO appeals Unix ownership decision.

6. Groklaw - Novell Wins Again.

Can Open Source go to the moon?

In 2007, Fred Bourgeois announced that he would contend for the Lunar X prize by building a spacecraft and sending it to the moon by 2012.¹ But this space race came with a twist: in the style of Linus Torvalds, he put the project online and made it accessible to anyone who wanted to participate. An open-source space race would certainly prove that mankind can achieve whatever he wants to. But as the details of Team FredNet show, mankind isn't immune to every setback.

First, no amount of technical ingenuity can take the place of the project's greatest need: money. In a 2008 interview with NPR, Bourgeois said that the cost of a launch is as much as $10 million.² The cost of a single launch is significant, but if the launch fails, the fundraising would start all over again.

A project needs planning, resources, and money to succeed. Without grants and tremendous third-party sponsorship, the project won't go far. This is where the drawbacks of open-source emerge: asking people to donate the money for a project of this size is a long shot. Open source works great for development and design, but it doesn't always bring in the money.

Second of all, Team FredNet doesn't offer a goal to justify the project. After forty years of government-funded space missions, what would set this apart? What would motivate us to support this team out of all the other teams contending for the prize? Most importantly, what would they do with the money if they won? Bourgeois gave the answer in his announcement:

"Ultimately, we're going to build a city on the Moon.  I'm not sure if you can do that with only $20 to $30 million but it is a good start.  I would hope to use that money to establish a foundation to pursue the longer term goal, incrementally of course.  We're building a lot of the methods, systems and processes that we're going to need for further projects just by doing this one, but probably even more importantly we are building a community of people with expertise in actually doing a space project.  The goal of the foundation will be to utilize that expertise to accomplish the next goal, and the next."³

But what are those goals? If going to the moon is the means to an end, then what's the end? They say that they want to help "save the earth,"⁴ but they never say what that means or how they'll do it. It's a waste to spend money on projects that don't solve the problems facing our world.

An open-source space race is a great concept, but how you do it makes the difference. Team FredNet has gone in with gusto and vision, but their goals don't justify the project. Moon missions have already been done, and the only major difference between NASA and Team FredNet is that FredNet is doing it open-source. Furthermore, any good project has to fill a need; the team hasn't indicated that they want to fill a need, but instead want to go for a prize and a place in the history books.

Team FredNet's website encourages people to join the project and "become a part of history."⁵ If and when they get their rover to the moon, I won't be a bit surprised. I'll even applaud them. But based on their long-range goals and reasons for the project, I won't donate, and I won't encourage others to donate. Getting the public involved in science and space exploration is a great concept, but if they're doing it just to further their goals, then there are simply better projects and causes to support.

--

Works Cited:

1, 3. "First Press Release."
2. "Open-source Crowd Shoots for the Moon."
4. "Interview with Fred Bourgeois, 2007/09/28."
5. "Team FREDNET."

Numbering the Linux kernel

As of October 10, 2010, the most stable kernel release is 2.6.35.7.¹ Using this number, here's how the numbering scheme works. The 2 stands for the second big update in the kernel's design. The 6 stands for important modifications to 2. 35 stands for smaller modifications; since it incorporates new features and drivers that go into a solid release, the third number in the series defines the most current kernel. (This is different from a version--the 2, in this case--which indicates a major revamping of the kernel's code.) The 7 stands for a set of very small modifications--most of which are on the level of typos and debugging.²

Until 2004, the development of stable and unstable releases was numbered differently. When the kernel version was unstable, the second number was odd; months of development and debugging would then follow until they finished an even-numbered stable release. But this pattern ended in 2004; by then, development and testing weren't falling into an easy "even is stable, odd is unstable" pattern. From then on, the numbering system became what it is today.

However, in 2008, Linus Torvalds suggested changing the numbering scheme to match the date somehow:

"If the version were to be date-based, instead of releasing 2.6.26, maybe we could have 2008.7 instead. Or just increment the major version every decade, the middle version every year, and the minor version every time we make a release. Whatever. I could also see the second number as being the 'year', and 2008 would get 2.8, and then next year I'd make the first release of 2009 be 2.9.1 (and probably avoid the '.0' just because it again has the connotations of a 'big new untested release', which is not true in a date-based numbering scheme). And then 2010 would be 3.0.1 etc.."³

But since the most recent kernel doesn't have a 3.0.x.x number, the numbering system hasn't used either of these formats.

The numbering system today is effective and flexible because it keeps track of the changes as time goes by. Updating the first number every time a minor update is released isn't efficient; having lesser numbers stand for different levels of revision keeps the first number small and the system easier to understand. But as you can tell from all the sources, it took a bit of research to find out what each number means. Another disadvantage I see is that unless it's established what constitutes a major or minor change, the number could be updated unnecessarily (e.g., because a few comments were added). So unless a new system is discovered--one that works better than the system in use today--
the current system works fine, and there's no need to change it.

-----

Works Cited:


1. The Linux Kernel Archives.

2. Linux kernel version numbering.

3. Kernel Release Numbering Redux.