On The Road To Professional Web Development | Software Licenses

*The objective of this article is to prepare for a technical interview. To succeed (1) we must be technically proficient, and (2) we must be capable of communicating our proficiency effectively.

In this post, we’ll first become conversationally fluent on the topic of software licenses. Next we’ll understand community recommendations for license selection. Finally we’ll finish the discussion with a curated list of (reportedly) common interview questions.

This post is part of a series on becoming a professional web developer — click here to navigate to the table of contents*

*This article does not constitute legal advice. Opinions listed here are my own.*

Part I: Licenses

How Difficult Is It To Master?

As non-legal-experts, we’d be overstepping our bounds to suggest we’ll become true masters of this topic. But we can work towards improving our understanding while forming reasoned points of view. Studying properties of popular licenses is a necessary ingredient to succeed during technical interviews. To build deeper intuition, it will be equally important to understand their context in law.

Software Licenses: What Are They?

A software license is a legal document governing the use or redistribution of software. Under United States copyright law, our software is copyright protected by default. Attaching licenses to our software is not mandatory in order to be protected, but doing so allows us to clearly specify which protections we intend to keep or surrender.

What Are Licenses To Developers?

• There are many popular licenses, freely available for us to attach to our contributions
• While licenses are optional according to law, outside of proprietary settings devs know better than to risk using unlicensed code (or to contribute unlicensed code without written agreement as to what others may use it for)
• In repository hosting services such as GitHub, software licenses are attached to a project as easily as using a drop-down menu — knowing which to select is the first step for most open-source projects

Where Do Licenses Come From?

Copyright law has existed almost as long as the United States. From the dawn of computing until almost two decades ago, software was likened to a type of “mathematical formula” which is not copyrightable. Legal protections were available through other means, but the Digital Millennium Copyright Act (DMCA) of 1998 changed the status quo — stating that software and digital data were considered copyrightable. Software licenses became the de facto standard for specifying exactly what copyright protections code authors would relax or retain.

How Do They Work?

Licenses are a type of legal document, typically included with code as a plaintext file (or as a comment inside each source code file). There is no special process required to author a license that is legally binding. Anyone can write one, but unless they’re an expert in legal jargon, they probably shouldn’t.

From a legal perspective, we are the copyright holders of our own code. Due to US copyright law, we are automatically afforded protections against others’ use, duplication, modification or distribution of our original work. If they do so without consent, it constitutes copyright infringement. But it’s not mandatory for us to pursue charges (especially if we don’t mind others using our code). One convenient way to let others know what actions we’re comfortable with is to attach a software license to our code.

Since US copyright law affords all protections automatically, we can’t demand more protections in our license and expect courts to help enforce them. All we can do with a license is keep or relax the rights we already have. The list below explores some of the common modes of protection available to us, from least-to-most permissive:

• The most restrictive case is the “trade secret”. This is not a license, but a practice where an individual or company’s software is kept private. Trade secrets mitigate the risk of infringement in the first place.
• Slightly less restrictive is the “proprietary license”. This is used when code can’t be kept private, such as when selling paid software to a customer. In this case, all copyright protections are retained — the license serves as a promise not to pursue infringement charges against buyers who comply with the rules of the sale.
• “Noncommercial licenses” grant special allowances for noncommercial use. Exactly which rights are granted may vary.
• “Copyleft licenses” require that derivative works use a license “at least as permissive” as the original.
• “Permissive licenses” allow use, modification, and distribution of source code.
• Release into the “public domain” goes a step beyond permissive licenses by allowing anyone to use the source code for any reason without restriction, forever.

The above categories apply to several popular open-source licenses:

• Examples of noncommercial licenses include JRL and AFPL licenses.
• Examples of permissive licenses include MIT licenses (e.g. Expat), BSD licenses, Mozilla Public Licenses, and Apache licenses.
• Examples of copyleft licenses include GNU General Public licenses.
• Examples of public-domain-equivalent licenses include BSD Zero Clause license and the Creative Commons Zero license.

These and other licenses are categorized according to their stances on:

• Commercial use
• Distribution
• Modification
• Patent use
• Private use
• Source disclosure
• License and copyright notices
• Network use as distribution
• Contributor licenses
• State changes
• Sublicenses
• Liability
• Trademark use
• Warranty

