So why am I publishing yet another tutorial on this topic? Well, I am not an electrical engineer. I make tonnes of wiring mistakes, and I should have killed my Arduino many times over by now. This is acceptable for a $27 microcontroller platform, but not for the Lego Mindstorms (which is an order of order of magnitude more expensive). So I set out to find a safe way to isolate Arduino wiring errors from the Lego controller brick.

Watchword: Galvanic Isolation

So we want the Arduino to talk to the Lego Mindstorms, but we don’t want shorts and other errors to propagate to the Lego device. This is the perfect situation for something called Galvanic Isolation. Quoting Wikipedia:

Galvanic isolation is a principle of isolating functional sections of electrical systems, thus preventing the movement of charge-carrying particles from one section to another, i.e. no direct current flows between the sections. Information can still be exchanged between the sections by other means, e.g. capacitance, induction or electromagnetic waves, or by optical, acoustic or mechanical means.

So, galvanic isolation allows information to be exchanged without the exchange of electrons. This is exactly what we need.

I2C Serial Communication

Ok, so we know we want galvanic isolation to protect the NXT from the Arduino — but what kind of communication needs to take place? Well, it turns out that the Lego NXT brick uses the I2C serial bus for low-speed (9600 bps) communication with some advanced sensors (e.g., the ultrasonic rangefinder). Fortunately for us, the Arduino can also speak I2C with the help of the built-in wire.h library. There are many tutorials describing how this can be accomplished.

So how do we galvanically isolate the I2C serial bus? Well there are actually several approaches for this (e.g., see the article Opto-electrical isolation of the I2C-Bus). Many of these approaches are complex, and require a number of components. Fortunately, there are several one-chip solutions. In this article, I use the Silicon labs Si8400, but I have heard reports that Analog Device’s ADUM1250 is pin compatible (Thanks Anton for pointing this out!).

Note 1: The NXT’s I2C interface has some very peculiar requirements — namely, the use of very high 82K Ohm pull-up resistors.

Note 2: In this schematic there are no pull-up resistors on the Arduino side. This is because Arduino’s wire.h library enables the AVR atmega’s internal pull-up resistors.

Note 3: The Si8400 is only available in the SOIC-8 surface mount package form. You will need a SOIC-to-DIP breakout board (e.g., see ShmartBoard‘s offerings) to use this chip in standard 0.1″ perfboard.

Arduino Code

/*
  * Adapted from Gatsu's post on Arduino's forums:
  * http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1262353163
  */
#include <Wire.h>

int ADDRESS = 0x43;   // The Arduino's I2C Address

uint8_t SensorVersion[9]  =    "V0.1    ";
uint8_t SensorName[9]     =    "Arduino ";
uint8_t SensorType[9]     =    "Exprmntl";

byte x = 0;
byte val = 0;
byte sendbuffer[] = {0};

void setup() {
    Wire.begin(ADDRESS);
    Wire.onReceive(receiveEvent); 
    Wire.onRequest(requestEvent);
}

void loop() {
  // This could be any code used to read a sensor.
  // In this simple example, we just count up once a second
  val++;
  delay(1000);
}

void receiveEvent(int howMany) {
    if (Wire.available() >0 ) {
        x = Wire.read(); // receive register address (1 byte)
    }
}

void requestEvent() { 
    if (x == 0x00) {   
        Wire.write(SensorVersion, 8); 
    } 
    else if (x == 0x08) {   
        Wire.write(SensorName, 8); 
    }
    else if (x == 0x10) {
        Wire.write(SensorType, 8); 
    }
    else if (x == 0x42) {
        sendbuffer[0] = val;
        Wire.write(sendbuffer, 1); 
    }
}

Mindstorms Code (LeJOS 0.9)

Note 4: This code reports a “Bus Error” whenever the NXT cannot find the Arduino on the serial bus. There are a variety of potential causes for this error. In my experience, the first problem to rule out is that of mismatching I2C addresses. Due to some addressing incompatibilities, the LeJOS code must address the Arduino at an address which is twice the value declared in the Arduino code (i.e., left shifted one bit). See the comments in the code below for more details.

Note 5: The latest LeJOS build (v0.9.1) changed the LeJOS API again. The necessary changes are documented below.

import lejos.nxt.*;

public class TalkToArduino {

