Blog - Bradley M. Kuhn ( Brad ) ( bkuhn )

2011

December

2011-12-16: FaiFCast Release, and Submit to FOSDEM Legal & Policy Issues DevRoom

Today Karen Sandler and I released Episode 0x1E of the Free as in Freedom oggcast (available in ogg and mp3 formats). There are two important things discussed on that oggcast that I want to draw your attention to:

Submit a proposal for the Legal & Policy Issues DevRoom CFP

Tom Marble, Richard Fontana, Karen Sandler, and I are coordinating the Legal and Policy Issues DevRoom at FOSDEM 2012. The Call for Participation for the DevRoom is now available. I'd like to ask anyone reading this blog post who has an interest in policy and/or legal issues related to software freedom to submit a talk by Friday 30 December 2011, by emailing <fosdem-legal@faif.us>.

We only have about six slots for speakers (it's a one-day DevRoom), so we won't be able to accept all proposals. I just wanted to let everyone know that so you don't flame me if you submit and get rejected. Meanwhile, note that our goal is to avoid the “this is what copyrights, trademarks and patents are” introductory talks. Our focus is on complex issues for those already informed about the basics. We really felt that the level of discourse about legal and policy issues at software freedom conferences needs to rise.

There are, of course, plenty of secret membership clubs ⁰, even some with their own private conferences, where these sorts of important issues are discussed. I personally seek to move high-level policy discussion and debate out of the secret “old-boys” club backrooms and into a public space where the entire software freedom community can discuss openly important legal and policy questions in the community. I hope this DevRoom is a first step in that direction!

Issues & Questions List for the Software Freedom Non-Profits Debate
I've made reference recently to debates about the value of non-profit organizations for software freedom projects. In FaiFCast 0x1E, Karen and I discuss the debate in depth. As part of that, as you'll see in the show notes, I've made a list of issues that I think were fully conflated during the recent debates. I can't spare the time to opine in detail on them right now (although Karen and I do a bit of that in the oggcast itself), but I did want to copy the list over here in my blog, mainly to list them out as issues worth thinking about in a software freedom non-profit:
- Should a non-profit home decide what technical infrastructure is used for a software freedom project? And if so, what should it be?
- If the non-profit doesn't provide technological services, should non-profits allow their projects to rely on for-profits for technological or other services?
- Should a non-profit home set political and social positions that must be followed by the projects? If so, how strictly should they be enforced?
- Should copyrights be held by the non-profit home of the project, or with the developers, or a mix of the two?
- Should the non-profit dictate licensing requirements on the project? If so, how many licenses and which licenses are acceptable?
- Should a non-profit dictate strict copyright provenance requirements on their projects? If not, should the non-profit at least provide guidelines and recommendations?
This list of questions is far from exhaustive, but I think it's a pretty good start.

⁰ Admittedly, I've got a proverbial axe to grind about these secretive membership-only groups, since, for nearly all of them, I'm persona non grata. My frustration level in this reached a crescendo when, during a session at LinuxCon Europe recently, I asked for the criteria to join one such private legal issues discussions group, and I was told the criteria themselves were secret. I pointed out to the coordinators of the forum that this wasn't a particularly Free Software friendly way to run a discussion group, and they simply changed the subject. My hope is that this FOSDEM DevRoom can be a catalyst to start a new discussion forum for legal and policy issues related to software freedom that doesn't have this problem.

BTW, just to clarify: I'm not talking about FLOSS Foundations as one of these secretive, members-only clubs. While the FLOSS Foundations main mailing list is indeed invite-only, it's very easy to join and the only requirement is: “if you repost emails from this list publicly, you'll probably be taken off the mailing list”. There are no “Chatham House Rules” or other silly, unenforceable, and spend-inordinate-amount-of-times-remembering-how-to-follow rules in place for FLOSS Foundations, but such silly rulesets are now common with these other secretive legal issues meeting groups.

Finally, I know I haven't named publicly the members-only clubs I'm talking about here, and that's by design. This is the first time I've mentioned them at all in my blog, and my hope is that they'll change their behaviors soon. I don't want to publicly shame them by name until I give them a bit more time to change their behaviors. Also, I don't want to inadvertently promote these fora either, since IMO their very structure is flawed and community-unfriendly.

Posted on Friday 16 December 2011 by Bradley M. Kuhn.

Comment on this post in this identi.ca conversation.

November

2011-11-28: What's a Free Software Non-Profit For?

Over on Conservancy's blog, I just published a blog post entitled What's a Free Software Non-Profit For?. It responds in part to what was written last week about non-profit homes for Free Software projects.

Posted on Monday 28 November 2011 by Bradley M. Kuhn.

Comment on this post in this identi.ca conversation.
2011-11-24: No, You Won't See Me on Facebook, Google Plus, nor Skype

Most folks outside of technology fields and the software freedom movement can't grok why I'm not on Facebook. Facebook's marketing has reached most of the USA's non-technical Internet users. On the upside, Facebook gave the masses access to something akin to blogging. But, as with most technology controlled by for-profit companies, Facebook is proprietary software. Facebook, as a software application, is written in a mix of server-side software that no one besides Facebook employees can study, modify and share. On the client-side, Facebook is an obfuscated, proprietary software Javascript application, which is distributed to the user's browser when they access facebook.com. Thus, in my view, using Facebook is no different than installing a proprietary binary program on my GNU/Linux desktop.

Most of the press critical of Facebook has focused on privacy, data mining of users' data on behalf of advertisers, and other types of data autonomy concerns. Such concerns remain incredibly important too. Nevertheless, since the advent of the software freedom community's concerns about network services a few years ago, I've maintained this simple principle, that I still find correct: While I can agree that merely liberating all software for an online application is not a sufficient condition to treat the online users well, the liberation of the software is certainly a necessary condition for the freedom of the users. Releasing freely all code for the online application the first step for freedom, autonomy, and privacy of the users. Therefore, I certainly don't give in myself to running proprietary software on my FaiF desktops. I simply refuse to use Facebook.

Meanwhile, when Google Plus was announced, I didn't see any fundamental difference from Facebook. Of course, there are differences on the subtle edges: for example, I do expect that Google will respect data portability more than Facebook. However, I expect data mining for advertisers' behalf will be roughly the same, although Google will likely be more subtle with advertising tie-in than Facebook, and thus users will not notice it as much.

But, since I'm firstly a software freedom activist, on the primary issue of my concern, there is absolutely no difference between Facebook and Google Plus. Google Plus' software is a mix of server-side trade-secret software that only Google employees can study, share, and modify, and a client-side proprietary Javascript application downloaded into the users' browsers when they access the website.

Yet, in a matter of just a few months, much of the online conversation in the software freedom community has moved to Google Plus, and I've heard very few people lament this situation. It's not that I believe we'll succeed against proprietary software tomorrow, and I understand fully that (unlike me) most people in the software freedom community have important reasons to interact regularly with those outside of our community. It's not that I chastise software freedom developers and activist for maintaining a minimal presence on these services to interact with those who aren't committed to our cause.

My actual complaint here is that Google Plus is becoming the default location for discussion of software freedom issues. I've noticed because I've recently discovered that I've missed a lot of community conversations that are only occurring on Google Plus.

What's more, I've received more pressure than ever before to sign up for not only Google Plus, but for Google Plus Hangout, Skype and other socially-oriented online communication services. Indeed, just in the last ten days, I've had three different software freedom development projects and/or organizations request that I sign up for a proprietary online communication service merely to attend a meeting or conference call. Of course, I refused, but I've not felt peer pressure this strong since I was a teenager.

Indeed, the advent of proprietary social networking software adds a new challenge to those of us who want to stand firm and resist proprietary software. As adoption of services like Facebook, Google Plus, Skype and Google Plus Hangouts increases, those of us who resist using proprietary software will come under ever-increasing peer pressure. Disturbingly, I've found that peer pressure comes not only from folks outside our community, but also from those who have, for years, otherwise been supporters of the software freedom movement.

When I point out that I use only Free Software, some respond that Skype, Facebook, and Google Plus are convenient and do things that can't be done easily with Free Software currently. I don't argue that point. It's easy to resist Microsoft Windows, or Internet Explorer, or any other proprietary software that is substandard and works poorly. But proprietary software developers aren't necessarily stupid, nor untalented. In fact, proprietary software developers are highly paid to write easy-to-use, beautiful and enticing software (cross-reference Apple, BTW). The challenge the software freedom community faces is not merely to provide alternatives to the worst proprietary software, but to also replace the most enticing proprietary software available. Yet, if FaiF Software developers settle into being users of that enticing proprietary software, the key inspiration for development disappears.

The best motivator to write great new software is to solve a problem that's not yet solved. To inspire ourselves as FaiF Software developers, we can't complacently settle into use of proprietary software applications as part of our daily workflow. That's why you won't find me on Google Plus, Google Plus Hangout, Facebook, Skype or any other proprietary software network service. You can phone with me with SIP, you can read my blog and identi.ca feed, and chat with me on IRC and XMPP, and those are the only places that I'll be until there's Free Software replacements for those other services. I sometimes kid myself into believing that I'm leading by example, but sadly few in the software freedom community seem to be following.

Posted on Thursday 24 November 2011 by Bradley M. Kuhn.

Comment on this post in this identi.ca conversation.
2011-11-13: Just Ignore Him; He'll Go Away Eventually.

One of my favorite verbal exchanges in an episode of The West Wing occurs in S03E08, The Women of Qumar. In the story, after President Bartlet said at a fundraiser: Everything has risks. Your car can drive into a lake and your seatbelt jams, but no one's saying don't wear your seat belt, someone had a car accident while not wearing a seatbelt and filed a lawsuit naming the President as a defendant. Sam, the Deputy Communications Director, thinks the White House should respond preemptively before the story. Toby, the Communication Director, instead ignores Sam and then has this wonderfully deadpan exchange with the President:

BARTLET

[Toby,] Come with me for a second, would you?

TOBY

Sir, it's possible you're going to hear some stuff about seatbelts today. I urge you to ignore it.

BARTLET

No problem. [changes topic] Are you straightening things out with the Smithsonian?

I remember when I first watched this episode in late 2001. It expressed to me a cogent and concise fact of press relations: someone may be out there trying to get attention for themselves on a topic related to you with some sophistic argument, but you should sometimes just ignore it.

With that, I say: Dear readers of my blog, you may have heard some stuff about Edward Naughton again this week. I urge you to ignore it.

I hope you'll all walk in the shoes of President Bartlet and respond with a “No problem” and change the topic. If you really want to follow this story, just read what I've said before on it; nothing has changed.

Meanwhile, while Naughton seems to be happy to selectively quote me to support his sophistry, he still hasn't gotten in touch with me to help actually enforce the GPL. It's obvious he doesn't care in the least about the GPL; he just wants to use it inappropriately to attack Android/Linux and Google. There are criticisms that Google and Android/Linux deserve, but none of them relate to the topic of GPL violations.

Posted on Sunday 13 November 2011 by Bradley M. Kuhn.

Comment on this post in this identi.ca conversation.
2011-11-11: Last Four FaiF Episodes

Those of you that follow my blog have probably wondered we're I've been. Quite frankly, there is just so much work going on at Conservancy that I have almost had no time to do anything but Conservancy work, eat and sleep. My output on this blog and on identi.ca surely shows that.

The one thing that I've kept up with is the oggcast, Free as in Freedom that I co-host with Karen Sandler, and which is produced by Dan Lynch.

Since I last made a blog post here, Karen, Dan and I released four oggcasts. I'll discuss them here in reverse chronological order:

In Episode 0x1C, which was released today, we published Karen's interview with Adam Dingle of Yorba. IMO (which is undoubtedly biased), this episode is an important one since it relates to the issues of non-profit organizations in our community who waiting in the 501(c)(3) application queue. This is a detailed and specific follow-up to the issues that Karen and I discussed on FaiF's Episode 0x13.

In Episode 0x1B, Karen and I discuss in some detail about the work that we've been up to. Both Karen and I are full-time Executive Directors, and the amount of work that job takes always seems insurmountable. Although, after we recorded the episode, I somewhat embarrassingly remembered the Bush/Kerry debate where George W. Bush kept saying his job as president is hard work. It's certainly annoying when a chief executive goes on and on about how hard his job is, so I apologize if I did a little too much of that in Episode 0x1B.

In Episode 0x1A, Karen and I discussed in detail Steve Jobs' death and the various news coverage about it. The subject is a bit old news now that I write this, but I'm glad we did that episode, since it gave me an opportunity to say everything I wanted to stay about Steve Jobs' life and death.

In Episode 0x19, we played Karen's interview with Jos Poortvliet, discussed the identi.ca upgrade, and Karen discussed GNOME 3.2.

My plan is to at least keep the FaiF oggcast going, and I'm even bugging Fontana that he and I should start an oggcast too. Beyond that, I can't necessarily commit to any other activities outside of that (and my job at Conservancy and volunteer duties at FSF). BTW, I recently attended a few conferences (both LinxCon Europe and the Summer of Code Mentor Summit). At both of them, multiple folks asked me why I haven't been blogging more. I appreciate people's interest in what I'm writing, but at the moment, my day-job at Conservancy and volunteer work at FSF has had to take absolute priority.

Based on the ebb and flow (yes, that's the first time I've actually used that phrase on my ebb.org blog :) of the Free Software community that I've gotten used to over the last decade and a half, I usually find that things slow down in mid-December until mid-January. Since Conservancy's work is based on the needs of its Free Software projects, I'll likely be able to return a “normal” 50 hour work week (instead of the 60-70 I've been doing lately) in December. Thus, I'll probably try to write some queued blog posts then to slowly push out over the few months that follow.

Finally, I want to mention that Conservancy has an donation appeal up on its website. I hope you'll give generously to support Conservancy's work. On that, I'll just briefly mention my “hard work” again, to assure you that donors to Conservancy definitely get their money's worth when I'm on the job. Since I'm on the topic of that, I also thank everyone who has donated to FSF and Conservancy over the years. I've been fortunate to have worked full-time at both organizations, and I appreciate the community that has supported all that work over the years.

Posted on Friday 11 November 2011 by Bradley M. Kuhn.

Comment on this post in this identi.ca conversation.

September

2011-09-28: Two FaiF Episodes

I've not been particularly good at keeping up with this blog here, although I have generally kept up with the oggcast that I co-host with Karen Sandler, Free as in Freedom, which is released every two weeks.

Episode 0x18 was a recording of my OSCON 2011 talk, 12 Years of Compliance: A Historical Perspective, which may be of interest to those who enjoy hearing about stories of GPL enforcement. It's available in ogg and mp3, and the slides are available if you want to follow along while you listen.

Today's episode 0x19 (available as ogg or mp3) is a bunch of discussion about various topics. Karen talks about GNOME 3.2, I discuss various issues with the identi.ca upgrade (in particular, the fact it still locks-in your data and won't let me export it), and the issue of UEFI so-called “secure” booting.

On the last point, I strongly recommend everyone look at Matthew Garrett's blog post about UEFI. I've not been completely happy with what Matthew has said since his initial post on the subject — it seems like he wants to find a way to support UEFI for GNU/Linux systems and I think we should refuse — but Matthew is pointing out that Microsoft is misleading people in its anti-software-freedom campaigns (like always).
Posted on Wednesday 28 September 2011 by Bradley M. Kuhn.

Comment on this post in this identi.ca conversation.

August

2011-08-21: Desktop Summit 2011

I realize nearly ten days after the end of a conference is a bit late to blog about it. However, I needed some time to recover my usual workflow, having attended two conferences almost back-to-back, OSCON 2011 and Desktop Summit. (The strain of the back-to-back conferences, BTW, made it impossible for me to attend Linux Con North America 2011, although I'll be at Linux Con Europe. I hope next year's summer conference schedule is not so tight.)

This was my first Desktop Summit, as I was unable to attend the first one in Grand Canaria two years ago. I must admit, while it might be a bit controversial to say so, that I felt the conference was still like two co-located conferences rather than one conference. I got a chance to speak to my KDE colleagues about various things, but I ended up mostly attending GNOME talks and therefore felt more like I was at GUADEC than at a Desktop Summit for most of the time.

The big exception to that, however, was in fact the primary reason I was at Desktop Summit this year: to participate in a panel discussion with Mark Shuttleworth and Michael Meeks (who gave the panel a quick one-sentence summary on his blog). That was plenary session and the room was filled with KDE and GNOME developers alike, all of whom seemed very interested in the issue.

The panel format was slightly frustrating — primarily due to Mark's insistence that we all make very long open statements — although Karen Sandler nevertheless did a good job moderating it and framing the discussion.

I get the impression most of the audience was already pretty well informed about all of our positions, although I think I shocked some by finally saying clearly in a public forum (other than identi.ca) that I have been lobbying FSF to make copyright assignment for FSF-assigned projects optional rather than mandatory. Nevertheless, we were cast well into our three roles: Mark, who wants broad licensing control over projects his company sponsors so he can control the assets (and possibly sell them); Michael, who has faced so many troubles in the OpenOffice.org/LibreOffice debacle that he believes inbound=outbound can be The Only Way; and me, who believes that copyright assignment is useful for non-profits willing to promise to do the public good to enforce the GPL, but otherwise is a Bad Thing.

Lydia tells me that the videos will be available eventually from Desktop Summit, and I'll update this blog post when they are so folks can watch the panel. I encourage everyone concerned about the issue of rights transfers from individual developers to entities (be they via copyright assignment or other broad CLA means) to watch the video once it's available. For the moment, Jake Edge's LWN article about the panel is a pretty good summary.

My favorite moment of the panel, though, was when Shuttleworth claimed he was but a distant observer of Project Harmony. Karen, as moderator, quickly pointed out that he was billed as Project Harmony's originator in the panel materials. It's disturbing that Shuttleworth thinks he can get away with such a claim: it's a matter of public record, that Amanda Brock (Canonical, Ltd.'s General Counsel) initiated Project Harmony, led it for most of its early drafts, and then Canonical Ltd. paid Mark Radcliffe (a lawyer who represents companies that violate the GPL) to finish the drafting. I suppose Shuttleworth's claim is narrowly true (if misleading) since his personal involvement as an individual was only tangential, but his money and his staff were clearly central: even now, it's led by his employee, Allison Randal. If you run the company that runs a project, it's your project: after all, doesn't that fit clearly with Shuttleworth's suppositions about why he should be entitled to be the recipient of copyright assignments and broad CLAs in the first place?

The rest of my time at Desktop Summit was more as an attendee than a speaker. Since I'm not desktop or GUI developer by any means, I mostly went to talks and learned what others had to teach. I was delighted, however, that no less than six people came up to me and said they really liked this blog. It's always good to be told that something you put a lot of volunteer work into is valuable to at least a few people, and fortunately everyone on the Internet is famous to at least six people. :)

Meanwhile, I want to thank the GNOME Foundation for sponsoring my trip to Desktop Summit 2011, as they did last year for GUADEC 2010. Given my own work and background, I'm very appreciative of a non-profit with limited resources providing travel funding for conferences. It's a big expense, and I'm thankful that the GNOME Foundation has funded my trips to their annual conference.

BTW, while we await the videos from Desktop Summit, there's some “proof” you can see that I attended Desktop Summit, as I appear in the group photo, although you'll need to view the hi-res version and scroll to the lower right of the image, and find me. I'm in the second/third (depending on how you count) row back, 2-3 from the right, and two to the left from Lydia Pintscher.

Finally, I did my best to live dent from the Desktop Summit 2011. That might be of interest to some as well, for example, if you want to dig back and see what folks said in some of the talks I attended. There was also a two threads after the panel that may be of interest.

Posted on Sunday 21 August 2011 by Bradley M. Kuhn.

Comment on this post in this identi.ca conversation.
2011-08-18: Will Nokia Ever Realize Open Source Is Not a Panacea?

I was pretty sure there was something wrong with the whole thing in fall of 2009, when they first asked me. A Nokia employee contacted me to ask if I'd be willing to be a director of the Symbian Foundation (or so I thought that's what they were asking — read on). I wrote them a thoughtful response explaining my then-current concerns about Symbian:
- the poor choice of the Eclipse Public License for the eventual code,
- the fact that Symbian couldn't be built in any software freedom system environment, and
- that the Symbian source code that had been released thus far didn't actually run on any existing phones.
I nevertheless offered to serve as a director for one year, and I would resign at that point if the problems that I'd listed weren't resolved.

I figured that was quite a laundry list. I also figured that they probably wouldn't be interested anyway once they saw my list. Amusingly, they still were. But then, I realized what was really going on.

In response to my laundry list, I got back a rather disturbing response that showed a confusion in my understanding. I wasn't being invited to join the board of the Symbian Foundation. They had asked me instead to serve as a Director of a small USA entity (that they heralded as Symbian DevCo) that would then be permitted one Representative of the Symbian Foundation itself, which was, in turn, a trade association controlled by dozens of proprietary software companies.

In fact, this Nokia employee said that they planned to channel all individual developers toward this Symbian DevCo in the USA, and that would be the only voice these developers would have in the direction of Symbian. It would be one tiny voice against dozens of proprietary software company who controlled the real Symbian Foundation, a trade association.

Anyone who has worked in the non-profit sector, or even contributed to any real software freedom project can see what's deeply wrong there. However, my response wasn't to refuse. I wrote back and said clearly why this was failing completely to create a software freedom community that could survive vibrantly. I pointed out the way the Linux community was structured: whereby the Linux Foundation is a trade association for companies — and, while they do fund Linus' salary, they don't control his or any other activities of developers. Meanwhile, the individual Linux developers have all the real authority: from community structure, to licensing, to holding copyrights, to technical decision-making. I pointed out if they wanted Symbian to succeed, they should emulate Linux as much as they could. I suggested Nokia immediately change the whole structure to have developers in charge of the project, and have a path for Symbian DevCo to ultimately be the primary organization in charge of the codebase, while Symbian Foundation could remain the trade association, roughly akin to the Linux Foundation. I offered to help them do that.

