Final Project Licensing

This morning, my game studio teams had their final project planning meetings. One of the things I urged them to discuss was the licensing of their projects. It's also something that I bring up with my CS222 this time in the semester. Normally, in both courses, I just take a few minutes to lay the groundwork, give my recommendations, and answer questions. I have been trying to make as many things asynchronous as I can in order to accommodate the upheaval in students' schedules, and so I took a few hours today to transcribe my thoughts on final project licensing. I wrote this specifically for my CS222 students, who will be assigned to consider this, but I also tried to keep it accessible for other uses as well.

The "live" version of my introduction to licensing is in a private GitHub repository for my students. In the spirit of no wasted writing—and also to help me find it later—I decided to also share it here. This also gives an opportunity for you, dear reader, to share your feedback with me about it. I originally composed it in Markdown, but I ran it through a converter to post it here on my blog.

EDIT: Based on feedback received from a colleague over email, I have added a clarification in the "live" version that students have available.

Without further ado, here is the first draft of the final project licensing tips I wrote up for CS222 final projects.

Final Project Licensing Considerations

Caveat

I am not a lawyer. I am providing you the results of my scholarly investigation into intellectual property. If you need legal advice, get a lawyer.

Copyright

By default, you own the copyright on whatever you create. This means that you have the right to decide who gets to make copies of the work: it is literally the right to copy. In the United States, you don't have to do anything special to have the copyright. If you draw a doodle on a napkin, you own the copyright on it. You can register your copyrights with the federal government, which can be useful in the case of copyright dispute. However, remember that the copyright itself is automatic. 

For the final projects, your team co-owns the copyright to the project. This has the implication that if one of you wants to do something particular with the project, such as put it up on GitHub or try to commercialize it, you need the whole team to agree. If one member of the team does not agree, and in the absence of any other legally-binding agreement, there's really nothing else to be done about it. 

There are certain circumstances under which the university claims ownership to student-created work. An easy example is if the university paid you to make it, such as is the case for employees of the Digital Corps. This is called "work-for-hire" and it's very common: if your job is to write code for an employer, then they own the copyright—not you. The more nebulous circumstance is when the university has put significant resources into the development of your work. They have changed the articulation and specification of this rule during my years here, but in general it is meant to include cases where students benefit significantly and extraordinarily from input of faculty or access to equipment. It is important to note that for this class, I designed our interactions so that the university would have no clear claim on the intellectual property. You defined the problem, you designed the solution. While it is true that I evaluated the structure and process of your solution and helped you approach the learning objectives of the course, the projects themselves are yours.

Licensing

A license determines what rights a user has with regard to a software system. This includes, but is not limited to, the rights of the user to investigate the source code of the software or to decompile or disassemble it. You probably have seen End User License Agreements (EULA) when you run software for the first time. Maybe you've even scrolled through them before clicking "Accept". These are licenses, and they are an important part of the organizational structures around software development companies. EULAs generally are examples of proprietary licenses. This means that the user has no rights to inspect the source code of the programs they are running. Proprietary licenses are not the only kind of licenses. 

Licenses do not just apply to end users. As a developer, your use of third-party libraries is also bound by the terms of its license. Make sure you understand the licenses of the libraries you add to your applications.

Freedom

Before we can get into the non-proprietary options for licensing, it is important to understand freedom. Richard Stallman famously defined free software as software that preserves the following freedoms:

• The freedom to run the program as you wish, for any purpose (freedom 0).
• The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
• The freedom to redistribute copies so you can help others (freedom 2).
• The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

Software that upholds these freedoms is said to be "free software." Note that "free" here means "free as in freedom." Critics of Stallman's choice of words have suggested that we use "libre software" instead, to make it clear that this is not about economic cost. This is also called the distinction between "Free as in speech vs. free as in beer." 

A common misconception of Stallman's position is that he wants software to be given away, but that could not be farther from the truth. Stallman advocates selling software for as much as the market will bear. One of his key observations is that "the market" here is different from "the market" in, say, sub-saharan Africa. It would be permissible under a free software license for you to buy software and then to share it with your disadvantaged brother—a form of charity that is generally disallowed by proprietary licenses. 

Free software is distinct from open source software. Free software is about licensing, but open source is about development methods. Open source software is developed "in the open" for everyone to see. Rather than do their development behind closed doors, open source software developers keep their code publicly readable. Part of the philosophy is open source is that many eyes make all bugs shallow. 

Many open source projects are also free, such as the Linux kernel, but not all open source projects are free, and not all free software is open source. However, because these often go together, you see the combination of the two referenced as FOSS, meaning Free and Open Source Software.

Common FOSS Licenses

There are a few licenses that I recommend for FOSS-licensed student project work. The Expat License (a.k.a. MIT License) is a simple and permissive license; if you've never read a license before, start here, because it's short and to the point. The GNU General Public License (GPL) is a free software license that clearly upholds the four software freedoms. This observation is echoed by ChooseALicense.com, which is a project by GitHub to help people choose the right license for their work. 

The GPL is the one I recommend to student teams because I think it aligns best with the mission of the university. The GPL says that your users can study, share, and modify the software, as long as their changes are also shared back with the community. This feels like a good choice for projects created at a public university, where the public is a stakeholder in our collective success. I like the idea that others can learn from the things you have made, and that what they learn from it is also shared back in a virtuous positive feedback loop. 

There are many more free and open source licenses. The Free Software Foundation provides a useful list of them, organizing them by whether they respect software freedom or not. However, GPL and Expat ("MIT License") are two you see frequently in use, along with Apache 2, which is essentially similar to Expat. 

Note that in none of these licensing cases do you give up copyright, nor do they restrict you from entering into other license agreements. For example, just because you release a version of your project under the GPL does not mean that you cannot also sell a version of it without GPL clauses to a customer: you own the copyright and you dictate the terms. Licenses are for the users or customers, not for the creators.

Public Domain

Besides proprietary and FOSS licenses, you have the option to release your copyright to the project and put it in the public domain. This means that anyone can do literally anything they like with the work. Note that if you choose to go this route, I recommend that you state your software as following CC0 1.0 Universal (CC0 1.0), which is essentially an international form of American public domain designation. One does not normally use Creative Commons licenses for software, but CC0 1.0 is an exception.

Considerations for Future Employment

You have spent a lot of time and energy on your project this semester, and there are extrinsic benefits to this effort. In particular, you can put it to work to help you land a job or an internship. I recommend that, at the end of the semester, you migrate your repository from our private class organization to a public presence on GitHub. This will allow you to share that link with potential employers, who can then see the fruits of your labor. That is, rather than just see that you earned some grade in some course, they can actually see the work you did. 

Of course, before you make a public location for your project, you should choose how you want to license it. Choosing your license removes any ambiguity from those reading your code and from within your team. GitHub provides a convenient Web-based interface for adding the requisite license files to your repository. Keep in mind that the libraries you use may place restrictions on how you can license your own work. For example, if you use a library that is licensed under the GPL, then by the terms of that license, your work must also be licensed under the GPL. 

Of course, it should go without saying that you need to make sure you have followed all the licenses of the libraries and assets you have used in your project! I recommend that you list all of your assets and dependencies in your README.md file, including the licenses under which you used them—including those that you are using under public domain, just to cover all your bases. This, in addition to the project itself, shows potential employers that you are serious about the business of software development.

References

For more about software freedom, I recommend Free Software, Free Society: Selected Essays of Richard M. Stallman. 

For more about the history of intellectual property and copyright and their impact upon creativity, innovation, and society, I recommend Free Culture by Lawrence Lessig. This book establishes the case for the important Creative Commons movement.