Not all licenses impose license requirements on contributed code. As they own the copyrights over their contributions, their power to legally attack a project is unchecked, unless they’re willing to participate in a license agreement (a Contributor License Agreement, or CLA). A CLA can be specified in an email, in a license, in a document separate from a license, or possibly already baked-in to the terms of service for a the code hosting platform you’re using (GitHub’s “inbound=outbound” policy is an important example).

What Terminology Comes Up When Discussing Software Licenses?

• Affero GPL Licenses: the regular GPL with one additional requirement applicable to servers. “If AGPL licensed software runs on a server that others can communicate with, the server must allow them to download a copy of the modified source code”
• Aladdin Free Public Licenses (AFPL): based on GPL with additional requirements. “AFPL limits use to noncommercial purposes and requires that any distributions include a copy of the source code. It is considered a source-available license”
• Apache Licenses: a license maintained by the Apache Software Foundation, designed to be GNU-compatible and able to attach to code by reference instead of including a copy of the license in every file (as some licenses require). “GNU recommends this license for small programs (less than 300 lines) as it protects against ‘patent treachery’ ”
• BSD Licenses: permissive licenses which have multi-clause varieties. “The original BSD license had 4 clauses. Over time, variations of BSD licenses removed clauses up to and including the Zero Clause BSD license, which is so permissive it is equivalent to a release into the public domain”
• Contributor License Agreement (CLA): defines the terms under which a contribution has been made to a company or project. “CLAs exist to prevent legal issues that may arise from the challenge of having different copyright owners across various portions of code in a codebase”
• Copyleft Licenses: licenses requiring that derivative works are at least as permissive as the original. “Copyleft is represented by a backwards-C inscribed in a circle, similar to the copyright symbol. But copyleft is still a form of copyright, so the copyright symbol is still applicable to copylefted works”
• Copyright: authors of creative works own an intangible object called a copyright. Copyright ownership is what gives authors the authority to allow or deny others the ability to use, modify, or distribute the author’s work. “When others use creative works without the original author’s permission, this is called copyright infringement. Courts will protect authors’ rights by enforcing copyright law”
• Creative Commons Licenses (CC): a set of licenses that apply to creative work which could be, but is not limited to, software. “In addition to the public domain dedication (CC0), there are six available creative commons licenses”
• Debian Free Software Guidelines (DFSG): guidelines that Debian uses to determine if software is ‘free’ and able to be included in the Debian project. “The DFSG is part of the Debian Social Contract. It maintains a popular definition of free software”
• Developer Certificates of Origin (DCO): a type CLA agreed to one-time-only early on in a project, intended to reduce administrative burden by relying on digital signatures (e.g. the email address tied to a git commit) instead of attaching an entire agreement to a contribution. “The language for a DCOs here, and a comparison to CLA is here”
• Expat License: the MIT/X11 license. “Though commonly called ‘the MIT license’ some organizations prefer using the ‘Expat’ for clarity, as there are multiple ‘MIT licenses’ ”
• Free Software: not necessarily zero-cost software. “This concept is commonly phrased ‘free as in freedom’ ”
• Free/Libre and Open Source Software (FLOSS): FOSS software with the addition of the Spanish word ‘Libre’ to clarify ‘free as in freedom’. “This compensates for ambiguity in the English language, which lacks a clear definition for the word freedom”
• Free and Open Source Software (FOSS): software that is both free software and open-source software. “FLOSS and FOSS mean the same thing, but FSF recommends using the term FLOSS”
• Free Software Foundation (FSF): a nonprofit organization with the mission to protect computer user freedom. “FSF funds many popular projects, including but not limited to the GNU project (an operating system plus free software). Many FSF resources regarding license recommendations are hosted on GNU’s website”
• GPL Licenses: GNU General Public Licenses aren’t considered permissive, but are considered copyleft. Their intention is to keep software and derivative works free for all. “Some argue that GPL licenses aren’t ‘free’ because they limit users’ rights to take away freedoms for others. The author of Producing Open Source Software has an interesting take on this matter”
• Java Research Licenses (JRL): a research license to be used for non-commercial academic uses. “JRL strictly forbids commercial use”
• Lesser GPL Licenses (LGPL): Like GPL, but allows code use in proprietary programs. “The LGPL is used in limited instances to incentivize certain contributors to participate, but only when absolutely necessary”
• MIT License: typically refers to the Expat license, but there are many others. “GNU recommends using the term Expat to be exact”
• Mozilla Public Licenses (MPL): a free and open-source license maintained by the Mozilla Foundation “Libre Office, the Eigen C++ library, and Mozilla Firefox all rely on MPL licenses”
• Open Source Software: source code available under a permissive license. “Open-source software is a common example of open collaboration”
• Open Source Initiative (OSI): a non-profit organization advocating open-source software. “The OSI maintains open-source license recommendations”
• Proprietary Licenses: paid licenses for closed-source software. “Intellectual property rights are retained under copyright or patent law”
• Proprietary Relicensing: the act of maintaining a free open-source codebase alongside a paid commercial version. “Also known as dual-licensing or multi-licensing, Producing Open Source Software discusses the pros and cons of this business model”
• Permissive Licenses: licenses with minimal requirements on distribution. “BSD, Apache, MIT, and MPL licenses are considered permissive”
• Patent: a form of intellectual property protection. “Patents may challenge copyright protections, exposing developers to the ever-present risk of frivolous lawsuits. Some licenses, such as GPLv3, build in protections in an attempt to battle this”
• Public domain: all creative works where no exclusive intellectual property rights apply. “If you prefer permissive licenses and aren’t bothered when someone turns your work around for a profit you’ll never see, consider placing your work in the public domain”
• Share-alike Licenses: licenses that require copies or adaptations of the work to be released under the same or similar license as the original. “Like copyleft, but not necessarily ‘free’ ”
• Source-available Licenses: licenses that are not open-source but make the software available for inspection and, in limited instances, modification. “AFPL is considered source-available”
• The Unlicense: a license used to formally declare the release of software into the public domain. “The Unlicense is so named as a jab against an arguably broken system”
• Trade Secret: the act of never releasing software externally (commercially or otherwise). “Trade secrets are among the most restrictive forms of protecting against the risk of copyright infringement”
• US Copyright Office (USCO): the official U.S. government body that maintains records of copyright registration. “Infringement claims cannot be pursued until the copyright in question has been formally registered with the USCO”
• WTF Public License (WTFPL): a permissive license. “This license is comical but not recommended”