You might guess that I never got a reply to that email. It was thus no surprise to me in the least what happened to Symbian after that:
- In December 2010 (nearly 13 months to the day after my email exchange described above), the Symbian Foundation shut down all its websites.
- In February 2011, Nokia announced its partnership with Microsoft to prefer Windows 7 on its phones.
- In April 2011, Nokia announced that Symbian would no longer be available as Free Software.
- In June 2011, Nokia announced that some other consulting company will take over proprietary development of Symbian.
So, within 17 months of Symbian Foundation's inquiry to ask me to help run Symbian DevCo, the (Open Source) Symbian project was canceled entirely, the codebase was now again proprietary (with a few of the old codedumps floating around on other sites), and the Symbian Foundation consists only of a single webpage filled with double-speak.

Of course, even if Nokia had tried its hardest to build an actual software freedom community, Symbian still had a good chance of failing, as I pointed out in March 2010. But, if Nokia had actually tried to release control and let developers have some authority, Symbian might have had a fighting chance as Free Software. As it turned out, Nokia threw some code over the wall, gave all the power to decide what happens to a bunch of proprietary software companies, and then hung it all out to dry. It's a shining example of how to liberate software in a way that will guarantee its deprecation in short order.

Of course, we now know that during all this time, Nokia was busy preparing a backroom deal that would end its always-burgeoning-but-never-complete affiliation with software freedom by making a deal with Microsoft to control the future of Nokia. It's a foolish decision for software freedom; whether it's a good business decision surely isn't for me to judge. (After all, I haven't worked in the for-profit sector for fifteen years for a reason.)

It's true that I've always given a hard time to Maemo (and to MeeGo as well). Those involved from inside Nokia spent the last six months telling me that MeeGo is run by completely different people at Nokia, and Nokia did recently launch yet another MeeGo based product. I've meanwhile gotten the impression that Nokia is one of those companies whose executives are more like wealthy Romans who like to pit their champions against each other in the arena to see who wins; Nokia's various divisions appear to be in constant competition with each other. I imagine someone running the place has read too much Ayn Rand.

Of course, it now seems that MeeGo hasn't, in Nokia's view, “survived as the fittest”. I learned today (thanks to jwildeboer) that, In Elop's words, there is no returning to MeeGo, even if the N9 turns out to be a hit. Nokia's commitment to Maemo/MeeGo, while it did last at least four years or so, is now gone too, as they begin their march to Microsoft's funeral dirge. Yet another FLOSS project Nokia got serious about, coordinated poorly, and yet ultimately gave up.

Upon considering Nokia's bad trajectory, it led me to think about how Open Source companies tend to succeed. I've noticed something interesting, which I've confirmed by talking to a lot of employees of successful Open Source companies. The successful ones — those that get something useful done for software freedom while also making some cash (i.e., the true promise of Open Source) — let the developers run the software projects themselves. Such companies don't relegate the developers into a small non-profit that has to lobby dozens of proprietary software companies to actually make an impact. They don't throw code over the wall — rather, they fund developers who make their own decisions about what to do in the software. Ultimately, smart Open Source companies treat software freedom development like R&D should be treated: fund it and see what comes out and try to build a business model after something's already working. Companies like Nokia, by contrast, constantly put their carts in front of all the horses and wonder why those horses whinny loudly at them but don't write any code.

Open Source slowly became a fad during the DotCom era, and it strangely remains such. A lot of companies follow fads, particularly when they can't figure what else to do. The fad becomes a quick-fix solution. Of course, for those of us that started as volunteers and enthusiasts in 1991 or earlier, software freedom isn't some new attraction at P. T. Barnum's circus. It's a community where we belong and collaborate to improve society. Companies are welcomed to join us for the ride, but only if they put developers and users in charge.

Meanwhile, my personal postscript to my old conversation with Nokia arrived in my inbox late in May 2011. I received a extremely vague email from a lawyer at Nokia. She wanted really badly to figure out how to quickly dump some software project — and she wouldn't tell me what it was — into the Software Freedom Conservancy. Of course, I'm sure this lawyer knows nothing about the history of the Symbian project wooing me for directorship of Symbian DevCo and all the other history of why “throwing code over the wall” into a non-profit is rarely known to work, particularly for Nokia. I sent her a response explaining all the problems with her request, and, true to Nokia's style, she didn't even bother to respond to me thanking me for my time.

I can't wait to see what project Nokia dumps over the wall next, and then, in another 17 months (or if they really want to lead us on, four years), decides to proprietarize or abandon it because, they'll say, this open-sourcing thing just doesn't work. Yet, so many companies make money with it. The short answer is: Nokia, you keep doing it wrong!

Update (2011-08-24): Boudewijn Rempt argued another side of this question. He says the Calligra suite is a counterexample of Nokia getting a FLOSS project right. I don't know enough about Calligra to agree or disagree.

Posted on Thursday 18 August 2011 by Bradley M. Kuhn.

Comment on this post in this identi.ca conversation.
2011-08-15: If Only They'd Actually Help Enforce GPL

Unfortunately, Edward Naughton is at it again, and everyone keeps emailing me about, including Brian Proffitt, who quoted my email response to him this morning in his article.

As I said in my response to Brian, I've written before on this issue and I have nothing much more to add. Naughton has not identified a GPL violation that actually occurred, at least with respect to Google's own distribution of Android, and he has completely ignored my public call for him to make such a formal report to the copyright holders of GPL violations for which he has evidence (if any).

Jon Corbet of LWN has also picked up the story, mostly pontificating on what it would mean if loss of distribution rights under GPLv2§4 are used nefariously instead of the honorable way it has been hitherto used to defend software freedom. I commented on the LWN post.

I think Jon's right to raise that specific concern, and that's a good reason for projects to upgrade to GPLv3. But, nevertheless, this whole thing is not even relevant until someone actually documents a real GPL violation that has occurred. As I previously mentioned, I'm aware of plenty of documented violations (thanks to Matthew Garrett), and I'd love if more people were picking up and act on these violations to enforce the GPL. I again tell Naughton: if you are seriously concerned about enforcing GPL, then volunteer your time as a lawyer to help. But we all know that's not really what interests you: rather, your job is to spread FUD.

Posted on Monday 15 August 2011 by Bradley M. Kuhn.

Comment on this post in this identi.ca conversation.
2011-08-05: You're Living in the Past, Dude!

At the 2000 Usenix Technical Conference (which was the primary “generalist” conference for Free Software developers in those days), I met Miguel De Icaza for the third time in my life. In those days, he'd just started Helix Code (anyone else remember what Ximian used to be called?) and was still president of the GNOME Foundation. To give you some context: Bonobo was a centerpiece of new and active GNOME development then.

Out of curiosity and a little excitement about GNOME, I asked Miguel if he could show me how to get the GNOME 1.2 running on my laptop. Miguel agreed to help, quickly taking control of the keyboard and frantically typing and editing my sources.list.

Debian potato was the just-becoming-stable release in those days, and of course, I was still running potato (this was before my experiment with running things from testing began).