     /* The Lego/NXT uses 8-bit I2C addresses in the range 0x02-0xFE,
      * where the low bit is always zero. Many devices (like the Arduino) 
      * use 7-bit addresses in the range 0x01-0x7F. To compensate, 7-bit
      * addresses must be shifted left one place (multiplied by 2).
      * This issue cost me hours of frustration.
      */
    private static int ARDUINO_ADDRESS = 0x43 << 1;

    public static void main (String[] args) { 
        I2CSensor arduino = new I2CSensor(SensorPort.S1); 
        arduino.setAddress(ARDUINO_ADDRESS);

        byte [] buf = new byte[1];
        buf[0] = 0;

        LCD.setAutoRefresh(false);

        while(!Button.ESCAPE.isPressed()){
            LCD.clear();
            int result = arduino.getData(0x42, buf, 1);  

            if (result == -5) {
                LCD.drawString("Not connected", 0, 0);
            }
            else if (result == -3) {
                LCD.drawString("Bus error", 0, 0);
            }
            else {		           
                LCD.drawString("Name:    " + arduino.getProductID(), 0, 0);

		// If LeJOS version 0.9, then use this line                     
                LCD.drawString("Type:    " + arduino.getSensorType(), 0, 1);
                
                // Else if LeJOS version 0.9.1 and above, then use this line instead of the previous                     
                // LCD.drawString("Vendor: " + arduino.getVendorID(), 0, 1);
                
                LCD.drawString("Version: " + arduino.getVersion(), 0, 2);
                LCD.drawString("===============", 0, 3);
                LCD.drawString("Value: " +  buf[0], 0, 4);
            }

            LCD.refresh();
            try{Thread.sleep(100);}catch(Exception e) {}
        }
    }
}

Other resources

• LeJOS Website
• Arduino wire.h library documentation
• Wikipedia Lego NXT Entry (with cable pinout)
• Si8400 on Mouser
• ADUM1250 on Digikey
• Arduino as Lego Mindstorms NXT RC Sensor (Arduino Forums)
• Lego Beyond Toys (Several projects in the 2009 offering use Arduino)
  — PS: I like the WordPress theme they chose!

“10. Placating people with options. In any software project with multiple contributors, sometimes they will disagree on a design issue. Where the contributors are employees, usually they’ll continue work even if they disagree with the design. But with volunteers, it’s much more likely that the project maintainer will agree to placate a contributor by adding a configuration setting for the behavior in question. The number, obscurity, and triviality of such preferences ends up confusing ordinary users, while everyone is penalized by the resulting bloat and reduced thoroughness of testing.” — mpt

And,

“14. Mediocrity through modularity. Free software hackers prize code reuse. Often they talk of writing code to perform a function, so that other programmers can write a “front end” (or multiple alternative “front ends”) to let humans actually use it. They consider it important to be able to swap out any layer of the system in favor of alternative implementations.

This is good for the long-term health of a system, because it avoids relying on any single component. But it also leads to a lack of integration which lessens usability, especially if the interfaces between the layers weren’t designed with usability in mind.” — mpt

Ok,  keeping those points in mind, have a look at the following partial transcript of Paul Davis’ interview. Note, Paul is cognizant  of the issues, but the problems remain quite challenging to overcome. (Sorry for any transcription errors. This interview is just filled with amazing points on usability!)

[Starting at 8:44]
Jono: So, with Ardour — I come from a Q-base background. I use Q-base in my studio, and I’ve always found it pretty easy to use, and I’ve never really got on with pro-tools either; I found it a little bit too complex — I remember a while back I evaluated Ardour as an option to move over to Linux, and I found it very very complex. Is the back-end and the front-end sufficiently separated so you can kind of put some lipstick on it and make it easy to use.

Paul: Yes. You absolutely can. … And so it’s quite possible to imagine that, if somebody wanted to put the work into making a super simplified version of an Ardour interface, then you could do that still based on that back-end.

Jono: And is that a project that you are actively working on. Because, I tried Ardour fairly recently. I’m running the development version of Ubuntu and I installed it from Ubuntu, so it’s a pretty recent release. And I still found I could feel my eyeballs spinning around due to the complexity of the interface. Like I don’t care about bits and streams and any of these details. I just want to record music.

Paul: No it’s not a direction that currently I or any of the other developers are really paying too much attention to. We are very focused on workflow issues. Which is where people can identify specific tasks that they need to perform with the software. We definitely want to make sure that the task is accomplishable with a minimal number of mouse clicks and keyboard operations and so-on.

But, the general goal of trying to create a program that, for example is as easy to use as GrarageBand, which I think is a very nicely designed program for people who are new to this sort of stuff, that’s not a goal that we have right now. I think its quite a difficult problem to solve.

