A Brief Introduction to Copyright and Licensing
 |
|
A lot of the content above has been all “license” this and “license” that without a lot of context on what a license actually is and why it’s such a big deal, particularly for free and open source software.
So it’s time for a very brief introduction to copyright, a complicated matter without which free and open source software wouldn’t exist. As you saw above, Richard Stallman realized that he could use the existing copyright laws and systems to ensure software would always remain Free through careful licensing. Copyright therefore underpins everything in FOSS. Without it, and without an understanding of it, FOSS is not possible. Keep in mind: copyright law is a complex subject, so this is only a rudimentary introduction. Also, I am not a lawyer. What follows is not legal advice, only guidance to help you understand some of the basic concepts and complications of copyright.
When you create something, be it artwork, music, writing, software code, or any other creative endeavor, by default you own the copyright over that thing. This is an oversimplification, because in some countries and jurisdictions, you have to register something to get copyright. It’s not as common anymore, but it’s common enough that you might want to check on how copyright is assigned in your country.
However the assignment happens, as the copyright owner, you have the right to control how that thing can be used. This control comes through licensing the work. A license is a legal document used to give people or entities permission to use copyrighted material. If someone else would like to use your work in any way, you can provide them a license that details the specific ways they may use your creation. A creator can apply the statement “All Rights Reserved” to their work to indicate that they don’t want anyone to reuse or repurpose their work in any way; the creator has reserved the reuse or repurposing rights for themselves alone.
Things become complicated when there are multiple creators of a work. Each one of the creators, by default, retains copyright over the portions that they contributed to the whole work. If you program a piece of software, you have copyright over the code you wrote for it. If I come along and add a unit test for your software, I have copyright over the code I wrote for that test. The entire piece of software now has two copyright holders involved somehow.
Free and open source software licenses can help when there are multiple copyright holders for a single piece of software. These licenses often (but not always) contain a statement requiring contributions to a project (the unit test in the above example) to be contributed and released under the same license as the original work. This helps to keep the copyright and licensing complexities more comprehensible. As you can imagine, in a large project, questions of copyright could easily become mind-bendingly complicated.
Whatever creative work you contribute to a project, unless you agree to assign your copyright elsewhere (as can happen in a work for hire or a Contributor License Agreement situation, both covered later in the book), you retain copyright over your contribution and—if the project is released under an OSI- Approved License—your contributions will be publicly available. This means you can build a professional portfolio without fear of breaking copyright law or violating someone else’s copyright.
This is not the case for creative work you contribute for your employer. Internships, freelance, hourly, and full-time jobs are all what is called work for hire. Unlike FOSS contributions, by default, the copyright on any work you contribute to a work for hire situation belongs to the organization paying you. Once you contribute that work to the organization, you no longer have any rights over it at all, and you may not share it in any form without very express and very written permission. It is illegal to share any creative work for which you do not have copyright or that is not licensed in such a way that it may be made public. This holds true for code, designs, documentation, project plans, or anything else that you create in a work-for-hire situation.
If you are interviewing or applying for a new position, and the prospective employer asks for work samples, you must not share anything that you created for past or current employers unless you can demonstrate that they have given you permission to do so. If you share private and proprietary work of past employers, how do you think that makes you look to your potential employers? Answer: Like a thief. You will have just proven to them that you cannot be trusted to keep their secrets. Why would they want to hire someone like that?
A portfolio comprising contributions to free and open source software contributions avoids the legal, moral, and reputational risks of sharing samples from proprietary work-for-hire creations. It not only allows you to highlight your skills, but it also demonstrates that you are ambitious and passionate enough about technology that you’re willing to dedicate time outside of work to learn and contribute back to the community.
Because nothing is simple where copyright law is involved, there are, of course, exceptions to the work-for-hire copyright ownership rule. This comes in the form of employment agreements, proprietary information assignment agreements, and similarly named and intentioned legal documents. These usually come into play when you start employment with an organization, and they detail who owns the intellectual property (has the copyright) for what creations in which situations. Often these will declare that anything created on company property (computers) and/or on company time is the property of the company. However, thanks to the rise of free and open source software, some companies such as GitLab[34] and GitHub[35] have employment agreements that allow employees to retain copyright over their free and open source software contributions for the duration of their employment, regardless of when or how these contributions were created. This practice isn’t yet common, and you should carefully read and review your employment agreements before signing them, regardless.
On the other side of the copyright ownership exception coin, we have Contributor License Agreements (CLA). These are discussed further in Chapter 3. Some (but not all) CLAs include the requirement that the contributor assign the copyright of all of their project contributions to the organization that oversees the project. This gives the organization the ability to enforce that copyright, or even to change the license under which the project is distributed, without having to bother every contributor to ask their permission. CLAs are legal documents, and like all legal documents, it’s important that you read them before you sign so you know what you’re getting yourself into.
📣 Like what you see? Hire me! 📣
I can bring my decades of experience and knowledge of business strategy, software development, servant leadership, and open source to your organisation.
Check out my resume then contact me today!