After a few minutes hacking on my keyboard, Miguel realized that I wasn't running woody, Debian's development release. Miguel looked at me, and said: You aren't running woody; I can't make GNOME run on this thing. There's nothing I can do for you. You're living in the past, dude!. (Those who know Miguel IRL can imagine easily how he'd sound saying this.)

So, I've told that story many times for the last eleven years. I usually tell it for laughs, as it seems an equal-opportunity humorous anecdote. It pokes some fun at Miguel, at me, at Debian for its release cycle, and also at GNOME (which has, since its inception, tried to never live in the past, dude).

Fact is, though, I rather like living in the past, at least with regard to my computer setup. By way of desktop GUIs, I used twm well into the late 1990s, and used fvwm well into the early 2000s. I switched to sawfish (then sawmill) during the relatively brief period when GNOME used it as its default window manager. When Metacity became the default, I never switched because I'd configured sawfish so heavily.

In fact, the only actual parts of GNOME 2 that I ever used on a daily basis have been (a) a small unobtrusive panel, (b) dbus (and its related services), and (c) the Network Manager applet. When GNOME 3 was released, I had no plans to switch to it, and frankly I still don't.

I'm not embarrassed that I consistently live in the past; it's sort of the point. GNOME 3 isn't for me; it's for people who want their desktop to operate in new and interesting ways. Indeed, it's (in many ways) for the people who are tempted to run OSX because its desktop is different than the usual, traditional, “desktop metaphor” experience that had been standard since the mid-1990s.

GNOME 3 just wasn't designed with old-school Unix hackers in mind. Those of us who don't believe a computer is any good until we see a command line aren't going to be the early adopters who embrace GNOME 3. For my part, I'll actually try to avoid it as long as possible, continue to run my little GNOME 2 panel and sawfish, until slowly, GNOME 3 will seep into my workflow the way the GNOME 2 panel and sawfish did when they were current, state-of-the-art GNOME technologies.

I hope that other old-school geeks will see this distinction: we're past the era when every Free Software project is targeted at us hackers specifically. Failing to notice this will cause us to ignore the deeper problem software freedom faces. GNOME Foundation's Executive Director (and my good friend), Karen Sandler, pointed out in her OSCON keynote something that's bothered her and me for years: the majority computer at OSCON is Apple hardware running OSX. (In fact, I even noticed Simon Phipps has one now!) That's the world we're living in now. Users who actually know about “Open Source” are now regularly enticed to give up software freedom for shiny things.

Yes, as you just read, I can snicker as quickly as any old-school command-line geek (just as Linus Torvalds did earlier this week) at the pointlessness of wobbly windows, desktop cubes, and zoom effects. I could also easily give a treatise on how I can get work done faster, better, and smarter because I have the technology of years ago that makes every keystroke matter.

Notwithstanding that, I'd even love to have the same versatility with GNOME 3 that I have with sawfish. And, if it turns out GNOME 3's embedded Javascript engine will give me the same hackability I prefer with sawfish, I'll adopt GNOME 3 happily. But, no matter what, I'll always be living in the past, because like every other human, I hate changing anything, unless it's strictly necessary or it's my own creation and derivation. Humans are like that: no matter who you are, if it wasn't your idea, you're always slow to adopt something new and change old habits.

Nevertheless, there's actually nothing wrong with living in the past — I quite like it myself. However, I'd suggest that care be taken to not admonish those who make a go at creating the future. (At this risk of making a conclusion that sounds like a time travel joke,) don't forget that their future will eventually become that very past where I and others would prefer to live.

Posted on Friday 05 August 2011 by Bradley M. Kuhn.

Comment on this post in this identi.ca conversation.

July

2011-07-29: GNU Emacs Developers Will Fix It; Please Calm Down

fabsh was the first to point me at a slashdot story that is (like most slashdot stories) sensationalized.

The story, IMO, makes the usual mistake of considering a GPL violation as an earth-shattering disaster that has breached the future of software freedom. GPL violations vary in degree of the problems they create; most aren't earth-shattering.

Specifically, the slashdot story points to a thread on the emacs-devel mailing list about a failure to include some needed bison grammar in the complete and corresponding sources for Emacs in a few Emacs releases in the last year or two. As you can see there, RMS quickly responded to call it a grave problem … [both] legally and ethically, and he's asked the Emacs developers to help clear up the problem quickly.

I wrote nearly two years ago that one shouldn't jump to conclusions and start condemning those who violate the GPL without investigating further first. Most GPL violations are mistakes, as this situation clearly was, and I suspect it will be resolved within a few news cycles of this blog post.

And please, while we all see the snickering-inducing irony of FSF and its GNU project violating the GPL, keep in mind that this is what I've typically called a “community violation”. It's a non-profit volunteer project that made an honest mistake and is resolving it quickly. Meanwhile, I've a list of hundreds of companies who are actively violating the GPL, ignoring users who requested source, and have apparently no interest in doing the right thing until I open an enforcement action against them. So, please keep perspective about what how bad any given violation is. Not all GPL violations are of equal gravity, but all should be resolved, of course. The Emacs developers are on it.

Posted on Friday 29 July 2011 by Bradley M. Kuhn.

Comment on this post in this identi.ca conversation.
2011-07-07: Project Harmony Considered Harmful

Much advertising is designed to convince us to buy or use of something that we don't need. When I hear someone droning on about some new, wonderful thing, I have to worry that these folks are actually trying to market something to me.

Very soon, you're likely to see a marketing blitz for this thing called Project Harmony (which just released its 1.0 version of document templates). Even the name itself is marketing: it's not actually descriptive, but is so named to market a “good feeling” about the project before even knowing what it is. (It's also got serious namespace collision, including with a project already in the software freedom community.

Project Harmony markets itself as fixing something that our community doesn't really consider broken. Project Harmony is a set of document templates, primarily promulgated and mostly drafted by corporate lawyers, that entice developers to give control of their software work over to companies.

My analysis below is primarily about how these agreements are problematic for individual developers. An analysis of the agreements in light of companies or organizations using them between each other may have the same or different conclusions; I just haven't done that analysis in detail so I don't know what the outcome is.

[ BTW, I'm aware that I've failed to provide a TL;DR version of this article. I tried twice to write one and ultimately decided that I can't. Simply put, these issues are complex, and I had to draw on a decade of software freedom licensing, policy, and organizational knowledge to fully articulate what's wrong with the Project Harmony agreements. I realize that sounds like a It was hard to write — it should be hard to read justification, but I just don't know how to summarize these Gordian problems in a pithy way. I nevertheless hope developers will take the time to read this before they sign a Project Harmony agreement, or — indeed — any CLA or ©AA. ]

Copyright Assignment That Lacks Real Assurances

First of all, about half of Project Harmony is copyright assignment agreements ( ©AAs). Assigning copyright completely gives the work over to someone else. Once the ©AA is signed, the work ceases to belong to the assignor. It's as if that work was done by the assignee. There is admittedly some value to copyright assignment, particularly if developers want to ensure that the GPL or other copyleft is enforced on their work and they don't have time to do it themselves. (Although developers can also designate an enforcement agent to do that on their behalf even if they don't assign copyright, so even that necessity is limited.)

One must immensely trust an assignee organization. Personally, I've only ever assigned some of my copyrights to one organization in my life: the Free Software Foundation, because FSF is the only organization I ever encountered that is institutionally committed to DTRT'ing with copyrights in a manner similar to my personal moral beliefs.

First of all, as I've written about before, FSF's ©AA make all sorts of promises back to the assignor. Second, FSF is institutionally committed to the GPL and enforcing GPL in a way that advances FSF's non-profit advocacy mission for software freedom. All of this activity fits my moral principles, so I've been willing to sign FSF's ©AAs.

Yet, I've nevertheless met many developers who refuse to sign FSF's ©AAs. While many of such developers like the GPL, they don't necessarily agree with the FSF's moral positions. Indeed, in many cases, developers are completely opposed to assigning copyright to anyone, FSF or otherwise. For example, Linus Torvalds, founder of Linux, has often stated on record that he never wanted to do copyright assignments, for several reasons: [he] think[s] they are nasty and wrong personally, and [he]'d hate all the paperwork, and [he] thinks it would actually detract from the development model.

Obviously, my position is not as radical as Linus'; I do think ©AAs can sometimes be appropriate. But, I also believe that developers should never assign copyright to a company or to an organization whose moral philosophy doesn't fit well with their own.

FSF, for its part, spells out its moral position in its ©AA itself. As I've mentioned elsewhere, and as Groklaw recently covered in detail, FSF's ©AA makes various legally binding promises to developers who sign it. Meanwhile, Project Harmony's ©AAs, while they put forward a few options that look vaguely acceptable (although they have problems of their own discussed below), make no such promises mandatory. I have often times pointed Harmony's drafters to the terms that FSF has proposed should be mandatory in any for-profit company's ©AA, but Harmony's drafters have refused to incorporate these assurances as a required part of Harmony's agreements. (Note that such assurances would still be required for the CLA options as well; see below for details why.)

Regarding ©AAs, I'd like to note finally that FSF does not require ©AAs for all GNU packages. This confusion is so common that I'd like to draw attention to it, even thought it's only a tangential point in this context. FSF's ©AA is only mandatory, to my knowledge, on those GNU packages where either (a) FSF employees developed the first versions or (b) the original developers themselves asked to assign copyright to FSF, upon their project joining GNU. In all other cases, FSF assignment is optional. Some GNU projects, such as GNOME, have their own positions regarding ©AAs that differ radically from FSF's. I seriously doubt that companies who adopt Project Harmony's agreement will ever be as flexible on copyright assignment as FSF, nor will any of the possible Project Harmony options be acceptable to GNOME's existing policy.

Giving Away Rights to Give Companies Warm Fuzzies?

Project Harmony, however, claims that the important part isn't its ©AA, but its Contributor License Agreement (CLA). To briefly consider the history of Free Software CLAs, note that the Apache CLA was likely the first CLA used in the Free Software community. Apache Software Foundation has always been heavily influenced by IBM and other companies, and such companies have generally sought the “warm fuzzies” of getting every contributor to formally assent to a complex legal document that asserts various assurances about the code and gives certain powers to the company.

The main point of a CLA (and a somewhat valid one) is to ensure that the developers have verified their right to contribute the code under the specified copyright license. Both the Apache CLA and Project Harmony's CLA go to great length and verbosity to require developers to agree that they know the contribution is theirs. In fact, if a developer signs one of these CLA's, the developer makes a formal contract with the entity (usually a for-profit company) that the developer knows for sure that the contribution is licensed under the specified license. The developer then takes on all liability if that fact is in any way incorrect or in dispute!

Of course, shifting away all liability about the origins of the code is a great big “warm fuzzy” for the company's lawyers. Those lawyers know that they can now easily sue an individual developer for breach of contract if the developer was wrong about the code. If the company redistributes some developer's code and ends up in an infringement suit where the company has to pay millions of dollars, they can easily come back and sue the developer⁰. The company would argue in court that the developer breached the CLA. If this possible outcome doesn't immediately worry you as an individual developer signing a Project Harmony CLA for your FLOSS contribution, it should.

“Choice of Law” & Contractual Arrangement Muddies Copyright Claims

Apache's CLA doesn't have a choice of law clause, which is preferable in my opinion. Most lawyers just love a “choice of law” clause for various reasons. The biggest reason is that it means the rules that apply to the agreement are the ones with which the lawyers are most familiar, and the jurisdiction for disputes will be the local jurisdiction of the company, not of the developer. In addition, lawyers often pick particular jurisdictions that are very favorable to their client and not as favorable to the other signers.

Unfortunately, all of Project Harmony's drafts include a “choice of law” clause¹. I expect that the drafters will argue in response that the jurisdiction is a configuration variable. However, the problem is that the company decides the binding of that variable, which almost always won't be the binding that an individual developer prefers. The term will likely be non-negotiable at that point, even though it was configurable in the template.

Not only that, but imagine a much more likely scenario about the CLA: the company fails to use the outbound license they promised. For example, suppose they promised the developers it'd be AGPL'd forever (although, no such option actually exists in Project Harmony, as described below!), but then the company releases proprietarized versions. The developers who signed the CLA are still copyright holders, so they can enforce under copyright law, which, by itself, would allow the developers to enforce under the laws in whatever jurisdiction suits them (assuming the infringement is happening in that jurisdiction, of course).

However, by signing a CLA with a “choice of law” clause, the developers agreed to whatever jurisdiction is stated in that CLA. The CLA has now turned what would otherwise be a mundane copyright enforcement action operating purely under the developer's local copyright law into a contract dispute between the developers and the company under the chosen jurisdiction's laws. Obviously that agreement might include AGPL and/or GPL by reference, but the claim of copyright infringement due to violation of GPL is now muddied by the CLA contract that the developers signed, wherein the developers granted some rights and permission beyond GPL to the company.

Even worse, if the developer does bring action in a their own jurisdiction, their own jurisdiction is forced to interpret the laws of another place. This leads to highly variable and confusing results.

Problems for Individual Copyright Enforcement Against Third-Parties

Furthermore, even though individual developers still hold the copyrights, the Project Harmony CLAs grant many transferable rights and permissions to the CLA recipient (again, usually a company). Even if the reasons for requiring that were noble, it introduces a bundle of extra permissions that can be passed along to other entities.

Suddenly, what was once a simple copyright enforcement action for a developer discovering a copyleft violation becomes a question: Did this violating entity somehow receive special permissions from the CLA-collecting entity? Violators will quickly become aware of this defense. While the defense may not have merit (i.e., the CLA recipient may not even know the violator), it introduces confusion. Most legal proceedings involving software are already confusing enough for courts due to the complex technology involved. Adding something like this will just cause trouble and delays, further taxing our already minimally funded community copyleft enforcement efforts.

Inbound=Outbound Is All You Need

Meanwhile, the whole CLA question actually is but one fundamental consideration: Do we need this? Project Harmony's answer is clear: its proponents claim that there is mass confusion about CLAs and no standardization, and therefore Project Harmony must give a standard set of agreements that embody all the options that are typically used.

Yet, Project Harmony has purposely refused to offer the simplest and most popular option of all, which my colleague Richard Fontana (a lawyer at Red Hat who also opposes Project Harmony) last year dubbed inbound=outbound. Specifically, the default agreement in the overwhelming majority of FLOSS projects is simply this: each contributor agrees to license each contribution using the project's specified copyright license (or a license compatible with the project's license).

No matter what way you dice Project Harmony, the other contractual problems described above make true inbound=outbound impossible because the CLA recipient is never actually bound formally by the project's license itself. Meanwhile, even under its best configuration, Project Harmony can't adequately approximate inbound=outbound. Specifically, Project Harmony attempts to limit outbound licensing with its § 2.3 (called Outbound License). However, all the copyleft versions of this template include a clause that say: We [the CLA recipient] agree to license the Contribution … under terms of the … licenses which We are using on the Submission Date for the Material. Yet, there is no way for the contributor to reliably verify what licenses are in use privately by the entity receiving the CLA. If the entity is already engaged in, for example, a proprietary relicensing business model at the Submission Date, then the contributor grants permission for such relicensing on the new contribution, even if the rest of § 2.3 promises copyleft. This is not a hypothetical: there have been many cases where it was unclear whether or not a company was engaged in proprietary relicensing, and then later it was discovered that they had been privately doing so for years. As written, therefore, every configuration of Project Harmony's § 2.3 is useless to prevent proprietarization.

Even if that bug were fixed, the closest Project Harmony gets to inbound=outbound is restricting the CLA version to “FSF's list of ‘recommended copyleft licenses’”. However, this category makes no distinction between the AGPL and GPL, and furthermore ultimately grants FSF power over relicensing (as FSF can change its list of recommended copylefts at will). If the contributors are serious about the AGPL, then Project Harmony cannot assure their changes stay AGPL'd. Furthermore, contributors must trust the FSF for perpetuity, even more than already needed in the -or-later options in the existing FSF-authored licenses. I'm all for trusting the FSF myself in most cases. However, because I prefer plain AGPLv3-or-later for my code, Project Harmony is completely unable to accommodate my licensing preferences to even approximate an AGPL version of inbound=outbound (even if I ignored the numerous problems already discussed).

Meanwhile, the normal, mundane, and already widely used inbound=outbound practice is simple, effective, and doesn't mix in complicated contract disputes and control structures with the project's governance. In essence, for most FLOSS projects, the copyright license of the project serves as the Constitution of the project, and doesn't mix in any other complications. Project Harmony seeks to give warm fuzzies to lawyers at the expense of offloading liability, annoyance, and extra hoop-jumping onto developers.

Linux Hackers Ingeniously Trailblazed inbound=outbound

Almost exactly 10 years ago today, I recall distinctly attending the USENIX 2001 Linux BoF session. At that session, Ted Ts'o and I had a rather lively debate; I claimed that FSF's ©AA assured legal certainty of the GNU codebase, but that Linux had no such assurance. (BTW, even I was confused in those days and thought all GNU packages required FSF's ©AA.) Ted explained, in his usual clear and bright manner, that such heavy-handed methods shouldn't be needed to give legal certainty to the GPL and that the Linux community wanted to find an alternative.

I walked away skeptically shaking my head. I remember thinking: Ted just doesn't get it. But I was wrong; he did get it. In fact, many of the core Linux developers did. Three years to the month after that public conversation with Ted, the Developer's Certificate of Origin (DCO) became the official required way to handle the “CLA issue” for Linux and it remains the policy of Linux today. (See item 12 in Linux's Documentation/SubmittingPatches file.)

The DCO, in fact, is the only CLA any FLOSS project ever needs! It implements inbound=outbound in a simple and straightforward way, without giving special powers over to any particular company or entity. Developers keep their own copyright and they unilaterally attest to their right to contribute and the license of the contribution. (Developers can even sign a ©AA with some other entity, such as the FSF, if they wish.) The DCO also gives a simple methodology (i.e., the Signed-off-by: tag) for developers to so attest.

I admit that I once scoffed at the (what I then considered naïve) simplicity of the DCO when compared to FSF's ©AA. Yet, I've been since convinced that the Linux DCO clearly accomplishes the primary job and simultaneously fits how most developers like to work. ©AA's have their place, particularly when the developers find a trusted organization that aligns with their personal moral code and will enforce copyleft for them. However, for CLAs, the Linux DCO gets the important job done and tosses aside the pointless and pro-corporate stuff.
Frankly, if I have to choose between making things easy for developers and making them easy for corporate lawyers, I'm going to chose the former every time: developers actually write the code; while, most of the time, company's legal departments just get in our way. The FLOSS community needs just enough CYA stuff to get by; the DCO shows what's actually necessary, as opposed to what corporate attorneys wish they could get developers to do.

What about Relicensing?

Admittedly, Linux's DCO does not allow for relicensing wholesale of the code by some single entity; it's indeed the reason a Linux switch to GPLv3 will be an arduous task of public processes to ensure permission to make the change. However, it's important to note that the Linux culture believes in GPLv2-only as a moral foundation and principle of their community. It's not a principle I espouse; most of my readers know that my preferred software license is AGPLv3-or-later. However, that's the point here: inbound=outbound is the way a FLOSS community implements their morality; Project Harmony seeks to remove community license decision-making from most projects.

Meanwhile, I'm all for the “-or-later” brand of relicensing permission; GPL, LGPL and AGPL have left this as an option for community choice since GPLv1 was published in late 1980s. Projects declare themselves GPLv2-or-later or LGPLv3-or-later, or even (GPLv1-or-later|Artistic) (ala Perl 5) to identify their culture and relicensing permissions. While it would sometimes be nice to have a broad post-hoc relicensing authority, the price for that's expensive: abandonment of community clarity regarding what terms define their software development culture.

An Anti-Strong-Copyleft Bias?

Even worse, Project Harmony remains biased against some of the more fine-grained versions of copyleft culture. For example, Allison Randal, who is heavily involved with Project Harmony, argued on Linux Outlaws Episode 204 that Most developers who contribute under a copyleft license — they'd be happy with any copyleft license — AGPL, GPL, LGPL. Yet there are well stated reasons why developers might pick GPL rather than LGPL. Thus, giving a for-profit company (or non-profit that doesn't necessarily share the developers' values) unilateral decision-making power to relicense GPL'd works under LGPL or other weak copyleft licenses is ludicrous.

In its 1.0 release, Project Harmony attempted to add a “strong copyleft only” option. It doesn't actually work, of course, for the various reasons discussed in detail above. But even so, this solution is just one option among many, and is not required as a default when a project is otherwise copylefted.

Finally, it's important to realize that the GPLv3, AGPLv3, and LGPLv3 already offer a “proxy option”; projects can name someone to decide the -or-later question at a later time. So, for those projects that use any of the set { LGPLv3-only, AGPLv3-only, GPLv3-only, GPLv2-or-later, GPLv1-or-later, or LGPLv2.1-or-later }, the developers already have mechanisms to move to later versions of the license with ease — by specifying a proxy. There is no need for a CLA to accomplish that task in the GPL family of licenses, unless the goal is to erode stronger copylefts into weaker copylefts.

This is No Creative Commons, But Even If It Were, Is It Worth Emulation?

Project Harmony's proponents love to compare the project to Creative Commons, but the comparison isn't particularly apt. Furthermore, I'm not convinced the FLOSS community should emulate the CC license suite wholesale, as some of the aspects of the CC structure are problematic when imported back into FLOSS licensing.

First of all, Larry Lessig (who is widely considered a visionary) started the CC licensing suite to bootstrap a Free Culture movement that modeled on the software freedom movement (which he spent a decade studying). However, Lessig made some moral compromises in an attempt to build a bridge to the “some rights reserved” mentality. As such, many of the CC licenses — notably those that include the non-commercial (NC) or no-derivatives (ND) terms — are considered overly restrictive of freedom and are therefore shunned by Free Culture activists and software freedom advocates alike.

Over nearly decade, such advocates have slowly begun to convince copyright holders to avoid CC's NC and ND options, but CC's own continued promulgation of those options lend them undue legitimacy. Thus, CC and Project Harmony make the same mistake: they act amorally in an attempt to build a structure of licenses/agreements that tries to bridge a gulf in understanding between a FaiF community and those only barely dipping their toe in that community. I chose the word amoral, as I often do, to note a situation where important moral principles exist, but the primary actors involved seek to remove morality from the considerations under the guise of leaving decision-making to the “magic of the marketplace”. Project Harmony is repeating the mistake of the CC license suite that the Free Culture community has spent a decade (and counting) cleaning up.

Conclusions

Please note that IANAL and TINLA. I'm just a community- and individual-developer- focused software freedom policy wonk who has some grave concerns about how these Project Harmony Agreements operate. I can't give you a fine-grained legal analysis, because I'm frankly only an amateur when it comes to the law, but I am an expert in software freedom project policy. In that vein — corporate attorney endorsements notwithstanding — my opinion is that Project Harmony should be abandoned entirely.

In fact, the distinction between policy and legal expertise actually shows the root of the problem with Project Harmony. It's a system of documents designed by a committee primarily comprised of corporate attorneys, yet it's offered up as if it's a FLOSS developer consensus. Indeed, Project Harmony itself was initiated by Amanda Brock, a for-profit corporate attorney for Canonical, Ltd, who is remains involved in its drafting. Canonical, Ltd. later hired Mark Radcliffe (a big law firm attorney, who has defended GPL violators) to draft the alpha revisions of the document, and Radcliffe remains involved in the process. Furthermore, the primary drafting process was done secretly in closed meetings dominated by corporate attorneys until the documents were almost complete; the process was not made publicly open to the FLOSS community until April 2011. The 1.0 documents differ little from the drafts that were released in April 2011, and thus remain to this day primarily documents drafted in secrecy by corporate attorneys who have only a passing familiarity with software freedom culture.

Meanwhile, I've asked Project Harmony's advocates many times who is in charge of Project Harmony now, and no one can give me a straight answer. One is left to wonder who decides final draft approval and what process exists to prevent or permit text for the drafts. The process which once was in secrecy appears to be now in chaos because it was opened up too late for fundamental problems to be resolved.

A few developers are indeed actively involved in Project Harmony. But Project Harmony is not something that most developers requested; it was initiated by companies who would like to convince developers to passively adopt overreaching CLAs and ©AAs. To me, the whole Project Harmony process feels like a war of attrition to convince developers to accept something that they don't necessarily want with minimal dissent. In short, the need for Project Harmony has not been fully articulated to developers.

Finally, I ask, what's really broken here? The industry has been steadily and widely adopting GNU and Linux for years. GNU, for its part, has FSF assignments in place for much of its earlier projects, but the later projects (GNOME, in particular) have either been against both ©AA's and CLA's entirely, or are mostly indifferent to them and use inbound=outbound. Linux, for its part, uses the DCO, which does the job of handling the urgent and important parts of a CLA without getting in developers' way and without otherwise forcing extra liabilities onto the developers and handing over important licensing decisions (including copyleft weakening ones) to a single (usually for-profit) entity.

In short, Project Harmony is a design-flawed solution looking for a problem.

Further Reading
⁰Project Harmony advocates will likely claim to their § 5, “Consequential Damage Waiver” protects developers adequately. I note that it explicitly leaves out, for example, statutory damages for copyright infringement. Also, some types of damages cannot be waived (which is why that section shouts at the reader TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW). Note my discussion of jurisdictions in the main text of this article, and consider the fact that the CLA recipient will obviously select a jurisdiction where the fewest possible damages can be waived. Finally, note that the OR US part of that § 5 is optionally available, and surely corporate attorneys will use it, which means that if they violate the agreement, there's basically no way for you to get any damages from them, even if they their promise to keep the code copylefted.

¹Note: Earlier versions of this blog post conflated slightly “choice of venue&rdquo: with “choice of law”. The wording has been cleared up to address this problem. Please comment or email me if you believe it's not adequately corrected.

Posted on Thursday 07 July 2011 by Bradley M. Kuhn.

Comment on this post in this identi.ca conversation.
2011-07-04: Identi.ca Weekly Summary

Identi.ca Summary, 2011-06-26 through 2011-07-04
- In response to my summary last week, @fontana started a subthread about multiple copyright holders solving proprietary relicensing issues (or, in his view, lack thereof). I complained that @fontana shouldn't have started that subthread in the meta-thread for the summary itself. He disagreed. Anyway, I think the upshot of this discussion is that @fontana is more concerned about proprietary relicensing than I am, which means he must be really concerned, because I'm very concerned.
- @fontana is interested in etymology of phrase could care less. I compared it to irregardless. This descended into a discussion of whether or not I'm bothered by bad grammar.
- I started a thread complaining about trying to prepay for hotels for conference travelers. This got more interest from my followers than I would have thought. (Slow identi.ca day on Monday?)
- @laforge dented about horrible things he's seeing in his GPL enforcement efforts in Germany. I commiserated with him. He then released a blog post with further details, which had its own discussion thread on identi.ca, which in turn descended into a discussion of whether or not people should know by default where Mauritius is.
- @singpolyma answered my call to find Javascript libraries under GPL that aren't proprietary relicensed. @singpolyma indicated he couldn't find any Javascript libraries of consequence licensed as GPL.
- I complained about Conservancy inquiries for projects that haven't actually started coding yet.
- @ossguy is visiting Frank Lloyd Wright buildings in Pittsburgh. I encouraged him to Falling Water and Kentuck Knob. Turns out, that's what @ossguy meant in the first place.
- @fabsh proposed @methoddan play the Star Spangled Banner on Linux Outlaws this 2011-07-04. I suggested it be the Hendrix version.
- I started a strange thread about “Open Source” Leaders.
- @michaeldexter discovered rantofabkuhn.
- @rahulsundaram and @fontana had an interesting discussion on Red Hat's history of preference for the OPL. I joined later to point out the deprecation of OPL (which I just discovered this week).
- Harmony debates continued:
  - @allisonrandal claims she deals with developers who pick GPL or LGPL and “don't understand” the implications of combining that with permissive licensed code. I find this claim quite dubious.
  - A new thread began where @allisonrandal changed the topic to discussing newbie developers. I had thought we were talking about developers who had already chosen GPL, it seems to me the topic change was a rhetorical maneuver.
  - @allisonrandal claimed that FLOSS licenses are not appropriate for inbound licensing. This position is incredibly radical; I think the Linux developers (and nearly every other Free Software developer) will be amazed to learn @allisonrandal believes that they are not using FLOSS licenses appropriately.
  - @dbs noted that his April posts to the Project Harmony mailing list didn't receive a reply.
  - @allisonrandal and I discussed copyright assignment and inbound=outbound.
  - One of the subthreads in the Harmony debates descended into various memories about discussions long before.
- I complained about the cow-orking facility where I'm working.
- I complained about Gnus being slow, and my wish to switch to running from GNU Emacs trunk.
- Someone stepped forward to talk about the hold of 501(c)(3) applications for FLOSS non-profits.
- I discussed racism in Star Wars prequels, and Jello Biafra's view on noncommercial copyright file sharing.
- I picked up on the Gilligan's Island copyright notice thread with a full blog post on the topic.
- @fontana uses OpenOffice, not LaTeX.
- Off-topic to the Gilligan's Island thread, @fontana suggested we start an AGPL'd replacement for Disqus.
- I struggled with bad aspell corrections this week.
- Verizon can't tell the difference between Canonical, Ltd. and the Canonical Hackers.
- Spawning from a discussion about Conkeror/Konqueror and lynx/links (in which @fontana was trolling @copiesofcopies), I had a rather odd conversation with @pchestek. (I am still at a loss of what fathers' sins she's talking about; I presumed she meant that preferring to avoid lawyers in some situations is a sin. “Avoiding lawyers” would certainly be a definition of sin only a lawyer could love! :) She clarified that she was using a parent/child metaphor for original trademark holders and those infringing on the trademark. I'm not particularly comfortable about the metaphor, or considering poor use of a trademark is a sin.
- I was very busy at work this week (as I also noted earlier in the week (and I'm still behind on many things :-/ ).
- I watched the documentary, Hot Coffee, and posted a few links about it.
- @jra said good things about FISL in Brazil including interesting comments about @webmink's talk.
- @fontana claimed that there is an alternative universe where Ronald Reagan stars in It's A Wonderful Life and I write proprietary PHP programs.
- @webmink made a blog post quoting me.
- @fontana and I started using OSCON's social network system in a goofy way, then @fontana compared me to Jerry Brown, which I took offense to.
- My laptop's video card failed and I had to switch laptops.
- FaiF 0x13 comes out tomorrow.
Posted on Monday 04 July 2011 by Bradley M. Kuhn.

Comment on this post in this identi.ca conversation.

June

2011-06-28: What's This “…And the Rest” Crap!?!

Famously, the Gilligan's Island theme song, in its first season, left out mentioning the Professor and Mary Ann characters by name, simply including …And the Rest in that lyric where their names later were heard. Mystery Science Theater 3000 even spoofed this issue during screening of This Island Earth, in which the actor Russell Johnson (The Professor) appeared. When Johnson first appears on screen while viewing This Island Earth, MST3K's Mike says over the film: Hey, what's this …And the Rest Crap!?!. Indeed, what's that all about?

Anyone would get easily annoyed if they've contributed some work but, when credit is giving, they were just relegated into … and the rest. Anyone who is thrown into that group would assume their contribution is somehow also not important, or that the contributions of the credited are somehow better.

Some Free Software projects websites, however, often relegate many of their contributors to being And the Rest, just like The Professor and Mary Ann in their first season of Gilligan's Island. This is a mistake that ought to be addressed when it occurs.

The example of this problem that was recently brought to my attention was on Fedora Project's website. At the bottom of all of the pages of Fedora's website, there's © 2011 Red Hat, Inc. and others. I've dubbed this a “Gilligan's Island copyright notice” because, while Red Hat is probably a copyright holder some of Fedora, Red Hat employees are also fond of pointing out how many contributors they have from outside Red Hat. Yet, with regard to the website, those contributors aren't considered important enough to appear in the copyright notice. They're secondary characters that Red Hat is indicating don't matter that much: like The Professor and Mary Ann in Gilligan's Island's first season.

However, the solution for this problem isn't completely clear. Obviously, listing all the copyright holders at the bottom of every web page is completely unreasonable. In projects themselves, we usually have a CREDITS or COPYRIGHT file that has everyone's notice collected, but rarely is every copyright notice put in the single files of the project. Perhaps website could do the same. Certainly, Gilligan's Island copyright notices can't continue; they relegate everyone but the main entity into a supporting character role, when in fact, in Free Software projects, everyone should be equal.

I've been discussing discussing this issue on identi.ca lately with Richard Fontana of Red Hat, and he's started a thread on Fedora list about this. I hope that it gets resolved soon, and I'm grateful to Fontana for addressing this issue.

It's worth noting that a few examples of other distributions, such as Debian, Arch Linux, and Ubuntu, are even worse in this regard, because they list only a few authors (or a single corporate entity) that may or may not have all the copyright on the project and the website; they don't do the minimal … and the Rest. For example, Debian's copyright notice says: Copyright © 1997-2011 SPI. Such notices are even worse than Gilligan's Island Copyright Notices, because they fail to even acknowledge at all that a diversity of contributors are present and hold copyrights. Note that there's a long-standing Debian bug on this issue (and the related issue of poor licensing of the site).

I suppose Gilligan's Island Copyright Notices are better than marking the work as an organization's own when in fact there has been no assignment of copyright. Still, I think Free Software projects should take more care on this issue. As is noted in the GNOME Foundation Guidelines on Copyright Assignment (which I co-authored), many developers want to see their “name in lights” under the copyright notice when they contribute to a project. It's important that we give them that opportunity.

Posted on Tuesday 28 June 2011 by Bradley M. Kuhn.

Comment on this post in this identi.ca conversation.
2011-06-26: Identi.ca Weekly Summary

Identi.ca Summary, 2011-06-19 through 2011-06-26
- The conversation that I mentioned last week about GPL for Javascript libraries continued in a new thread this week. The thread was rather long:
  - @fontana rather strangely argued that no one should use GPL for Javascript, this seemed like a generally anti-copyleft position to me, and @fontana went on further to say he's now anti-copyleft in some situations, when it relates to proprietary relicensing.
  - I pointed out, using OpenFOAM as an example that being against illegitimate use of otherwise good things doesn't mean you need to be universally against the thing.
  - There was a subthread discussing how GPL requirements work with Javascript, but the subthread diverged into a discussion of CLAs and Fedora, wherein @fontana strangely said that multiple copyright holders won't solve proprietary relicensing problem.
  - @fontana asked for example of a GPL'd Javascript library with multiple copyright holders (i.e., one that isn't using a proprietary recliensing business model). I'd much appreciate if someone can look for an example of a GPL'd Javascript library matching the criteria @fontana describes; I haven't had time to look. I offered @fontana a prop bet on this, regardless.
  - Finally, in the same thread, @jasonriedy mentioned the so-called Lisp LGPL, which I said was a seemed unnecessary now that we have LGPLv3.
- I noted that I wrote a blog post on OpenFOAM.
- I complained about the (lack of a) USA healthcare system.
- @fontana and I had a discussion about crossposting on identi.ca.
- I ack'ed that @fabsh had launched the oggcast, rantofabkuhn.
- The biggest news this week was that @kaz is now Executive Director of the GNOME Foundation, although the thread discussing it on identica was rather short. OTOH, @fontana asked if @kaz would be required to use GNOME 3.
- The thread about @allisonrandal's appearance on Linux Outlaws continued:
  - @allisonrandal claimed to have not said that those who chose strong copyleft were just as happy with weak copyleft relicensing. I found the exact place where she said that in the LO 204 ogg file, wherein she says at 36:15 and 37:30:
    
    Part of that reason is that when a developer develops code they want their code to be used. They may have a general philosophy that they want used. Most developers who contribute under a copyleft license &mdash they'd be happy with any copyleft license — AGPL, GPL, LGPL — they think — that's my “set”. …
    
    You're using GPL and we're using LGPL, so we can't use your code. Hmmm, we can't do that! … this just doesn't fit the way developers think! We want our code to be used — and we're happy to have — if I said GPL, it's probably true that I'm happy to have it under LGPL as well. It's just too much work [without Harmony] to make that happen.
  - @allisonrandal, @fontana and I debated the differences between strong and weak copyleft in a subthread.
  - A subthread discussed who the leadership of Harmony is. I asked for a definitive place where I can find who are the decision-makers of Harmony and no one answered this, but @fontana made some speculations, @allisonrandal claims that Harmony has no leadership (I wondered but didn't dent: should people really be adopting important documents from a group with no leadership?). Also, @fabsh pointed out that he doubted that it was without leaders. @fontana pointed out that SFLC was not previously leader of Harmony; @allisonrandal says she thought they were and yet SFLC claims they weren't. I ended the subtread by asking again how Harmony governing works and got no response.
  - In a subthread, @allisonrandal reiterated that FSF was wrong to change the terms of GPL with GPLv3 (which she'd previously stated on the LO interview. I still believe her position on this ironically contradicts the plans of Harmony, which seeks to empower companies to change licenses unilaterally. (Why should companies have a right to change a license, but FSF shouldn't?)
  - I pointed out to @allisonrandal that GPLv2 already specified inside the license plans for GPLv3. @allisonrandal said in response that FSF updating GPL wasn't helpful to Free Software developers. She further claimed that FSF's update to GPLv3 constituted Manifest Destiny, which I disputed.
  - The conversation on that sub-thread descended into a discussion of @allisonrandal's culturally relativistic attitude toward Free Software, wherein @allisonrandal admitted she's primarily a cultural relativist.
  - Finally, there was subthread discussing how one can be pro-copyleft, believe that proprietary software is morally wrong, but also not believe permissive licensing is morally wrong. I would think such is obvious and well established by, for example, RMS' writings since 1984, but we nevertheless rehashed that old debate. In this subthread, I did point out that Harmony is biased against copyleft, and therefore is not merely an amoral proposition of all options, as @allisonrandal has claimed. (Oh, and this dent of mine in that thread was redented a bit.) I favorites and nearly redented @mlinksva's contribution to the subthread.
  - @fontana linked to a Harmony list post wherein @allisonrandal attempts to make an 11th-hour effort to remove anti-strong-copyleft parts of Harmony.
- There was a rather pointlessly lengthy thread about accents, mostly my Balmur accent (or adjusted version thereof). That discussion bled over onto another thread that started when I left @fontana a voicemail in a think Balmur accent.
- @fontana doesn't like it that I call Hitler a “dude”, even though I said evil dude.
- I was a guest on FLOSS Weekly on Wednesday. @joncruz mentioned he enjoyed the show.
- I mentioned again to @mcgrof my copyleft-by-guilt theory of OpenBSD, which I'd previously mentioned publicly, which @chromatic found amusing.
- FSF intern @williamtheaker is working this summer on some historical GPLv3 data-gathering.
- @fontana started a thread on a Fedora list and on identi.ca about Gilligan's Island copyright of the Fedora website. This was previously discussed in two threads about a month ago, wherein I coined the phrase “Gilligan's Island copyright”. @fontana gave me credit on the Fedora thread for coining the phrase. I'm working on a more complete blog post on Gilligan's Island copyright.
- dneary's blog post made me think of an old boss.
- There was a discussion of my reasons for phoning @fontana.
- My beloved plastic $2 Pretty neat travel soap dish (tray / holder) that I got in 1991 is now cracked.
- @kraai is registered to donate bone marrow. I'm considering it.
- I'm continuing to work on some patches for GNU Bash.
- Some people apparently want an @bkuhn GPL enforcement action figure.
Posted on Sunday 26 June 2011 by Bradley M. Kuhn.

Comment on this post in this identi.ca conversation.
2011-06-21: Welcome to Karen Sandler, New GNOME Foundation Executive Director

In November 2010, after I informed the GNOME Foundation that I'd like to submit some names of potential Executive Director candidates, Germán Póo-Caamaño invited me to serve on the GNOME Foundation's Executive Director Hiring Committee. We agreed that the Committee's work would remain confidential (as any hiring process is wrought with complicated and frank discussions). I usually prefer open processes to confidentiality, but with things like hiring, confidentiality is somewhat of a necessity.

As it turned out, though, I did find myself needing to resign from the committee. Once a particular candidate seriously submitted herself for consideration, I felt that I just had too much of a conflict of interest to continue as part of the Hiring Committee. Specifically, this candidate has been my personal friend for six years (we met after she was hired to work at SFLC), and even co-hosts an oggcast with me.

By now, the world knows why it is that I had to resign from the Hiring Committee: Karen Sandler was today appointed the Executive Director of the GNOME Foundation.

The GNOME project faces a lot of challenges in the next few years. While I am obviously biased, I firmly believe that Karen is an excellent choice to lead the GNOME Foundation and help the GNOME project through these challenges.

Karen will fortunately continue co-hosting the Free as in Freedom oggcast with me, and will still spend some time as pro bono legal counsel to Conservancy. But, her primary role now is leader of the GNOME Foundation, and I welcome her into the job of Executive Director. I did warn her how hard of a job Executive Director can be, but she's the type to take on a challenge. :)

Update: You can hear Karen discuss her new position on Free as in Freedom Episode 0x12, or her interview on LWN with Joe ‘Zonker‘ Brockmeier about the new position.

Posted on Tuesday 21 June 2011 by Bradley M. Kuhn.

Comment on this post in this identi.ca conversation.
2011-06-20: With GPLv3, Everything Old Can Be New Again

I was invited last week to keynote at the Sixth OpenFOAM Conference held at Penn State University in State College, PA. OpenFOAM is a computational fluid dynamics software package released under GPLv3. I was grateful for this opportunity, because rarely do I get the opportunity to meet what I think of as insulated Free Software communities.

By “insulated”, I don't mean that these communities are naïve in any way. They are, however, insulated from the usual politics of the general software freedom community. While the users of OpenFOAM are all familiar with GNU/Linux and other interesting software freedom packages, OpenFOAM users and developers aren't generally reading blogs like mine or following the weekly discussions about copyleft and non-copyleft licensing, or debating with Simon Phipps what “Open By Rule” means.

These users and developers interact with one software freedom license, GPLv3, about one specific codebase. All of there focus comes about that codebase and how the licensing impacts their businesses, their work and their research. This is as it should be: some of the best work in society comes out of communities focusing together very intently on an important area of study.

For me, it's quite interesting to see how these communities sometimes, quite organically, end up having some serious similarities to other ones we find. As I began to research the history of the OpenFOAM, I started as I usually do with the Wikipedia entry, which is (at the time of writing) marked with the Advert template. This was an immediate sign that something odd was going on, so I dug deeper.

Between my research before the workshop and from discussions with users and developers at it, I've pretty much gotten a straight, non-advertising story of what happened. The OpenFOAM codebase was developed at Imperial College as an academic codebase. As often (unfortunately) happens, the university allowed the codebase to be spun off as a proprietary software product into a for-profit company. Eventually, in 2004, the codebase was released under GPL. After usual corporate politics and disputes that our community has seen before, a single corporation, OpenCFD, Ltd., now maintains itself as sole copyright holdership and trademark holdership of the OpenFOAM name.

As such, events have progressed as we have all seen before with MySQL, and other would-be community projects that have ended up under single corporate control. OpenCFD maintains a proprietary relicensing business model, a practice that I've previously denounced. Also, there is aggressive trademark enforcement and licensing control going on, which we have also seen more than once in the software freedom world.

However, despite this, I'm actually quite hopeful about this community I met last week, despite how grim the last paragraph sounds. I theorize this has something do with the heavy academic connections of the project, but for whatever reason, there is a burgeoning but reasonably healthy fork, currently called OpenFOAM-Extend, with a community of academics, volunteer developers, and small businesses interested in it. They are in the classic catbird seat when facing a proprietary relicensed codebase: they can take all they want from the official OpenFOAM releases under GPLv3, and can add their own code without assigning it back to OpenCFD and keeping their own copyrights. I encouraged everyone I met at the conference to do this.

The community faces really only one difficult obstacle: they will eventually have to give up the name, OpenFOAM. The name is trademarked by OpenCFD, and therefore there will always be difficult trying to build a healthy software freedom community around a project whose name is trademarked and aggressively enforced by a for-profit company. I spent my time at the workshop pointing out that a name is just a moniker and that developers and users will gravitate to wherever the healthiest codebase lives, regardless of a name. I pointed out how forks of MySQL like Drizzle have easily built communities, and encouraged OpenFOAM users to watch with interest what happens with other fork+name-change projects like LibreOffice and Jenkins. I hope the OpenFOAM-Extend community will take these examples to heart.

Finally, I'd like to thank the OpenFOAM Workshop organizers for inviting me to keynote at their sixth annual event. I enjoyed meeting everyone at the workshop. I've put the slides from talk there on my website. I also hope to release the recording of my talk as Free as in Freedom oggcast, but I have discuss that with my co-host Karen Sandler before I do.

Posted on Monday 20 June 2011 by Bradley M. Kuhn.

Comment on this post in this identi.ca conversation.
2011-06-19: Identi.ca Weekly Summary

Simon Phipps, when I recently expressed surprise at how he makes 1.37 blog posts/day, suggested that I post enough to identi.ca to make them into blog posts that frequent. I doubt I'm going to do that, but I'm going to have a short go at posting a “Identi.ca Weekly Summary” of threads of interest from the week.

Identi.ca Summary, 2011-06-11 through 2011-06-19
- I started this past week in a thread discussing @laforge's blog post about hackers using Gmail. This led to a a debate with @marjoleink about what a program is and whether how copyright should apply to them.
- In his usual debate-rousing way, @fontana started a thread about GPL and Javascript. That descended into discussion of whether or not this was a troll. I was home alone so I just phoned @fontana and talked to him until he had to hang up.
- There is a a brief discussion about misspellings of my name.
- A discussion ensued about whether or not @fontana and I had made a covenant not to troll each other. rahulsundaram made a cute reference to the Novell/Microsoft deal and I picked up on it with a joke of my own in the same vein.
- Red Hat's CEO has trouble pronouncing GNOME. Is it a desktop, or is it genetics?
- fabsh started a thread by saying he wouldn't sign the Fedora CLA, I asked him why, which led to a debate between me and @fontana about whether or not it is a CLA. In the end, @fontana conceded to call it a ghost of a CLA.
- Following up on @fontana's previous week of using Planet of the Apes to make points at me, I pointed him at The Simpsons Planet of the Apes musical.
- I made a few comments on the Tony Awards.
- For once in history (so far), I thanked Matt Aslett for something.
- @magicfab is using GLPI which I noted was a great program.
- @fontana and I briefly discussed RMS' debates with Gosling about early Emacs.
- There was a brief discussion of toplevel vs. file-by-file copyright inventory.
- There was discussion of lilURL and that fact that it and identi.ca are written in PHP. Later, @fontana agreed to help me rewrite lilURL in Python. It can't be wrong to rewrite from scratch a project with only 462 lines of code and docs.
- I visited State College, PA (for the OpenFOAM Workshop, blog post on that tomorrow), and felt old seeing the students' behavior there.
- The HHKB Type-S came out, but it doesn't seem to be available in the USA yet.
- Evergreen joined the Conservancy.
- I discussed with @copiesofcopies, @fabsh, and others the fact that VMS users and lawyers like ALL CAPS.
- There was a discussion, started by @fontana saying Subversion is dead, about possible merits of Subversion compared to Git. I don't know why @fontana intermixed it with my comments on Allison Randal's appearance on Linux Outlaws.
- @fontana invented the phrase “Asay's Fallacy”. Then @fontana and I ended up discussing characters from It's a Wonderful Life! again.
- @fabsh likes Al Franken's hair, but @fontana and I remember him from SNL instead.
- @fontana asked who ESR is and @glynmoody explained.
That was longer than I thought. I suspect it'll be shorter once/if it's a regular thing.

Posted on Sunday 19 June 2011 by Bradley M. Kuhn.

Comment on this post in this identi.ca conversation.
2011-06-01: Ditching Copyleft to Compete with a Fork?

I was disturbed today to read that Oracle will seek to relicense all OpenOffice code under the Apache-2.0 license and move OpenOffice into the Apache Software Foundation.

I've written recently about how among the permissive licenses, my favorite is clearly the Apache License 2.0. However, I think that one should switch from a copyleft license to a permissive one only in rare circumstances and with the greatest of care.

Obviously, in this case, I oppose Oracle's relicense of OpenOffice.org under Apache-License-2.0. It is probably obvious why I feel that way, but I shall explain nonetheless, just in case. I'm going to mostly ignore the motives for doing so, which I think are obvious: Oracle (and IBM, who are quoted in support of this move) for their own reasons don't like The Document Foundation fork (LibreOffice) of OpenOffice.org. This is a last-ditch effort by IBM and Oracle to thwart the progress of that fork, which has been reported as quite successful and many distributions have begun to adopt LibreOffice. (Even non-software sites sites like Metafilter have users discussing changing to LibreOffice .)

Anyway, as you might suspect, I'm generally against the idea of relicensing from a copyleft to a non-copyleft license in most situations. In fact, I generally take the stance that you should go with the strictest copyleft possible unless there's a strong reason not to. This is well-argued in RMS' essay on the LGPL itself, and I won't repeat those arguments here. Frankly, if I were picking a license for OpenOffice.org and/or LibreOffice from start, I'd pick AGPLv3-or-later, because of the concern that it could be turned into a Google Docs-like web service. But, what I'd do is obviously irrelevant.

OpenOffice.org was put out under LGPLv3, and that was its license for some time. LGPL was presumably chosen to allow proprietary plugins to OpenOffice.org. That might be useful and perhaps a reasonable trade-off decision, since one of the goals of the project is to woo users away from Microsoft's tools which presumably permit proprietary plugins too. Thus, an argument can be made that the situation is vaguely analogous to the C Library situation that inspired LGPL's creation.

But, what does a change from a weak copyleft like LGPLv3 to a fully permissive license do? Specifically, it allows not only proprietary plugins using the OpenOffice.org's defined plugin interfaces, but also for any sort of plugin that reaches into OpenOffice.org code in any way. Even worse, a permissive license allows for direct integration of OpenOffice.org into larger proprietary systems that might offer other desktop suite applications hitherto unimplemented in Free Software.

It's my belief that this license change, if successful in its goals, may help foster a bit of a tragedy of the commons for the core codebase. The codebase is already well known for being somewhat unwieldy and time-consuming to learn. Those who take the time to learn it, but who aren't Free Software enthusiasts, may quickly decide that it's better for them to use that rare knowledge to proprietarize the codebase rather than contribute to the public Free Software versions. The LGPLv3 currently keeps such developers “honest”; the Apache-License-2.0 will not.

Perhaps most importantly, the major consequence to consider is the the ultimate impact on the LibreOffice fork. To consider that impact, we have to look at the instigators of the relicense. IBM and Oracle both now will have a vested interest in maintaining a “barely adequate” public Apache-2.0-licensed codebase while keeping the best stuff in their proprietary versions. OpenOffice.org has actually always suffered from this very tragedy, but historically the regime was held up by mandatory copyright assignment to Oracle (and a semi-exclusive proprietary license from Oracle to IBM) rather than a permissive license. On the surface, then, this seems subtly like the kind of improvement I've written about before — namely — at least a public permissive license puts everyone on equal footing, whereas copyleft with a single for-profit proprietary relicensor gives special powers to the for-profit.

And, frankly, but for the existence of LibreOffice, I think I probably would have concluded that an Apache-2.0 relicense of OpenOffice.org was the lesser of two evils. However, LibreOffice's very existence and momentum turns those two evils into a false dichotomy. Specifically, there's now a third alternative: LibreOffice is a vibrant, open, easy-to-contribute-to, non-copyright-assigned LGPLv3'd codebase now. In that community, the LGPLv3 is the shared and equal agreement; no one has special rights to the code outside of LibreOffice's license. Free Software communities, in fact, always rely on an equitable shared agreement to assure good governance and project health.

Actually, relicensing part of the codebase out from under LibreOffice may actually be the most insidious attack Oracle and IBM could make on the project. Unilateral relicense is the single most destabilizing action you can take against a Free Software community, particularly if the relicense comes from wholly outside the community. Indeed, in my time at various copyright-holding Free Software organizations, I've seen situations where I was helping support a relicensing effort by the copyright holder. In every case, I've seen leaders who could have done a unilateral relicense chose to first consult the community before taking the action to ensure that there weren't any key community members who dissented. Just because you have the right to do something doesn't mean it's the correct action to take, and Free Software leaders know this well; that's why they very rarely act unilaterally on anything.

Meanwhile, in this situation today, we have a copyright holder (Oracle) whose primary goal in relicensing is, in fact, to cause the outcome that Free Software leaders seek to avoid; Oracle is relicensing to undermine a successful Free Software project that relies on its copyrighted code.

Nevertheless, I'm not too worried. I believe the LibreOffice community is strong and grows stronger every day. Since their license is LGPLv3, and they continue to add new code, the fact that most of the underlying code is suddenly available under Apache-2.0 license may matter a lot today, but it will matter less and less with each passing day of new commits under LGPLv3.

In fact, I hope the LibreOffice folks will use this relicense to their advantage. Specifically, I suggest they take an Apache-2.0 license of Oracle's code, which is an LGPLv3-compatible license, and relicense the whole project to LGPLv3-or-later⁰, so they have an easy way (years from now) to switch to LGPLv4, GPLv3, or AGPLv4 if they want to. (BTW, they already have an easy way to switch to GPLv3, since LGPLv3 permits this, and even to AGPLv3 thereafter (via GPLv3§13).)

Note finally that there is one other benefit of this action: according to TDF, some OpenOffice.org code that had previously been proprietary is coming with the Apache-2.0-licensed code dump. This alone may make it all worthwhile, and given the points I make above, I think the ultimate outcome, long term, will be all positive for the LGPL'd LibreOffice codebase.

(I'd like note finally that I'm not the only one to point out that Oracle's action would be different if LibreOffice didn't exist. Sean Michael Kerner said something similar.)

Update (on 2011-06-02): This comment on the Apache/OpenOffice issue by my friend Jeremy Allison was so well written that I felt compelled to update this blog post with it. He's made the comment on the blog of Rob Wier, who appears to be IBM's pointman for handling the politics of this situation.

If you take a careful look linguistically at what IBM's been saying about this situation, I hope you'll notice how politically manipulative it is. Unlike Oracle, which acts like a big gorilla that browbeats their customers, IBMers are a politically aware group of folks deeply skilled at rhetoric. The Free Software community should feel honored that IBM sends skilled diplomats to deal with us, but we shouldn't be fooled by what they are saying. As Jeremy points out, this is about copyleft vs. non-copyleft. We've got a vibrant, weak-copyleft community going now, and IBM and Oracle are making a final attempt to disrupt it.

For example, look carefully at how Wier uses the verb “blessed” to refer to FSF's recent announcement of its licensing recommendations. Of course, he quotes FSF out of context, and doesn't quote this part of FSF's recommendations:
When you contribute to an existing project, you should usually release your modified versions under the same license as the original work. It's good to cooperate with the project's maintainers, and using a different license for your modifications often makes that cooperation very difficult. You should only do that when there is a strong reason to justify it.

The existing license of OpenOffice.org and LibreOffice is LGPLv3. Oracle, in coordination with IBM, unilaterally changed the license out from under the community, rather than cooperating with the existing licensing. Oracle of course had the legal right to do so as copyright holder, but this was an act in conflict with the existing community in a moral sense, even if, again, it was a permissible act under the OO.o “community” guidelines.

⁰ Update on 2011-06-05: idoric pointed out to me that the LibreOffice website says it's LGPLv3-or-later. The LibreOffice website is a bit misleading on in some places on this point. idoric later pointed out that the better description is on the LibreOffice Get Involved for Developers page, which makes it clear that the effective license of Libreoffice is LGPLv3, but the community has chosen (LGPLv3-or-later|MPL) for new contributions. I don't really understand why the dual license with MPL makes sense; I presume it's there to help out pro-software-patent companies that might want to avoid the patent provisions of LGPLv3. It's a shame really, so in some ways, I'm slightly glad that LibreOffice is stuck on LGPLv3 as the effective license, even if it is LGPLv3-only. That brings me back to what I suggest in the main body of the post: relicensing the Apache-2.0 license code from Oracle as LGPLv3-or-later would presumably allow the effective license of the whole codebase to be LGPLv3-or-later.

Posted on Wednesday 01 June 2011 by Bradley M. Kuhn.

Comment on this post in this identi.ca conversation.

May

2011-05-31: Should a Power-User Key Mapping Change Be This Difficult?

It's been some time since X made me hate computing, but it happened again today (well, yesterday into the early hours of today, actually.

I got the stupid idea to upgrade to squeeze from lenny yesterday. I was at work, but it was actually a holiday in the USA, and I figured it would be a good time to do some sysadmin work instead of my usual work.

I admittedly had some things to fix that were my fault: I had backports and other mess installed, but upon removing, the upgrade itself was more-or-less smooth. I faced only a minor problem with my MD device for /boot not starting properly, but the upgrade warned me that I needed to switch to properly using the UUIDs for my RAID arrays, and once I corrected that, all booted fine, even with GRUB2 on my old hardware.

Once I was in X, things got weird, keyboard-wise. My meta and alt keys weren't working. BTW, I separate Alt from Meta, making my actual Alt key into a meta key, while my lower control is set to an Alt (ala Mod2), since I throw away caps lock and make it a control. (This is for when I'm on the laptop keyboard rather than the HHKB.)

I've used the same xmodmap for two decades to get this done:
```
                keycode 22 = BackSpace
                
                clear Mod1
                clear Mod2
                clear Lock
                clear Control
                
                keycode 66  = Control_L
                
                keycode 64 = Meta_L
                keycode 113 = Meta_R
                keycode 37 = Alt_L
                keycode 109 = Alt_R
                
                add Control = Control_L
                
                add Mod1 = Meta_L
                add Mod1 = Meta_R
                
                add Mod2 = Alt_L
                add Mod2 = Alt_R
                
```
This just “doesn't work” in squeeze (or presumably any Xorg 7.5 system). Instead, it just gives this error message:
```
                X Error of failed request:  BadValue (integer parameter out of range for operation)
                  Major opcode of failed request:  118 (X_SetModifierMapping)
                  Value in failed request:  0x17
                  Serial number of failed request:  21
                  Current serial number in output stream:  21
                
```
… and while my Control key ends up fine, it leaves me with no Mod1 nor Mod2 key.

There appear to be at least two Debian bugs (564327 and 432011), which were against squeeze before it was released. In retrospect, I sure wish they'd have been release-critical!. (There's also an Ubuntu bug, which of course just punts to the upstream Debian bug.) There are also two further upstream bugs at freedeskop (20145 and 11822), although Daniel Stone thinks the main problem might be fixed upstream.

I gather that many people “in the know” believe xmodmap to be deprecated, and we all should have switched to xkb years ago. I even got snarky comments to that effect. (Update:) However, after I made this first post, quite angry after 8 hours of just trying to make my Alt key DTRT, I was elated to see Daniel Stone indicate that xmodmap should be backwards compatible. It's always true that almost every time I get pissed off about some Free Software not working, a developer often shows up and tells me they want to fix it. This is in some ways just as valuable as the thing being fixed: knowing that the developer doesn't want the bug to be there — it means it'll be fixed eventually and only patience is required.

However, the bigger problem really is that xkb appears to lack good documentation. If any exists, I can't find it. madduck did this useful blog post (and, later, vinc17 showed me some docs he was working on too). These are basically the only things I could find that were real help on the issue, and they were sparse. I was able to learn, after hours, that this should be the rough equivalent to my old modmap:
```
                partial modifier_keys
                xkb_symbols "thinkpad" {
                    replace key <CAPS>  {  [ Control_L, Control_L ] };
                    modifier_map  Control { <CAPS> };
                    replace key <LALT>  {  [ Meta_L ] };
                    modifier_map Mod1   { Meta_L, Meta_R };
                    key <LCTL> { [ Alt_L ] };
                    modifier_map Mod2 { Alt_L };
                };
                
```
But, you can't just load that with a program! No, it must be placed in a file called /path/symbols/bkuhn, which it is then loaded with an incantation like this:
```
                xkb_keymap {
                        xkb_keycodes  { include "evdev+aliases(qwerty)" };
                        xkb_types     { include "complete"      };
                        xkb_compat    { include "complete"      };
                        xkb_symbols   { include "pc+us+inet(evdev)+bkuhn(thinkpad)"     };
                        xkb_geometry  { include "pc(pc105)"     };
                };
                
```
…which, in turn, requires to be fed into: xkbcomp -I/path - $DISPLAY as stdin. Oh, did I mention you have to get the majority of that stuff above by running setxkbmap -print, then modify it to add the bkuhn(thinkpad) part? I'm impressed that madduck figured this all out. I mean, I know xmodmap was archane incantations and all, but this is supposed to be clearer and better for users wanting to change key mappings? WTF!?!

Oh, so, BTW, my code in /path/symbols/bkuhn didn't work. I tried every incantation I could think of, but I couldn't get it to think about Alt and Meta as separate Mod2 and Mod1 keys. I think it's actually a bug, because weird things happened when I added lines like:
```
                    modifier_map Mod5 { <META> };
                
```
Namely, when I added the above line to my /path/symbols/bkuhn, the Mod2 was then picked up correctly (magically!), but then both LCTL and LALT acted like a Mod2, and I still had no Mod1! Frankly, I was too desperate to get back to my 20 years of keystroke memory to try to document what was going on well enough for a coherent bug report. (Remember, I was doing all this on a laptop where my control key kept MAKING ME SHOUT INSTEAD OF DOING ITS JOB.)

I finally got the idea to give up entirely on Mod2 and see if i could force the literal LCTL key to be a Mod3, hopefully allowing Emacs to again see my usual Mod1 Meta expectations for LALT. So, I saw what some of the code in /usr/share/X11/xkb/symbols/altwin did to handle Mod3, and I got this working (although it required a sawfish change to expect Mod3 instead of Mod2, of course, but that part was 5 seconds of search and replace). Here's what finally worked as contents of /path/symbols/bkuhn:
```
                partial modifier_keys
                xkb_symbols "thinkpad" {
                    modifier_map  Control { <CAPS> };
                    replace key <LALT>  {  [ Meta_L ] };
                    modifier_map Mod1   { Meta_L };
                    key <LCTL> { type[Group1] = "ONE_LEVEL",
                                 symbols[Group1] = [ Super_L ] };
                    modifier_map Mod3 { Super_L };
                };
                
```
So, is all this really less arcane than xmodmap? Was the eight hours of my life spent learning xkb was somehow worth it, because now I know a better tool than xmodmap? I realize I'm a power user, but I'm not convinced that it should be this hard even for power users. I felt reminiscent of days when I had to use Eric Raymond's mode timings howto to get X working. That was actually easier than this!

Even though spot claimed this is somehow Debian's fault, I don't believe him. I bet I would run into the same problem on any system using Xorg 7.5. There are clearly known bugs in xmodmap, and I think there is probably a subtle bug I uncovered that exist xkbd, but I am not sure I can coherently report it without revisiting this horrible computing evening again. Clearly, that first thing I tried should have not made two keys be a Mod2, but only when I moved META into Mod5, right?

BTW, If you're looking for me online tomorrow early, you hopefully know where I am. I'm going to bed two hours before my usual waketime. Ugh. (Update: tekk later typo'ed xmodmap as ’xmodnap‘ on identi.ca. Quite fitting; after working on that all night, I surely needed an xmodnap!

Posted on Tuesday 31 May 2011 by Bradley M. Kuhn.

Comment on this post in this identi.ca conversation.
2011-05-26: Choosing A License

Brett Smith of the FSF has announced a new tutorial available on the GNU website that gives advice about picking a license for your project.

I'm glad that Brett wrote this tutorial. My typical answer when someone asks me which license to chose is to say: Use AGPLv3-or-later unless you can think of a good reason not to. That's a glib answer that is rarely helpful to questioner. Brett's article is much better and more useful.

For me, the particularly interesting outcome of the tutorial is how it finishes a the turbulent trajectory of the FSF's relationship with Apache's license. Initially, there was substantial acrimony between the Apache Software Foundation and the FSF because version 2.0 of the Apache License is incompatible with the GPLv2, a point on which the Apache Software Foundation has long disagreed with the FSF. You can even find cases where I was opining in the press about this back when I was Executive Director of the FSF.

An important component of GPLv3 drafting was to reach out and mend relationships with other useful software freedom licenses that had been drafted in the time since GPLv2 was released. Brett's article published yesterday shows the culmination of that fence-mending: Apache-2.0 is now not only compatible with the GPLv3 and AGPLv3, but also the FSF's recommended permissive license!

Posted on Thursday 26 May 2011 by Bradley M. Kuhn.

Comment on this post in this identi.ca conversation.
2011-05-19: Clarification on Android, its (Lack of) Copyleft-ness, and GPL Enforcement

I'm grateful to Brian Proffitt for clarifying some of these confusions about Android licensing. In particular, I'm glad I'm not the only one who has cleared up the confusions that Edward J. Naughton keeps spreading regarding the GPL.

I noted that Naughton even commented on Proffitt's article; the comment spreads even more confusion about the GPL. In particular, Naughton claims that most BusyBox GPL violations are on unmodified versions of BusyBox. That's just absolutely false, if for no other reason that a binary is a modified version of the source code in the first place, and nearly all BusyBox GPL violations involve a binary-only version distributed without any source (nor an offer therefor).

Mixed in with Naughton's constant confusions about what the GPL and LGPL actually requires, he does have a possible valid point lurking: there are a few components in Android/Linux that are under copyleft licenses, namely Linux (GPL) and Webkit (LGPL). Yet, in all of Naughton's screeching about this issue, I haven't seen any clear GPL or LGPL violation reports — all I see is speculation about what may or may not be a violation without any actual facts presented.

I'm pretty sure that I've spent more time reading and assessing the veracity of GPL violation reports than anyone on the planet. I don't talk about this part of it much: but there are, in fact, a lot of false alarms. I get emails every week from users who are confused about what the GPL and LGPL actually require, and I typically must send them back to collect more details before I can say with any certainty a GPL or LGPL violation has occurred.

Of course, as a software freedom advocate, I'm deeply dismayed that Google, Motorola and others haven't seen fit to share a lot of the Android code in a meaningful way with the community; failure to share software is an affront to what the software freedom movement seeks to accomplish. However, every reliable report that I've seen indicates that there are no GPL nor LGPL violations present. Of course, if someone has evidence to the contrary, they should send it to those of us who do GPL enforcement. Meanwhile, despite Naughton's public claims that there are GPL and LGPL violations occurring, I've received no contact from him. Don't you think if he was really worried about getting a GPL or LGPL violation resolved, he'd contact the guy in the world most known for doing GPL enforcement and see if I could help?

Of course, Naughton hasn't contacted me because he isn't really interested in software freedom. He's interested in getting press for himself, and writing vague reports about Android copyrights and licensing is a way to get lots of press. I put out now a public call to anyone who believes they haven't received source code that they were required to get under GPL or LGPL to get in touch with me and I'll try to help, or at the very least put you in touch with a copyright holder who can help do some enforcement with you. I don't, however, expect to see a message in my inbox from Naughton any time soon, nor do I expect him to actually write about the wide-spread GPL violations related to Android/Linux that Matthew Garrett has been finding. Garrett's findings are the real story about Android/Linux compliance, but it's presumably not headline-getting enough for Naughton to even care.

Finally, Naughton is a lawyer. He has the skills at hand to actually help resolve GPL violations. If he really cared about GPL violations, he'd offer his pro bono help to copyright holders to assist in the overwhelming onslaught of GPL violations. I've written and spoken frequently about how I and others who enforce the GPL are really lacking in talented person-power to do more enforcement. Yet, again, I haven't received an offer from Naughton or these other lawyers who are opining about GPL non-compliance to help me get some actual GPL compliance done. I await their offers, but I'm certainly not expecting they'll be forthcoming.

(BTW, you'll notice that I don't link to Naughton's actual article myself; I don't want to give him any more linkage than he's already gotten. I'm pretty aghast at the Huffington Post for giving a far-reaching soapbox to such shoddy commentary, but I suppose that I shouldn't expect better from a company owned by AOL.)

Posted on Thursday 19 May 2011 by Bradley M. Kuhn.

Comment on this post in this identi.ca conversation.
2011-05-18: Germany Trip: Samba XP Keynote and LinuxTag Keynote

I just returned a few days ago to the USA after one week in Germany. I visited Göttingen for my keynote at Samba XP (which I already blogged about). Attending Samba XP was an excellent experience, and I thank SerNet for sponsoring my trip there. Since going full-time at Conservancy last year, I have been trying to visit the conferences of each of Conservancy's member projects. It will probably take me years to do this, but given that Samba is one of Conservancy's charter members, it's good that I have finally visited Samba's annual conference. It was even better that they asked me to give a keynote talk at Samba XP.

I must admit that I didn't follow the details many of the talks other than Tridge's Samba 4 Status Report talk and Jeremy's The Death of File Protocols. This time I really mean it! talk. The rest, unsurprisingly, were highly specific and detailed about Samba, and since I haven't been a regular Samba user myself since 1996, I didn't have the background information required to grok the talks fully. But I did see a lot of excited developers, and it was absolutely wonderful to meet the entire Samba Team for the first time after exchanging email with them for so many years.

It's funny to see how different communities tend to standardize around the same kinds of practices with minor tweaks. Having visited a lot of project-specific conferences for Conservancy's members, I'm seeing how each community does their conference, and one key thing all projects have in common is the same final conference session: a panel discussion with all the core developers.

The Samba Team has their own little tweak on this. First, John Terpstra asks all speakers at the conference (which included me this year) to join the Samba Team and stand up in front of the audience. Then, the audience can ask any final questions of all speakers (this year, the attendees had none). Then, the Samba Team stands up in front of the crowd and takes questions.

The Samba tweak on this model is that the Samba Team is not permitted to sit down during the Q&A. This year, it didn't last that long, but it was still rather amusing. I've never seen a developers' panel before where the developers couldn't sit down!

After Samba XP, I headed “back” to Berlin (my flight had landed there on Saturday and I'd taken the Deutsche Bahn ICE train to Göttingen for Samba XP), and arrived just in time to attend LinuxNacht, the LinuxTag annual party. (WARNING: name dropping follows!) It was excellent to see Vincent Untz, Lennart Poettering, Michael Meeks and Stefano Zacchiroli at the party (listed in order I saw them at the party).

The next day I attended Vincent's talk, which was about cross-distribution collaboration. It was a good talk, although, I think Vincent glossed over too much the fact that many distributions (Fedora, Ubuntu, and OpenSUSE, specifically) are controlled by companies and that cross-distribution collaboration has certain complications because of this corporate influence. I talked with Vincent in more detail about this later, and he argued that the developers at the companies in question have a lot of freedom to operate, but I maintain there are subtle (and sometimes, not so subtle) influences that cause problems for cross-distribution collaboration. I also encouraged Vincent to listen to Richard Fontana's talk, Open Source Projects and Corporate Entanglement, that Karen and I released as an episode of the FaiF oggcast.

I also attended Martin Michlmayr's talk on SPDX. I kibitzed more than I should have from the audience, pointing out that while SPDX is a good “first start”, it's a bit of a “too little, too late” attempt to address and prevent the flood of GPL violations that are now all too common. I believe SPDX is a great tool for those who already are generally in compliance, but it isn't very likely to impact the more common violations, wherein the companies just ignore their GPL obligations. A lively debate ensued on this topic. I frankly hope to be proved wrong on this; if SPDX actually ends or reduces GPL violations, I'll be happy to work on something else instead.

On Friday afternoon, I gave my second keynote of the week, which was an updated version of my talk, 12 Years of GPL Compliance: A Historical Perspective. It went well, although I misunderstood and thought I had a full hour slot, but only actually had a 50 minute slot, so I had to rush a bit at the end. I really do hate rushing at the end when speaking primarily to a non-native-English-speaking audience, as I know I'm capable of speaking English way too fast (a problem that I am constantly vigilant about under normal public speaking circumstances).

The talk was nevertheless pretty well received, and afterward, I was surrounded by a gaggle of interested copyleft enthusiasts, who, as always, were asking what more can be done to enforce the GPL. My talks on enforcement always tend to elicit this reaction, since my final slides are a bit depressing with regard to the volume of GPL enforcement that's currently occurring.

Meanwhile, I also decided I should also start putting up my slides from talks in a more accessible fashion. Since I use S5 (although I hope to switch to jQuery S5 RSN), my slides are trivially web-publishable anyway. While I've generally published the source code to my slides, it makes sense to also make compiled, quickly viewable versions of my slides on my website too. Finally, I realized I should also put my upcoming public speaking events on my frontpage and have done so.

After a late lunch on Friday, I saw only the very end of Lennart's talk on systemd, and then I visited for a while with Claudia Rauch, Business Manager of KDE, e.V. in the KDE booth. Claudia kindly helped me practice my German a bit by speaking slowly enough that I could actually parse the words.

I must admit I was pretty frustrated all week that my German is now so poor. I studied German for two years in High School and one semester in college. I even participated in a three-week student exchange trip to a Gymnasium (the German term for college-prep high school) in Munich in 1990. Yet, German speaking skills are just a degraded version of what they once were.

Meanwhile, I did rather like Berlin's Tegel airport (TXL). It's a pretty small airport, but I really like its layout. Because of its small size, each check-in area is attached to a security checkpoint, which is then directly connected to the gate. While this might seem a bit tight, it makes it very easy to check-in, go through security, and then be right at your gate. I can understand why an airport this small would have to be closed (it's slated for closure in 2012), but I am glad that I got a chance to travel to it (and probably again, for the Desktop Summit) before it closes.

Posted on Wednesday 18 May 2011 by Bradley M. Kuhn.

Comment on this post in this identi.ca conversation.
2011-05-10: Samba XP Keynote, Jeremy's GPLv3 talk, & GPLv2/LGPLv3

This morning, I gave the keynote talk at Samba XP. I was really honored to be invited to speak to Samba XP (the Samba Developers and Users Conference).

My talk, entitled Samba, GPL Enforcement, and the GPLv3 was about GPL enforcement, and how it relates to the Samba project and embedded devices. I've pushed my slides to my gitorious “talks” project. That's of course just the source code of the slides. Previously, some folks have complained that they have trouble building the slides because they don't have pandoc or other such dependencies installed. (I do, BTW, believe that my Installation Information is adequate, even though the talk isn't GPLv3'd, but it does have some dependencies :). Anyway, I've put up an installed version of my Samba XP slides as well.

Some have asked if there's a recording of the talk. I see video cameras and the like here at Samba XP, and I will try to get the audio for a future FaiF Cast.

Speaking of FaiFCast, Karen and I timed it (mostly by luck) so that, while I'm at Samba XP, we'd release FaiF 0x0F, which includes audio from Jeremy's Linux Collaboration Summit talk about why Samba chose to switch to GPLv3. BTW, I'm sorry I didn't do show notes this week, but because of being at Samba XP the last few days, I wasn't able to write detailed show notes. However, the main thing you need are Jeremy's slides, which are linked to from the show notes section.

Later this week, I'm giving the Friday keynote at Linux Tag, also on GPL enforcement (It's at 13:00 on Friday 2011-05-13). I hope those of you who can come to Berlin will come see my talk!

Finally, Ivo de Decker in the audience at Samba XP asked about LGPLv3/GPLv2 incompatibility. In my answer to the question, I noted the GPL Compatibility Matrix on the GNU site. Also, regarding the specific LGPLv3 compatibility issue, I mentioned post I made last year on the GNOME desktop-devel-list about the LGPLv3/GPLv2 issue. I promised that I'd also quote that post here in my blog, so that there was a stable URL that discussed the issue. I therefore quote the relevant parts of that email here:
The most important point [about GPLv2-only/LGPLv3-or-later incompatibility], I'd like to make is to suggest a possible compromise. Specifically, I suggest disjunctive licensing, (GPLv2|LGPLv3-or-later), which could be implemented like this:
This program's license gives you software freedom; you can copy, modify, convey, propagate, and/or redistribute this software under the terms of either:
- the GNU Lesser General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version.
- the GNU General Public License, version 2 only, as published by the Free Software Foundation.
In addition, when you convey, distribute, and/or propagate this software and/or modified versions thereof, you may also preserve this notice so that recipients of such distributions will also have both licensing options described above.
A good moniker for this license is (GPLv2|LGPLv3-or-later). It actually gives 3+ licensing options to downstream: they can continue under the full (GPLv2|LGPLv3-or-later), or they can use GPLv2-only, or they can use LGPLv3 (or any later version of the LGPL).

Some folks will probably note this isn't that different from LGPLv2.1-or-later. The key difference, though, is that it removes LGPLv2.1 from the mix. If you've read the LGPLv2.1 lately, you've seen that it really shows its age. LGPLv3 is a much better implementation of the weak copyleft idea. If any license needs deprecation, it's LGPLv2.1. I thus personally believe upgrade to (GPLv2|LGPLv3-or-later) is something worth doing right away.

I note, BTW, that existing code licensed LGPLv2.1-or-later has also already given permission to migrate to the license (GPLv2|LGPLv3-or-later). Specifically, it's permitted by LGPLv2.1 to license the work under GPLv2 if you want to. Furthermore, LGPLv2.1-or-later permits you to license LGPLv3-or-later. Therefore, LGPLv2.1-or-later can, at anyone's option, be upgraded to (GPLv2|LGPLv3-or-later).

Note the incompatibility exists on both [GPLv2-only and LGPLv3] sides (it proverbially takes two to tango), but the incompatibility centers primarily around the strong copyleft on the GPLv2 side, not the weak copyleft on the LGPLv3 side. Specifically, GPLv2 requires that:

You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License.
and
You may not impose any further restrictions on the recipients' exercise of the rights granted herein.

This is part of the text that creates copyleft: making sure that other terms can't be imposed.

The problem occurs in interaction with another copyleft license (even a weak one). Usually, no two copyleft implementations are isomorphic and therefore there are different requirements in the details. LGPLv3, for its part, doesn't care much about additional restrictions imposed by another license (hence its weak copyleft nature). However, from the point of view of the GPLv2-side observer, any additional requirement, even minor ones imposed by LGPLv3, are merely “further restrictions”.

This is why copyleft licenses, when they want compatibility, have to explicitly permit relicensing (as LGPLv2 does for GPLv2/GPLv3 and as LGPLv3 does for GPLv3), by allowing you to “upgrade” to the another copyleft from the current copyleft. To be clear, from the point of view the LGPLv3 observer, it has no qualms about “upgrading” from LGPLv3 to GPLv2. The problem occurs from the GPLv2 side, specifically because the (relatively) minor things that LGPLv3 requires are written differently from the similar things asked for in GPLv2.

It's a common misconception that LGPL has no licensing requirements whatsoever on “works that use the library” (LGPLv2) or the “Application” (LGPLv3). That's not completely true; for example, in LGPLv3 § 4+5 (and LGPLv2.1 § 6+7), you find various requirements regarding licensing of such works. Those requirements aren't strict and are actually very easy to comply with. However, from GPLv2's point of view, they are “further restrictions” since they are not written exactly in the same fashion in GPLv2.

(BTW, note that LGPLv2.1's compatibility with GPLv2 and/or GPLv3 comes explicitly from LGPLv2.1's Section 3, which allows direct upgrade to GPLv2 or GPLv3, or to any later version published by FSF).

I hope the above helps some to clarify the GPLv2/LGPLv3 incompatibility.
Posted on Tuesday 10 May 2011 by Bradley M. Kuhn.

Comment on this post in this identi.ca conversation.
2011-05-03: Mono Developers Losing Jobs Isn't Good

Both RMS and I have been critical of Mono, which is an implementation of Microsoft's C# language infrastructure for GNU/Linux systems. (Until recently, at Novell, Miguel De Icaza has led a team of developers working on Mono.)

Most have probably heard that the Attachmate acquisition of Novell completed last week, and that reports of who will be fired because of the acquisition have begun to trickle. This evening, it's been reported that the developers working on Mono will be among those losing their jobs.

In the last few hours, I've seen some folks indicating that this is a good outcome. I worry that this sort of response is somehow inspired by the criticisms and concerns about Mono that software freedom advocates like myself raised. I thus seek to clarify the concerns regarding Mono, and point out why it's unfortunate that these developers won't work on Mono anymore.

First of all, note that the concerns about Mono are that many Microsoft software patents likely read on any C# implementation, and Microsoft's so-called “patent promise” is not adequate to defend the software freedom community. Anyone who uses Mono faces software patent danger from Microsoft. This is precisely why using Mono to write new applications, targeted for GNU/Linux and other software freedom systems, should be avoided.

Nevertheless, Mono should exist, for at least one important reason: some developers write lots and lots of new code on Microsoft systems in C#. If those developers decide they want to abandon Microsoft platforms tomorrow and switch to GNU/Linux, we don't want them to change their minds and decide to stay with Microsoft merely because GNU/Linux lacks a C# implementation. Obviously, I'd support convincing those developers to learn another language system so they won't write more code in C#, but initially, the lack of Free Software C# implementation might impede their switch to Free Software.

This is a really subtle point that has been lost in the anti-Mono rhetoric. I am not aware of any software freedom advocate who wants Mono to cease to exist. The problem that I and others point out is this: it's dangerous to write new code that relies on technology that's likely patented by Microsoft — a company that's known to shake down or even sue Free-Software-using companies over patents. But the value of Mono (while much more limited than its strongest proponents claim) is still apparent and real: it has a good chance to entice developers living in a purely Microsoft environment to switch to a software freedom environment. It was therefore valuable that Novell was funding developers to work on Mono; it's a bad outcome for software freedom that those developers will lose their jobs. Finally, while perhaps some of those developers might get jobs working on more urgent Free Software tasks, many will likely end up in jobs doing proprietary software development. And developers switching from Free Software work to proprietary software work is surely always a loss for software freedom.

Update (2011-05-04): ciarang pointed out to me that Mono for Android is proprietary software. As such, it's certainly better if no one is working on that proprietary project anymore. However, I would make an educated guess that most of the employed Mono developers at Novell were working on the Free Software components, so the above analysis in the main blog post still likely applies in most cases.

Posted on Tuesday 03 May 2011 by Bradley M. Kuhn.

Comment on this post in this identi.ca conversation.

April

2011-04-29: Hopefully My Voice Will Hold Out

Those of you that follow me on identi.ca already know that I caught a rhinovirus, and was very sick while at the 2011 Linux Collaboration Summit (LCS). Unfortunately, the illness got worse since I “worked through” it while at LCS, and I was too sick to work the entire week afterward (the week of 2011-04-11).

I realized thereafter that, before the conference, I forgot to even mention online that I was speaking and chairing the legal track at LCS. I can't blame that on the illness, since I should have noted it on my blog the week before.

So, just barely, I'm posting ahead of time about my appearances this weekend at LinuxFest Northwest (LFNW). I have been asked to give four (!) talks in two days; and unfortunately three are scheduled almost right in a row in one day (I begged the organizers to fix it so I was giving two each day, but they'd already locked in the schedule, and even though I told them within hours of the schedule going up, they weren't able to change it.)

It's a rather amusing story how I ended up giving four talks. Most of you that go to many conferences (and particularly those that speak at them) know that the hardest part of speaking is preparing a new talk. I learned in graduate school that you must practice talks to keep the quality high, and if a talk is new, I usually try to practice twice. That's a pretty large time investment, not to mention the research that has to go into a talk.

So, what I typically do is have between three and five talks that are “active” on my playlist. I'll keep a talk in rotation for about ten to eighteen months and then discontinue it (unless there's new at least 40% new material that I can cycle into, which I sort of consider more-or-less a new talk).

Often, I'll submit up to four active talks to a given conference. I do this for a couple of reasons. The first and foremost reason is to give choice to the program chairs. If I'm prepared to speak on an array of topics, I'd rather offer up what I can to the chairs so that they can pick the best fit for the track they wish to construct. The second reason is, quite frankly, is for when I really want to go to a conference. My employer only funds my travel if I am speaking at a conference, so sometimes, if I really want to go, I have to increase my odds as much as possible that a talk will be accepted. Multiple submissions usually help in this regard (although I can imagine it may hurt one's chances in some rare cases).

Now, something happened with LFNW that's never happened to me before: the organizers accepted three of my four talk submissions, and wait-listed one of them! I wrote to them immediately telling them I was honored they wanted so many of my talks, and that I was of course happy to give all of them if they really wanted me to. Then, I happened to be working on my talks last weekend when the LFWN organizers were updating the schedule, and suddenly, I reloaded the page and saw they'd added the fourth talk as well!

So, in the next two days, I'm giving four talks at LFNW! Most of them are talks I've given before (or at least, given substantially similar talks), so I am not worried about preparation (although I may have to skip any social events on Saturday night to practice the three-in-row for Sunday). What I'm worried about is that my voice has just recovered in the last few days from that long-lasting illness, and I am a bit afraid it won't hold out through all four. So, if you're at LFNW and notice I'm more quiet than usual in the hallway conversations (I'm not known for my silence, after all ;), it's because I'm saving my voice for my talks!

Anyway, here's the run down of my LFWN talks:
- On Saturday 30 April 2011 at 14:30, I'll give my talk which I debuted at LCS: 12 Years of FLOSS License Compliance: A Historical Perspective
- On Sunday 1 May 2011 at 11:00, I'll reprise a talk I've not given for a quite a while, With Software as a Service, Is Only the Network Luddite Free?
- On Sunday 2011-05-01 at 13:30, I'll reprise a talk I've not given for a quite a while, GPLv3: Better Copyleft for Developers and Users (my GPLv3 advocacy talk, which is oft-cited by Fontana, although I can't tell if he's mocking me or not).
- On Sunday 2011-05-01 at 14:30, I'll give the talk I debuted as a keynote at Indiana Linux Fest: Software Freedom Conservancy: Non-Profit Infrastructure for FLOSS.
If you're not able to attend LFNW, I'll try to live-dent as much as I can (when I'm not speaking, which will actually be almost half the conference ;). Watch my identi.ca stream for the #lfnw tag. In particular, I'm really looking forward to Tom “spot” Callaway's talk. I really want to understand his reasoning for not signing the Chromium CLA, since, as Fontana suggests, it might illuminate the reasoning why developers might oppose CLAs for permissively licensed projects.

By way of previews of what conferences I'll be at soon (I'll try to blog more fully about them a week before they start), I'll be giving keynotes at both Samba XP and LinuxTag in a few weeks (both about GPL compliance). I'll also be speaking about GPL compliance at OSCON in late July, and I might be on a panel at the Desktop Summit. I hope to see many of you at one of these events.

I should also apologize to the excellent folks who run RMLL (aka the Libre Software Meeting) in France each year. When I came back so ill from LCS and lost that whole week of work because of it, I took a hard look at my 2011 travel schedule and I just had to cut something. I'm sorry it had to be RMLL, but I hope to make it up to them in a future year. (I actually had to do something similar to the LFNW guys in 2010, which I'm about to make up for this weekend!)

Posted on Friday 29 April 2011 by Bradley M. Kuhn.

Comment on this post in this identi.ca conversation.

March

2011-03-18: Questioning The Original Analysis On The Bionic Debate

I was hoping to avoid having to comment further on this problematic story. I figured a comment as a brief identi.ca statement was enough when it was just a story on the Register. But, it's now hit a major tech news outlet, and I feel that, given that I'm typically the first person everyone in the Free Software world comes to ask if something is a GPL violation, I'm going to get asked about this soon, so I might as well preempt the questions with a blog post, so I can answer any questions about it with this URL.

In short, the question is: Does Bionic (the Android/Linux default C library developed by Google) violate the GPL by importing “scrubbed” headers from Linux? For those of you seeking TL;DR version: You can stop now if you expect me to answer this question; I'm not going to. I'm just going to show that the apparent original analysis material that started this brouhaha is a speculative hypothesis which would require much more research to amount to anything of note.

Indeed, the kind of work needed to answer these questions typically requires the painstaking work of a talented developer working very closely with legal counsel. I've done analysis like this before for other projects. The only one I can easily talk about publicly is the ath5k situation. (If you want to hear more on that, you can listen to an old oggcast where I discussed this with Karen Sandler or read papers that were written on the subject back where I used to work.)

Anyway, most of what's been written about this subject of the Linux headers in Bionic has been poorly drafted speculation. I suppose some will say this blog post is no better, since I am not answering any questions, but my primary goal here is to draw attention that absolutely no one, as near as I can tell, has done the incredibly time consuming work to figure out anything approaching a definitive answer! Furthermore, the original article that launched this debate (Naughton's paper, The Bionic Library: Did Google Work Around the GPL?) is merely a position paper for a research project yet to be done.

Naughton's full paper gives some examples that would make a good starting point for a complete analysis. It's disturbing, however, that his paper is presented as if it's a complete analysis. At best, his paper is a position statement of a hypothesis that then needs the actual experiment to figure things out. That rigorous research (as I keep reiterating) is still undone.

To his credit, Naughton does admit that only the kind of analysis I'm talking about would yield a definitive answer. You have to get almost all the way through his paper to get to:
Determining copyrightability is thus a fact-specific, case-by-case exercise. … Certainly, sorting out what is and isn’t subject to GPLv2 in Bionic would require at least a file-by-file, and most likely line-by-line, analysis of Bionic — a daunting task[.]
Of course, in that statement, Naughton makes the mistake of subtly including an assumption in the hypothesis: he fails to acknowledge clearly that it's entirely possible the set of GPLv2-covered work found in Bionic could be the empty set; he hasn't shown it's not the empty set (even notwithstanding his very cursory analysis of a few files).

Yet, even though Naughton admits full analysis (that he hasn't done) is necessary, he nevertheless later makes sweeping conclusions:
The 750 Linux kernel header files … define a complex overarching structure, an application programming interface, that is thoughtfully and cleverly designed, and almost assuredly protected by copyright.
Again, this is a hypothesis, that would have be tested and proved with evidence generated by the careful line-by-line analysis Naughton himself admits is necessary. Yet, he doesn't acknowledge that fact in his conclusions, leaving his readers (and IMO he's expecting to dupe lots of readers unsophisticated on these issues) with the impression he's shown something he hasn't. For example, one of my first questions would be whether or not Bionic uses only parts of Linux headers that are required by specification to write POSIX programs, a question that Naughton doesn't even consider.

Finally, Naughton moves from the merely shoddy analysis to completely alarmist speculation with:
But if Google is right, if it has succeeded in removing all copyrightable material from the Linux kernel headers, then it has unlocked the Linux kernel from the restrictions of GPLv2. Google can now use the “clean” Bionic headers to create a non-GPL’d fork of the Linux kernel, one that can be extended under proprietary license terms. Even if Google does not do this itself, it has enabled others to do so. It also has provided a useful roadmap for those who might want to do the same thing with other GPLv2-licensed [sic] programs, such as databases.

If it turns out that Google has succeeded in making sure that the GPLv2 does not apply to Bionic, then Google's success is substantially more narrow. The success would be merely the extraction of the non-copyrightable facts that any C library needs to know about Linux to make a binary run when Linux happens to be the kernel underneath. Now, it should be duly noted that there already exist two libraries under the LGPL that have already implemented that (namely, glibc, and uClibc — the latter of which Naughton's cursory research apparently didn't even turn up). As it stands, anyone who wants to write user-space applications on a Linux-based system already can; there are multiple C library choices available under the weak copyleft license, LGPL. Google, for its part, believes they've succeed at is to make a permissively licensed third alternative, which is an outcome that would be no surprise to us who have seen something like it done twice before.

In short, everyone opining here seems to be conflating a lot of issues. There are many ways to interface with Linux. Many people, including me, believe quite strongly that there is no way to make a subprogram in kernel space (such as a device driver) without the terms of the GPLv2 applying to it. But writing a device driver is a specialized task that's very different from what most Linux users do. Most developers who “use Linux” — by which they typically mean write a user space program that runs on a GNU/Linux operating system — have (at most) weak copyleft (LGPL) terms to follow due to glibc or uClibc. I admit that I sometimes feel chagrin that proprietary applications can be written for GNU/Linux (and other Linux-based) systems, but that was a strategic decision that RMS made (correctly) at the start of the GNU project one that the Linux project, for its part, has also always sought.

I'm quite sure no one — including hard-core copyleft advocates like me — expects nor seeks the GPLv2 terms to apply to programs that interface with Linux solely as user-space programs that runs on an operating system that uses Linux as its kernel. Thus, I'd guess that even if it turned out that Google made some mistakes in this regard for Bionic, we'd all work together to rectify those mistakes so that the outcome everyone intended could occur.

Moreover, to compare the specifics of this situation to other types of so-called “copyleft circumvention techniques” is just link-baiting that borders on trolling. Google wasn't seeking to circumvent the GPL at all; they were seeking to write and/or adapt a permissively licensed library that replaced an LGPL'd one. I'm of course against that task on principle (I think Google should have just used glibc and/or uClibc and required LGPL-compliance by applications). But, to deny that it's possible to rewrite a C library for Linux under a license that isn't GPLv2 would also imply immediately the (incorrect) conclusion that uClibc and glibc are covered by the GPLv2, and we are all quite sure they aren't; even Naughton himself admits that (regarding glibc).

Google may have erred; no one actually knows for sure at this time. But the task they sought to do has been done before and everyone intended it to be permitted. The worst mistake of which we might ultimately accuse Google is inadvertently taking a copyright-infringing short-cut. If someone actually does all the research to prove that Google did so, I'd easily offer a 1,000-to-1 bet to anyone that such a copyright infringement could be cleared up easily, that Bionic would still work as a permissively licensed C library for Linux, and the implications of the whole thing wouldn't go beyond: “It's possible to write your own C library for Linux that isn't covered by the GPLv2” — a fact which we've all known for a decade and a half anyway.

Update (2011-03-20): Many people, including slashdot, have been linking to this comment by RMS on LKML about .h files. It's important to look carefully at what RMS is saying. Specifically, RMS says that sometimes #include'ing a .h file creates a copyright derivative work, and sometimes it doesn't; it depends on the details. Then, RMS goes to talk on some rules of thumb that can help determine the outcome of the question. The details are what matters; and those are, as I explain in the main post above, what requires careful analysis done jointly and in close collaboration between a developer and a lawyer. There is no general rule of thumb that always immediately leads one to the right answer on this question.

Posted on Friday 18 March 2011 by Bradley M. Kuhn.

Comment on this post in this identi.ca conversation.
2011-03-11: Thoughts On GPL Compliance of Red Hat's Linux Distribution

Today, I was interviewed by Sam Varghese about whether Red Hat's current distribution policies for the kernel named Linux are GPL-compliant. You can read there that AFAICT they are, and have been presented with no evidence to the contrary.

Last week, when the original story broke, I happened to be at the Linux Foundation's End User Summit, and I had a rather extensive discussion with attendees there about this issue, including Jon Corbet, who wrote an article about it. In my mind, the issue was settled after that discussion, and I had actually put out of my mind, until I realized (when Varghese contacted me for an interview) that people had conflated my previous blog post from last weekend as being a comment specifically on the kernel distribution issue. (I'd been otherwise busy this week, and thus hadn't yet seen Jake Edge's follow-up article on LWN (to which I respond to in detail below).)

(BTW, on this issue please note that my analysis below is purely a GPLv2 analysis. GPLv3 analysis may be slightly different here, but since, for the moment, the issue relates to the kernel named Linux which is currently licensed GPLv2-only, discussing GPLv3 in this context is a bit off-topic.)

Preferred Form For Modification

I have been a bit amazed to watch that so much debate on this has happened around the words of preferred form of the work for making modifications to it from GPLv2§3. In particularly, I can't help chuckling at the esoteric level to which many people believe they can read these words. I laugh to myself and think: not a one of these people commenting on this has ever tried in their life to actually enforce the GPL.

To be a bit less sardonic, I agree with those who are saying that the preferred form of modification should be the exact organization of the bytes as we would all like to have them to make our further work on the software as easy as possible. But I always look at GPL with an enforcers' eye, and have to say this wish is one that won't be fulfilled all the time.

The way preferred form for modification ends up working out in GPLv2 enforcement is something more like: you must provide complete sources that a sufficiently skilled software developer can actually make use of it without any reverse engineering. Thus, it does clearly prohibit things like source on cuneiform tablet that Branden mentions. (BTW, I wonder if Branden knows we GPL geeks started using that as an example circa 2001.) GPLv2 also certainly prohibits source obfuscation tools that Jake Edge mentions. But, suppose you give me a nice .tar.bz2 file with all the sources organized neatly in mundane ASCII files, which I can open up with tar xvf, cd in, type make and get a binary out of those sources that's functional and feature-equivalent to your binaries, and then I can type make install and that binary is put into the right place on the device where your binary runs. I reboot the device, and I'm up and running with my newly compiled version rather than the binary you gave me. I'd call that scenario easily GPLv2 compliant.

Specifically, ease of upstream contribution has almost nothing to do with GPL compliance. Whether you get some software in a form the upstream likes (or can easily use) is more or less irrelevant to the letter of the license. The compliance question always is: did their distribution meet the terms required by the GPL?

Now, I'm talking above about the letter of the license. The spirit of the license is something different. GPL exists (in part) to promote collaboration, and if you make it difficult for those receiving your distributions to easily share and improve the work with a larger community, it's still a fail (in a moral sense), but not a failure to comply with the GPL. It's a failure to treat the community well. Frankly, no software license can effectively prevent annoying and uncooperative behavior from those who seek to only follow the exact letter of the rules.

Prominent Notices of Changes

Meanwhile, what people are actually complaining about is that Red Hat RHEL customers have access to better meta-information about why various patches were applied. Some have argued (quite reasonably) that this information is required under GPLv2§2(a), but usually that section has been interpreted to allow a very terse changelog. Corbet's original article mentioned that the Red Hat distribution of the kernel named Linux contains no changelog. I see why he said that, because it took me some time to find it myself (and an earlier version of this very blog post was therefore incorrect on that point), but the src.rpm file does have what appears to be a changelog embedded in the kernel.spec file. There's also a simple summary as well that in release notes found in a separate src.rpm (in the file called kernel.xml). This material seems sufficient to me to meet the letter-of-the-license compliance for GPLv2§2(a) requirements. I, too, wish the log were a bit more readable and organized, but, again, the debate isn't about whether there's optimal community cooperation going on, but rather whether this distribution complies with the GPL.

Relating This to the RHEL Model

My previous blog post, which, while it was focused on answering the question of whether or not Fedora is somehow inappropriately exploited (via, say, proprietary relicensing) to build the RHEL business model, also addressed the issue whether RHEL's business model is GPL-compliant. I didn't think about that blog post in connection with the distribution of the kernel named Linux issue, but even considering that now, I still have no reason to believe RHEL's business model is non-compliant. (I continue to believe it's unfriendly, of course.)

Varghese directly asked me if I felt the if you exercise GPL rights, then your money's no good here business model is an additional restriction under GPLv2. I don't think it is, and said so. Meanwhile, I was a bit troubled by the conclusions Jake Edge came to regarding this. First of all, I haven't forgotten about Sveasoft (geez, who could?), but that situation came up years after the RHEL business model started, so Jake's implication that Sveasoft “tried this model first” would be wrong even if Sveasoft had an identical business model.

However, the bigger difficulty in trying to use the Sveasoft scenario as precedent (as Jake hints we should) is not only because of the “link rot” Jake referenced, but also because Sveasoft frequently modified their business model over a period of years. There's no way to coherently use them as an example for anything but erratic behavior.

The RHEL model, by contrast, AFAICT, has been consistent for nearly a decade. (It was once called the “Red Hat Advanced Server”, but the business model seems to be the same). Notwithstanding Red Hat employees themselves, I've never talked to anyone who particularly likes the RHEL business model or thinks it is community-friendly, but I've also never received a report from someone that showed a GPL violation there. Even the “report” that first made me aware of the RHEL model, wherein someone told me: I hired a guy to call Red Hat for service all day every day for eight hours a day and those jerks at Red Hat said they were going to cancel my contract didn't sound like a GPL violation to me. I'd cancel the guy's contract, too, if his employee was calling me for eight hours a day straight!

More importantly, though, I'm troubled that Jake indicates the RHEL model requires people to trade their GPL rights for service, because I don't think that's accurate. He goes further to say that terminat[ing] … support contract for users that run their own kernel … is another restriction on exercising GPL rights; that's very inaccurate. Refusing to support software that users have modified is completely different from restricting their right to modify. Given that the GPL was designed by a software developer (RMS), I find it particularly unlikely that he would have intended GPL to require distributors to provide support for any conceivable modification. What software developers want a license that puts that obligation hanging over their head?

The likely confusion here is using the word “restriction” instead of “consequence”. It's undeniable that your support contractors may throw up their hands in disgust and quit if you modify the software in some strange way and still expect support. It might even be legitimately called a consequence of choosing to modify your software. But, you weren't restricted from making those modifications — far from it.

As I've written about before, I think most work should always be paid by the hour anyway, which is for me somewhat a matter of personal principle. I therefore always remain skeptical of any software business model that isn't structured around the idea of a group of people getting paid for the hours that they actually worked. But, it's also clear to me that the GPL doesn't mandate that “hourly work contracts” are the only possible compliant business model; there are clearly others that are GPL compliant, too. Meanwhile, it's also trivial to invent a business model that isn't GPL compliant — I see such every day, on my ever-growing list of GPL violating companies who sell binary software with no source (nor offer therefor) included. I do find myself wishing that the people debating whether the exact right number of angels are dancing on the head of this particular GPL pin would instead spend some time helping to end the flagrant, constant, and obvious GPL violations with which I spent much time dealing time each week.

On that note, if you ever think that someone is violating the GPL, (either for an esoteric reason or a mundane one), I hope that you will attempt to get it resolved, and report the violation to a copyright holder or enforcement agent if you can't. The part of this debate I find particularly useful here is that people are considering carefully whether or not various activities are GPL compliant. To quote the signs all over New York City subways, If you see something, say something. Always report suspicious activity around GPL software so we find out together as a community if there's really a GPL violation going on, and correct it if there is.

Posted on Friday 11 March 2011 by Bradley M. Kuhn.

Comment on this post in this identi.ca conversation.
2011-03-05: The Slur “Open Core”: Toward More Diligent Analysis

I certainly deserve some of the blame, and for that I certainly apologize: the phrase “Open Core” has apparently become a slur word, used by those who wish to discredit the position of someone else without presenting facts. I've done my best when using the term to also give facts that backed up the claim, but even so, I finally abandoned the term back in November 2010, and I hope you will too.

The story, from my point of view, began seventeen months ago, when I felt that “Open Core” was a definable term and that behavior was a dangerous practice. I gave it the clear definition that I felt reflected problematic behavior, as I wrote at the time:
Like most buzzwords, Open Core has no real agreed-upon meaning. I'm using it to describe a business model whereby some middleware-ish system is released by a single, for-profit entity copyright holder, who requires copyright-assigned changes back to the company, and that company sells proprietary add-ons and applications that use the framework.

Later — shortly after I pointed out Mark Shuttleworth's fascination with and leanings towards this practice — I realized that it was better to use the preexisting, tried-and-true term for the practice: “proprietary relicensing”. I've been pretty consistent in avoiding the term “Open Core” since then. I called on Shuttleworth to adopt the FSF's recommendations to show Canonical, Ltd. isn't seeking proprietary relicensing and left the whole thing at that. (Shuttleworth, of course, has refused to even respond, BTW.)

Sadly, it was too late: I'd help create a monster. A few weeks later, Alexandre Oliva (whose positions on the issue of proprietary software inside the kernel named Linux I definitely agree with) took it a step too far and called the kernel named Linux an “Open Core” project. Obviously, Linux developers don't and can't engage in proprietary relicensing; some just engage in a “look the other way” mentality with regard to proprietary components inside Linux. At the time, I said that the term “Open Core” was clearly just too confusing to analyze a real-world licensing situation.

So, I just stopped calling things “Open Core”. My concerns currently are regarding the practice of collecting copyright assignments to copyleft software and engaging in proprietary relicensing activity, and I've focused on advocating against that specific practice. That's what I've criticized Canonical, Ltd. for doing — both with their existing copyright assignment policies and with their effort to extend those policies community-wide with the manipulatively named “Project Harmony”.

Shuttleworth, for his part, is now making use the slur phrase I'd inadvertently help create. Specifically, a few days ago, Shuttleworth accused Fedora of being an “Open Core” product.

I've often said that Fedora is primarily a Red Hat corporate project (and it's among the reasons that I run Debian rather than Fedora). However, since “Open Core” clearly still has no agreed-upon meaning, when I read what Shuttleworth said, I considered the question of whether his claim had any merit (using the “Open Core” definition I used myself before I abandoned the term). Put simply, I asked myself the question: Does Red Hat engaged in “proprietary relicensing of copyleft software with mandatory copyright assignment or non-copyleft CLA“ with Fedora?.

Fact is, despite having serious reservations about how the RHEL business model works, I have no evidence to show that Red Hat requires copyright assignment or a mandatory non-copyleft CLA on copyleft projects on any products other than Cygwin. So, if Shuttleworth had said: Cygwin is Red Hat's Open Core product, I would still encourage him that we should all now drop the term “Open Core”, but I would also agree with him that Cygwin is a proprietary-relicensed product and that we should urge Red Hat to abandon that practice. (Update: It's also been noted by Fontana on identi.ca (although the statement was subsequently deleted by the user) that some JBoss projects require permissive CLAs but licenses back out under LGPL, so that would be another example.)

But does Fedora require contributors to assign copyright or do non-copyleft licensing? I can't find the evidence, but there are some confusing facts. Fedora has a Contributor Licensing Agreement (CLA), which, in §1(D), clearly allows contributors to chose their own license. If the contributor accepts all the defaults on the existing Fedora CLA, the contributor gives a permissive license to the contribution (even for copyleft projects). Fortunately, though, the author can easily copyleft a work under the agreement, and it is still accepted by Fedora. (Contrast this with Canonical, Ltd.'s mandatory copyright assignment form, which explicitly demands Canonical, Ltd.'s power for proprietary relicensing.)

While Fedora's current CLA does push people toward permissive licensing of copylefted works, the new draft of the Fedora CLA is much clearer on this point (in §2). In other words, the proposed replacement closes this bug. It thus seems to me Red Hat is looking to make things better, while Canonical, Ltd. hoodwinks us and is manufacturing consent in Project “Harmony” around a proprietary copyright-grab by for-profit corporations. When I line up the two trajectories, Red Hat's slowly getting better, and Canonical, Ltd. is quickly getting worse. Thus, Shuttleworth, sitting in his black pot, clearly has no right say that the slightly brown kettle sitting next to him is black, too.

It could be that Shuttleworth is actually thinking of the RHEL business model itself, which is actually quite different than proprietary relicensing. I do have strong, negative opinions about the RHEL business model; I have long called it the if you like copyleft, your money is no good here business model. It's a GPL-compliant business model merely because the GPL is silent on whether or not you must keep someone as your customer. Red Hat tells RHEL customers that if they chose to engage in their rights under GPL, then their support contract will be canceled. I've often pointed out (although this may be the first time publicly on the Internet) that Red Hat found a bright line of GPL compliance, walked right up to it, and were the first to stake out a business model right on the line. (I've been told, though, that Cygnus experimented with this business model before being acquired by Red Hat.) This practice is, frankly, barely legitimate.

Ironically, RMS and I used to say that Canonical, Ltd.'s new business model of interest — proprietary relicensing (once trailblazed by MySQL AB) — was also barely legitimate. In one literal sense, that's still true: it's legitimate in the sense that it doesn't violate GPL. In the sense of software freedom morality, I think proprietary relicensing harms the Free Software community too much, and that it was therefore a mistake to ever tolerate it.

As for RHEL's business model, I've never liked it, but I'm still unsure (even ten years later since its inception) about its software freedom morality. It doesn't seem as harmful as proprietary relicensing. In proprietary licensing, those mistreated under the model are the small business and individual developers who are pressured to give up their copyleft rights lest their patches be rejected or rewritten. The small entities are left to chose between maintaining a fork or giving over proprietary corporate control of the codebase. In RHEL's business model, by contrast, the mistreated entities are large corporations that are forced to choose between exercising their GPL rights and losing access to the expensive RHEL support. It seems to me that the RHEL model is not immoral, but I definitely find it unfriendly and inappropriate, since it says: if you exercise software freedom, you can't be our customer.

However, when we analyze these models that occupy the zone between license legitimacy and software freedom morality, I think I've learned from the mistake of using slur phrases like “Open Core”. From my point of view, most of these “edge” business models have ill effects on software freedom and community building, and we have to examine their nuances mindfully and gage carefully the level of harm caused. Sometimes, over time, that harm shows itself to be unbearable (as with proprietary relicensing). We must stand against such models and meanwhile continue to question the rest with precise analysis.

Posted on Saturday 05 March 2011 by Bradley M. Kuhn.

Comment on this post in this identi.ca conversation.
2011-03-01: Software Freedom Is Elementary, My Dear Watson.

I've watched the game show, Jeopardy!, regularly since its Trebek-hosted relaunch on 1984-09-10. I even remember distinctly the Final Jeopardy question that night as This date is the first day of the new millennium. At the age of 11, I got the answer wrong, falling for the incorrect What is 2000-01-01?, but I recalled this memory eleven years ago during the debates regarding when the millennium turnover happened.

I had periods of life where I watched Jeopardy! only rarely, but in recent years (as I've become more of a student of games (in part, because of poker)), I've watched Jeopardy! almost nightly over dinner with my wife. I've learned that I'm unlikely to excel as a Jeopardy! player myself because (a) I read slow and (b) my recall of facts, while reasonably strong, is not instantaneous. I thus haven't tried out for the show, but I'm nevertheless a fan of strong players.

Jeopardy! isn't my only spectator game. Right after college, even though I'm a worse-than-mediocre chess player, I watched with excitement as Deep Blue played and defeated Kasparov. Kasparov has disputed the results and how much humans were actually involved, but even so, such interference was minimal (between matches) and the demonstration still showed computer algorithmic mastery of chess.

Of course, the core algorithms that Deep Blue used were well known and often implemented. I learned α-β pruning in my undergraduate AI course and it was clear that a sufficiently fast computer, given a few strong heuristics, could beat most any full information game with a reasonable branching factor. And, computers typically do these days.

I suppose I never really thought about the issues of Deep Blue being released as Free Software. First, because I was not as involved with Free Software then as I am now, and also, as near as anyone could tell, Deep Blue's software was probably not useful for anything other than playing chess, and its primary power was in its ability to go very deep (hence the name, I guess) in the search tree. In short, Deep Blue was primarily a hardware, not a software, success story.

It was nevertheless, impressive, and last month, I saw the next installment in this IBM story. I watched with interest as IBM's Watson defeated two champion Jeopardy! players. Ken Jennings, for one, even welcomed our new computer overlords.

Watson beating Jeopardy! is, frankly, a lot more innovative than Deep Blue beating chess. Most don't know this about me, but I came very close to focusing my career on PhD work in Natural Language Processing; I believe fundamentally it's the area of AI most in need of attention and research. Watson is a shining example of success in modern NLP, and I actually believe some of the IBM hype about how Watson's technology can be applied elsewhere, such as medical information systems. Indeed, IBM has announced a deal with Columbia University Medical Center to adapt the system for medical diagnostics. (Perhaps Watson's next TV appearance will be on House.)

This all sounds great to most people, but to me, my real concern is the freedom of the software. We've shown in the software freedom community that to advance software and improve it, sharing the software is essential. Technology locked up in a vaulted cave doesn't allow all the great minds to collaborate. Just as we don't lock up libraries so that only the guilded overlords have access, nor should the best software technology be restricted in proprietariness.

Indeed, Eric Brown, at his Linux Foundation End User Linux Summit talk, told us that Watson relied heavily on the publicly available software freedom codebase, such as GNU/Linux, Hadoop, and other FLOSS components. They clearly couldn't do their work without building upon the work we shared with IBM, yet IBM apparently ignores its moral obligation to reciprocate.

So, I just point-blank asked Brown why Watson is proprietary. Of course, I long ago learned to never ask a confrontational question from the crowd at a technical talk without knowing what the answer is likely to be. Brown answered in the way I expected: We're working with Universities to provide a framework for their research. I followed up asking when he would actually release the sources and what license would be. He dodged the question, and instead speculated about what licenses IBM sometimes like to use when it does chose to release code; he did not indicate if Watson's sources will ever be released. In short, the answer from IBM is clear: Watson's general ideas will be shared with academics, but the source code won't be.

This point is precisely one of the reasons I didn't pursue a career in academic Computer Science. Since most jobs — including professorships at Universities — for PhDs in Computer Science require that any code written be kept proprietary, most Computer Science researchers have convinced themselves that code doesn't matter; only publishing ideas do. This belief is so pervasive that I knew something like this would be Brown's response to my query. (I was even so sure, I wrote almost this entire blog post before I asked the question).

I'd easily agree that publishing papers is better than the technology being only a trade secret. At least we can learn a little bit about the work. But in all but the pure theoretical areas of Computer Science, code is written to exemplify, test, and exercise the ideas. Merely publishing papers and not the code is akin to a chemist publishing final results but nothing about the methodologies or raw data. Science, in such cases, is unverifiable and unreproducible. If we accepted such in fields other than CS, we'd have accepted the idea that cold fusion was discovered in 1989.

I don't think I'm going to convince IBM to release Watson's sources as Free Software. What I do hope is that perhaps this blog post convinces a few more people that we just shouldn't accept that Computer Science is advanced by researchers who give us flashy demos and code-less research papers. I, for one, welcome our computer overlords…but only if I can study and modify their source code.

Posted on Tuesday 01 March 2011 by Bradley M. Kuhn.

Comment on this post in this identi.ca conversation.

February

2011-02-15: Everyone in USA: Comment against ACTA today!

In the USA, the deadline for comments on ACTA is today (Tuesday 15 February 2011) at 17:00 US/Eastern. It's absolutely imperative that every USA citizen submit a comment on this. The Free Software Foundation has details on how to do so.

ACTA is a dangerous international agreement that would establish additional criminal penalties, promulgate DMCA/EUCD-like legislation around the world, and otherwise extend copyright law into places it should not go. Copyright law is already much stronger than anyone needs.

On a meta-point, it's extremely important that USA citizens participate in comment processes like this. The reason that things like ACTA can happen in the USA is because most of the citizens don't pay attention. By way of hyperbolic fantasy, imagine if every citizen of the USA wrote a letter today to Mr. McCoy about ACTA. It'd be a news story on all the major news networks tonight, and would probably be in the headlines in print/online news stories tomorrow. Our whole country would suddenly be debating whether or not we should have criminal penalties for copying TV shows, and whether breaking a DVD's DRM should be illegal.

Obviously, that fantasy won't happen, but getting from where we are to that wonderful fantasy is actually linear; each person who writes to Mr. McCoy today makes a difference! Please take 15 minutes out of your day today and do so. It's the least you can do on this issue.

The Free Software Foundation has a sample letter you can use if you don't have time to write your own. I wrote my own, giving some of my unique perspective, which I include below.

The automated system on regulations.gov assigned this comment below the tracking number of 80bef9a1 (cool, it's in hex! :)

Stanford K. McCoy
Assistant U.S. Trade Representative for Intellectual Property and Innovation
Office of the United States Trade Representative
600 17th St NW
Washington, DC 20006

Re: ACTA Public Comments (Docket no. USTR-2010-0014)

Dear Mr. McCoy:

I am a USA citizen writing to urge that the USA not sign ACTA. Copyright law already reaches too far. ACTA would extend problematic, overly-broad copyright rules around the world and would increase the already inappropriate criminal penalties for copyright infringement here in the USA.

Both individually and as an agent of my employer, I am regularly involved in copyright enforcement efforts to defend the Free Software license called the GNU General Public License (GPL). I therefore think my perspective can be uniquely contrasted with other copyright holders who support ACTA.

Specifically, when engaging in copyright enforcement for the GPL, we treat it as purely a civil issue, not a criminal one. We have been successful in defending the rights of software authors in this regard without the need for criminal penalties for the rampant copyright infringement that we often encounter.

I realize that many powerful corporate copyright holders wish to see criminal penalties for copyright infringement expanded. As someone who has worked in the area of copyright enforcement regularly for 12 years, I see absolutely no reason that any copyright infringement of any kind ever should be considered a criminal matter. Copyright holders who believe their rights have been infringed have the full power of civil law to defend their rights. Using the power of government to impose criminal penalties for copyright infringement is an inappropriate use of government to interfere in civil disputes between its citizens.

Finally, ACTA would introduce new barriers for those of us trying to change our copyright law here in the USA. The USA should neither impose its desired copyright regime on other countries, nor should the USA bind itself in international agreements on an issue where its citizens are in great disagreement about correct policy.

Thank you for considering my opinion, and please do not allow the USA to sign ACTA.

Sincerely,
Bradley M. Kuhn

Posted on Tuesday 15 February 2011 by Bradley M. Kuhn.

Comment on this post in this identi.ca conversation.

January

2011-01-23: A Brief Tutorial on a Shared Git Repository

A while ago, I set up Git for a group privately sharing the same central repository. Specifically, this is a tutorial for those who would want to have a Git setup that is a little bit like a SVN repository: a central repository that has all the branches that matter published there in one repository. I found this file today floating in a directory of “thing I should publish at some point”, so I decided just to put it up, as every time I came across this file, it reminded me I should put this up and it's really morally wrong (IMO) to keep generally useful technical information private, even when it's only laziness that's causing it.

Before you read this, note that most developers don't use Git this way, particularly with the advent of shared hosting facilities like Gitorious, as systems like Gitorious solve the weirdness of problems that this tutorial addresses. When I originally wrote this (more than a year ago), the only well-known project that I found using a system like this was Samba; I haven't seen a lot of other projects that do this. Indeed, this process is not really what Git is designed to do, but sometimes groups that are used to SVN expect there to be a “canonical repository” that has all the contents of the shared work under one proverbial roof, and set up a “one true Git repository” for the project from which everyone clones.

Thus, this tutorial is primarily targeted to a user mostly familiar with an SVN workflow, that has ssh access to host.example.org that has a writable (usually by multiple people) Git repository living in the directory /git/REPOSITORY.git/.

Ultimately, The stuff that I've documented herein is basically to fill in the gaps that I found when reading the following tutorials:
- The Git Crash Course for SVN Users. (NOTE: some things in that tutorial, where the author says various commands are equivalent to various svn commands are misleading. It'd better said: if you do foo in Git, it will feel like you were using svn and did bar.)
- Linux Developers' Git Manual
- The Official Git Tutorial.
- A Collection site for Git Documentation (which includes some links already here).
- The Samba guys use Git very similarly to the method discussed in this tutorial.
- markpasc points out there is no svn cp equivalent in git.
- reinh's blog post is the first thing I ever read that explained git push particularly well.
So, here's my tutorial, FWIW. (I apologize that I make the mortal sin of tutorial writing: I drift wildly between second-person-singular, first-person-plural, and passive-voice third-person. If someone sends me a patch to the HTML file that fixes this, I'll fix it. :)

Initial Setup

Before you start using git, you should run these commands to let it know who you are so your info appears correctly in commit logs:
```
                 $ git config --global user.email Your.Email@example.com
                 $ git config --global user.name “Your Real Name”
                
```
Examining Your First Clone

To get started, first we clone the repository:
```
                  $ git clone ssh://host.example.org/git/REPOSITORY.git/
                
```
Now, note that Git almost always operates in the terms of branches. Unlike Subversion, Git's branches are first-class citizens and most operations in Git operate around a branch. The default branch is often called “master”, although I tend to avoid using the master branch for much, mainly because everyone who uses git has a different perception of what the master branch should embody. Therefore, giving all your branches more descriptive name is helpful. But, when you first import something into git, (for example, from existing Subversion trees), everything from Subversion's trunk is thrown on the master branch.

So, we take a look at the result of that clone command. We have a new directory, called REPOSITORY, that contains a “working checkout&rquo; of the repository, and under that there is one special directory, REPOSITORY/.git/, which is a full copy of the repository. Note that this is not like Subversion, where what you have on your local machine is merely one view of the repository. With Git, you have a full copy of everything. However, an interesting thing has been done on your copy with the branches. You can take a look with these commands:
```
                  $ git branch
                  * master
                  $ git branch -r
                  origin/HEAD
                  origin/master
                
```
The first list of branches are the branches that are personal and local to you. (By default, git branch uses the -l option, which shows you only “local” branches; -r means “remote” branches. You can also use -a to see all of them.) Unless you take action to publish your local branches in some way, they will be your private area to work in and live only on your computer. (And be aware: they are not backed up unless you back them up!) The remote ones, that all start with “origin/” track the progress on the shared repository.

(Note the term “origin” is a standard way of referring to “the repository from whence you cloned”, and origin/BRANCH refers to “BRANCH as it looks in the repository from whence you cloned”. However, there is nothing magical about the name “origin”. It's set up to DTRT in your WORKING-DIRECTORY/.git/config file, and the clone command set it all up for you, which is why you have them now.)
Get to Work

The canonical way to “get moving” with a new task in Git is to somehow create a branch for it. Branches are designed to be cheap and quick to create so that users will not be shy about creating a new one. Naming conventions are your own, but generally I like to call a branch USERNAME/TASK when I'm still not sure exactly what I'll be doing with it (i.e., who I will publish it to, etc.) You can always merge it back into another branch, or copy it to another branch (perhaps using a more formal name) later.

Where do you Start Your Branch From?

Once a repository exists, each branch in the repository comes from somewhere — it has a parent. These relationships help Git know how to easily merge branches together. So, the most typical procedure of starting a new branch of your own is to begin with an existing branch. The git checkout command is the easiest to use to start this:
```
                   git checkout -b USERNAME/feature origin/master
                
```
In this example, we've created our own local branch, called USERNAME/feature, and it's started from the current state of origin/master. When you are getting started, you will probably usually want to always base your new branches off of ones that exist on the origin. This isn't a rule, it's just less confusing for a newbie if all your branches have a parent revision that live on the server.

Now, it's important to note here that no branch stands still. It's best to think about a branch as a “moving pointer” to a linked list of some set of revisions in the repository.

Every revision stored in git, local or remote, has a SHA1 which is computed based on the revisions before it plus new patch the revision just applied.

Meanwhile, the only two substantive differences between one of these SHA1 identifiers and an actual branch is that (a) Git keeps changing what identifier the branch refers to as new commits come in (aka it moves the branch's HEAD), and (b) Git keeps track of the history of identifiers the branch previously referred to.
So, above, when we asked git checkout to creat a new branch called USERNAME/feature based on origin/master, the two important things to realize are that (a) your new branch has its HEAD pointing at the same head that is currently the HEAD of origin/master, and (b) you got a new list to start adding revisions in the new branch.

We didn't have to use branch for that. We could have simply started our branch from any old SHA1 of any revision. We happened to want to declare a relationship with the master branch on the server in this case, but we could have easily picked any SHA1 from our git log and used that one.

Do Not Fear the checkout

Every time you run a git checkout SOMETHING command, your entire working directory changes. This normally scares Subversion users; it certainly scared me the first time I used git checkout SOMETHING. But, the only reason it is scary is because svn switch, which is the roughly analogous command in the Subversion world, so often doesn't do something sane with your working copy. By contrast, switching branches and changing your whole working directory is a common occurrence with git.

Note, however, that you cannot do git checkout with uncommitted changes in your directory (which, BTW, also makes it safer than svn switch). However, don't be too Subversion-user-like and therefore afraid to commit things. Remember, with Git (and unlike with Subversion), committing and publishing are two different operations. You can commit to your heart's content on local branches and merge or push into public branches later. (There are even commands to squash many commits into one before putting it on a public branch, in case you don't want people to see all the intermediate goofiness you might have done. This is why, BTW, many Git users commit as often as an SVN user would save in their editors.)

However, if you must switch checkouts but really do fear making commits, there is a tool for you: look into git stash.

Share with the Group

Once you've been doing some work, you'll end up with some useful work finished on a USERNAME/feature branch. As noted before, this is your own private branch. You probably want to use the shared repository to make your work available to others.

When using a shared Git repository, there are two ways to share your branches with your colleagues. The first procedure is when you simply want to publish directly on an existing branch. The second is when you wish to create your own branch.

Publishing to Existing Branch

You may choose to merge your work directly into a known branch on the remote repository. That's a viable option, certainly, but often you want to make it available on a separate branch for others to examine, even before you merge it into something like the master branch. We discuss the slightly more complicated new branch publication next, but for the moment, we can consider the quicker process of publishing to an existing branch.
Let's consider when we have work on USERNAME/feature and we would like to make it available on the master branch. Make sure your USERNAME/feature branch is clean (i.e., all your changes are committed).

The first thing you should verify is that you have what I call a “local tracking branch” (this is my own term that I made up, I think, you won't likely see it in other documentation) that is tied directly with the same name to the origin. This is not completely necessary, but is much more convenient to keep track of what you are doing. To check, do a:
```
                   $ git branch -a
                   * USERNAME/feature
                     master
                     origin/master
                
```
In the list, you should see both master and origin/master. If you don't have that, you should create it with:
```
                   $ git checkout -b master origin/master
                
```
So, either way, you wan to be on the master branch. To get there if it already existed, you can run:
```
                   $ git checkout master
                
```
And you should be able verify that you are now on master with:
```
                   $ git branch
                   * master
                   ...
                
```
Now, we're ready to merge in our changes:
```
                   $ git merge USERNAME/feature
                   Updating ded2fb3..9b1c0c9
                   Fast forward
                   FILE ...
                   N files changed, X insertions(+), Y deletions(-)
                
```
If you don't get any message about conflicts, everything is fine. Your changes from USERNAME/feature are now on master. Next, we publish it to the shared repository:
```
                  $ git push
                  Counting objects: N, done.
                  Compressing objects: 100% (A/A), done.
                  Writing objects: 100% (A/A), XXX bytes, done.
                  Total G (delta T), reused 0 (delta 0)
                  refs/heads/master: IDENTIFIER_X -> IDENTIFIER_Y
                  To ssh://host.example.org/git/REPOSITORY.git
                   X..Y  master -> master
                
```
Your changes can now be seen by others when they git pull (See below for details).

Publishing to a New Branch

Suppose, what you wanted to instead of immediately putting the feature on the master branch, you wanted to simply mirror your personal feature branch to the rest of your colleagues so they can try it out before it officially becomes part of master. To do that, first, you need tell Git we want to make a new branch on the shared repository. In this case, you do have to use the git push command as well. (It is a catch-all command for any operations you want to do to the remote repository without actually logging into the server where the shared Git repository is hosted. Thus, Not surprisingly, nearly any git push commands you can think of will require you to be net.connected.)

So, first let's create a local branch that has the actual name we want to use publicly. To do this, we'll just use the checkout command, because it's the most convenient and quick way to create a local branch from an already existing local branch:
```
                  $ git branch -l
                  * USERNAME/feature
                    master
                    ...
                  $ git checkout -b proposed-feature USERNAME/feature
                  Switched to a new branch “proposed-feature”
                  $ git branch -l
                  * proposed-feature
                    USERNAME/feature
                    master
                    ...
                
```
Now, again, we've only created this branch locally. We need an equivalent branch on the server, too. This is where git push comes in:
```
                  $ git push origin proposed-feature:refs/heads/proposed-feature
                
```
Let's break that command down. The first argument for push is always “the place you are pushing to”. That can be any sort of git URL, including ssh://, http://, or git://. However, remember that the original clone operation set up this shorthand “origin” to refer to the place from whence we cloned. We'll use that shorthand here so we don't have to type out that big long URL.

The second argument is a colon-separated item. The left hand side is the local branch we're pushing from on our local repository, and the right hand side is the branch we are pushing to on the remote repository.

(BTW, I have no idea why refs/heads/ is necessary. It seems you should be able to say proposed-feature:proposed-feature and git would figure out what you mean. But, in the setups I've worked with, it doesn't usually work if you don't put in refs/heads/.)

That operation will take a bit to run, but when it is done we see something like:
```
                  Counting objects: 35, done.
                  Compressing objects: 100% (31/31), done.
                  Writing objects: 100% (33/33), 9.44 MiB | 262 KiB/s, done.
                  Total 33 (delta 1), reused 27 (delta 0)
                  refs/heads/proposed-feature: 0000000000000000000000000000000000000000
                                                 -> CURRENT_HEAD_SHA1_SUM
                  To ssh://host.example.org/git/REPOSITORY.git/
                   * [new branch]      proposed-feature -> proposed-feature
                
```
In older Git clients, you may not see that last line, and you won't get the origin/proposed-feature branch until you do a subsequent pull. I believe newer git clients do the pull automatically for you.

Reconfiguring Your Client to see the New Remote Branch

Annoyingly, as the creator of the branch, we have some extra config work to do to officially tell our repository copy that these two branches should be linked. Git didn't know from our single git push command that our repository's relationship with that remote branch was going to be a long term thing. To marry our local to origin/proposed-feature to a local branch, we must use the commands:
```
                  $ git config branch.proposed-feature.remote origin
                  $ git config branch.proposed-feature.merge refs/heads/proposed-feature
                
```
We can see that this branch now exists because we find:
```
                  $ git branch -a
                  * proposed-feature
                    USERNAME/feature
                    master
                    origin/HEAD
                    origin/proposed-feature
                    origin/master
                 
```
After this is done, the remote repository has a proposed-feature branch and, locally, we have a proposed-feature branch that is a “local tracking branch” of origin/proposed-feature. Note that our USERNAME/feature, where all this stuff started from, is still around too, but can be deleted with:
```
                git branch -d USERNAME/feature
                
```
Finding It Elsewhere

Meanwhile, someone else who has separately cloned the repository before we did this won't see these changes automatically, but a simple git pull command can get it:
```
                  $ git pull
                  remote: Generating pack...
                  remote: Done counting 35 objects.
                  remote: Result has 33 objects.
                  remote: Deltifying 33 objects...
                  remote:  100% (33/33) done
                  remote: Total 33 (delta 1), reused 27 (delta 0)
                  Unpacking objects: 100% (33/33), done.
                  From ssh://host.example.org/git/REPOSITORY.git
                   * [new branch]      proposed-feature -> origin/proposed-feature
                  Already up-to-date.
                  $ git branch -a
                  * master
                    origin/HEAD
                    origin/proposed-feature
                    origin/master
                
```
However, their checkout directory won't be updated to show the changes until they make a local “mirror” branch to show them the changes. Usually, this would be done with:
```
                  $ git checkout -b proposed-feature origin/proposed-feature
                
```
Then they'll have a working copy with all the data and a local branch to work on.

BTW, if you want to try this yourself just to see how it works, you can always make another clone in some other director just to play with, by doing something like:
```
                  $ git clone ssh://host.example.org/git/SOME-REPOSITORY.git/ \
                    extra-clone-for-git-didactic-purposes
                
```
Now on this secondary checkout (which makes you just like the user who is not the creator of the new branch), work can be pushed and pulled on that branch easily. Namely, anything you merge into or commit on your local proposed-feature branch will automatically be pushed to origin/proposed-feature on the server when you git push. And, anything that shows up from other users on the origin/proposed-feature branch will show up when you do a git pull. These two branches were paired together from the start.

Irrational Rebased Fears
When using a shared repository like this, it's generally the case that git rebase usually screws something up. When Git is used in the “normal way”, rebase is one of the amazing things about Git. The rebase idea is: you unwind the entire work you've done on one of your local branches, bringing in changes that other people have made in the meantime, and then reapply your changes on top of them.

It works out great when you use Git the way the Linux Project does. However, if you use a single, shared repository in a work group, rebase can be dangerous.

Generally speaking, though, with a shared repository, you can use git merge and won't need rebasing. My usual work flow is that I get started on a feature with:
```
                  $ git checkout -b bkuhn/new-feature starting-branch
                
```
I work work work away on it. Then, when it's ready, I send a patch around to a mailing list that I generate with:
```
                  $ git diff $(git merge-base starting-branch bkuhn/new-feature) bkuhn/new-feature
                
```
Note that the thing in the $() returns a single identifier for a version, namely, the version of the fork point between starting-branch and bkuhn/new-feature. Therefore, the diff output is just the stuff I've actually changed. This generates all the differences between the place where I forked and my current work.

Once I have discussed and decided with my co-developers that we like what I've done, I do this:
```
                  $ git checkout starting-branch
                  $ git merge bkuhn/new-feature
                
```
If all went well, this should automatically commit my feature into starting-branch. Usually, there is also an origin/starting-branch, which I've probably set up for automatic push/pull with my local starting-branch, so I then can make the change officially by running:
```
                  $ git push
                
```
The fact that I avoid rebase is probably merely FUD, and if I learned more, I could use it safely in cases with shared repository. But I have no advice on how to make it work. In particular, this Git FAQ entry shows quite clearly that my work sequence ceases to work all that well when you do a rebase — namely, doing a git push becomes more complicated.

I am sure a rebase would easily become very necessary if I lived on bkuhn/new-feature for a long time and there had been tons of changes underneath me, but I generally try not to dive to deep into a fork, although many people love DVCS because they can do just that. YMMV, etc.

Posted on Sunday 23 January 2011 by Bradley M. Kuhn.

Comment on this post in this identi.ca conversation.
2011-01-18: Free as in Freedom, Episode 0x07

I realized that I should start regularly noting here on my blog when the oggcast that I co-host with Karen Sandler is released. There are perhaps folks who want content from my blog but haven't subscribed to the RSS feed of the show, and thus might want to know when new episodes come out. If this annoys people reading this blog, please let me know via email or identica.

In particular, perhaps readers won't like that, in these posts (which are going to be written after the show), I'm likely to drift off into topics beyond what was talked about on the show, and there may be “spoilers” for the oggcast in them. Again, if this annoys you (or if you like it) please let me know.

Today's FaiF episode is entitled Revoked?. The main issue of discussion is some recent confusions about the GPLv2 release of WinMTR. I was quoted in an article about the topic as well, and in the oggcast we discuss this issue at length.

To summarize my primary point in the oggcast: I'm often troubled when these issues come up, because I've seen these types of confusions so many times before in the last decade. (I've seen this particular one, almost exactly like this, at least five times.) I believe that those of us who focus on policy issues in software freedom need to do a better job documenting these sorts of issues.

Meanwhile, after we recorded the show I was thinking again about how Karen points out in the oggcast that the primary issues are legal ones. I don't really agree with that. These are policy questions, that are perhaps informed by legal analysis, and it's policy folks (and, specifically, Free Software project leaders) that should be guiding the discussion, not necessarily lawyers.

That's not to say that lawyers can't be policy folks as well; I actually think Karen and a few other lawyers I know are both. The problem is that if we simply take things like GPL on their face — as if they are unchanging laws of nature that simply need to be interpreted — we miss out on the fact that licenses, too, can have bugs and can fail to work the way that they should. A lawyer's job is typically to look at a license, or a law, or something more or less fixed in its existence and explain how it works, and perhaps argue for a particular position of how it should be understood.

In our community, activists and project leaders who set (or influence) policy should take such interpretations as input, and output plans to either change the licenses and interpretation to make sure they properly match the goals of software freedom, or to build up standards and practices that work within the existing licensing and legal structure to advance the goal of building a world where all published software is Free Software.

So, those are a few thoughts I had after recording; be sure to listen to FaiF 0x07 available in ogg and mp3 formats.

Posted on Tuesday 18 January 2011 by Bradley M. Kuhn.

Comment on this post in this identi.ca conversation.
2011-01-02: Conservancy Activity Summary, 2010-10-01 to 2010-12-31

[ Crossposted from Conservancy's blog. ]

I had hoped to blog more regularly about my work at Conservancy, and hopefully I'll do better in the coming year. But now seems a good time to summarize what has happened with Conservancy since I started my full-time volunteer stint as Executive Director from 2010-10-01 until 2010-12-31.

New Members

We excitedly announced in the last few months two new Conservancy member projects, PyPy and Git. Thinking of PyPy connects me back to my roots in Computer Science: in graduate school, I focused on research about programming language infrastructure and, in particular, virtual machines and language runtimes. PyPy is a project that connects Conservancy to lots of exciting programming language research work of that nature, and I'm glad they've joined.

For its part, Git rounds out a group of three DVCS projects that are now Conservancy members; Conservancy is now the home of Darcs, Git, and Mercurial. Amusingly, when I reminded the Git developers when they applied that their “competition” were members, the Git developers told me that they were inspired to apply because these other DVCS' had been happy in Conservancy. That's a reminder that the software freedom community remains a place where projects — even that might seem on the surface as competitors — seek to get along and work together whenever possible. I'm glad Conservancy now hosts all these projects together.

Meanwhile, I remain in active discussions with five projects that have been offered membership in Conservancy. As I always tell new projects, joining Conservancy is a big step for a project, so it often takes time for communities to discuss the details of Conservancy's Fiscal Sponsorship Agreement. It may be some time before these five projects join, and perhaps they'll ultimately decide not to join. However, I'll continue to help them make the right decision for their project, even if joining a different fiscal sponsor (or not joining one at all) is the ultimately right choice.

Also, about once every two weeks, another inquiry about joining Conservancy comes in. We won't be able to accept all the projects that are interested, but hopefully many can become members of Conservancy.

Annual Filings

In the late fall, I finished up Conservancy's 2010 filings. Annual filings for a non-profit can be an administrative rat-hole at times, but the level of transparency they create for an organization makes them worth it. Conservancy's FY 2009 Federal Form 990 and FY 2009 New York CHAR-500 are up on Conservancy's filing page. I always make the filings available on our own website; I wish other non-profits would do this. It's so annoying to have to go to a third-party source to grab these documents. (Although New York State, to its credit, makes all the NY NPO filings available on its website.)

Conservancy filed a Form 990-EZ in FY 2009. If you take a look, I'd encourage you to direct the most attention to Part III (which is on the top of page 2) to see most of Conservancy's program activities between 2008-03-01 to 2009-02-28.

In FY 2010, Conservancy will move from the New York State requirement of “limited financial review” to “full audit“ (see page 4 of the CHAR-500 for the level requirements). Conservancy had so little funds in FY 2007 that it wasn't required to file a Form 990 at all. Now, just three years later, there is enough revenue to warrant a full audit. However, I've already begun preparing myself for all the administrative work that will entail.

Project Growth and Funding

Those increases in revenue are related to growth in many of Conservancy's projects. 2010 marked the beginning of the first full-time funding of a developer by Conservancy. Specifically, since June, Matt Mackall has been funded through directed donations to Conservancy to work full-time on Mercurial. Matt blogs once a month (under topic of Mercurial Fellowship Update) about his work, but, more directly, the hundreds of changesets that Matt's committed really show the advantages of funding projects through Conservancy.

Conservancy is also collecting donations and managing funding for various part-time development initiatives by many developers. Developers of jQuery, Sugar Labs, and Twisted have all recently received regular development funding through Conservancy. An important part of my job is making sure these developers receive funding and report the work clearly and fully to the community of donors (and the general public) that fund this work.

But, as usual with Conservancy, it's handling of the “many little things” for projects that make a big difference and sometimes takes the most time. In late 2010, Conservancy handled funding for Code Sprints and conferences for the Mercurial, Darcs, and jQuery. In addition, jQuery held a conference in Boston in October, for which Conservancy handled all the financial details. I was fortunate to be able to attend the conference and meet many of the jQuery developers in person for the first time. Wine also held their annual conference in November 2010, and Conservancy handled the venue details and reimbursements to many of travelers to the conference.

Also, as always, Conservancy project contributors regularly attend other conferences related to their projects. At least a few times a month, Conservancy reimburses developers for travel to speak and attend important conferences related to their projects.

Google Summer of Code

Since its inception, Google's Summer of Code (SoC) program has been one of the most important philanthropy programs for Open Source and Free Software projects. In 2010, eight Conservancy projects (and 5% of the entire SoC program) participated in SoC. The SoC program funds college students for the summer to contribute to the projects, and an experienced contributor to project mentors each student. A $500 stipend is paid to the non-profit organization of the project for each project contributor who mentors a student.

Furthermore, there's an annual conference, in October, of all the mentors, with travel funded by Google. This is a really valuable conference, since it's one of the few places where very disparate Free Software projects that usually wouldn't interact can meet up in one place. I attended this year's Soc Mentor Summit and hope to attend again next year.

I'm really going to be urging all Conservancy's projects to take advantage of the SoC program in 2011. The level of funding given out by Google for this program is higher than any other open-application funding program for FLOSS. While Google's selfish motives are clear (the program presumably helps them recruit young programmers to hire), the benefit to Free Software community of the program can nevertheless not be ignored.

GPL Enforcement

GPL Enforcement, primarily for our BusyBox member project, remains an active focus of Conservancy. Work regarding the lawsuit continues. It's been more than a year since Conservancy filed a lawsuit against fourteen defendants who manufacture embedded devices that included BusyBox without source nor an offer for source. Some of those have come into compliance with the GPL and settled, but a number remain and are out of compliance; our litigation efforts continue. Usually, our lawyers encourage us not to comment on ongoing litigation, but we did put up a news item in August when the Court granted Conservancy a default judgment against one of the defendants, Westinghouse.

Meanwhile, in the coming year, Conservancy hopes to expand efforts to enforce the GPL. New violation reports on BusyBox arrive almost daily that need attention.

More Frequent Blogging

As noted at the start of this post, my hope is to update Conservancy's blog more regularly with information about our activities.

This blog post was covered on LWN and on lxnews.org.

Posted on Sunday 02 January 2011 by Bradley M. Kuhn.

Comment on this post in this identi.ca conversation.

Tag Cloud

Powered by

Bradley M. Kuhn's Blog

2012

February

2012-02-01: Some Basic Thoughts on GPL Enforcement

January

2012-01-17: FaiFCast and Upcoming Talks

2012-01-16: It May Be Boring, But Worth Reading Anyway

2011

December

2011-12-16: FaiFCast Release, and Submit to FOSDEM Legal & Policy Issues DevRoom

Submit a proposal for the Legal & Policy Issues DevRoom CFP

Issues & Questions List for the Software Freedom Non-Profits Debate

November

2011-11-28: What's a Free Software Non-Profit For?

2011-11-24: No, You Won't See Me on Facebook, Google Plus, nor Skype

2011-11-13: Just Ignore Him; He'll Go Away Eventually.

2011-11-11: Last Four FaiF Episodes

September

2011-09-28: Two FaiF Episodes

August

2011-08-21: Desktop Summit 2011

2011-08-18: Will Nokia Ever Realize Open Source Is Not a Panacea?

2011-08-15: If Only They'd Actually Help Enforce GPL

2011-08-05: You're Living in the Past, Dude!

July

2011-07-29: GNU Emacs Developers Will Fix It; Please Calm Down

2011-07-07: Project Harmony Considered Harmful

Copyright Assignment That Lacks Real Assurances

Giving Away Rights to Give Companies Warm Fuzzies?

“Choice of Law” & Contractual Arrangement Muddies Copyright Claims

Problems for Individual Copyright Enforcement Against Third-Parties

Inbound=Outbound Is All You Need

Linux Hackers Ingeniously Trailblazed inbound=outbound

What about Relicensing?

An Anti-Strong-Copyleft Bias?

This is No Creative Commons, But Even If It Were, Is It Worth Emulation?

Conclusions

Further Reading

2011-07-04: Identi.ca Weekly Summary

Identi.ca Summary, 2011-06-26 through 2011-07-04

June

2011-06-28: What's This “…And the Rest” Crap!?!

2011-06-26: Identi.ca Weekly Summary

Identi.ca Summary, 2011-06-19 through 2011-06-26

2011-06-21: Welcome to Karen Sandler, New GNOME Foundation Executive Director

2011-06-20: With GPLv3, Everything Old Can Be New Again

2011-06-19: Identi.ca Weekly Summary

Identi.ca Summary, 2011-06-11 through 2011-06-19

2011-06-01: Ditching Copyleft to Compete with a Fork?

May

2011-05-31: Should a Power-User Key Mapping Change Be This Difficult?

2011-05-26: Choosing A License

2011-05-19: Clarification on Android, its (Lack of) Copyleft-ness, and GPL Enforcement

2011-05-18: Germany Trip: Samba XP Keynote and LinuxTag Keynote

2011-05-10: Samba XP Keynote, Jeremy's GPLv3 talk, & GPLv2/LGPLv3

2011-05-03: Mono Developers Losing Jobs Isn't Good

April

2011-04-29: Hopefully My Voice Will Hold Out

March

2011-03-18: Questioning The Original Analysis On The Bionic Debate

2011-03-11: Thoughts On GPL Compliance of Red Hat's Linux Distribution

Preferred Form For Modification

Prominent Notices of Changes

Relating This to the RHEL Model

2011-03-05: The Slur “Open Core”: Toward More Diligent Analysis

2011-03-01: Software Freedom Is Elementary, My Dear Watson.

February

2011-02-15: Everyone in USA: Comment against ACTA today!

January

2011-01-23: A Brief Tutorial on a Shared Git Repository

Initial Setup

Examining Your First Clone

Get to Work

Where do you Start Your Branch From?

Do Not Fear the checkout

Share with the Group

Publishing to Existing Branch

Publishing to a New Branch