I was recently asked to provide some feedback on a couple of projects that Phase2 is planning to release under an open source license. As a company, we definitely have a bias towards using open systems because they give our clients flexibility, cost savings, and transparency. Picking an open source license is complex, but there are reasons for choosing one license over another.
The following topic is complicated. I’m offering up my research, but also need to offer up the following disclaimer. I am not a lawyer. I am a technologist. While I have a pretty extensive history in using and participating in open source projects, this work should not be taken as legal advice. That said, I do not think just any lawyer will do to help you decipher your open source licensing needs.
If you are truly interested in the legal ramifications of a software licensing decision you need to make, consult with a lawyer that specializes in copyright, intellectual property, and software law. Further, software licensing and the related laws differ from country to country based on the legal systems present. Make sure your legal advice comes from someone that knows law that covers your type of software. Software licensing for devices, particularly networked devices, differs significantly from web and service software, which will be the focus of this post.
What is open source?
Open source is a huge concept. At its simplest level, open sourced software has not been compiled. A person can analyze the source code that allows the application to run. Open source does not mean free, though many open source projects are also FOSS (free open source software). It is worth noting that one of the founders of the free software movement, Richard Stallman, would argue that open source “misses the point” of software truly being “free” to use. (https://www.gnu.org/philosophy/open-source-misses-the-point.html)
The original intent of much of the FOSS movement was to make software free for use and for developers to extend the uses of software. As a movement, it has morphed into legal protections to allow either the developer or the owner of the intellectual property created or the user of the finished software to maintain or release rights to that work. The tool used to accomplish this declaration of rights is a license.
What is a license and why does it get applied to software?
A software license is an intersection of copyright, patent law, and legal precedents. Since software is essentially written word, in most countries, it falls under copyright law. Most modern copyright law in the United States was established in the Copyright Act of 1976. The STELA Reauthorization Act of 2014 extended the bulk of this law. The recognized power to establish copyright law—and patent law—stems from the constitution itself. (Article 1, section 8)
Perhaps it is because people in the United States are litigious, but the US is where most open source licensing law has been established and tested—albeit tested in limited fashion, which I will get into a little later.
The scope of copyright is pretty well established. (https://www.copyright.gov/title17/92chap1.html)
“Copyright protection subsists, in accordance with this title, in original works of authorship fixed in any tangible medium of expression, now known or later developed, from which they can be perceived, reproduced, or otherwise communicated, either directly or with the aid of a machine or device.”
Technically, anything original that is written gets the protection of copyright given to the author or authors of that work. This protection extends for the life of the author or authors, plus a default of 70 years. Yes, in a work by more than one author, copyright extends to all the participants equally. This joint “ownership” becomes extremely important in open source licensing.
The license itself is a legal statement by the owner of the copyright to share their intention for that work.
Lest you have any doubt about it, unlicensed software with no mention of copyright leaves that software in the public domain. Everyone can use it and distribute it as they wish—which sounds great—except that a license could still technically be applied to this work at a later time by the author or authors of the work.
Lack of a license leads to a lot of confusion as to what the intent was for a large body of work in distributed code hosting services such as Github. That confusion of intent was an impetus for starting choosealicense.com—a Github project that helps new project creators choose a license and apply it to their project.
If you are releasing software for others to use, please add a license—especially if you intend for others to share in the creation of that software on Github or Gitlab or even a self-hosted versioning repository that others can access.
Now that you have an inkling of why we license software, stay tuned for a deeper dive into the types of licensing available in part two.