Image from FreeCodeCamp
What exactly happens when you attach a license to your GitHub Repository?
GitHub readily provides the ability to add a number of licenses to a repository, but what are the legal implications of doing so? Read on to find more information about what happens when you choose to - or choose not to - attach a license to your project.
Image from FreeCodeCamp
Background information for those who aren't familiar.
Have you ever worked with a group on a project and dealt with the pains of letting everyone edit the same document at the same time? If you use a single file, like Microsoft Word Document, perhaps you've emailed the same document back and forth between each other, adding and editing each time. Or maybe you've used Google Drive or another service, where everyone can edit the same thing at a time. Regardless, the process is tedious and messy.
Programmers run into the same issues, but on a much grander scale. What if two programmers are trying to work on the same project at once? Working on the same code in one file at the same time would be disastrous. You can't wait until another programmer finishes to start working, because that's just wasting money. And emailing whole folders of interrelated files isn't reasonable. Git and GitHub are two utilities that address these issues for programmers.
Git is a command-line utility that tracks entire projects in what are called "repositories", which are - in layman's terms - the folder that your entire project is stored in. Git also tracks historical revisions to the repository, so if a major bug is found, an older version can be reverted to. GitHub is a service used to host git repositories. The two together allow for multiple programmers to work on a project at the same time from their own devices without interfering with one another. Git tracks the changes, history, and merging of anyone's interactions with the project. If two programmers make changes, Git will ensure that the newest version - stored and accessible to all on GitHub - has the changes from all users.
When a repository is created on Github, the user – in this case, usually a programmer – is provided with a selection of several open source licenses to attach to the project. In doing this, the standard in coding culture is that many user-programmers with little legal expertise simply follow through the over-simplified guide for choosing which license is “best” for a given project. However, all of the default licenses are open source, and an individual looking to profit off of his or her work may not be sure of what license to distribute their works under. Similar issues also arise regarding for-hire works hosted on Github where the developer is not in a position to make such a decision. What follows is a comparison of the licenses provided by GitHub and an analysis of the implications this has for programmers and their works.
Image from GCN
What sort of environment surrounds software development?
Lawrence Lessig writes about the open source movement and its roots in his 2004 piece on Free Culture. Lessig discusses how, historically, software tended to become restricted and how this initiated towards open source movements. He writes
"When computers with software were first made available commercially, the software—both the source code and the binaries—was free. You couldn’t run a program written for a Data General machine on an IBM machine, so Data General and IBM didn’t care much about controlling their software."In this environment, developers were able to alter software as necessary to meet their individual needs. Culture existed in this manner until technological innovation made it
"possible to import programs from one system to another, [at which point] it became economically attractive (at least in the view of some) to hide the code of your program."
In this new environment, software written for companies was - and oftentimes still is - usually regarded as a trade secret or otherwise protected due to its integral role in business operations. The open source software movement came about to combat this, and return to the way in which software was managed before. By creating a community that works collaboratively, the open source software movement seeks to develop software that, generally speaking, can be used for nearly any purpose. The open source software movement can be closely related to open access research. In a piece for the MIT Press, John Willinsky discusses how open access journalism has grown in recent years. Willinsky advocates for the benefits of open access, which he suggests is useful in its ability
"to extend an invitation and to acknowledge a right, for scholarship exists only as it is shared and circulated, only as it is open to new and diverging voices."The open source software movement, similarly, strives to ensure that software can be accessed and altered by these voices.
Dr. Brian D Ballentine of West Virginia University discusses copyright and open source software somewhat critically in his chapter in Composition & Copyright. In the piece, Ballentine discusses an incident where an accident related to alterations in software led to a surgery being performed on the wrong side of the patient's body. Ballentine uses this case to argue that
"the flagrant disregard and disrespect for the obfuscation techniques employed in the hospital software point towards a larger cultural, legal, and and ethical disconnect regarding copyrighted works in digital form."In this way, Ballentine suggests that the standard cultural practices occurring within the open source community, such as ignoring the decision to obfuscate software, stem from a culture built on altering software without regularly acknowledging ownership or fitness for a given purpose. Because members of the open source community often have full-time positions within corporate entities, where they might often encounter obfuscated software, Ballentine suggests that the standard remix culture that pervades the software industry serves detrimental towards private ownership.
My stance may not be as extreme as that of Ballentine, but his argument misses a crucial point: I feel that many in the software industry assume a right to alter anything without understanding what rights they do and do not have. This leads to a culture that ignores the legal status of software and the rights associated with it or its owner. While it is a larger effort to change the entire cultural practice, I designed this site to provide a simple idea of what licensure rights are provided to contributors by the licenses commonly used on GitHub, and hopefully take a step towards making sure more are aware of the implications of adhering to and violating these licenses.
Tweet from Diana Carrier
GitHub - being so central to programming - has a lot of influence through providing licenses. Who should be aware of what these licenses entail?
Diana Carrier, developer at Bold Commerce, jokes about programming, but all jokes have a hint of truth. Software and software developers have a significant impact in nearly every aspect of our day to day lives. News sites, GPS apps, online food ordering, and more are all created by software developers. Developers are people too, however, and they are influenced by their environment. Influence on programmers, then, can have a serious impact on nearly every aspect of society. It's important to be aware of and acknowledge the potential influences on programmers to ensure that nobody is "unleashing demons and destroying everything."
GitHub, being such a prominent tool for programmers, creates opportunity for many interested parties to impact the software development process as a whole. Programmers who manage projects through GitHub need to be aware of the potential legal implications of hosting code on GitHub. GitHub itself should be concerned with how their policies and actions reflect their intentions, as well as how others view GitHub. Microsoft, having purchased GitHub, must understand how owning and managing the foremost version control system is impacted by historical actions Microsoft has taken. In addition to these three larger entities, there are plenty of other groups that would be impacted by any changes to GitHub. Smaller corporations, universities, and other independents that use GitHub instead of hosting their own instance on a private server will always be impacted by changes to the platform. Because many of these agents can be considered users of GitHub, their concerns are most closely related to those of programmers regarding changes to GitHub or its licensure. The multifaceted userbase and potential impact on so many groups requires a deeper analysis of each involved party.
Programmers have one of the most significant roles in the use of GitHub as a platform. Designed to manage projects, GitHub needs to be a tool that serves the needs of a developer (or in many cases a group of developers) which include facilitating the rapid development and management of a larger project. Because of the crucial role GitHub plays, anything that GitHub provides has the potential to impact the development process of nearly any and every project worldwide. Developers need to understand the implications of utilizing licenses provided by GitHub and ensure that any projects released with a license that reserves any rights the developer(s) wish to reserve. Because GitHub is a strong advocate for Open Source Software, many of the different licenses provided by GitHub allow for the public control and ownership of a project rather than private ownership. On one hand, this approach ensures that GitHub itself is not directly involved with the ownership of projects hosted on its servers, which can be an incentive to recruit new users. However, this can also work against the programmer by removing the development team's ownership of code hosted on GitHub. Releasing software under an open source license has many benefits, including the potential for outside parties to contribute updates and provide support for different operating systems and platforms, but all of this occurs alongside the loss of ability to privately distribute and monetize a project. As such, GitHub users need to stay vigilant and weigh the potential benefits and losses associated with privately licensing a project on GitHub. Fortunately, GitHub never attaches a license by default - leaving the project privately owned by the original development team to distribute and monetize if they so choose. An open source license can be attached to a project at a later point if the development team so chooses.
Image from Nikolas Schmidt
GitHub's octocat mascot from GitHub
As one might expect, the licenses provided by GitHub also have a significant impact on GitHub itself. Users of GitHub need to be comfortable hosting and distributing their work on the platform, and GitHub needs to do its part to ensure they are. As such, GitHub does have a large amount of information about the licensure process, as well as a number of statements they provide about their decision-making process. The most easily-accessible of these is GitHub's Choose a License site, which quickly helps users find out the most basic information about the provided licenses and select which one to attach to a project. The site tries to be as simple as possible, providing basic information on legal implications of select licenses. Options are also given for non-software projects, additional licenses beyond the scope of the tool, and information on what occurs if a project is published without a license. However, because GitHub is a platform for hosting software, a disclaimer is provided regarding their relationship and involvement in any legal matters. Specifically, the site states
"We are not lawyers. Well, most of us anyway. It is not the goal of this site to provide legal advice. The goal of this site is to provide a starting point to help you make an informed choice by providing information on popular open source licenses. If you have any questions regarding the right license for your code or any other legal issues relating to it, it’s up to you to do further research or consult with a professional."GitHub's stance on providing these open source licenses stems from their ideology, provided in another disclaimer on their help page,
"The goal of GitHub's open source licensing efforts is to provide a starting point to help you make an informed choice. GitHub displays license information to help users get information about open source licenses and the projects that use them. We hope it helps, but please keep in mind that we’re not lawyers and that we make mistakes like everyone else. For that reason, GitHub provides the information on an “as-is” basis and makes no warranties regarding any information or licenses provided on or through it, and disclaims liability for damages resulting from using the license information. If you have any questions regarding the right license for your code or any other legal issues relating to it, it’s always best to consult with a professional."GitHub's stance shows that it encourages open source projects and makes that the primary goal of its pre-supplied licenses. However, it also acknowledges that this might not be the case for all of its users and provides alternatives to open source licensing. GitHub's default of no license being the most beneficial for the user indicates that they value the developer's autonomy and do not force their view of open source software on users.
Microsoft, as a prominent figure in both software and the world as a whole, is also significantly impacted by any decisions related to GitHub. When Microsoft acquired GitHub in late 2018, many were outraged by the tech giant, known for its stance against free software for decades. Because of the significance of GitHub to programming as a trade, many longtime GitHub users migrated to alternatives, such as GitLab, following the acquisition. In an attempt to appease the angry mob, Nat Friedman, the CEO-to-be of GitHub following the acquisition, provided a statement on the acquisition and how Microsoft and GitHub would work together moving forward. In this statement, Friedman articulated two major points, that
"GitHub will operate independently as a community, platform, and business"and
"GitHub will retain its product philosophy".Since the acquisition, GitHub has now allowed free-level users to privatize repositories, limiting access to up to three collaborators. This feature had previously been available using a paid plan. Despite its reputation, in its acquisition of GitHub, Microsoft seems to have acknowledged and responded to the userbase and worked to redeem its image. These actions taken by Microsoft and GitHub together show that both agencies understand the mindset of the userbase and their goals towards ensuring the community is satiated in spite of the new changes. Additionally, by avoiding changes to the licensure practices GitHub had established previously, Microsoft has shown that it continues to value the freedoms GitHub has offered to its users. Microsoft's engagement with GitHub highlights the company's understanding of how significant the platform is to programmers as a whole, and indicates its intent to maintain a positive relationship. However, this relationship is still new and there are plenty of opportunities for growth and change - both positive and negative - on either side. Only time will tell how this relationship develops.
Microsoft logo from NotebookCheckbook
Image from Scot & Scott LLP
What options are available and what are the implications?
The various licenses GitHub makes accessible are listed below, and analyzed to help users better select which licenses might be more useful for a given project. To describe the impacts of these licenses, I relate them to Creative Commons licenses as described previously.
Image from Taylor Swift
Background information for those who aren't familiar.
In my experience, the only course in my university’s Computer Science program not related to writing code, algorithms, or hardware is a Computer Ethics Course - which I was never able to take. Though, from anecdotal accounts, I've heard the course touches very little on who owns code, and instead touches on who is to blame when something goes wrong, such as a machine and related software administering the wrong amount of radiation to a cancer patient. Who would be to blame in this scenario if a work-for-hire programmer wrote code for Company A, who provided the software associated with Company B who built the machine, who then in turn sold it to the hospital? What if there was a license attached to this software that nobody had read? Then who would be responsible? My senior project involved the use of artwork, text, and content created by other parties other than myself. I asked my adviser whether there were any legal ramifications for using content that wasn't my own, but it seemed to be brushed off as something I really need not worry about.
Generally speaking, I feel as though programmers aren't as concerned about the legal status of their works as they could and should be. Programmers are constantly creating new intellectual property, often using GitHub, and the fact that many users can simply attach licenses to projects - and likely have done so - is simply shocking. The music industry would be up in arms over artists dropping music without trying to merchandise it, and the same can be said for myriad others. So why is programming any different? The implications of ownership of software are so broad and significant that attention needs to be paid towards anything that has a substantial impact on the development process. GitHub's stance as a major interchange in the process provides it with a great deal of influence and into the day-to-day operations of computer programmers. As such, programmers need to be aware of the legal implications of attaching a license to their projects, and GitHub's default licenses need to be analyzed to see just how much impact they have on the control programmers have on their software.
The goal of this site is to provide a detailed analysis of why licenses are needed and what exactly GitHub is doing with the licenses provided by their platform. Generally speaking, I feel GitHub is in a really good spot. They advocate for open source software, but they don't force anyone into releasing their software unless they truly want to.
In addition to sites linked to above, the following resources were also used:
Ballentine, Brian D. “In Defense of Obfuscation: Questioning Open Source and a New Perspective on Teaching Digital Literacy in the Writing Classroom” Composition & Copyright: Perspectives on Teaching, Text-making, and Fair Use, edited by Westbrook, Steve, New York Press, 2009, pp. 68-89.
“GPLv3 - Transcript of Richard Stallman from the Second International GPLv3 Conference, Porto Alegre, Brazil; 2006-04-21.” FSFE, fsfe.org/campaigns/gplv3/fisl-rms-transcript.en.html#before-gnu-gpl
Lessig, Lawrence. Free Culture: How Big Media Uses Technology and the Law to Lock Down Culture and Control Creativity. Penguin, 2004, pp. xiii–13, 275–306, http://www.free-culture.cc/freecontent/
Willinsky, John. “Introduction” and “Access.” The Access Principle: The Case for Open Access to Research and Scholarship. MIT Press, 2006, pp. 1–37, http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.183.3482&rep=rep1&type=pdf