Could Open Source Software Be Put Into The Public Domain Instead?

from the need-to-fix-public-domain-first dept

There are dozens of free software and open source licences -- many would argue rather too many. Different licenses impose different conditions. For example, the best-known and most widely-used is the GNU General Public License, which is designed to ensure that anyone building on GPL'd software and distributing it should make the modified program available under the same license. Others, such as the BSD license simply require the copyright and license notices to be included with any code that is used.
Open source licenses are often described as the "constitutions" for the communities that form around the software they govern. That would seem to imply that in their absence, alongside other unwanted consequences, the communities would collapse. A provocative paper by Clark Asay, Assistant Professor at Penn State University Dickinson School of Law, suggests that this isn't the case, and that software could be released into the public domain and yet still thrive as a collaborative project.
He points out that despite its undeniable success -- free software now dominates many of the most important sectors in computing -- there are transaction costs associated with it. For companies, these arise from ensuring full compliance with licenses, no mean task if corporate lawyers are unfamiliar with the subtleties of this world. For programmers who are choosing a free software license for their code, not only is there a bewildering choice, but some of them are mutually incompatible. This means that code from one project can't always be dropped into another using a different licence, which makes building on open source harder than it should be.
Asay suggests that placing software into the public domain would avoid all these issues, and allow the code to be re-used more widely, with resulting benefits for coders, companies and users alike. However, he recognizes that there are some important concerns that need addressing.
For example, one of the strengths of licenses like the GNU GPL is that it prevents free riding: if a company takes GPL'd software and uses it in a product that it distributes, it must adopt the GNU GPL and contribute its code back to the original code's community. If the code were in the public domain, that wouldn't be the case -- it could simply be taken and used without further ado. But Asay notes that there are good reasons why companies are likely to make their code available anyway:

if a firm were to take and close a project, they almost certainly would not obtain the free labor that contributors around the world are willing to provide to open-licensed projects. Without that free labor, firms would lose the most significant advantages of an open model of innovation, and the free labor would likely remain loyal to the open version of the project. Firms thus already have incentives to open and contribute as much of their materials as possible, since doing so will attract free labor and trigger innovation in directions that better suit the firm and its strategic direction.

The key point is that the code without the community that creates it is pretty much dead. A company may gain a short-term advantage in taking public domain code and enclosing it, but by refusing to give back its changes, it loses any chance of collaborating with the coders who are writing the future versions. It will have no influence, and no way of raising issues of particular concern that help it with its products. Instead, it will have to keep up the development of its own version of the code single-handed. That's likely to be costly at best, and may even be impossible except for the very largest companies (Apple is an example of one that has succeeded, basing its Mac OS X operating system on the free BSD version of Unix.) That also explains why coding communities will still function, even in the absence of "constitutions". Anyone who refuses to accept consensus decisions simply becomes isolated if they try to ignore them. Alternatively, if the community leadership starts to go astray, forks of the code may occur that gain sufficient supporters to become the main line of development. In other words, the natural collaborative development dynamics produce many of the same results as formal licenses that lay down what norms and behavior are expected.
Asay also tackles the important issue of attribution in a world of public domain software. Many programmers contribute to free software not for direct economic benefit, but to enhance their reputations, which may translate into financial benefits in the form of a higher salary or job offers. Asay points out that the current system of providing recognition is unsatisfactory -- often attribution is buried deep in licensing documents that no one ever looks at. That may explain in part why developer profiles on the popular GitHub code hosting service are becoming more common: it's a way of displaying programming prowess in a form that is easy for peers -- or potential employers -- to access. As the site itself explains:

Every developer gets their own profile page that is automatically updated with a stream of the important things they are doing on GitHub and a list of the Open Source projects they are hosting at GitHub. Many developers have started referring to GitHub Profiles as the new résumé.

The use of such pages makes the attribution requirements of software licenses less crucial, and would obviously work fine even if software were released into the public domain. One problem with Asay's idea is that the state of the public domain today is unsatisfactory. For example, it is very hard to place works in the public domain -- the Creative Commons CC0 is perhaps the most thoroughly worked-out tool for doing so. As Asay notes, we need legislation to formalize and facilitate this move, and to address issues such as liability.
This difficulty emphasizes how much the public domain has been neglected as copyright maximalists have sought to portray it as an anomalous wasteland that needs to be made "productive" by reclaiming it through copyright enclosure. But the public domain is the natural condition of all knowledge -- that which can be shared freely -- while it is copyright and its monopoly that is the deviation from that state. If nothing else, Asay's proposal may help to bring some much-needed attention to this important but neglected area.