decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.


To read comments to this article, go here
The GPL Barter Cycle - A Graphic - Updated
Tuesday, January 05 2010 @ 01:55 AM EST

In our efforts at Groklaw to explain the General Public License, or GPL, over the years, we've used many words. But the other day I asked if anyone could think of a way to show it graphically, and PolR has done it.

That captures it, don't you think?

Some imagine that it's unthinkable to, as they view it, give away valuable IP for nothing. But, first, it's not giving it away, and second, it's not for nothing. Nor does pooling your code put you out of business. The diagram shows a barter process. This is the key word, because such contributions of code are compensated, but the consideration is not money. It is code. You give a little code, and you get back a lot more.

When people receive back a complete Linux, they have the source code. It lets them make changes and adjustments to suit their purposes more exactly, and then they can contribute those modifications back to the project and all the contributions are then able to be integrated into the project. This ball keeps rolling, and getting bigger, and Linux keeps improving. People contribute because they want Linux to be available and to improve.

There's a fairness to it, which is why it is the most popular FOSS license. And there is a purpose, to make a large body of code available that anyone can improve and enjoy. People build businesses around Linux. Google did. Amazon too. It's great for startups, as Mark Shuttleworth has explained. He built a profitable business, Thawte, using FOSS code. He was asked in an interview about the impact of FOSS:

Jeremy Jones: What impact will free and open source software have on the world?

Mark Shuttleworth: Perhaps a better way to look at this is that free software itself is just one manifestation of a broader change that is happening in the world. 10 years ago we were all extremely excited about connecting the world. And while that job isn't yet done, there are still billions of people who don't have running water or electricity, let alone access to the Internet. But it's clear that we're on a trajectory now to get the whole world connected to the Internet, whether that takes 10 years or 50 years is a matter of social policy and conscience. But we are on that trajectory.

What's happening now, a decade later, is that we're figuring out completely new ways to create work, powered by the Internet. And what we're finding is that it's possible to very efficiently, very effectively, gather together the best thinkers, or the best producers, or the best creators in a particular field and empower them to create something that everybody benefits from. This is clearly true in the field of software, where free software has captured that ideal and that process....

And so us free software guys can be proud of, in one sense, being the first to capture the possibilities of global collaboration around a shared digital commons. But we shouldn't overstate our contribution, that we are ourselves part of a much bigger movement. And over the next few years, I believe that will become increasingly clear. And smart companies, smart individuals will figure out how to make the most of that.

All of this may help one to comprehend why Ransom Love, formerly CEO of Caldera before Darl McBride, said he wanted to Open Source Unix and merge it with Linux:
"When we acquired SCO and Unix, our intention was to see how Unix could expand and extend Linux. In a lot of technologies, Linux was going in slightly different ways, but we thought Unix was the natural companion to it.

"We took the Linux code that was available and learned to cleanly match it with the Unix APIs. The idea was to adopt Linux APIs and mechanisms to function on top of a scalable Unix code designed for SMP [symmetric multiprocessing]. At the time, Linux was moving to clustering to make Linux more scalable. We wanted to combine Unix's improved symmetric multiprocessing with Linux so that it would have both excellent clustering and SMP," he continued.

"Indeed, at first we wanted to open-source all of Unix's code, but we quickly found that even though we owned it, it was, and still is, full of other companies' copyrights," Love added.

Hopefully this will explain why Caldera, now SCO Group, would enter into contracts that involved pooling IP with partners. And it also explains rather simply how high end code ended up in UnitedLinux and Linux, period, don't you think? But how to explain SCO then turning around and suing because SMP and other high end functionality was in Linux? That is the puzzlement.

So what happened? Why wasn't UNIX completely open sourced? Love explained in this longer interview in 2003 by Steven J. Vaughan-Nichols:

Love: The challenge was that there were a lot of business entities that didn't want this to happen. Intel [Corp.] was the biggest opposition.

Vaughan-Nichols: Intel? Why?

Love: I don't know their real reason, but my sense was that they were using Linux against Unix and Sun [Microsystems Inc.]. They wanted to destroy the Unix base on Intel in favor of Linux so Sun wouldn't have a low-end Unix path.

And, of course, there was their love-hate relationship with Microsoft. At the same time, they didn't want to displace Microsoft with a Linux that had the best of both operating systems.

Linux and Unix are highly compatible and should be supportive of each other, but they were being pitted against each other because no one wants to threaten Microsoft. In Intel's case, Windows was also making them too much money.

We didn't want to spend years clearing out the old copyright issues in the face of corporate opposition. So, instead we worked on Linux Kernel Personalities to bring Linux application compatibility to SCO Unix (formerly UnixWare) and OpenServer. The idea was to enable developers to write for both Unix and Linux with a common Application Programming Interface (API) and common Application Binary Interface (ABI). That way developers didn't have to work so hard, and Unix users, the client base we inherited from SCO, could run Linux applications.

We were no longer thinking about mixing code; we were trying to create a common development environment. We were trying to keep the Unix and Linux kernels separate, while tying them to common APIs and ABIs.

And yet SCO, under new management, turned around and threatened Linux end users regarding ABIs. Imagine the world's surprise. How can one explain SCO sending a letter [PDF] to Linux end users in December of 2003 saying that "...the UNIX ABI Code has only been made available under copyright restrictions" and was made available for development for Unix and not for Linux under the GPL. So, which CEO was telling the truth? I direct you to the previous article for some indications.

Hopefully, this graphic will help people to understand the GPL better. There may be other aspects of the way the GPL works that you can express graphically. If so, let us know. PO1R took the penguin image, Tux, from Larry Ewing's site. Ewing lets us use Tux with the following terms:

Permission to use and/or modify this image is granted provided you acknowledge me lewing@isc.tamu.edu and The GIMP if someone asks.
And PolR says you can use his image under the same terms.

Update: Greg Kroah-Hartman describes it beautifully in this interview with LinuxUser:

*What would you say youíve learned from being a Linux kernel maintainer?

*I think the best thing Iíve learned over the years is humility. There is always someone out there that is better than you and can point out problems in your code. And thatís good, because in the end what matters most is the code getting better, and by virtue of that, Linux getting better. The old phrase is, ďThereís always someone smarter than you, and they work for someone elseĒ when it comes to employees at a company. But with Linux, it doesnít matter what company someone works for, they all contribute to the kernel as a shared goal of making it better. And by the individuals making things better, everyone overall gets something that is better as well. I think it is absolutly amazing to see how far Linux has come in the short time it has been around. It now powers over 80% of the worldís top supercomputers, as well as powering the most common cell phone for 2008, with the exact same codebase. Thatís an engineering goal that no one has ever achieved, and one that no one set out to accomplish in the beginning either. Itís only through the thousands of different contributors, and hundreds of companies, all working together to make Linux better for them, has something like this evolved. Itís changed the way people think about software engineering practices, and how large projects can be run and constructed.


  View Printable Version


Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )