The licensing practices of open source software developers have often centered around copyleft or permissive licenses that provide free public access to a project’s source code with only a few restrictions on how the code may be used. These licenses often require that any derivative work created from the source code must also be licensed under similar terms. Websites, GitHub being a prominent example, allow developers to post their code so that others can download the master code, make changes to it and push those changes back up to the master copy. Sites like these are described as “distributed reversion control repositories” (DRCRs). With advancements in DRCRs, some trends show that today’s open source developers do not take into account licensing considerations until well after a project has been created and made available to the public. Labeled the POSS (Post Open Source Software) approach in a 2012 tweet by James Governor of RedMonk, many open-source developers are now skipping past licensing and governance considerations regarding code, and simply posting their work to sites like GitHub. This trend may offer more risks than opportunities regarding the ability of the code to be adopted into the OS community, and may expose code developers to greater liability regarding non-disclaimer of warranties.
Git version management
Git is a software version management system that allows for version control across small and large scale programming projects. Created in 2005 by the founder of the Linux kernel, Linus Torvalds, Git provides a system by which any number of programmers may download a project’s source code creating their own “local branch”, make changes to the code, and “commit” or save those changes back to the “main branch” of the project. What’s unique about this branch-based model is that it lets numerous developers make changes to the code – often to the same file – while providing a system where changes to the code are captured systematically and programmers do not end up overwriting each other’s work. It achieves this by attaching unique identifiers to code changes, and requiring a resolution to any coding conflicts before changes can be merged back into the master branch. Coding conflicts can arise when a developer attempts to push changes in a file back to the master branch, except that the developer was not working with the latest copy of the master branch file. In such a case, the developer must “resolve the conflict” – i.e. get the latest copy of the master file and incorporate the changes, making sure the updated change works as expected with the latest copy of the master file.
GitHub
Founded in 2008, the privately-held San Francisco-based GitHub Inc. runs the website repository where users of the Git versioning system may store their code in adherence to the site’s terms of service. Projects on GitHub may be marked as public, allowing anyone with access to the internet to download a particular project’s source code and make modifications. Once changes are complete, the programmer may send the changes back to the main project branch, where the developer in charge of the project may choose to commit the changes back into the master branch.
Unique Approach
What is unique about GitHub and its approach is that it allows for an unprecedented level of cooperation without coordination. Anyone with an internet connection and Git installed on their computer can access, contribute and commit changes to a project. Projects on GitHub range from single-developer efforts, like the free shopping cart system Open Cart, to well-known open-source undertakings, like GNOME and Mozilla.
This approach differs from past approaches, which included only allowing one programmer to work on or “checkout” a particular file at a time, or dealing with the chaotic results that occur when multiple programmers work on, save and overwrite each other’s work.
How is FOSS licensed on GitHub?
A 2013 analysis of GitHub’s licensing practice by Ohloh revealed that many projects in the site’s repository are made available with little or no associated licensing terms. Upon examination, this makes sense. Slightly more than half (51%) of the projects on GitHub have only one developer committing code on project. As a result, the projects tend to be fairly small. In these instances, the project does not experience the expansive growth and activity that occurs in larger projects with 50 or more active developers who are all committing changes to the master branch. With the lack of outside activity and engagement, the lone developer is less concerned with locking down the code via licensing restrictions, than about developing the project and gaining public attention.
According to Ohloh’s 2013 analysis, it turns out that GitHub is well-suited to the lone developer and small project. As a hosting environment and repository, it provides a low barrier to entry for collaboration on a project. In fact, when projects grow and multiple developers are committing to the master branch, two changes seem to play out.
The first change that occurs is that the managing developer is forced to take into account licensing considerations for the project. This is often at the behest of contributors and corporate users and programmers who seek to use the project’s code in a legal and legitimate manner. At this point, GitHub projects tend to sway towards the minimalist MIT license. The MIT license is a permissive one, requiring that any changes or updates to a project’s code also be governed by the terms of that license as well. It is the most widely used license on GitHub, and requires (among other things) that the code be made freely available. It also requires that any subsequent code derived or created be made freely available under the same terms. (The question of what subsequent code is “derived or created” from the original open-source code is a topic for a separate blog post.)
The second change that occurs when a project grows considerably in size is that it moves from GitHub to a different hosting provider. This likely occurs because, while GitHub provides hosting service, it does not offer the level of service found through larger providers, like Amazon Web Services or Akamai’s cloud services. As it grows in size and scope, a project’s parameters and requirements may be better established and may necessitate a greater offering of hosting services. Later in the project, developers know what is required for the project to run smoothly, and often times those requirements necessitate abandoning GitHub.
What’s wrong with foregoing licensing consideration?
According to Silicon Valley attorney Mark Radcliffe, the problem with the POSS approach is that it may hamper the very goal of open-source projects, which is broad public adoption. Without an established licensing provision, corporations and government actors will be wary to include such code in their own offerings because they are sensitive of the fact that all of the code they use must be properly licensed. Without a clear and established license, these parties are more likely to simply remove the code instead of include it, which would open themselves to any uncertainties.
Another consideration Radcliffe cites is that the lack of licensing may also expose the project developer to liability under Article 2 of the Uniform Commercial Code (UCC), the codified standardized law adopted by most states to govern most commercial transactions. UCC Article 2 states that if certain warranties are not disclaimed, then the distributor or seller automatically gives those warranties. These lists of warranties are usually what is found in capital letters at the beginning of a license or terms of use statement disclaiming warranties of “merchantability” and “fitness for a particular use”. By failing to disclaim such warranties by failing to provide a license of some sort, POSS developers open themselves up to unnecessary liability. There is some doubt whether Article 2 of the UCC applies to software license, epecially those were there is no actual license entered into in the first place (as here). But it is this uncertainty that is the problem for prospective developers and end users. And this very uncertainty may torpedo a project’s adoption and use on a larger scale.
Conclusion
GitHub provides a valuable service that provides for an increased level of code collaboration in an environment that fosters open-source ideals. Whether or not POSS developers will understand the importance of licensing project code remains to be seen. Even within the GitHub environment, licensing a project’s code serves in some manner to not only protect developer’s interests and shield them from unnecessary liability, but also makes the code fit for use among corporate and state actors for whom clear licensing is a legal requirement. Such licensing considerations should be present at every stage of development, including when the project is first made available on GitHub.
Add Comment