My experience so far has been that most people who use digital audio workstations have a list of things that they would like to be able to do very easily, and they believe that the program that is before them ought to do those things very easily. And they are right. The problem is that there is a whole bunch of other people who have their own list of things that it ought to be able to do very easily and straightforwardly. And, when you take the union of all these lists, you end up with a program that looks like pro-tools or like Ardour.

So you end up having to make some choices at some point where you  say, okay we are absolutely not going to cater to the following types of goals. We are going to limit it entirely to this set of things. And my experience so far is that when you do that you immediately run into the wrath of the user who says ‘well it was great, I got started nice and quickly and I understood how to use it but it doesn’t do this ?!? Are you crazy?’

So we haven’t really resolved that and for the moment we’re happier working on Ardour 3.0, which we can talk about as we roll along, as apposed to figuring out how we can build a really simple interface that is sort-of roughly equivalent to GarageBand. I think another way to put it is that for me, in the back of my head, I’m writing Ardour catering to audio engineers or musicians who have audio engineering skills. I’m not really writing it with the idea of targeting musicians who just don’t do that sort of thing.

Jono: So just to clarify, you’re kind of going for the professional and the semi-professional audio engineer. Kind of, those people who are passionate about audio. People who want to produce bands professionally, as opposed to kind-of the hobbyists with a laptop who just wants to put down some guitar riffs.

Paul: Yes. Yeah, that’s certainly our general goal. And I would say that I’m quite happy to come across quite significant amounts of feedback from new users who do report back to us saying ‘Oh, it was really great. I just clicked a few buttons and it all worked’. Certainly we are happy when that happens, but there is not a lot of effort going into making things really easy for that second group that you mentioned.

Jono: Some time ago, when I was looking into Ardour, and I thought it was a bit too complicated, I formed a project called Jokosher — a simplified multitrack editor. I’m really interested int he fact that you said that the back-end is completely separate. Because Jokosher was kind of build from the perspective of just throw away all the assumed knowledge of audio engineering and think of it from a completely new usability standpoint. So are you saying that we could conceivably take Jokosher interface and hook into the Ardour back-end?

Paul: Yes. You can do that. In fact, there is already a project whose name I wish I could give you right now but I can’t. There is a project that took libardour — which is basically our back-end — and I think that that project has died. There is no activity with it now. But they were attempting to build a completely modular workstation system where, rather than everything being one program, there were completely separate applications with their own windows and so-on. And that was built on Ardour’s back-end. (…)

So yeah. It’s completely possible to do that. The only thing I would say is that, of the current code-base of Ardour, approximately 75% of all the code  is the GUI. So, once you get up to talking about a fairly rich user interface with lots of things that pop up and bits that control ability, you will will probably get into a situation where you realize that the back-end is actually not that much code. And, the really hard work is actually implementing the user interface.

The story begins with Eric S. Raymond trying to configure CUPS (Common Unix Printing System) to print to a shared printer cue on a remote machine. In the process, Raymond became frustrated with the usability issues of this process, and so he decided to write the essay “The Luxury of Ignorance: An Open-Source Horror Story“. In this essay, Raymond describes some legitimate usability issues; but the tone of the essay was highly condescending to almost everyone. Repeatedly he describes the need to better design interactions to make Linux more accessible to “dumb clueless users” (his words, not mine). As we will see in the other blog posts (not yet mentioned), it is actually quite challenging to attract good designers to open source projects. Perhaps attitudes like Raymond’s are part of the problem: above all, a good designer knows to respect their users. This can be contrasted to Raymond’s suggestion that designers “sit down at the system like a dumb user who’s never seen it before”.

Anyways, I digress from the story. So a few days after posting the aforementioned easy, Raymond post a follow-up entitled “The Luxury of Ignorance: Part Deux”. In this essay, Raymond described positive feedback to the first essay, and notes that he received numerous emails with comments such as “Gee. And all this time I thought it was just me.” At this point, Raymond’s essay get the attention of John Gruber over at Daring Fireball. Gruber’s reaction is more inline with my own. Specifically, he notes:

“Developing software with a good UI requires both aptitude and a lot of hard work. Raymond acknowledges neither.”

And later,

“If there’s a glib, nutshell synopsis for why Linux desktop software tends to suck, it’s this: Raymond and his ilk have no respect for anyone but themselves.”

