Software Freedom Law Center

June 29, 2009 by Bradley M. Kuhn

Considerations on Patents that Read on Language Infrastructure

In an essay last Friday entitled Why free software shouldn't depend on Mono or C#, RMS argued a key point that I agree with: the software freedom community should minimize its use of programming language infrastructure that comes primarily from anti-software-freedom companies, notwithstanding FaiF (Free as in Freedom) implementations. I've been thinking about an extension of that argument: that language infrastructure created in a community process is likely more resilient against attacks from proprietary software companies.

Specifically, I am considering the risk that a patent attack will occur against the language or its canonical implementation. We know that the USPTO appears to have no bounds in constantly granting so-called “software patents”, most of which are invalid within their own system, and the rest may be like the RSA patent, and will force our community to invent around them, or (as we had to do with RSA), “wait them out”. I'd like to consider how these known facts apply to the implementation of language infrastructure in the Free Software world.

Programming languages and their associated standard libraries and implementations evolve in three basic ways:

• A Free Software community designs and implements the language in a grassroots fashion. Perl, PHP, and Python are a few examples.
• A single corporate entity controls the language and its canonical implementation. They perhaps also convince some standards body to adopt it, but usually retain complete control. C# and Java a few examples.
• A single corporate entity controlled the language initially, but more than 20 years have passed and the language now has many proprietary and Free Software implementations. C and C++ are a few examples.

The patent issues in each of these situations deserves different consideration, primarily related to the dispersion of patents that likely read on the given language implementation. We have to assume that the USPTO has granted many patents that read on any software a person can conceivably write. The question is always: of all the things you can write, which has the most risk of patent attack from the patent holders in question?

In the case of the community-designed and Free-Software-implemented languages, the patent risk is likely spread across many companies, and mitigated by the fact that few have probably filed patents applications designed specifically to read on the language and its implementation. Since various individuals and companies contributed to the development and design, and because it was a process run by the community, it's unlikely there was a master plan by one entity to apply specifically for patents on the language. So, while there are likely many patents that read on the implementation, a single holder is unlikely to hold all the patents, and those patents were probably not crafted for the specific language. Only some of these many patent-holding entities will have a desire to attack Free Software. It is therefore less likely that a user of the language will be sued; a patent troll would have to do some work to acquire the relevant patent. If that unlikely event does anyway occur, the fact that the patent was not specifically designed to read on the language implementation may indeed help, either by easing the process of “inventing around” or by making it more difficult for the patent troll to show the patent reads on the language implementation. Finally, if the implementation is under a license like GPL, or the Apache License (or any license with a patent grant), those companies that did contribute to the language implementation may have granted a patent license already.

Of course, these are all relative arguments against the alternative: a language designed by a single company. If a single corporate entity designed and implemented the language more recently than 20 years ago, that company likely filed many yet-unexpired patents throughout the process of designing and implementing the language and its infrastructure. When the Free Software community implements fresh versions of the language from scratch, it's very likely that it will generate software that reads on those patents. Thus, the community must live in constant and direct fear of that company. We must assume the patents exist, and we know who holds them, and we know they filed them with this very language in mind. It may be tough to invent around them and still keep the Free Software implementation compatible. This is why I and other Free Software advocates have insisted for years the all companies who claim to support software freedom should grant GPL-compatible patent licenses for all their patents. (I still await Sam Ramji's response on my call for Microsoft to do so.)

Without that explicit patent license, we certainly should prefer the community-driven and Free-Software-developed languages over those developed by companies (like Microsoft) that have a history of anti-Free Software practices. Regarding companies with a more ambiguous history toward Free Software, some might argue that patents consolidated in a “friendly” company is safest of all alternatives. They might argue that with all those patents consolidated, patent trolls will have a tough time acquiring patents and attacking FaiF implementations. However, while this can sometimes be temporarily true, one cannot rely on this safety. Java, for example, is in a precarious situation now. Oracle is not a friend to Free Software, and soon will hold all Sun's Java patents — a looming threat to FaiF Java implementations. While I think it's more likely that Microsoft will attack FaiF C# implementations with its patents eventually, an Oracle attack on FaiF Java is a possibility. (We should also not forget that Sun in the late 1990s was very opposed to Free Software implementations of Java; the corporate winds always change and we should not throw ourselves to them.)

The last case in my list deserves at least a brief mention. Languages like C (which was a purely AT&T endeavor initially) have reached the age that the early patents would have now expired, and such languages have slowly moved into community and standards-driven control. Thus, over long periods of time, history shows us that companies do loosen their iron grip of proprietary control of language implementations. However, during that first 20 year period, we should face them with great trepidation and stick with languages developed by the Free Software community itself.

Finally, I close with the advice that I and my colleagues at SFLC constantly give Free Software projects: don't be paralyzed with fear over software patents. There are likely some USA patents that read on any software you write. Make good choices (like avoiding C#, as RMS suggests, and favoring languages like Perl, Python, PHP and C), and get on with your work. If, as a non-profit Free Software developer, someone writes you a threatening letter about patents or sues you for patent infringement, write to <help@softwarefreedom.org>; that's what SFLC is there for.