Part II: Using Software Licenses

Part II focuses on license selection. Up to this point we’ve examined what rights we stand to protect. If push comes to shove and we wind up in a legal dispute, we will be held to the nitty-gritty details of the exact license attached to our project.

Choosing A License

Attaching a license to a project is easy, but choosing one that affords us necessary protections is not so straightforward. When in doubt, we should seek legal council. When not in doubt, we should really be nervous as to why on earth we’re not in doubt. But all we can do is make an informed decision, and use a graded approach (proportional to the importance of the project) to determine how much deliberation is justified.

1. Explore this license selection tool developed by the Institute of Formal and Applied Linguistics (the goal here is to reinforce the selection criteria we need to consider)
2. See GitHub’s recommendations for license selection (and don’t miss the comparison chart)
3. See GNU/FSF’s recommendations for license selection, their commentary on popular licenses, and their four-point definition of free software
4. See the definition of free software per DFSG and their list of DFSG-compliant licenses
5. See OSI’s recommendations for license selection and their ten-point definition of open-source software
6. Read Chapter 9 of the free eBook “Producing Open Source Software”, paying special attention to Contributor Agreements, Proprietary Relicensing, and Patents

Part III: Software License Interview Questions

• compare definitions of free software to definitions of open-source software
• discuss contributor agreements
• discuss copyright ownership
• discuss licenses for data
• discuss use of open-source licenses in commercial software
• list compliance requirements of popular licenses
• list licenses of open-source software you use
• list popular licenses
• list properties of popular licenses

Closing Thoughts

I hope you’ve enjoyed this post as much as I enjoyed writing it. If you have thoughts you’d like to share, your editorial suggestions are always welcome. This post is part of a series on becoming a professional web developer. If you’d like to see more content like this, please click here to navigate to the table of contents.