But it’s more than that. Gruber goes on to point out that it wasn’t just the “dumb users” who had trouble configuring CUPS, it was Raymond himself, along with other UNIX geeks who read his blog. The problem is certainly much deeper than Raymond realizes. On this note, Gruber wonders how Raymond could write an essay on FOSS usability problems but not mention Matthew Paul Thomas’s (apparently well-known) blog post “Why Free Software usability tends to suck“. This is where things get really interesting.

In Matthew Paul Thomas’s (M.T.P) blog post, he describes 9 hypothesis or observations why might help to explain some of the usability issues common to many free and open source software projects. While these are interesting in their own right, M.T.P’s follow up essay “Why Free Software has poor usability, and how to improve it” expands the list to 15 items, and represents six years of reflection on this topic. As such, I will be focusing on this later piece. In brief, the 15 reasons are as follows:

1. Without monetary reward (e.g., salaries), there are few incentives to do usability work in FOSS.
2. It is difficult to attract good designers. (Noted above)
3. Related to 2., design suggestions are not welcomed by developers.
4. It is difficult to measure success or improvements to usability.
5. In FOSS, projects are started by Coders. Design is tacked on later.
6. With many people voicing design decisions, it’s hard to maintain a unified and consistent design trajectory.
7. FOSS software tends to simply imitate proprietary interfaces.
8. Developers work on parts of the system that they are interested in. Design is often not of interest.
9. Small usability errors are often assigned low priority, and fixes are delayed.
10. Project leaders often agree to add new options and configurations to placate the many volunteer contributors.
11. Every developer want to have their “15 pixels of fame” on the GUI.
12. FOSS communication channels are not suitable for doing design work.
13. Release early, release often means that early adopters get used to poorly thought-out designs.
14. Developers often code “back end” functionality, assuming usability issues will be addressed by those writing a “front end”.
15. FOSS software often interacts with other FOSS software from different projects — but the communities rarely communicate.

Ok, that’s the long list of M.P.T’s points. I’m sure I’ll be discussing some of these in more detail in future posts.

• Scacchi, W. 2007. Free/open source software development: recent research results and emerging opportunities. In the 6th Joint Meeting on European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering: Companion Papers (Dubrovnik, Croatia, September 03 – 07, 2007). ESEC-FSE companion ’07. ACM, New York, NY, 459-468.

• Ye, Y. and Kishida, K. 2003. Toward an understanding of the motivation Open Source Software developers. In Proceedings of the 25th international Conference on Software Engineering (Portland, Oregon, May 03 – 10, 2003). International Conference on Software Engineering. IEEE Computer Society, Washington, DC, 419-429.

• Ducheneaut, N. 2005. Socialization in an Open Source Software Community: A Socio-Technical Analysis. Comput. Supported Coop. Work 14, 4 (Aug. 2005), 323-368.

I will refer to these papers as [Scacchi], [Ye], and [Ducheneaut] respectively.

The [Scacchi] paper is basically a literature review of research studying a vast range of aspects related to FOSS development. For example, the paper discusses everything from the ad-hoc arrangement of personal resources (computers, bandwidth etc.) contributed to projects, their trust and accountability mechanisms, the systems for supporting cooperation and coordination, and even a discussion of the beliefs supporting FOSS development. On this note, one of the more interesting findings is that developers enjoy various freedoms that are not typically discussed in the literature. These freedoms include choice of:

• What problem to work on.
• What tools to employ.
• When to release products.
• When and what to review.
• “What can be said to whom or without reservation.”

Another really interesting take-home message from this paper is that people participate in FOSS projects for a variety of complex reasons –but gaining “social capital” is one major contributor.

This notion of gaining social capital is also expressed in the [Ye] paper. This paper argues that the learning theory of “legitimate peripheral participation” is “one of the major motivational forces that attract developers and users to participate in OSS development”. Don’t let the name fool you. The motivation is not simply to learn, but instead to move from “apprentice” to “master” through participation in the community. Along with the new skills acquired, the apprentice gains social capital as they move through the ranks. I would argue that this latter point is the stronger motivation, and I think the authors would agree — otherwise there would be no way to explain the motivation of the “masters” or “core developers”. Regarding this point, Ye et al. argue:

“By establishing their own identities or shaping the identities of others through voluntary participation in the community practice, members help reproduce and preserve the community. This process is also in their own interests because their identity, skills, and reputation as master rely on the continuous existence of the community. Therefore, from the perspective of the community to which each member belongs, an individual’s altruistic behavior is ‘altruistically’ selfish and ‘selfishly’ altruistic” [Ye]