Posted by Bradley M. Kuhn on June 29, 2009

Tags: licensing, patents, community

May 12, 2009 by Bradley M. Kuhn

Support Your Friendly Neighborhood FLOSS Charities

I don't think we talk enough in the FLOSS community about the importance of individual support of FLOSS-related charitable organizations. On a recent Software Freedom Law Show episode, Karen and I discuss with Stormy Peters how important it is for geeks — who may well often give lots of code to many FLOSS projects — also should consider giving a little bit of financial funding to FLOSS organizations as well.

Of course, it's essential that people give their time to the charities and the causes that they care about. In the FLOSS world, we typically do that by giving code or documentation to our favorite FLOSS project. I think that's led us all into the classic “I gave at the office” feeling. Indeed, I know that I too have fallen into this rut at times myself.

I suppose I could easily claim that, more than most people, I've given enough at the office. Working at various non-profit organizations since the 1990s, I've always made substantially less in salary than I would in the for-profit industry for similar work. I also have always volunteered my time in addition to my weekly work schedule. For example, I currently get paid for my 40 hour/week job at the SFLC, but I also donate about 20 hours of work for the Software Freedom Conservancy each week.

Still, I don't believe that this is enough. There are many, many FLOSS non-profits that deserve support — more than I have time to give. Meanwhile, very small amounts of money, aggregated over many people giving, makes a world of difference in a number of ways to these organizations.

Non-profits that are funded by a broad base of supporters are much more stable and have greater longevity than other types of non-profits that are funded primarily by corporate donations. This is because one donor or even a few disappearing is not disaster. Also, through these donations, organizations build a constituency of supporters that truly represent the people that the non-profit seeks to serve.

Traditionally (with a few notable exceptions), non-profits in the FLOSS world have relied primarily on corporate donations. I generally think this is not ideal for a community that wishes to be fully represented by the non-profits that embody the projects we care about. We want these projects to represent the interest of developers and users, not necessarily the for-profit corporate interests. Plus, we want the organizations to survive even when companies stop supporting FLOSS or just simply go out of business.

If we all contribute, it doesn't take that much for each individual to be a part of making a real difference. I believe that if each person who has benefited seriously from FLOSS gave $200/year, we'd make a substantial change and a wonderful positive impact on the non-profit organizations that shepherd and keep these FLOSS projects alive. I'm not suggesting giving to any specific organization: just to take $200/year and divide in the way you think is best across 2-4 different FLOSS non-profits that sponsor project you personally care about or benefit from.

Think about it: $200/year breaks down to $16/month. For me (and likely for most people in a major city), $16/month means one fewer dinner at a restaurant each month. Can't we all eat at home one more time per month, and share that savings to help FLOSS non-profits?

If you are looking for a list of non-profits that could use your support, the FLOSS Foundations Directory is a good place to start. FWIW, in addition to my volunteer work with Conservancy, here's the list of non-profits that I'm supporting with a total of $200 this year (in alphabetical order): The Free Software Foundation, GNOME Foundation, The Parrot Foundation, and The Twisted Project. Which ones will you give to this year?

Posted by Bradley M. Kuhn on May 12, 2009

Tags: community, non-profits

April 28, 2009 by Bradley M. Kuhn

If We Can't End Software Patents Tomorrow, What Should We Do In the Meantime?

As we've talked about in our recent podcasts, and as I mentioned in various blog posts, software patents (i.e., patents that read on software) are a major threat to software freedom. Due to this constant threat, the primary goal of the Software Freedom community must be an end to all software patents worldwide. “Patent reform” will never be enough. The hard part, though, given that abolishing the software patent system is such a long and tough war, is what to do in the meantime about software patents that stand in the way of immediate advancement of software freedom.

We've all known for some time that Microsoft will pressure (and sometimes convince) companies to give in to Microsoft's patent aggression. They know that a software patent pool can be used both as a tool to attack FLOSS, and as a revenue stream by engaging in trolling behavior. It is, effectively, their last ditch effort to kill FLOSS.

If we had the necessary political power and resources, we'd be able to end software patents soon, so that all software patents would be nullified. There are people working on this, and we should put the primary resources available behind efforts to end software patents. That's unlikely to happen soon, and meanwhile we've already seen Microsoft acting as a patent troll against FLOSS redistributors. So, the question is, what can we do in the meantime, specifically about patents that have been actively asserted?

While we cannot make the strategic move of ending software patents quickly, we must turn to tactical plans. The tactical move, then, is to disable the weapons we see actively used against FLOSS redistributors. The weapons, in this case, are individual patents that anyone holds that are actively enforced against a FLOSS redistributor.

To that end, the Post Issue Peer To Patent project has begun requesting prior art on the patents, such as the FAT filesystem ones, that have been used to attack FLOSS. If you go to their website, you can follow the links to a form that allows you to submit things you've seen in the world that could be used as prior art to reexam and perhaps destroy those patents.

It's worthwhile for folks who are privy to some information that might be prior art to submit there. This won't push forward our ultimate goal of ending software patents, but it might create an opportunity to disarm a few of the active weapons used to hurt FLOSS. The problem remains that there are thousands of these weapons out there — some of which will surely be like the RSA patent and resilient to any reexam or other such destruction attempt. Thus, we shouldn't let this tactical goal distract us from the strategic one of ending software patents.

