The vast majority of free and open source (FOSS) projects today operate on a license in/license out basis. In other words, each contributor to a code base continues to own her code while committing to provide a license to anyone that wants to download that code. Of course, no developer ever actually signs a downstream license. Instead, all contributors to a given project agree on the OSI (Open Source Initiative) approved license they want to use, and those terms stand as an open promise to all downstream users. But is that really the best way to operate? What about the minority of projects that require contributors to assign ownership of their code to the project? They clearly think assignment is a better way to go. Are they right?

Sometimes, the answer to that question is easy. If a project isn’t controlled by a legal entity, there’s no one to assign code to. Numerically speaking, that’s the case for more than ninety-nine percent of the tens of millions of libraries hosted by GitHub and other forges. Forges are happy to host code, but not take ownership of it.

But the percentage flips when you look at the most important FOSS products in use today. The vast majority of those programs are supported by either umbrella organizations, like the Apache, Eclipse and Linux Foundations, or by foundations formed just to host a single project. Most of those organizations do not require code assignment. Why not?

Before we turn to that question, let’s review the benefits and disadvantages of each approach.
The main benefit of licensing, as compared to assignment, is that the developer retains unrestricted rights to their code.

The disadvantages are that no one can speak for the entire code base. If, for example, a new version of a project  license came along, it could be difficult for the project to upgrade to that license, particularly if it was no longer able to get in contact with contributors that were no longer active. There would also be no single owner that could bring an action against those violating the terms of the outbound license (largely a concern where a “copyleft” license is involved). That’s because under the laws of countries like the United States, only the owner or the exclusive licensee of a copyrighted work can bring an action against an infringer – like a commercial company that’s using copyleft software in its products without contributing its own innovations back.

At the same time, the market can be abused by contributors that want to exploit their position as contributors in order to extort damages from inadvertent infringers. While, happily, this has been extremely rare, there is at least one developer, Patrick McHardy, who has been making a business out of suing Linux users, despite the fact that his own contributions to the Linux kernel were estimated two years ago to be less than .25% of the total (that percentage is even lower today). If ownership was in one place, the community of developers could decide among themselves what they deemed, collectively, to be most appropriate.

When viewing this comparison, it’s worth noting that the reserved rights of a contributor under the licensing model really don’t add up to much other than the right to sue directly, something most developers would never have the inclination or budget to do, anyway. Code that has been assigned and then made available under a non-copyleft license is still available to be used by the original author for any purpose and to the same extent as if the original author still owned it. And if a developer contributes to a copyleft-license project, she has already opted into the concept that using her code comes with obligations. Finally, a project that owns code can be forked as easily as one where only license rights have been provided. So, what of value has the developer gained by retaining ownership?

Stated another way, if a developer is no better or worse off assigning ownership than licensing it, why don’t more projects operate on that basis today?

The answer is largely historical. But having said that, it’s interesting to note that the first free software project ever launched as such – Richard Stallman’s GNU Project – in fact requires the assignment of code. And no one is a greater champion of developer rights than Stallman. Why didn’t later projects just follow the same path?

There are multiple reasons. The first is that some of the first FOSS licenses didn’t have this issue. The BSD license, for example, was created to license the Berkeley Software Distribution (BSD) of UNIX, which was owned outright by the Regents of the University of California. That license became popular, and individual developers began using it as well, both individually and collectively without focusing on the differences between sole and collective ownership.

Another is that assignment got off to a bad start in the early days of FOSS when important projects supported by corporations generally required assignment. The community of developers did not always believe these proprietary vendors were acting in the best interests of developers. Even where relations were initially good, ownership of those projects sometimes changed hands due to the volatility of the software industry. This happened, for example, when Sun Microsystems was acquired by Oracle, which had less interest in many projects Sun had actively supported.

Importantly, these companies also owned the trademark in the software, meaning that, although the code owned by the proprietary companies could still be forked, the fork would have to be distributed under a new name, meaning that the project fork would need to figure out how to spread the word to users everywhere that an alternative code base was now available. In other words, from a practical standpoint, the problem was much less about who owned the code than who controlled the trademark.

Regardless, the result was that code assignment got a bad name, and developers became more interested in working on projects where their ownership rights could be preserved.

What was lost along the way was the fact that assigning code to a non-profit company that doesn’t commercialize the code can provide the best of both worlds. Such organizations can provide long-term stability and economic support for a project, as well as a platform for whatever type of governance a given community wishes to put in place. Many such organizations now exist, both stand-alone (e.g., OpenStack) and umbrella (Apache, Eclipse and The Linux foundation, among others). True, many of these foundations have boards of directors where most seats are held by representatives of proprietary companies. But the technical process is usually entirely independent. Many stand-alone projects are completely controlled by developers.

Most significantly, communities of developers today readily agree that it is appropriate for such organizations to own the trademarks for the code the developers still own. Given that trademarks are much more important than copyright ownership (code can be forked; trademarks cannot), why not allow such organizations to own the code as well?

It’s an interesting question, and one I think deserves a fresh look. Certainly, there’s a lot to be said for centralizing the legal policing of community code rather than allowing every owner to make up her own mind who should and who should not be approached, and how heavy handed to be when doing so. Putting that power in the hands of the project rather than individual developers would make it far easier for a project to make it clear what types of commercial behavior will and will not be acceptable, and what consequences will follow from violating the rules.

Centralizing ownership would also help shield developers from liability for inadvertent infringement of patents owned by third parties (and particularly non-contributors).  Once copyright ownership of the code has changed hands, the project, rather than the individuals that originally created the code, would more likely be held liable for inducing others to infringe a third party’s patent.

My guess is that if we were to start with a fresh sheet of paper and have an open discussion about which approach is preferable, many developers would decide that collective ownership of code via a non-profit entity with a governance structure acceptable to the community would provide a more rational, efficient and preferable way to run a FOSS project.