Later, on the same topic, the authors add:

“Relying purely on altruism makes OSS unsustainable. Intrinsic motivation is positively reinforced and amplified when social structure and conventions of the community recognize and reward the contributions of its members.” [Ye]

This idea of “selfish altruism” appeals to me as a leading hypothesis as to why people participate in these online communities. Specifically, one should not undervalue the importance or the appeal of belonging, and of being recognized and appreciated by a community.

This brings us to the final paper by Nicolas Ducheneaut. This paper stresses the dynamic nature of a FOSS project’s community, and describes (in detail) the various trials a new developer must face in order to achieve “core developer” status. On this topic, the paper follows the trajectory of two aspiring developers: one who achieves core developer status, and one who does not. Importantly, this paper makes it clear that the aspiring contributors are already very skilled developers who may bring well-developed (complete, or nearly complete) contributions. Nevertheless, it requires a tremendous amount of additional effort to successfully incorporate these additions into the project trunk. This would seem to suggest that learning alone cannot fully explain the motivation of successful FOSS developers; it is difficult to argue that significant technical learning is taking place when the hurdles are chiefly political and bureaucratic.

Apache

• Apache was, for the most part, entirely volunteer driven. All the core project members had other “day jobs”.
• Coordination between core members was done almost exclusively through the developer mailing list.
• The core apache group (AG) has between 8 and 25 members. At the time of the study, the AG had 12 members.
• At any given time, 4 to 6 members of the AG were actively writing code alongside 2 to 3 AG nominees (highly active, non-AG developers).
• There was little evidence of code ownership. AG members were trusted to modify any parts of the code.
• Over 400 developers contributed some code.
• 15 developers (the “core developers”) contributed 83% of the CVS commits for new functionality.
• 15 developers produced 66% of the code related to bug fixes.
• Over 3000 contributors submitted about 4000 problem reports. 591 of those problem reports resulted in a code (or documentation change)
• The top 15 problem report submitters contributed only 5% of the total PRs.
• Reported problems are typically addressed very quickly (depending on priority), with half of the problem reports being corrected within a single day.

Mozilla

• Mozilla had a number of payed employees, many of them originally from Netscape.
• Code ownership was strongly enforced. For each of Mozilla’s modules, one developer (the module owner) was responsible for reviewing and committing changes.
• Mozilla modules had 22-35 core members. I.e., 22 to 35 people wrote 83% of the code for new functionality.
• Apache had 76 or modules. For each module, between 87 and 174 people contributed code.
• 6837 contributors submitted about 58,000 problem reports. 11,616 of those problem reports resulted in a code (or documentation change)
• The top 113 submitters reported 50% of all problems. Only 25 of these were external. There were formal testing teams tasked with finding problems.
• Reported problems required longer to fix. This was mostly because all changes needed to be approved by the module owners.

Hypotheses

From these two studies, the authors made the folowing 7 hypothesis for OSS projects in general (quoted directly, and included in this summary for completeness):

“Hypothesis 1a: Open source developments will have a core of developers who control the code base, and will create approximately 80% or more of the new functionality. If this core group uses only informal, ad hoc means of coordinating their work, it will be no larger than 10-15 people.

Hypothesis 2a: If a project is so large that more than 10-15 people are required to complete 80% of the code in the desired time frame, then other mechanisms, rather than just informal, ad hoc arrangements, will be required in order to coordinate the work. These mechanisms may include one or more of the following: explicit development processes, individual or group code ownership, and required inspections.

Hypothesis 3: In successful open source developments, a group larger by an order of magnitude than the core will repair defects, and a yet larger group (by another order of magnitude) will report problems.

Hypothesis 4: Open source developments that have a strong core of developers but never achieve large numbers of contributors beyond that core will be able to create new functionality but will fail because of a lack of resources devoted to finding and repairing defects.

Hypothesis 5: Defect density in open source releases will generally be lower than commercial code that has only been feature-tested, i.e., received a comparable level of testing.

Hypothesis 6: In successful open source developments, the developers will also be users of the software.

Hypothesis 7: OSS developments exhibit very rapid responses to customer problems.”, [Mockus, et al.]

Compared to “free software” (circa. 1984), the term “open source” is relatively new. The term came out of a 1998 meeting at the offices of VA Research as part of a strategy to market free software to the business world:

“(This strategy was) conceived as a program to market the free software concept to people who wore ties.” — Bruce Perens