Finally, I can't let an opportunity go by without again mentioning, as I always do, the easiest thing that developers can do that will ultimately have the greatest impact on stopping software patents. Relicense your software under AGPLv3, GPLv3, LGPLv3, or some other GPLv3-based software license. GPLv3 and its derivatives have the strongest patent protections available in any FLOSS license. As a FLOSS developer, it's unlikely you've got at your fingertips some usable prior art for some existing patent, or have political power to change the USPTO. However, you have the power to pick the license of your software, so pick the one that defends against patents best.

Posted by Bradley M. Kuhn on April 28, 2009

Tags: gpl, licensing, microsoft, patents

April 24, 2009 by Bradley M. Kuhn

Fork Well: It Could Be The Last, Best Hope for Community

I have faced with much trepidation the news of Oracle's looming purchase of Sun. Oracle has never shown any interest in community development, particularly in the database area. They are the largest proprietary database vendor on the planet, and they probably have very simple plans for MySQL: kill it.

That's why I read with relief this post by Monty (co-founder of the MySQL project) this week, wherein Monty plans (and encourages others, too) to put their full force behind a MySQL “fork” that will be centered outside of Oracle.

Monty is undoubtedly correct when he says I don't think that anyone can own an open source project; the projects are defined by the de-facto project leaders and the developers that are working on the project. and that [w]ith Oracle now owning MySQL, I think that the need for an independent true Open Source entity for MySQL is even bigger than ever before.

I don't find the root of this problem in that one company has sold itself to another, pursuant to the the greater glory of the Ferengi Rules of Acquisition. Instead, I think the error is that projects inside Sun did not have a non-profit entity to shepherd them. When a single for-profit company is in control of a project's copyrights, its trademarks, and employs nearly all its core developers, there is a gross imbalance. The community around the project isn't healthy, and can easily be disrupted by the winds of corporate change, which blow in service of the only goal of for-profit existence: higher profits.

I encourage Monty, as well as core developers of VirtualBox, OpenOffice, OpenSolaris, Sun's Java, and any other project that is currently under the full control of Sun (or indeed any other for-profit corporation) to think about this idea. Non-profits, particularly 501(c)(3)'s, are fundamentally different than for-profits. They exist to serve a community or a constituency and the public good, never profit. Therefore, the health of the codebase, the diversity of the developer and user community, and the advancement of software freedom can be the clear mission of a non-profit that houses a FLOSS project. A non-profit ensures that while corporate funding comes and goes, the mission of the project and its institutional embodiment stay stable. For example, just like shareholders have a duty to fire a CEO when he fails to make enough profit (i.e., the for-profit company is not reaching its maximal goal), boards of directors and/or memberships of non-profits must fire the President and/or Executive Director when they fail to serve the community well. Instead of the “profit motive”, 501(c)(3)'s have the “community motive”.

Yet, the challenge of focusing on such goals remains difficult for projects that did not spawn from a community to start. GNU and Linux were both started by individual developers that built strong communities before there was any for-profit corporate interest in the software. When a project started inside a company with profit in mind, shoehorning community principles into the project can rarely succeed. I believe that a community must usually evolve from the ashes of some incident that wakes everyone up to realize the project will come to harm due to strict adherence to the profit motive.

I should probably remind everyone that I'm not opposed to capitalism per se. Indeed, I've often fought on the other side of this equation when licenses (such as MySQL's own very early pre-GPL license) permit noncommercial use but prohibit commercial use. I believe that commercial and non-commercial activity with the code should be equally permitted in a non-discriminatory way. However, the center of gravity for developers, where the copyrights and trademarks live, and how core work on the codebase is funded are all orthogonal questions to the question of the software's license.

My experience has anecdotally taught me that FLOSS communities function best when the following two things are true: (a) the codebase is held neutrally, either in the hands of the individual developers who wrote the code, or in a 501(c)(3) non-profit, and (b) not too many core developers share the same employer. I believe that reaching that state should be Job One of any for-profit seeking to build a FLOSS community. Sadly, this type of community health is often at direct odds with the traditional capitalist thinking of for-profit shareholders. I'm thus not surprised when FLOSS community managers in for-profit companies can only do so much. The rest is really up to the community of developers to fork and demand that a non-profit or other neutral and diverse developer-controlled management team exist. Attempts at this, sadly, fail much more often than they succeed.

Monty's post likely had more hope in it than this one. Monty didn't jump to my conclusion that Oracle will kill MySQL; Monty considers it also possible that Oracle might sell MySQL or (and here's the possibility I really doubt) that Oracle will change into a community-driven FLOSS company. I love Monty's optimism in even considering this possible. I honestly hope my pragmatism about this is shown to be sheer pessimism. In the meantime, focusing on the MySQL forks and pressuring Oracle to engage the FLOSS community in a genuine way is the best strategy no matter what outcome you think is most likely.

Update (on 17 May 2009): Monty announced an industry consortium that will seek to be a neutral space for MySQL development. I tend to prefer charitable non-profits to trade associations, but better the latter than hoping for Oracle to do the right thing.

Posted by Bradley M. Kuhn on April 24, 2009

Tags: copyright, licensing, community, non-profits

April 16, 2009 by Bradley M. Kuhn

TomTom/Microsoft: A Wake-Up Call for GPLv3 Migration

There has been a lot of press coverage about the Microsoft/TomTom settlement. Unfortunately, so far, I have seen no one speak directly about the dangers that this deal could pose to software freedom, and what our community should consider in its wake. Karen and I discussed some of these details on our podcast, but I thought it would be useful to have a blog post about this issue as well.

Most settlement agreements are sealed. This means that we won't ever actually know what TomTom agreed to and whether or not it violates GPLv2. The violation, if one exists, would likely be of GPLv2's § 7. The problem has always been that it's difficult to actually witness a v2§7 violation occurring (due in large part to less than perfect wording of that section). To find a violation v2§7, you have to discover that there were conditions imposed on [TomTom] ... that contradict the conditions of [GPLv2]. So, we won't actually know if this agreement violates GPLv2 unless we read the agreement itself, or if we observe some behavior by Microsoft or TomTom that shows that the agreement must be in violation.

To clarify the last statement, consider the hypothetical options. For TomTom to have agreed to something GPLv2-compliant with Microsoft, the agreement would have needed to either (a) not grant a patent license at all (perhaps, for example, Microsoft conceded in the sealed agreement that the patents aren't actually enforceable on the GPLv2'd components), or (b) give a patent license that was royalty-free and permitted all GPLv2-protected activities by all recipients of patent-practicing GPLv2'd code from TomTom, or downstream from TomTom.

It's certainly possible Microsoft either capitulated regarding the unenforceability (or irrelevancy) of its patents on the GPLv2'd software in question, or granted some sort of license. We won't know directly without seeing the agreement, or by observing a later action by Microsoft. If, for example, Microsoft later is observed enforcing the FAT patent against a Linux distributor, one might successfully argue that the user must have the right to practice those Microsoft patents in the GPLv2 code, because otherwise, how was TomTom able to distribute under GPLv2? (Note, BTW, that any redistributor of Linux could make themselves downstream from TomTom, since TomTom distributes source on their website.) If no such permission existed, TomTom would then be caught in a violation — at least in my (perhaps minority) reading of GPLv2.⁰

Many have argued that GPLv2 § 7 isn't worded well enough to verify this line of thinking. I and a few other key GPL thinkers disagree, mainly because this reading is clearly the intent of GPLv2 when you read the Preamble. But, there are multiple interpretations of GPLv2's wording on this issue, and, the wording was written before the drafters really knew exactly how patents would be used to hurt Free Software. We'll thus probably never really have complete certainty that such patent deals violate GPLv2.

This TomTom/Microsoft deal (and indeed, probably dozens of others like it whose existence is not public, because lawsuits aren't involved) almost surely plays into this interpretation ambiguity. Microsoft likely convinced TomTom that the deal is GPLv2-compliant, and that's why there are so many statements in the press opining about its likely GPLv2 compliance. I, Jeremy Allison, and others might be in the minority in our belief of the strength of GPLv2 § 7, but no one can disagree with the intent of the section, as stated in the Preamble. Microsoft is manipulating the interpretation disagreements to convince smaller companies like Novell, TomTom, and probably others into believing that these complicated patent licensing deals and/or covenants are GPLv2-compliant. Since most of them are about the kernel named Linux, and the Linux copyright holders are the only ones with power to enforce, Microsoft is winning on this front.

Fortunately, the GPLv3 clarifies this issue, and improves the situation. Therefore, this is a great moment in our community to reflect on the importance of GPLv3 migration. The drafters of GPLv3, responding to the Microsoft/Novell deal, considered carefully how to address these sorts of agreements. Specifically, we have these two paragraphs in GPLv3:

If, pursuant to or in connection with a single transaction or arrangement, you convey, or propagate by procuring conveyance of, a covered work, and grant a patent license to some of the parties receiving the covered work authorizing them to use, propagate, modify or convey a specific copy of the covered work, then the patent license you grant is automatically extended to all recipients of the covered work and works based on it.

A patent license is “discriminatory” if it does not include within the scope of its coverage, prohibits the exercise of, or is conditioned on the non-exercise of one or more of the rights that are specifically granted under this License. You may not convey a covered work if you are a party to an arrangement with a third party that is in the business of distributing software, under which you make payment to the third party based on the extent of your activity of conveying the work, and under which the third party grants, to any of the parties who would receive the covered work from you, a discriminatory patent license (a) in connection with copies of the covered work conveyed by you (or copies made from those copies), or (b) primarily for and in connection with specific products or compilations that contain the covered work, unless you entered into that arrangement, or that patent license was granted, prior to 28 March 2007.

Were Linux under GPLv3 (but not GPLv2), these terms, particularly those in the second paragraph, would clearly and unequivocally prohibit TomTom from entering into any arrangement with Microsoft that doesn't grant a license to any Microsoft patent that reads on Linux. Indeed, even what has been publicly said about this agreement seems to indicate strongly that this deal would violate GPLv3. While the Novell/Microsoft deal was grandfathered in (via the date above), this new agreement is not. Yet, the most frustrating aspect of the press coverage of this deal is that few have taken the opportunity to advocate for GPLv3 adoption by more projects. I hope now that we're a few weeks out from the coverage, project leaders will begin again to consider adding this additional patent protection for their users and redistributors.

Toward the goal of convincing GPLv2 users to switch to GPLv3, I should explain a bit why special patent licensing deals like this are bad for software freedom; it's not completely obvious. To do so, we can look specifically at what TomTom and Microsoft said in the press coverage of their deal: The agreement protects TomTom's customers under the patents …, the companies said (Microsoft, TomTom Settle Patent Dispute, Ina Fried).

Thus, according to Microsoft and TomTom, the agreement gives some sort of “patent protection” to TomTom customers, and presumably no one else. This means that if someone buys a GNU/Linux-based TomTom product, they have greater protection from Microsoft's patents than if they don't. It creates two unequal classes of users: those who pay TomTom and those who don't. The ones who don't pay TomTom will have to worry if they will be the next ones sued or attacked in some other way by Microsoft over patent infringement.

Creating haves and have-nots in the software licensing space is precisely what all versions of the GPL seek to prevent. This is why the Preamble of GPLv2 said: any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary.

Further to this point, in the Rationale Document for the Third Discussion Draft of GPLv3, a similar argument is given in more detail:

The basic harm that such an agreement can do is to make the free software subject to it effectively proprietary. This result occurs to the extent that users feel compelled, by the threat of the patent, to get their copies in this way. So far, the Microsoft/Novell deal does not seem to have had this result, or at least not very much: users do not seem to be choosing Novell for this reason. But we cannot take for granted that such threats will always fail to harm the community. We take the threat seriously, and we have decided to act to block such threats, and to reduce their potential to do harm. Such deals also offer patent holders a crack through which to split the community. Offering commercial users the chance to buy limited promises of patent safety in effect invites each of them to make a separate peace with patent aggressors, and abandon the rest of our community to its fate.

It's true that one can blissfully use, redistribute, sell and modify some patent-covered software for years without ever facing a patent enforcement action. But, particularly in situations where known patents have been asserted, those without a patent license often live in fear of copying, modifying and sharing code that exercises the teachings of the patent. We saw this throughout the 1990s with RSA, and today most commonly with audio and video codecs. Microsoft and other anti-Free Software companies have enough patents to attack if we let them. The first steps in stopping it are to (a) adopt GPLv3, LGPLv3 and AGPLv3 with the improved patent provisions, and (b) condemning GPLv2-only deals that solve a patent problem for some users but leave the rest out in the cold, and (c) pointing out that the purported certainty that such deals are GPLv2-compliant is definitely in question.

Patents always remain a serious threat, and, while the protection under GPLv2 has probably been underestimated, we cannot overestimate the additional protection that GPLv3 gives us in this regard. Microsoft clearly knows that the GPLv3 terms will kill their patent aggression business model, and have therefore focused their attacks on GPLv2-licensed code. Shouldn't we start to flank them by making less GPLv2 code available for these sorts of deals?

Finally, I would like to draw specific attention the fact that TomTom, as a company, is not necessarily an ally of software freedom. They are like most for-profit companies; they use FLOSS when it is convenient for them, and give back when the licenses obligate them to do so, or when it behooves them in some way. As a for-profit company, they made this deal to please their shareholders, not the Free Software community. Admittedly, their use of the FLOSS in their products was done legitimately (that is, once their GPLv2 non-compliance was corrected by Harald Welte in 2004). However, I do not think we should look upon TomTom as a particularly helpful member of the community. Indeed, most of the patents that Microsoft asserted against TomTom were on their proprietary components, not their FLOSS ones. Thus, most of this dispute was a proprietary software company arguing with another proprietary software company over patents that read on proprietary software. Our community should tell TomTom that if they want to join and support the FLOSS world, they should release their software under a FLOSS license — including software that they aren't obligated to do so by the licenses. Wouldn't it be quite interesting if TomTom's mapping display software were available under, say, GPLv3?

(Added later): Even if TomTom fails to release their mapping applications as Free Software, our minimal demand should be a license to their patents for use in Free Software. Recall that TomTom countersued Microsoft, also alleging patent infringement on TomTom's patents. TomTom has still yet to offer a public license on those patents for use by the Free Software community. If they are actually not hostile to software freedom, wouldn't they allow us to at least practice the teachings of their patents in GPL'd software?

---

⁰Update: Andrew Tridgell pointed out that my verb tenses in my hypothetical example made the text sound more broadly worded than I intended. I've thus corrected the text in the hypothetical example to be clearer. Thanks for the clarification, Tridge!

Posted by Bradley M. Kuhn on April 16, 2009

Tags: gpl, licensing, microsoft, patents

April 8, 2009 by Bradley M. Kuhn

Neary on Copyright Assignment: Some Thoughts

Dave Neary found me during breakfast at the Linux Collaboration Summit this morning and mentioned that he was being flamed for a blog post he made, Copyright assignment and other barriers to entry. Or, as some might title it in a Computer Science academic tradition: Copyright Assignment Considered Harmful. I took a look at Dave's post, and I definitely think it's worth reading and considering, regardless of whether you agree with it or flame it. For my part, I think I agree with most of his points.

One of the distinctions that Dave is making that some might miss is the difference between non-profit, community-controlled copyright assignment assignees and for-profit copyright assignees. He quotes Luis Villa to make the point that companies, ultimately, aren't the best destinations as a final home of FLOSS copyrights. If copyright assignment is looked only through the lens of a for-profit corporate entity — with only the duty to its shareholders to determine its future — then indeed it's a dangerous situation for many of the reasons that Dave raises.

I believe strongly that assigning copyright to a for-profit corporate entity is usually problematic. As Dave points out, corporations aren't really community members proper of a Free Software community; rather, their employees typically are. I have always felt that either copyrights should be assigned to a transparently-run non-profit 501(c)(3) entity, or they should be held by individual contributors. Indeed, the Samba project even has a policy to accept absolutely no corporate copyrights in their codebase, and I would love to see more projects adopt that policy.

I trust 501(c)(3) non-profits more than for-profits not only because I've spent most of my career in the former, and have enjoyed that time more than my time at the latter. I trust non-profits more because their charters and founding documents require a duty to a public-benefiting mission and to a community. They are failing to act properly under their charters if they put the needs of a for-profit entity ahead of the needs of the community and the public. This is exactly the correct alignment of incentives for a consolidation of FLOSS copyrights.

Some projects don't like centralized copyright for various reasons. While I do prefer it myself, I can understand this desire among individuals to each keep their stake of control in the project. Thus, I don't object to projects that want each individual contributor to have their own copyright. In this situation, the incentives are still properly aligned, because individuals who helped make the project happen have the legal control. While these individuals have no required commitment to the public good like a non-profit, they are members of a community and are much more likely to put the community needs above the profit motive that controls all for-profit entities.

When Dave says copyright assignment might be harmful, he seems to talk primarily about for-profit corporate assignment. I agree with him on that point. however, when he mentions that it's unnecessary, I don't completely agree, but he raises well the points that I would raise as to why it's important.

However, in the middle of Dave's post is the bigger concern that deserves special mention. The important task is keeping a clear record of the copyright provenance about where the work came from, and who might have a copyright claim. Copyright assignment is a short-hand way to do this in an organized and clear fashion. It's a simple solution with some overhead, and sometimes projects over the years have been annoyed with (and even ridiculed) that overhead. However, the more complex solutions have overhead, too. If you don't do assignment, you must keep careful track of every contributor, what their employer agreements say, and whether they have the right to submit patches under their own copyrights to the project. Some projects do this better than others.

Regardless, all of this is hard work. For years, I've seen it as a personal task of mine to help develop systems and recommendations that help make either process (assignment or good copyright record-keeping) less burdensome. I haven't worked on this task as much as I should have, but I have not forgotten that it needs attention. I envision integrated hooks and systems with revision control systems that help with this. I think we eventually need something that makes it trivial for hackers to implement and easy to maintain. I understand that the last thing any Free Software hacker wants to do is sit and contemplate the legal implications of contributions they've received. As such, all of us who follow this issue hope to make it easier for projects to do the work. In the meantime, I think discussion about this is good, and I'm thankful for Dave to raising the issue again.

Posted by Bradley M. Kuhn on April 8, 2009

Tags: copyright, licensing

March 17, 2009 by Bradley M. Kuhn

Scale 7x Keynote Redux

Many people have been commenting on and/or asking about my keynote, When Software Is A Services, Is Only the “Network Luddite” Free? from Scale 7x in late February. There is finally a downloadable H264/MPEG-4 AAC version (114MB) available. There is also an audio recording of the same speech available from SCALE's website. Finally, please note that the keynote is substantially similar to my Plone Conference Keynote, which we released as a podcast.

I'm working with the SCALE 7x organizers to see if I can get the video and audio of the keynote in a freer format. However, since the mp4 file linked above does play in vlc, I figured it's worth getting it out to folks who are looking for it now.

There was also an article in Ars Technica that covered my keynote.

Posted by Bradley M. Kuhn on March 17, 2009

Tags: agplv3, netservices

January 27, 2009 by Bradley M. Kuhn

Welcome (Finally!) to the GCC Runtime Library Exception

For the past sixteen months, we've had a bit of a “mini-GPLv3 process” among folks at the FSF, SFLC, the GNU Compiler Collection Steering Committee (GCC SC), and the GCC community at large. We've been drafting an important GPLv3 license exception (based on a concept by David Edelsohn and Eben Moglen, that they invented even before the GPLv3 process itself started). Today, that GCC Runtime Library Exception for GPLv3 went into production.

I keep incessant track of my hours spent on various projects, so I have hard numbers that show I personally spent 188 hours — a full month of 40-hour weeks — on this project. I'm sure my colleagues have spent similar amounts, too. I am proud of this time, and I think it was absolutely worthwhile. I hope the discussion gives you a flavor of why FLOSS license exception drafting is both incredibly important and difficult to get right without the greatest of care and attention to detail.

Why GPL Exceptions Exist

Before I jump into discussion of this GCC Runtime Library exception, some background is needed. Exceptions have been a mainstay of copyleft licensing since the inception of the GNU project, and once you've seen many examples over many years, they become a standard part of FLOSS licensing. However, for the casual FLOSS developer who doesn't wish to be a licensing wonk (down this path lies madness, my friends, run screaming with your head covered!), exceptions are a rare discovery in a random source file or two, and they do not command great attention. An understandable reaction, but from a policy perspective, they are an essential part of the copyleft system.

From the earliest days of the copyleft, it was understood that copyleft was a merely a strategy to reach the goal of software freedom. The GPL is a tool that implements this strategy, but like any tool, it doesn't fit every job.

In some sense, the LGPL was the earliest and certainly the most widely known “GPL exception”. (Indeed, my friend Richard Fontana came up with the idea to literally make LGPL an exception to GPLv3, although in the v2 world, LGPLv2 was a fully separate license from GPLv2.) Discussions on why the LGPL exists are beyond the scope of this blog post (although I've written about them before). Generally speaking, though, LGPL is designed to be a tool when you don't want the full force of copyleft for all derivative works. Namely, you want to permit the creation of some proprietary (or partly proprietary) derivative works because allowing those derivations makes strategic sense in pursuing the goal of software freedom.

Aside from the LGPL, the most common GPL exceptions are usually what we generally categorize as “linking exceptions”. They allow the modifier to take some GPL'd object code and combine it in some way with some proprietary code during the compilation process. The simplest of these exceptions is found when you, for example, write a GPL'd program in a language with only a proprietary implementation, (e.g., VisualBasic) and you want to allow the code to combine with the VisualBasic runtime libraries. You use your exclusive right as copyright holder on the new program to grant downstream users, redistributors and modifiers the right combine with those proprietary libraries without having those libraries subject to copyleft.

In essence, copyleft exceptions are the scalpels of copyleft. They allow you to create very carefully constructed carve-outs of permission when pure copyleft is too blunt an instrument to advance the goal of software freedom. Many software freedom policy questions require this fine cutting work to reach the right outcome.

The GCC Exception

The GCC Exception (well, exceptions, really) have always been a particularly interesting and complex use of a copyleft exception. Initially, they were pragmatically needed to handle a technological reality about compilers that interacts in a strange way with copyright derivative works doctrine. Specifically, when you compile a program with gcc, parts of GCC itself, called the runtime library (and before that, crt0), are combined directly with your program in the output binary. The binary, therefore, is both a derivative work of your source code and a derivative work of the runtime library. If GCC were pure GPL, every binary compiled with GCC would need to be licensed under the terms of GPL.

Of course, when RMS was writing the first GCC, he realized immediately this licensing implication and created an exception to avoid this. Versions of that exception has been around and improved since the late 1980s. The task that our team faced in late 2007 was to update that exception, both to adapt it to the excellent new GPLv3 exceptions infrastructure (as Fontana did for LGPLv3), and to handle a new policy question that has been kicking around the GCC world since 2002.

The Plugin Concern

For years, compiler experimentalists and researchers have been frustrated by GCC. It's very difficult to add a new optimization to GCC because you need quite a deep understanding of the codebase to implement one. Indeed I tried myself, as a graduate student in programming languages in the mid-1990s, to learn enough about GCC to do this, but gave up when a few days of study got me nowhere. Advancement of compiler technology can only happen when optimization experimentation can happen easily.

To make it easy to try new optimizations out, GCC needs a plugin architecture. However, the GCC community has resisted this because of the software freedom implications of such an architecture: if plugins are easy to write, then it will be easy to write out to disk a version of GCC's internal program representation (sometimes called the intermediate representation, or IR). Then, proprietary programs could be used to analyze and optimize this IR, and a plugin could be used to read the file back into GCC.

From a licensing perspective, such an optimizing proprietary program will usually not be a derivative work of GCC; it merely reads and writes some file format. It's analogous to OpenOffice reading and writing Microsoft Word files, which doesn't make it a derivative of Word by any means! The only parts that are covered by GPL are the actual plugins to GCC to read and write the format, just as OpenOffice's Word reader and writer are Free Software, but Microsoft Word is not.

This licensing implication is a disaster for the GCC community. It would mean the advent of “compilation processes” that were “mixed”, FaiF and proprietary. The best, most difficult and most interesting parts of that compilation process — the optimizations — could be fully proprietary!

This outcome is unacceptable from a software freedom policy perspective, but difficult to handle in licensing. Eben Moglen, David Edelsohn, and a few others, however, came up with an innovative idea: since all binaries are derivative of GCC anyway, set up the exception so that proprietary binary output from GCC is permitted only when the entire compilation process involves Free Software. In other words, you can do these proprietary optimization plugins all you want, but if you do, you'll not be able to compile anything but GPL'd software with them!

The Drafting and the Outcome

As every developer knows, the path from “innovative idea” to “working implementation” is a long road. It's just as true with licensing policy as it is with code. Those 188 hours that I've spent, along with even more hours spent by a cast of dozens, have been spent making a license exception that implements that idea accurately without messing up the GCC community or its licensing structure.

With jubilation today, I link to SFLC's announcement, the announcement from the FSF, the FAQ and Rationale for the exception and the final text of the exception itself. This sixteen-month long cooperation between the FSF, the SFLC, the GCC SC, and the GCC community has produced some fine licensing policy that will serve our community well for years to come. I am honored to have been a part of it, and a bit relieved that it is complete.

Posted by Bradley M. Kuhn on January 27, 2009

Tags: gpl, copyright, licensing, gnu, exceptions

January 15, 2009 by Bradley M. Kuhn

Launchpad's License Will Be AGPLv3

Last week, I asked Karl Fogel, Canonical's newly hired Launchpad Ombudsman, if Launchpad will use the AGPLv3. His eyes said “yes” but his words were something like: Canonical hasn't announced the license choice yet. I was excited to learn this morning from him that Launchpad's license will be AGPLv3.

This is exciting news. Launchpad is precisely the type of application that we designed the AGPLv3 for, and Launchpad is rapidly becoming a standard in the next generation of Free Software project hosting. Over the last year, I've felt much trepidation that Launchpad would be “another SourceForge”: that great irony of a proprietary platform becoming the canonical method for Free Software project hosting. It seems now the canonical and the Canonical method for hosting will be Launchpad, and it will respect the freedom of network users of the service.

Given that they'd already announced plans to liberate Launchpad, it's not really surprising that Canonical has selected the AGPLv3. I would guess their primary worry about releasing the source was ensuring that competitors don't sprout up and fail to share their improvements back with the community of users. AGPLv3 is specifically designed for this situation.

I'm glad we've made a license that is getting adoption by top-tier Free Software projects like this one. Critics keep saying that AGPLv3 is a marginal license of limited interest. I hope this license choice by Canonical will show them again that they continue to be mistaken.

Thanks to Karl, Matthew Revell, Mark Shuttleworth himself, and all the others at Canonical who are helping make this happen.

Posted by Bradley M. Kuhn on January 15, 2009

Tags: agplv3, ubuntu, licensing, launchpad

January 14, 2009 by Bradley M. Kuhn

LGPL'ing of Qt Will Encourage More Software Freedom

The decision between the GPL or LGPL for a library is a complex one, particularly when that library solves a new problem or an old problem in a new way. TrollTech faced this decision for the Qt library, and Nokia (who acquired Trolltech last year) has now reconsidered the question and come to a different conclusion. Having followed this situation since even before Qt was GPL'd, I was glad that we have successfully encouraged the reconsideration of this decision.

Years ago, RMS wrote what many consider the definitive essay on this subject, entitled Why you shouldn't use the Lesser GPL for your next library. A few times a year, I find myself rereading that essay because I believe it puts forward some good points to think about when making this decision.

Nevertheless, there is a strong case for the LGPL in many situations. Sometimes, pure copyleft negatively impacts the goal of maximal software freedom. The canonical example, of course, is the GNU C Library (which was probably the first program ever LGPL'd).

Glibc was LGPL'd, in part, because it was unlikely at the time that anyone would adopt a fully FaiF (Free as in Freedom) operating system that didn't allow any proprietary applications. Almost every program on a Unix-like system combines with the C library, and if it were GPL'd, all applications would be covered by the GPL. Users of the system would have freedom, but encouraging the switch would be painful because they'd have to give up all proprietary software all at once.

The GNU authors knew that there would be proprietary software for quite some time, as our community slowly replaced each application with freedom-respecting implementations. In the meantime, better that proprietary software users have a FaiF C library and a FaiF operating system to use (even with proprietary applications) while work continued.

We now face a similar situation in the mobile device space. Most mobile devices used today are locked down, top to bottom. It makes sense to implement the approach we know works from our two decades of experience — liberate the operating system first and the applications will slowly follow.

This argument informs the decision about Qt's licensing. Qt and its derivatives are widely used as graphics toolkits in mobile devices. Until now, Qt was licensed under GPL (and before that various semi-Free licenses). Not only did the GPL create a “best is the enemy of the good” situation, but those companies that rejected the GPL could simply license a proprietary copy from TrollTech, which further ghettoized the GPL'd versions. All that is now changing.

Beyond encouraging FaiF mobile operating systems, this change to LGPL yields an important side benefit. While the proprietary relicensing business is a common and legitimate business model to fund further development, it also has some negative social side effects. The codebase often lives in a silo, discouraging contributions from those who don't receive funding from the company who controls the canonical upstream.

A change to LGPL sends a loud and clear message — the proprietary relicensing business for Qt is over. Developers who have previously rejected Qt because it was not community-developed might want to reconsider that position in light of this news. We don't know yet how the new Qt community will be structured, but it's now clear that Nokia, Qt's new copyright holder, no longer has a vested interest in proprietary relicensing. The opportunity for a true software freedom community around Qt's code base has maximum potential at this moment. A GUI programmer I am not; but I hope those who are will take a look and see how to create the software freedom development community that Qt needs.

Posted by Bradley M. Kuhn on January 14, 2009

Tags: gpl, licensing, lgpl, qt