This meeting was in response to Netscape releasing its web browser as free software — a decision largely influenced by Eric Raymond’s essay ‘The Cathedral and the Bazaar’.  Recognizing that Netscape Navigator would be the first case study of commercial free software, Raymond posited that the community could not afford to let Netscape fail. Additionally, Netscape would also be setting an example for other businesses to follow. Hence, the VA Research meeting was called in order to devise strategies to leverage these recent events and to make free software more appealing to businesses. The main part of this strategy was to rebrand free software as ‘open source’ (in part, to distance themselves from the Free Software Foundation, whose philosophies were not considered conducive to business).

Notably absent from this meeting was Bruce Perens. At the time, Bruce Perens was the community leader of the Debian project. One day after the meeting Raymond recruited Perens, and the pair founded the Open Source Initiative. One of the first orders of business was to establish the open source definition. This definition was based on the Debian Social Contract, and includes statements on the following 10 topics (which I do not discuss here in any detail):

1. Free distribution
2. Access to source code
3. Distribution of derived works
4. Option to maintain integrity of author’s source code
5. No discrimination against persons
6. No discrimination against fields or endeavours
7. Distribution of license (I don’t quite fully understand this point)
8. Licence must not be specific to a product
9. Licence must not restrict other software
10. License must be technology neutral

Importantly, the open source marketing campaign was highly successful. The mass media was frequently discussing open source in the late 1990’s and early 2000’s. Moreover, many businesses (e.g., IBM) embraced open source.

However, almost immediately after establishing the Open Source Initiative, the movement was controversial. Advocates of free software felt that the open source movement was abandoning the principles established by the free software foundation. Moreover, by marketing with the term ‘open source’, newcomers would not fully appreciate the freedoms that free software has granted. As such, they would not know how to fight to protect those freedoms. On this topic, Stallman writes:

The philosophy of open source, with its purely practical values, impedes understanding of the deeper ideas of free software; it brings many people into our community, but does not teach them to defend it. That is good, as far as it goes, but it is not enough to make freedom secure.

He also writes:

To spread this idea, we have to talk about freedom. A certain amount of the ‘keep quiet’ approach to business can be useful for the community, but it is dangerous if it becomes so common that the love of freedom comes to seem like an eccentricity.

This latter sentiment is reflected almost exactly in Bruce Perens’ essay ‘It’s Time to Talk about Free Software Again‘. Bruce Perens left the Open Source Initiative only a year after founding it with Raymond. Here, I get the feeling that Perens has some regret about those early years. In one of his essays, he notes that the dialog between Stallman and Raymond become so heated, and the community so divided, that he asked Raymond to tone down the rhetoric.

Sadly, open source and free software cover almost exactly the same body of work. The open source definition is slightly more permissive than the free software definition, but most software in this area qualifies as both free software and as open source software. As such, the conflict is largely unnecessary.

GPL v3 vs. Previous Versions

According to the FSF document ‘A quick guide to GPLv3‘, and supported by excerpts from  an audio interview with Eben Moglen, the GPLv3 differs from its predecessors in three important ways:

1. Internationalization. Previous versions of the GPL were very US-centric, and were based on US copyright laws. In writing the GPLv3, much attention was paid to ensuring that the GPL is internationally enforceable. This could prove to be very important reason to use this newer version of the license. Then again, previous versions of the GPL seem to have stood the test of time even when used internationally.
2. Clauses to prevent Tivoization. This is a terrible term, but basically, the GPLv3 ensures that, should a device manufacture choose to use GPL’ed software, they must ensure that users can continue to modify the software, and that modified versions will actually run on the device. This is clearly in the spirt of the GPL, and I think it is a very important (albeit, highly-specific) point.
3. Clauses regarding DRM. My understanding of the GPLv3 is that it allows developers to implement new DRM techniques in GPL’ed software, but goes on to state that this DRM cannot be considered an ‘effective measure’ for preventing copying. Basically, this ensure that DRM in GPL’ed software will never fall under the enforcement of the Digital Millennium Copyright Act. I think this is a very clever clause, and I am very much in agreement with the FSF on this point. However, it is highly political: no company would be crazy enough to implement DRM in open source software because it would be ineffective. DRM relies on security through obscurity for protection (since any device that allows playback has all the tools needed to circumvent the DRM… its just that this capability is very well hidden and hard to reverse engineer). By open-sourcing DRM, companies would basically be opening the kimono.
4. Patent clauses. The GPLv3 also includes numerous clauses to protect developers and users from patent litigation. Specifically, if a company modifies and contributes to GPL’ed software, and then uses patent law to litigate against other developers and users, then the company’s license to the software is revoked. I must admit that I don’t fully understand how this works.
5. Increased compatibility with other licences. The GPLv3 allows users to make small changes to the default terms and conditions of the license. This is designed to make GPLv3 more compatible with other licences (like the Apache licence). This is one possible response to addressing the problem of license proliferation. However, critics argue that this will only increase the number of license variations, and will make the problem worse. On this topic, Eben Moglen believes that there will initially be many variations that are tried, but (as is the case with other forms of law), a few variations will become standard; hence, there will be increased compatibility without contributing much to the proliferation problem.

GPLv3 Controversy

Ok, so those are the 5 major ways in which GPLv3 differs from previous version. These differences have been somewhat controversial in the FLOSS community. Most notably, the Linux Kernel developers have been very outspoken as to why they will not adopt  v3. On this topic, they published a position paper. This paper is based on an early draft of GPLv3 — it is not clear how their position may have changed in regards to the the licence’s final draft. In any case, the kernel developers take issue with almost all of the 5 points outlined above. Unfortunately, the position paper lacks specifics. Some of the objections become more clear in Linus’s postings [1][2] to the kernel developer mailing list. For example, on the topic DRM, Linus writes:

“I’m very much on record as not liking (DRM). That changes nothing. I’m also very much on record as saying that DRM, TPC etc have nothing at all to do with the kernel license. If you want to fight DRM, do so by joining the Creative Commons movement. (…) The whole ‘content’ discussion has nothing to do with an operating system. Trying to add that tie-in is a bad idea. It tries to link things that aren’t relevant.”

“BSD-Style License”

The FSF writes:

“The expression ‘BSD-style license’ leads to confusion because it lumps together licenses that have important differences. For instance, the original BSD license with the advertising clause is incompatible with the GNU General Public License, but the revised BSD license is compatible with the GPL.”

The original version of the BSD license (with the advertising clause) was rescinded over ten years ago. Go ahead. Call these licenses “Modified BSD-style” if you must; but, at present, there is not much risk of confusion.

“Content”

The FSF writes:

“If you want to describe a feeling of comfort and satisfaction, by all means say you are ‘content,’ but using the word as a noun to describe written and other works of authorship adopts an attitude you might rather avoid. It regards these works as a commodity whose purpose is to fill a box and make money.”

Alright. This is ridiculous.  The second (noun) definition of “content” offered by Merriam-Webster dictionary reads “the topics or matter treated in a written work <table of contents>”. Let me use this word in a sentence: I find some of the content this FSF article to be objectionable.

“Linux system”

The FSF writes:

“Linux is the name of the kernel that Linus Torvalds developed starting in 1991. The operating system in which Linux is used is basically GNU with Linux added. To call the whole system ‘Linux’ is both unfair and confusing.”

Ok, so this is the subject of a well-known religious war. Here I firmly state that I am opposed to rebranding Linux as GNU/Linux. While I definitely appreciate the history of GNU and of Linux, and I understand Stallman’s reasons for the rebranding campaign, I have chosen sides for various reasons:

• Primarily, the GNU name is plastered throughout Linux (e.g., GNU prefixes, gzip, gcc, gmake, glibc, GIMP, GNOME, GEdit, etc.). For users of Linux, GNU’s contributions will not be overlooked.
• Moreover, it is increasingly common to brand Linux by it’s distributions (e.g, Ubuntu, Red Hat, Fedora, Debian, etc.). If the Linux Kernel is indeed the only missing piece of a GNU system (and I’m not arguing against this stance), then perhaps FSF should distribute a GNU-branded complete system which they are free to name whatever they want.
• It is easy to argue that Linux’s early success is due, in large part, from the success of other non-GNU projects such as Apache. More recently, Linux is making great strides in desktops and mobile devices because of amazing web browsers. Specifically, Mozilla Firefox and KHTML (or WebKit). Yet, we don’t field complaints for rebranding things to “Apache/KDE/Mozilla/GNU/Linux”.

“Protection”

The FSF writes:

“Publishers’ lawyers love to use the term ‘protection’ to describe copyright. This word carries the implication of preventing destruction or suffering; therefore, it encourages people to identify with the owner and publisher who benefit from copyright, rather than with the users who are restricted by it.”

In fact, I think “protection” is a reasonable and natural word to use when discussing copyrights. After all, the preamble of the GPL v3 uses variations of the term “protection” in no fewer than 5 places. For example:

“For the developers’ and authors’ protection, the GPL clearly explains that there is no warranty for this free software.”

Linus Torvalds

Linus Torvalds was the original author, and is presently the chief architect and engineer of the Linux kernel.  The Linux project was started in 1991-1992 while Linus was studying at the University of Helsinki. The project started out as a hobby but later became Linus’ Masters thesis. As quoted in Glyn Moody’s book Rebel Code, an early newsgroup posting regarding Linux begins:

“I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) clones. This has been brewing since April, and is starting to get ready.” — Torvalds, as quoted by Moody, pp. 42

On the same topic, a later newsgroup posting reads:

“I can (well, almost) hear you asking yourselves `Why?’. Hurd will be out in a year (or two, or next month, who knows), and I’ve already got minix. This is a program for hackers by a hacker. I’ve enjoyed doing it, and somebody might enjoy looking at it and even modifying it for their own needs.” — Torvalds, as quoted by Moody, pp. 45

In Rebel Code, and elsewhere (e.g., Linus’ Wikipedia Entry), Linus is often described as a pragmatist. The Wikipedia article notes that Linus simply “uses the best tool for the job”, noting that Linus believes the open source model to be the best model for developing software. This pragmatism is evidenced by the fact that the Linux source repository was, for years, hosted using the proprietary BitKeeper revision control system. In regards to the licensing of Linux, the project was not always distributed under the GPL; in the early days, Linus wrote his own (simpler) license with a similar copyleft clause. This original license did not allow any money to be charged for distribution. When distributors complained, Linus revised the licensing to use the GPL. Linus is quoted as saying:

“I wasn’t really a GPL fan. It was too much lawyerese, and it’s a bit too strict in my opinion. (…) on the other hand, I can’t say I’m unhappy (with the license).” –Torvalds, as quoted by Moody, pp. 49

Presently, Linus is working for the Linux Foundation, a not-for-profit consortium which developed independently, and which later hired Linus so that he could work on the Linux kernel as a career (as opposed to a hobby).

• ASIDE: I am a fan of the FLOSS Weekly podcast. Listen here for an interview with Linus Torvalds.

Richard Matthew Stallman (RMS)

Before writing about Stallman, it is important to note that there is much to say about this individual. As such, I will keep this section brief. I will provide additional details in other sections and postings (as necessary).

In my previous post, I discussed Richard Stallman, and his role as principle founder and visionary of the Free Software Foundation (FSF). Simply put, Stallman is a champion for software freedoms, and is generally cast as an individual bound by principle.

In his early programming career, Stallman worked as a programmer in MIT’s Artificial Intelligence Laboratory. At the time, software was freely shared between institutions, practitioners, etc. However, times change. Software became proprietary, and source code became more like trade secretes. Stallman was against this turn of events, and his views against proprietary software were crystallized by an incident when Stallman could not acquire the source code for a printer driver.

Upon leaving MIT, and founding the Free Software Foundation, Stallman set out to develop a free (libre) computing infrastructure. This began with the release of the GNU public license, GNU emacs, the GNU c compile, etc. The most notable missing piece of this free system was an operating system kernel. Work started on the GNU Hurd microkernel, but the Linux kernel was released (and gained much popularity) before Hurd could be completed.

Eric Steven Raymond (EMS)

Eric Raymond is another key player in the FLOSS community. Raymond is perhaps best known for  his essay, The Cathedral and the Bazaar, which describes the mechanisms and ethos of open source software development. He is also known for his role in co-founding the Open Source Initiative.

I must admit that I first became aware of Raymond via. the book The New Hacker’s Dictionary, a print version of the Jargon File which Raymond actively maintains. I was particularly moved by the piece contributed by Ed Nather entitled The Story of Mel, a Real Programmer.

As with Stallman, there is is much to say about Raymond. For now it suffices to say that, when it comes to FLOSS licenses, he is more flexible than Stallman, and often rejects the FSF’s staunch position of software freedoms at all costs. In the blog post A Fan of Freedom: Thoughts on the Biography of RMS, Raymond writes:

“I thought Richard’s anti-propertarian dream was crazy, a nightmare that would lead to starving programmers and no good results. (…) We couldn’t sign on to Richard’s eccentric messianism.”

That being said, Raymond added

“(Richard Stallman’s) artifacts — GCC, Emacs, the GNU Public License — really have changed the world. The processes of open, collaborative development he did so much to invent is triumphing.”

In fact, it is this “open collaborative development” process is which Raymond so champions in support for open source software.