mirror of
https://github.com/ItsDrike/itsdrike.com.git
synced 2024-11-09 21:49:41 +00:00
Rewrite software-licensing & publish pending posts
This commit is contained in:
parent
7f89d1586a
commit
2c65ecc4b4
185
content/posts/changing-license.md
Normal file
185
content/posts/changing-license.md
Normal file
|
@ -0,0 +1,185 @@
|
|||
---
|
||||
title: Changing a software license
|
||||
date: 2023-10-12
|
||||
tags: [programming, licensing]
|
||||
changelog:
|
||||
2023-12-10:
|
||||
- "Publishing this post (was written earlier, but it was waiting for other posts that it refers to)"
|
||||
---
|
||||
|
||||
Figuring out how to properly and legally change the software license of your project can be a difficult task, and yet
|
||||
it's incredibly important that you do this right, as you might run into some legal issues otherwise, which I'm sure
|
||||
you'd like to avoid. For that reason, I wanted to write something explaining this process in detail, and demystify it a
|
||||
bit.
|
||||
|
||||
{{< notice note >}}
|
||||
This article assumes that you already know the basics of how software licensing works, and that you're familiar with
|
||||
the different types of licenses (permissive, (weak and strong) copy-left, public domain). If you aren't sure you're
|
||||
familiar enough with these topics, I'd strongly advice you to learn read about these before going through this article,
|
||||
as you will likely not end up understanding a lot of what I'm talking about here.
|
||||
|
||||
But don't worry, I actually have an article explaining these basics right here, [check it out!]({{< ref
|
||||
"posts/software-licenses" >}}).
|
||||
{{< /notice >}}
|
||||
|
||||
{{< notice warning >}}
|
||||
Even though I did a lot of research into software licenses, it is important to mention that I'm not a licensed lawyer,
|
||||
and this is not legal advice. Ideally, you should consult a lawyer if you need to get the licensing right. This article
|
||||
is here purely to give you a general understanding of how the relicensing process works in various cases.
|
||||
{{< /notice >}}
|
||||
|
||||
## Licenses stick around
|
||||
|
||||
So you've decided that you want to relicense some of your projects (or add a license to previously unlicensed
|
||||
projects), good! There is however an important consideration that you should be aware of when doing this.
|
||||
|
||||
In most cases, if your code already had some kind of license, it is very likely that that license will remain in effect
|
||||
even after the relicense. This is because most open-source licenses will give out "perpetual" and "irrevocable" rights
|
||||
to the code licensed under them.
|
||||
|
||||
By relicensing your code, all you're doing is adding yet another license in combination with that original one to all
|
||||
of your existing code. This will then mean that the code you had will now be available under either the terms of the
|
||||
original license, or the terms of the new one, and anyone who'd like to use your code will be able to pick whichever of
|
||||
those 2 licenses that they prefer.
|
||||
|
||||
So, while you can remove the first license from the repository, the code that was originally licensed under it will
|
||||
remain available under those terms. That said, any new code you write after the removal of the first license will then
|
||||
only be available under the new license.
|
||||
|
||||
This is why it's very important to really think about which license you want to use before publishing your code under
|
||||
it, as otherwise, you risk making your code available to anyone under very permissive terms, which you may end up
|
||||
regretting in the future.
|
||||
|
||||
## Relicensing public domain code
|
||||
|
||||
This is certainly the easiest of the cases. If you want to add a license to any code attributed to the public domain,
|
||||
you can do so without any worries about legal issues, as this code's license doesn't impose requirements on you, and
|
||||
simply gives anyone rights to do essentially anything with that code.
|
||||
|
||||
## Relicensing permissive code
|
||||
|
||||
Using permissively licensed code under a different license is still pretty easy, as that is their intention. That said,
|
||||
this time there will be at least some requirements for you to meet.
|
||||
|
||||
Generally these will just be simple things such as having to mention the original source, state changes, a clause
|
||||
preventing you from making software patents of this code, etc. These requirements will differ from license to license
|
||||
so you should understand them first before trying to use such code, however the relicensing process here will generally
|
||||
still pretty straightforward.
|
||||
|
||||
## Relicensing copy-left code
|
||||
|
||||
This case however won't be as easy. The whole point of copy-left licenses is to ensure that the code will stay open,
|
||||
and to guarantee this, they're designed to prevent most sublicensing. That said, they don't necessarily prevent all
|
||||
sublicensing, as you'll see in the following section:
|
||||
|
||||
### Compatible licenses
|
||||
|
||||
All copyleft licenses will by design have to prevent you from removing (freeing up) restrictions in the license, at
|
||||
least to some extent, otherwise they wouldn't be copy-left (they'd be permissive). Copy-left licenses then also prevent
|
||||
imposing further restrictions on the freedoms these licenses do give out, because without that, one could for example
|
||||
relicense the project under a technically copy-left license, but one that only allows a single person/entity to use
|
||||
this code, essentially making it proprietary. Once again, there may be some leeway here, and perhaps some additional
|
||||
restrictions can be imposed, but it's generally not going to be much, and in most cases, this leeway is essentially
|
||||
non-existent.
|
||||
|
||||
This means that even though in some (rare) cases, you might actually be able to find a compatible license that you
|
||||
could relicense to without any issues, this license will then likely be almost the same, often making this transition
|
||||
pretty much useless.
|
||||
|
||||
That said, a copy-left license can contain a list of some specific licenses, to which relicensing is explicitly
|
||||
allowed, even though they otherwise wouldn't be compatible. This is mostly done just to allow updating this license,
|
||||
such as for going from GPL version 2 to GPL version 3.
|
||||
|
||||
In many cases, these licenses provide a version without this clause, for people who consider it potentially dangerous
|
||||
though (for example with GPL v2, these versions are often called `GPL-2.0-or-later` vs `GPL-2.0`). It's very rare for
|
||||
this clause to allow completely different licenses though, and generally it will really only be for this "upgrade" use
|
||||
(downgrading usually isn't possible either, so once you update, you can't go back).
|
||||
|
||||
### Incompatible licenses with full code ownership
|
||||
|
||||
As you see, it's very unlikely that if you'd want to relicense, you'll be able to do so simply, by just moving to a
|
||||
compatible license. This therefore brings us to moving to incompatible licenses, and doing this can be incredibly hard.
|
||||
|
||||
However there is a simple case here, for when you own all of the code in the project yourself. In this case, as a
|
||||
copyright holder, it doesn't really matter what the license says, you own the full rights to your code. The license is
|
||||
just a way to give out some of those rights to others. You, as the owner, don't need to follow it though, and that
|
||||
means it's literally as simple as deleting the old license, and putting in a new one.
|
||||
|
||||
### Incompatible licenses without code ownership
|
||||
|
||||
The real issue only arises when you're trying to relicense a project that actually has some contributions from others,
|
||||
and you don't have the rights to relicense their code. This is because when they made their contribution, they
|
||||
submitted it to your project only under that original copy-left license.
|
||||
|
||||
At that point, you don't really have that many options. The simplest one is to just rewrite the code that you don't
|
||||
own, so that you will then have the copyright over all of the code. Once 100% of the codebase is owned by you, you can
|
||||
relicense, as we're essentially just back to the first case. Obviously though, this might be a huge task for bigger
|
||||
projects, and it might simply be infeasible to rewrite that much.
|
||||
|
||||
The other option is to get permission from the original contributors, allowing you to relicense their code. This works
|
||||
because you don't actually need to follow the original license, if you have some other agreement with the contributor,
|
||||
that allows you to use the code in a less restricted way. (This is pretty much also why the first case, where you own
|
||||
100% of the code is so easy.)
|
||||
|
||||
The issue with this one is also pretty obvious though, as not only do you need to find a way to contact the
|
||||
contributors, you also need them to actually agree to this license change. Contacting contributors alone can be a very
|
||||
difficult, and perhaps even impossible. Many contributors use no-reply emails from GitHub/GitLab in their commits, and
|
||||
their accounts don't list any way to get in touch with them. Even if you can find the email, they might not be using it
|
||||
anymore, or simply choose to not reply. But it gets even worse! It's possible that the contributor has died, in which
|
||||
case their copyright got transferred to their relatives, or to the state, and you'd need to obtain permission from
|
||||
them instead.
|
||||
|
||||
Let's say you were able to contact the contributor though, now you'll need them to agree to give you the rights that
|
||||
allow you to use their code in a different way, than that which they originally agreed to. This is no easy task,
|
||||
especially when the contributor wants their code to stay open, and they just aren't comfortable with the change you're
|
||||
trying to make. In many cases, when companies attempt this, they end up convincing people by offering to pay for these
|
||||
rights.
|
||||
|
||||
But even with contributors that wouldn't mind giving you those rights, you will still need them to sign a document
|
||||
(usually this will be a [CLA]({{< ref "posts/licensing-documents" >}})) confirming that they're granting you these
|
||||
rights, and generally, people just don't like signing things like that, even if the wording isn't that difficult to
|
||||
understand. In some cases, it is even possible that the code in your project was written by someone that is too young
|
||||
to be able to legally sign such a document, in which case, you would need to get their parents/guardians to do so
|
||||
(you'd be surprised just how many open-source developers are minors).
|
||||
|
||||
## Relicensing proprietary/unlicensed code
|
||||
|
||||
Projects without any sort of license are automatically considered proprietary, as the original owner(s) automatically
|
||||
get the copyright to what they wrote and they didn't give out the rights to use this code to anyone via a license.
|
||||
|
||||
### Intentionally proprietary
|
||||
|
||||
If you're dealing with a source-available code-base without a license, and you'd like to use some of it's code in your
|
||||
own project, or to fork it and license under some open-source license, the only choice you have is to contact the
|
||||
author, and get their permission to do so (often by paying the author to get it).
|
||||
|
||||
This is a pretty common thing for companies, who write code for clients, who only have usage rights, but not
|
||||
modification rights. So when the client wants to migrate to another company, they'd need to start over, or purchase the
|
||||
rights to modification.
|
||||
|
||||
### Unintentionally proprietary
|
||||
|
||||
In a lot of cases, the lack of license actually wasn't intentionally, and the author actually intended for their code
|
||||
to be open-sourced, but they just weren't aware that to do so, they need to add a license.
|
||||
|
||||
What's even worse is when someone actually makes a contribution to this kind of project, and the author accepts it. The
|
||||
thing is, that contributor was never authorized to even make a contribution, as it's a modification of the code-base,
|
||||
which the copyright prohibits by default. But the contributor didn't realize that, and neither did the author, so now,
|
||||
that code-base contains proprietary code hunks, some owned by the original author, and some by the contributor.
|
||||
|
||||
This is incredibly problematic, as it means even the original author now doesn't have the rights to edit the code
|
||||
written by that contributor, in their own project. They pretty much just legally locked themselves out of access to
|
||||
their own project.
|
||||
|
||||
The simplest thing the author could do now is to just revert this change, add a license, and ask the contributor to
|
||||
make another PR, offering the code under that new license. (You could also get the contributor to sign a CLA, which
|
||||
will give you rights to their code that they've already submitted, but this leads to the same issues as in the
|
||||
copy-left relicensing case, and getting people to sign something is much harder than to have them just redo the PR).
|
||||
|
||||
That said, this process gets exponentially more difficult with the number of contributors, as the amount of reverts to
|
||||
be done might get really high, to the point where you can't reasonably do it without going back to a really old
|
||||
version entirely, when all of the code was written only by you.
|
||||
|
||||
In that case, you should do your best to contact the contributors and get the appropriate permissions, but if you can't
|
||||
do so, either revert and rewrite any code that isn't yours, or if that's not viable, just delete the project entirely
|
||||
to avoid getting into legal trouble.
|
164
content/posts/licensing-documents.md
Normal file
164
content/posts/licensing-documents.md
Normal file
|
@ -0,0 +1,164 @@
|
|||
---
|
||||
title: Software licensing documents (CLA and DCO)
|
||||
date: 2023-04-03
|
||||
tags: [programming, licensing]
|
||||
changelog:
|
||||
2023-12-10:
|
||||
- "Publishing this post (was written earlier, but it was waiting for other posts that it refers to)"
|
||||
---
|
||||
|
||||
In many projects you'll find out that before you're allowed to contribute something to an open-sourced, you'll be
|
||||
required to sign a document requiring certain things. This is mostly the case of contributing to projects maintained by
|
||||
big companies, but it can be seen in smaller projects too sometimes. But what is the purpose of these documents, and
|
||||
should you be willingly signing them?
|
||||
|
||||
In most cases, you'll see one of the below two categories of documents, each doing very different things:
|
||||
|
||||
## Contributor's license agreement
|
||||
|
||||
Following the [relicensing post]({{< ref "posts/changing-license" >}}), it should be clear that any copy-left licensed
|
||||
project wishing to relicense won't have it easy and it may take years to gather the consents of all of the contributors
|
||||
to actually achieve that relicensing. Because of this, many companies choose to instead simply get this consent
|
||||
beforehand, with what's called a "CLA", (short for "Contributor's License Agreement").
|
||||
|
||||
CLA is a legal document that each contributor is often required to sign before the company will allow any code from
|
||||
said contributor to make it into their (usually copy-left licensed) codebase. This agreement states that all code
|
||||
contributed by this person will have it's copyright transferred over to that company. Making this company the single
|
||||
copyright holder and therefore making it really easy for them to change the project's license if the current license
|
||||
becomes inadequate. (If you're unsure how that works, check out the above linked relicensing post.)
|
||||
|
||||
This is often used to allow for updating the license to a newer version when it comes out (though you could just as
|
||||
well include a sort of update clause into the license itself, which for example the GPL license does allow). Another
|
||||
common use-case for this is to allow the company to dual-license a project, having the original copy-left license there
|
||||
for general public use, while also providing a permissively licensed version which can be purchased by companies for
|
||||
usage in their own closed-source code bases, which makes them profit from the project.
|
||||
|
||||
{{< notice tip >}}
|
||||
If you want to see how a full text CLA might look like, consider checking out
|
||||
[contributoragreements.org](https://contributoragreements.org/ca-cla-chooser/), where you can generate a template CLA
|
||||
based on some preferences which you can choose.
|
||||
{{< /notice >}}
|
||||
|
||||
### Dangers of a CLA
|
||||
|
||||
The biggest issue with a CLA is the fact that it often transfers your copyright away, rather than gives right to using
|
||||
your code. This means that you actually lose the ownership over that code, and if you were to use it elsewhere (like in
|
||||
your own personal projects), you could end up actually having to treat it as someone else's code, and adhere to the
|
||||
license it's released under. This might mean having to add a document where you attribute it to a different owner (such
|
||||
as a company), which is pretty scary considering this was your code to start with.
|
||||
|
||||
Another big issue is that, usually, if you're contributing to a copy-left licensed project, you expect that code to
|
||||
stay open-sourced. However with a CLA, the copyright owners could easily relicense it, and not just to some alternative
|
||||
copy-left license, not necessarily even to a permissive one, instead, as the single owners of the entire project, they
|
||||
could simply close-source it entirely, if they wanted to.
|
||||
|
||||
### Copyright back clause
|
||||
|
||||
While the first issue with CLAs, being you loosing your right to your own code sounds absolutely horrifying,
|
||||
the agreement can include a "copyright back" clause (or a similarly named one), which contains a software license
|
||||
granting you full irrevocable rights to use your code freely, without any restrictions or requirements.
|
||||
|
||||
The other case that's also seen quite often is one where you give the company full rights to your code, but without
|
||||
any copyright transferring. This is similar to the copyright back clause that you're given, except it's now you giving
|
||||
the company these unrestricted rights, including that to grant sublicenses to third parties, meaning your code could
|
||||
spread anywhere, under any license, at that companies discretion.
|
||||
|
||||
While the 2nd option might sound a bit better, as you're technically still the copyright holder, in reality it doesn't
|
||||
really matter, at all. That's because if the company has all rights to the content, it essentially makes that company
|
||||
an owner of that content. They can do absolutely anything with it, and you can't revoke this right, as it was an
|
||||
irrevocable grant. This is then also the case with the company giving these rights to you.
|
||||
|
||||
Thankfully, one of these 2 clauses is present in **almost** all CLAs, meaning you likely won't be loosing the rights to
|
||||
use your own code. It is however very common for [employee CLAs](#employee-contracts) to not include these, as the
|
||||
company often doesn't want you being able to share their proprietary code (though this is often also handled through an
|
||||
[NDA](https://en.wikipedia.org/wiki/Non-disclosure_agreement)). So, if you're considering signing any CLAs, make sure
|
||||
that one of these clauses is there, and if it's not, only sign it if you're really ready to accept the consequences of
|
||||
that.
|
||||
|
||||
### Limiting conditions
|
||||
|
||||
To somewhat mitigate the dangers of signing a CLA, some of them can actually include a "transfer back/nullification"
|
||||
clause, that can reassign the copyright back to you, or revoke the copyright rights you've given to the company.
|
||||
|
||||
This often requires you making a written letter about termination of the agreement, which you can request if the
|
||||
company didn't follow one of these conditions.
|
||||
|
||||
A very common condition that CLAs for open-source projects include is one that prevents relicensing under any license
|
||||
that wasn't FSF/OSI approved, or one that wasn't in an explicitly defined list of licenses (perhaps purely copy-left
|
||||
licenses). This can therefore remove the contributors worry about the company potentially making the project, along
|
||||
with your contribution closed-sourced.
|
||||
|
||||
So, if you don't mind signing a CLA, but you require the company to follow some conditions, you can always ask the
|
||||
maintainers to offer you a version with these extra conditions. This likely won't succeed though, as even if the
|
||||
company doesn't mind your conditions, it would require them to keep note that your contributions are under a different
|
||||
license, and to contact their lawyer to write up a modified version of the agreement, which can be expensive.
|
||||
|
||||
However if your proposal is reasonable enough, and especially if you get more people to ask for these additional
|
||||
conditions, you just might be able to convince them to change the main version of their CLA to include these by
|
||||
default, protecting every new contributor with them.
|
||||
|
||||
### Employee contracts
|
||||
|
||||
A very commonly sen use of CLAs is in employee contracts, so that the company you're working for will be the one
|
||||
holding the copyright over the code you write there. These CLAs are almost always incredibly invasive, and you likely
|
||||
won't find any nullification clauses, and **not even copyright back clauses** in there at all. However that is somewhat
|
||||
understandable as the company will probably want to be using that code in close-sourced projects with various licenses
|
||||
and perhaps also even sell it under different licenses.
|
||||
|
||||
That said, it is incredibly important that you go through the CLA in your employee contact and understand when does
|
||||
this copyright transfer occurs. Many companies go pretty far by simply having it apply to all projects that you work on
|
||||
from a company machine (even a borrowed one that you work on from home), so even if it's not a project you've been
|
||||
assigned to work on by that company, and you simply just opened up some personal project on a company owned machine,
|
||||
that might've been enough to transfer the copyright for your project to the company.
|
||||
|
||||
Of course, you could fight this in court, but if the company would have any evidence that you did indeed open your
|
||||
project on their machines, and their CLA stated that doing so means immediate copyright transfer, you're simply out of
|
||||
luck, and you just lost the rights to the code of your own project.
|
||||
|
||||
Another common rule for when CLA applies is any time during the checked in working hours, or whenever you're in the
|
||||
company building, etc. This is why you absolutely have to know under what conditions you're working, otherwise you're
|
||||
risking the company going against you and taking over one or more of your projects.
|
||||
|
||||
## Developer Certificate of Origin
|
||||
|
||||
A "DCO", sort for Developer Certificate of Origin is a legal document that deals with ensuring that all of the code you
|
||||
submit to some codebase is indeed owned by you, or you have a legal right to use it and contribute it to that codebase
|
||||
(meaning you also need to have the right to use submit this code under the project's license).
|
||||
|
||||
This kind of document is pretty important because it gives the maintainers a signed document, showing that you've
|
||||
agreed to always fact-check that your contributors are in fact license compatible and that you've met all of the
|
||||
conditions to actually use it. Or that the code you're contributing is yours, or that you simply have a right to use it
|
||||
and to add it to this project.
|
||||
|
||||
The reason maintainers often make it required for contributors to sign this document is because it gives them something
|
||||
to hold over the contributors if it turns up that someone actually contributed code they didn't have rights to.
|
||||
|
||||
This solution isn't full-proof and the project maintainers may still be the ones held liable even though a DCO was in
|
||||
place. However it will at least mean that the maintainers themselves can then hold the contributor liable which usually
|
||||
does a good enough job of discouraging anyone who'd want to add a code they don't have the rights to into a codebase as
|
||||
they'll now know that they could be facing lawsuits after doing so.
|
||||
|
||||
I think it makes sense for projects to include this document and you generally shouldn't be afraid to sign it (so long
|
||||
as you're not submitting any stolen code, which you really shouldn't be doing even if there isn't a DCO in place). It
|
||||
gives the maintainers at least some level of certainty that the submitted code isn't stolen and unlike a CLA, it
|
||||
doesn't really do anything with your copyright to that project, it just confirms that you do in fact have the rights to
|
||||
that code, and you're authorize to permanently add it to this project's code-base.
|
||||
|
||||
{{< notice warning >}}
|
||||
While signing a DCO is generally quite safe, you're still legally signing a document, and as with any such document you
|
||||
NEED to make sure that you've thoroughly read through it. It's entirely possible that a repository claims to have a DCO
|
||||
document that you need to sign, when in fact it's also a CLA, and you might end up giving your rights away.
|
||||
{{< /notice >}}
|
||||
|
||||
## Other issues
|
||||
|
||||
Perhaps the biggest issue with either a DCO or a CLA for many people, is the fact that they're legal
|
||||
documents. This means a few things:
|
||||
|
||||
- You need to be of legal age (often 18+) to even be able to sign them.
|
||||
- You need to sign them with your personal details, often requiring your address, date of birth and full name, which
|
||||
you might not be comfortable with sharing, especially if you're trying to stay anonymous on the internet / to the
|
||||
project.
|
||||
- Complexity of the document: Many CLAs can span over several pages (though thankfully most are pretty short 1-2
|
||||
pages), making them hard and annoying to read, especially if they're filled with a lot of legal talk which can be
|
||||
hard to understand for non-lawyers.
|
155
content/posts/multi-licensing.md
Normal file
155
content/posts/multi-licensing.md
Normal file
|
@ -0,0 +1,155 @@
|
|||
---
|
||||
title: Using multiple licenses in a single code-base
|
||||
date: 2023-12-10
|
||||
tags: [programming, licensing]
|
||||
sources:
|
||||
- <https://opensource.stackexchange.com/questions/9851/can-different-parts-of-a-project-be-under-different-licenses>
|
||||
- <https://en.wikipedia.org/wiki/Multi-licensing>
|
||||
---
|
||||
|
||||
Dual-licensing, or multi-licensing is the practice of distributing source-code for a single project under two or more
|
||||
licenses. The general idea is pretty simple, however I've seen many people misunderstanding some important aspects
|
||||
when it comes to it. There's especially a lot of confusion when it comes to multi-licensing a repository with
|
||||
a copy-left license, so in this article, I wanted to shed some light onto this practice, to hopefully make you
|
||||
a bit more confident in understanding, and maybe even maintaining multi-licensed projects.
|
||||
|
||||
{{< notice note >}}
|
||||
This article assumes that you already know the basics of how software licensing works, and that you're familiar with
|
||||
the different types of licenses (permissive, (weak and strong) copy-left, public domain). If you aren't sure you're
|
||||
familiar enough with these topics, I'd strongly advice you to learn read about these before going through this article,
|
||||
as you will likely not end up understanding a lot of what I'm talking about here.
|
||||
|
||||
But don't worry, I actually have an article explaining these basics right here, [check it out!]({{< ref
|
||||
"posts/software-licenses" >}}).
|
||||
{{< /notice >}}
|
||||
|
||||
## Multiple licenses for the same code
|
||||
|
||||
Licensing the same code under 2 different licenses at once may seem like a pretty weird thing to do, after all, those
|
||||
licenses can each have different requirements and grant different permissions, and there's generally not much of a need
|
||||
to do this.
|
||||
|
||||
That said, there is one very common use-case for this, which is pretty important to know about. That is, providing a
|
||||
stricter (usually copy-left) license to the project for free to everyone, while also selling a less strict (usually
|
||||
permissive) license for a price. This then means that if companies would want to include this project in their
|
||||
proprietary code-bases, they'd need to pay to be given the less strict license, allowing this. In fact, this is often
|
||||
the main way (other than donations) for open-sourced projects to make money.
|
||||
|
||||
This less strict license is often one, which doesn't allow the company it was sold to to distribute the project's code
|
||||
any further, however it can allow that company to use the project and make edits to it's source code in-house, and
|
||||
distributing a modified binary without disclosing any source, and with their project remaining closed-sourced, which a
|
||||
copy-left license would not allow.
|
||||
|
||||
### How does multi-licensing even work?
|
||||
|
||||
I've already [touched on this]({{< ref "posts/software-licenses#how-are-these-licenses-enforced" >}}) in my other
|
||||
article. Generally, as the owner of a copyrightable work, you can do anything you want with it, however others can't
|
||||
really do much of anything, unless you give them a permission to. To do that, we use a software license, which might
|
||||
however limit condition those extra permissions behind some clauses (that's why you need to follow software licenses),
|
||||
these conditions can be things like mentioning the original source, stating changes, etc.
|
||||
|
||||
When you, as the copyright owner, give out 2 (or more) licenses with your project, anyone is free to pick either of
|
||||
those, however they do need to follow at least one, in it's entirety, so that they get the rights granted by it. People
|
||||
can't just pick some terms to follow from the first license, and other from the second license, since neither of these
|
||||
licenses would then be applicable, as some of the conditions weren't met, and so no copyright permissions are given to
|
||||
you from either of those licenses.
|
||||
|
||||
## Using different licenses for different parts of the project
|
||||
|
||||
This is a simpler case than the above, as we don't actually have any code licensed under multiple licenses at the same
|
||||
time, all we have is different chunks of the code-base being differently-licensed, and this is actually incredibly
|
||||
common.
|
||||
|
||||
You'll likely find chunks of open-sourced code thrown around in almost every bigger code-base, because it's simply
|
||||
easier to re-use the already written things, than to reinvent the wheel and make up our own versions of everything.
|
||||
Most commonly, this is seen through projects using software libraries. These libraries will likely be under some
|
||||
permissive or weak copy-left license, and they're being used in your project along with your own code, under whatever
|
||||
license you chose.
|
||||
|
||||
A slightly less common case would be directly using differently licensed code in your own code-base. When doing this,
|
||||
you often end up having files like `LICENSE-THIRD-PARTY` next to your `LICENSE` file, where you're stating all of the
|
||||
different licenses used in your project, and what parts of the project they apply to. (Note that some licenses require
|
||||
more things, such as also stating changes).
|
||||
|
||||
Another, but much less common case is when someone contributing to the project decides to contribute their code under a
|
||||
different license to the rest of the project. They can do this by mentioning their changed/added part in that
|
||||
`LICENSE-THIRD-PARTY` file, or by including a copyright header in the contributed file, or a bunch of other ways.
|
||||
(Though the maintainers might just end up refusing that pull request).
|
||||
|
||||
### Contributing to multi-licensed project
|
||||
|
||||
When you see a project that's dual-licensed, being publicly available under some copy-left license, but offering a
|
||||
permissive license for profit, you might be confused about how contributions to such a project could then work. After
|
||||
all, if you submitted your code under a copy-left license, there's no way the company could then sell a permissive
|
||||
license to that code, since well, you didn't give them a permissive license, and they wouldn't have the right to
|
||||
release your copy-left code under a permissive license.
|
||||
|
||||
This is ultimately gonna be up to the project's maintainers, and you'll often find some guide on it in the project
|
||||
docs, or in a file like `CONTRIBUTING.md`. However to understand how something like this is generally done, here's a
|
||||
few common methods these projects use to handle external contributions:
|
||||
|
||||
- Making all contributors sign a [CLA]({{< ref "posts/licensing-documents#contributors-license-agreement" >}}), which
|
||||
grants the company maintaining this project permissive rights, even though you submitted your code under a copy-left
|
||||
license, and anyone else would need to honor that license. This CLA can be pretty narrow in it's scope, only allowing
|
||||
the company to distribute your code under a permissive license, but only when they sell it under certain conditions,
|
||||
etc. However it can also be very extensive, where you will be asked to give the company complete rights over that
|
||||
code.
|
||||
- Making all contributors use a permissive license, with the company maintaining the project having their code licensed
|
||||
under a copy-left license. In many cases, the company code makes up the majority of the code-base, so you end up with
|
||||
a mostly copy-left licensed code, with bits of permissively licensed code utilized in it. (See [section
|
||||
below](#using-different-licenses-for-different-parts-of-the-project) about split licensing like this.)
|
||||
- Allowing contributors to pick whether they want to publish under permissive or copy-left license, keeping the code
|
||||
written by contributors who picked copy-left only available in the community/free version. However the company will
|
||||
usually try to keep version parity between these, or perhaps even having the payed permissive version include more
|
||||
features, so locking themselves from being able to get this code is pretty rare.
|
||||
|
||||
### Conflicting licenses
|
||||
|
||||
It is however important to say that if you do have a strong copy-left licensed code in your codebase, it's supposed to
|
||||
force you to use that same (or compatible) license everywhere in your project, right? So is it even possible to
|
||||
dual-license in cases like these? Yes!
|
||||
|
||||
Even though having copy-left code in your codebase will mean you have to distribute the rest of the project under the
|
||||
same license, it doesn't actually force that license to be the only one. Aha! So we could leave the original permissive
|
||||
license over the code in there, and on top of it add a compatible copy-left license, allowing us to use this copy-left
|
||||
code.
|
||||
|
||||
{{< notice warning >}}
|
||||
This will however still mean that when you'll be distributing your binary, since it will contain the chunk of copy-left
|
||||
code, you'll have to follow the license yourself, as that license it the only thing giving you the right to use that
|
||||
code, and so you'll have to for example always bundle the source code with that binary. So your project is pretty much
|
||||
copy-left anyway, but you will allow others to use the rest of your code in a permissive manner, as it's also
|
||||
licensed that way, and that license is usually much more friendly to others trying to use your code.
|
||||
{{< /notice >}}
|
||||
|
||||
Since this code was originally permissive, you cold also just relicense and become fully copy-left, as permissive
|
||||
licenses do allow that. That's also why you could "add" a copy-left license that now also applies to all of the
|
||||
originally permissive code.
|
||||
|
||||
The reason why you might want to use this approach instead of just relicensing and going pure copy-left is that you
|
||||
might eventually remove the copy-left chunk of code you used, and you could then go back to purely permissive license
|
||||
over your project again. However if you've changed to copy-left without dual-licensing, going back might be harder (see
|
||||
[this post about relicensing]({{< ref "posts/changing-license" >}}).
|
||||
|
||||
### Drawbacks
|
||||
|
||||
While multi-licensing can have some clear advantages to the project, as it allows it's monetization, it has it's
|
||||
disadvantages too, mainly:
|
||||
|
||||
- Potential confusion for users who may not fully understand the licensing options
|
||||
- Some contributors might be uncomfortable with the licensing terms, and with their code potentially being sold for
|
||||
profit, under a permissive license, making them avoid contributing completely.
|
||||
|
||||
### Example projects
|
||||
|
||||
- MongoDB: MongoDB is a popular open-source database system that uses dual-licensing. Its Community Edition is released
|
||||
under the GNU Affero General Public License (AGPL), while its Enterprise Edition is released under a proprietary
|
||||
license. This allows MongoDB to offer different features and support options to its users depending on their needs.
|
||||
- Qt: Qt is a cross-platform application development framework that uses dual-licensing. Its Community Edition is
|
||||
released under the GNU Lesser General Public License (LGPL), while its Commercial Edition is released under a
|
||||
proprietary license. This allows Qt to offer additional features and support to its commercial users while still
|
||||
maintaining an open-source version.
|
||||
- MySQL: MySQL is another popular open-source database system that uses dual-licensing. Its Community Edition is
|
||||
released under the GNU General Public License (GPL), while its Commercial Edition is released under a proprietary
|
||||
license. This allows MySQL to offer additional features and support to its commercial users while still maintaining
|
||||
an open-source version that can be freely used and modified.
|
|
@ -1,503 +1,420 @@
|
|||
---
|
||||
title: Software Licenses
|
||||
date: 2022-01-23
|
||||
tags: [programming]
|
||||
tags: [programming, licensing]
|
||||
changelog:
|
||||
2023-12-10:
|
||||
- "Rewrite many long and hard-to-read sections"
|
||||
- "Make use of the new notice boxes"
|
||||
- "Add licensing tag to keep posts about licensing together"
|
||||
- 'Move sections about CLA and DCO into a [standalone post]({{< ref "posts/licensing-documents" >}})'
|
||||
- 'Remove sections about changing license, in favor of a [standalone post]({{< ref "posts/changing-license" >}})'
|
||||
- 'Create new related [post about multi-licensing]({{< ref "posts/multi-licensing" >}}) (not previously mentioned at all)'
|
||||
---
|
||||
|
||||
I wanted to talk a bit about what are software licenses, what different types of these licenses are there and why are
|
||||
they really important to know about and to know which one you like the most. Choosing a wrong license for your projects
|
||||
may lead to your code being used by others in ways you don't like and depending on the license you chose, you may not
|
||||
even have a way to really do anything about it. It is also important so that you personally won't misuse any code.
|
||||
Stealing code is illegal and you may get in trouble for it, so it is always good to know what you can and can't do with
|
||||
the code of others.
|
||||
I've recently been coming across more and more developers which had no idea about the importance of software licensing,
|
||||
how it works and what options there even are. What's worse, this lack of knowledge means people often end up not
|
||||
choosing a license at all, thinking it means anyone can just use that code without limitations, when in fact no-one
|
||||
can.
|
||||
|
||||
## Why are licenses important
|
||||
I've always been very interested in software licenses, and have accumulated a lot of knowledge about them over time, so
|
||||
I've decided to share this knowledge and explain the basics of how licenses work, what enforces them, what different
|
||||
types of licenses we have, and perhaps most importantly, why you need to use a license if you want to maintain an
|
||||
open-source project. Along with just explanations, I've also included some of my personal thoughts on what I like to
|
||||
use.
|
||||
|
||||
Whenever you publish essentially anything, not just source code, you automatically gain copyright over that content (at
|
||||
least in most countries, there are some which don't really respect the copyright law, but that's very rare). This
|
||||
copyright imposes pretty big legal restrictions on that content. Essentially, this means that even though you may have
|
||||
decided to publish your code on a website like GitLab or GitHub, you only made it "source-available", not
|
||||
"open-sourced". This is because for a project to be considered open-sourced, it must meet some very specific criteria,
|
||||
namely, it needs an open-source license. The reason we don't call source-available code open-source is because even
|
||||
though the author of these projects as the copyright owner have published his work for anyone to look at, this doesn't
|
||||
give others the legal permission to actually re-use this code or alter it in any way.
|
||||
## Why even have a license?
|
||||
|
||||
This means that everybody who would be interested in improving this code, or making derivative works from it would
|
||||
actually be breaking this copyright law. Even if they made no changes to it, just creating a "fork" is already a
|
||||
violation of this law. Think of it as if you were keeping a copy of some movie on your machine, or even hosted on the
|
||||
internet somewhere without any permission from the company that made this movie. Obviously, you can't do that, it's
|
||||
illegal, and so is doing the same with source-code without a license from the copyright owner that allows it.
|
||||
Many people often assume that unlicensed code is free, and anyone can use it anywhere they want, because there is no
|
||||
license prohibiting that use. This is a big misconception which has lead to many lawsuits against small developers, who
|
||||
just didn't know any better.
|
||||
|
||||
Most people interested in making their source code available are actually also interested in getting others to use
|
||||
their project in their own source-code perhaps integrated as a library, or in any other way, and more importantly, they
|
||||
are looking for others to help them with their projects and contribute to them to make these projects better for
|
||||
everyone. This is precisely what an open-source license allows. There's countless amount of these licenses, and many of
|
||||
them are written by individuals without any legal knowledge, which may be dangerous. For that reason, the Free Software
|
||||
Foundation (FSF) has a curated list of [FSF approved
|
||||
licenses](https://software.fandom.com/wiki/List:FSF_approved_software_licenses) out of which all of them are guaranteed
|
||||
by the FSF to legally make sense and to indeed allow this source code sharing, so you should really only pick one of
|
||||
these licenses unless you have a good lawyer who can confirm that the license you decided to use, even though it wasn't
|
||||
on this list does make legal sense and is legally enforcible.
|
||||
The reason you can't use unlicensed code is simple, whenever you publish essentially anything, not just source code,
|
||||
you automatically gain copyright over that published work. This copyright then imposes some pretty big legal
|
||||
restrictions to others on this published content, including preventing you from simply using it in your own code.
|
||||
|
||||
But there are many types of licenses that allow others to use your code with different kinds of permissions and
|
||||
restrictions imposed on them while using this code, most commonly for example the need to mention the usage of the
|
||||
original project in a derivative work.
|
||||
Generally, this means that when publishing your code without a license you are the sole copyright holder and no one
|
||||
else has any rights to that code. We often call public code like this "source-available", instead of "open-source",
|
||||
because while people can look at the code, inspect it, perhaps even find and report issues about it, they can't use
|
||||
this code in almost any other way. This means that an unlicensed project can't have any (legal) contributors, because
|
||||
even the action of making a fork will be considered illegal, since the contributor will be copying your code without
|
||||
permission.
|
||||
|
||||
{{< notice note >}}
|
||||
The exact restrictions will vary from country to country, because each country can have their own copyright law, and
|
||||
there are even some countries which don't respect any form of international copyright law (but that's quite rare).
|
||||
|
||||
Even though in most of the cases the copyright law is pretty similar with only minor differences in punishments and
|
||||
enforcement, it does not mean that there can't be any differences. Because of that, the info above may not necessarily
|
||||
be true for every country, and as always, you should do your own research (or delegate it to a lawyer you trust).
|
||||
{{< /notice >}}
|
||||
|
||||
For these unlicensed repositories, it leads to losing many potential contributors, who would like to make some changes
|
||||
to this project to improve it, but decide not to, because by doing so, they would put themselves in danger of getting
|
||||
sued for copyright infringement. That's why whenever I see a project without a license, unless it was intentional, I
|
||||
open an issue, or try to otherwise contact the author to inform them about this.
|
||||
|
||||
{{< notice warning >}}
|
||||
The worst case scenario that you can get into with an unlicensed code-base is that people do in fact decide to
|
||||
contribute, and you accept that contribution.
|
||||
|
||||
Not only did the contributor just break the copyright law by modifying your code without legal permission, now that
|
||||
their unlicensed code is in your project, you can't legally modify it either. So it's not just the contributor who may
|
||||
get in trouble, it's also you who the contributor can now press charges against for violation of their copyrighted
|
||||
code.
|
||||
|
||||
You as the author can't even go and add a license now, since there is code from others that you don't own, and so you
|
||||
can't simply relicense them. Solving this could then be very difficult, see my: [relicensing post]({{< ref
|
||||
"posts/changing-license#unintentionally-proprietary" >}}) for more details.
|
||||
|
||||
This is why you should steer far away from any unlicensed projects, and make absolutely certain that your project
|
||||
always have a license, or if they should be proprietary, make sure to explicitly mention that in your `README` file,
|
||||
and don't accept any contributions.
|
||||
{{< /notice >}}
|
||||
|
||||
## How can a license make code open-sourced
|
||||
|
||||
In order to make your source code classify as "open-source", it needs to be made freely available for anyone to copy
|
||||
and modify, without the contributors worrying that they might in legal trouble just for trying to improve the project.
|
||||
|
||||
To give someone these rights, you can use a license which specifies that you, as the owner of the copyright to your
|
||||
code, freely give out certain rights to everyone. This license is here to essentially "weaken" your copyright in that
|
||||
you reduce the restrictions it generally imposes on others, because they were freely given out through the terms of
|
||||
your software license.
|
||||
|
||||
These licenses can then also specify certain conditions, which limit when can the code be used by others. Picking a
|
||||
good license for your projects then means understanding what freedoms does the license give out, and under what
|
||||
conditions.
|
||||
|
||||
## How are these licenses enforced
|
||||
|
||||
It is important to understand how exactly the software licenses really work. How does simply having a text file with
|
||||
some legal gibberish allow others to use that project and contribute to it? After all, they didn't need to legally sign
|
||||
anything, so why should they be forced to follow that license's terms?
|
||||
|
||||
Well, the answer to that is simple, you don't need to follow the terms. The only issue is that if you decide not to,
|
||||
you lose the only thing giving you the extended copyright permissions to use that code, so while you don't have to
|
||||
follow the license, if you don't, you won't be able to use the code. You can think of it as the copyright over that
|
||||
code itself being extended to be usable by anyone who meets certain conditions. So it extends over that category of
|
||||
people. If you're in that category, you can use the code, if you're not, you don't have those right.
|
||||
|
||||
However, in some cases, you might have a different license given to you by the copyright holder, or maybe you are the
|
||||
copyright owner (copyright ownership can even be transferred, and it's often sold), in which case, you already have
|
||||
these rights even without following the license, so you can actually completely ignore it.
|
||||
|
||||
It's actually very common for many projects to be licensed under a stricter license for general usage, that doesn't
|
||||
allow using this code in closed-sourced projects, with the authors selling a more permissive license for profit to
|
||||
corporations which do need to use this project in their proprietary code bases. In many cases, this is the main way
|
||||
these open-sourced projects make money. I explain this a bit further in my [post about multi-licensing]({{< ref
|
||||
"posts/multi-licensing" >}})
|
||||
|
||||
So essentially, licenses aren't enforced, nobody will force you to follow them, you just need to do so if you want to
|
||||
gain the rights that license grants you.
|
||||
|
||||
## Contributing to a licensed project
|
||||
|
||||
A question that you might have now is about how will your code be licensed if you contribute to a project. The answer
|
||||
to this may be pretty obvious, but it is important to explain nevertheless.
|
||||
|
||||
Basically, if you pick a repository under say a GPL v3 license, fork it, change some things and make a pull-request
|
||||
back to the original repo, you're offering this code to that project under the same (GPL v3) license. This is because
|
||||
the LICENSE file in that project generally applies to the entire project, and you've added some code to a project with
|
||||
this LICENSE file, meaning just as if you added this file to your own project, you've contributed to this project and
|
||||
hence offering your code to it under this license.
|
||||
|
||||
However this isn't the only way to do it. There may be cases when you want to explicitly state that the code you've
|
||||
contributed is actually under some other license, like MIT for example. To do that, projects generally use another
|
||||
file, like `LICENSE-THIRD-PARTY`, where all of the differently licensed code chunks are stated, along with the
|
||||
copyright holder (usually a name and an email) and the full-text of this differing license.
|
||||
|
||||
However you can do this in different ways, all that's necessary is to clearly mark that the code you've added is under
|
||||
a different license, the way to do so is more or less just a convention (although some licenses to have specific
|
||||
requirements on where they need to be mentioned, be careful with those). Another pretty common way to do it is to add a
|
||||
comment at the start or end of the source code file containing the fulltext of the license, or a reference to the
|
||||
license.
|
||||
|
||||
There's a lot of reasons why you may want to contribute to a project under a different license, for example it might be
|
||||
that the code you're contributing isn't yours, but is instead from another project, with a license that requires you to
|
||||
do something specific. However it could also just be personal preference, maybe you like another license, and you're
|
||||
only willing to give out your code under that license, not under the one the project uses everywhere else.
|
||||
|
||||
## Available licenses
|
||||
|
||||
There are countless amount of licenses, each with different set of conditions and different rights they give out. As an
|
||||
author of your project, it is up to you to pick a license which best suits your needs, or if you can't find a license
|
||||
you like, perhaps even write your own.
|
||||
|
||||
But know that picking some random license, which could've just been written by some individual without any legal
|
||||
knowledge may be dangerous, because of the potential for some legal loop-holes which it may contain. For that reason,
|
||||
if you're making your own license, or picking one which isn't commonly used, you should always consult a lawyer.
|
||||
Usually, you will likely just want to stick to an already well-established license, verified by thousands, if not
|
||||
millions of users.
|
||||
|
||||
### Open-Source software licenses
|
||||
|
||||
I've mentioned before that the distinction between "source-available" and "open-sourced" code was having a license that
|
||||
allows the user to do some additional things (like modifying the code and using it in different projects). However it's
|
||||
not just as simple as having any license that does this. It's technically up to anyone to make their own mind about
|
||||
what they'd consider open-sourced, but it's probably fair to say that if your license is discriminating against some
|
||||
group of people, most probably wouldn't consider it as open-source license.
|
||||
|
||||
To address this, an organization called the "Open Source Initiative" (OSI) came up with their list of approved
|
||||
licenses, which were fact-checked by their lawyers and are commonly used by tons of people already. You can find this
|
||||
curated list of OSI-Approved licenses [here](https://opensource.org/licenses). All of these are generally considered to
|
||||
be open-sourced by almost everyone.
|
||||
|
||||
### Free software licenses
|
||||
|
||||
> “Free software” means software that respects users' freedom and community. Roughly, it means that **the users have
|
||||
> the freedom to run, copy, distribute, study, change and improve the software**. Thus, “free software” is a matter of
|
||||
> liberty, not price. To understand the concept, you should think of “free” as in “free speech,” not as in “free beer.”
|
||||
> We sometimes call it “libre software,” borrowing the French or Spanish word for “free” as in freedom, to show we do
|
||||
> not mean the software is gratis.
|
||||
>
|
||||
> -- [Explanation of "free software" by the Free Software Foundation](https://www.gnu.org/philosophy/free-sw.html)
|
||||
|
||||
As seen in the quote above, free software is essentially about software that has a license which guarantees you certain
|
||||
freedoms. Unlike the simple "open-source" software, which is merely about a project having a license which allows
|
||||
others to fearlessly contribute to it, "free" software extends that and also guarantees contributors the freedoms
|
||||
mentioned above.
|
||||
|
||||
Really, all you need in an open-sourced license is the ability for the contributor to change the code and pull-request
|
||||
it back. The rights to distribute the software on their own, use this code in a different project, or do a bunch of
|
||||
other things aren't all that necessary for pure open-source projects. So, to signify that these freedoms are being
|
||||
respected, we often call such projects "free and open-sourced", instead of just "open-sourced".
|
||||
|
||||
To easily recognize which licenses do follow this ideology, the Free Software Foundation (FSF) also has [their own list
|
||||
of licenses](https://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses) that they confirm do meets these
|
||||
guarantees.
|
||||
|
||||
## License types
|
||||
|
||||
Learning about different licenses may be a bit confusing at first, and I would always suggest to do your own research
|
||||
as I am not a lawyer and I do not offer any legal advice here. All I will do is try to explain the basic categories of
|
||||
the open-source licences and explain what these categories represent, but once again, don't just blindly trust some
|
||||
random guy on the internet, do your own research before picking a license and ensure it will really be exactly what you
|
||||
want it to be.
|
||||
Because there are thousands of very different open source licenses, we split them into several categories, which
|
||||
describe the main goal of the license. While the individual licenses in the same category can still be quite different,
|
||||
these differences are mostly minor details.
|
||||
|
||||
This categorization allows us to only remember what category a license is, and already know with fairly good confidence
|
||||
what the general guidelines of that license will be. Knowing what license category you prefer can save you a lot of
|
||||
time in finding a license you like, since you'll just need to look for licenses your preferred category.
|
||||
|
||||
### Copy-Left licenses
|
||||
|
||||
These licenses allow others to use your code, whether it means building a derivative project that can do certain things
|
||||
differently from your original code, but still uses a lot of the original code-base, or just utilizing a few snippets
|
||||
of your code-base for example just a single function, or even just using this project as a library, being integrated in
|
||||
some bigger scoped project which needs the logic of your project internally.
|
||||
The main point of copy-left licenses is to ensure that the code licensed under them will never go closed-sourced, and
|
||||
will always remain free and accessible to anyone.
|
||||
|
||||
The main point of this type of licenses is that they require all projects using work that's licensed under them to also
|
||||
use that same copy-left license. This is called propagating the copy-left. This basically means that if some other
|
||||
project would like to include some part of your code into their code-base, no matter how big the part is, or if it's
|
||||
the whole project, used as a library, they would need to license their code under the same license that your original
|
||||
code code has, or at least a compatible license (propagate the copy-left).
|
||||
To achieve this, copy-left licenses require everyone who would want to use the code licensed under them to publish
|
||||
their code under the same (or a compatible) license. This basically means that if some other project would like to use
|
||||
a part of copy-left licensed code, that other project would need to itself become entirely copy-left. We often call
|
||||
this "propagating the copy-left".
|
||||
|
||||
This behavior of copy-left licenses propagating themselves and prohibiting being licensed under any other
|
||||
(non-compatible) license is called forbidding sublicensing. Some copy-left licenses do actually allow you to change the
|
||||
license, but only to a selection of a few other copy-left licenses with similar terms, even though they wouldn't
|
||||
necessarily be "compatible" licenses legally, as they may enforce different set of rules, they can still include a
|
||||
clause allowing for such sublicensing. This is often done to allow for easily updating the license to a new version of
|
||||
it. As without a clause like that, changing licenses may get tricky, I will talk about this in another section later as
|
||||
it can be a pretty involved process. However be careful with this as even though one license may have a clause allowing
|
||||
you to sublicense your content under another, that other license may not have the same clause allowing you to go back.
|
||||
|
||||
Usually, if your project is compilable into a single executable file (or multiple executables) copy-left licenses can
|
||||
require shipping the license and the entire source-code (or at least the parts covered by this license), or at least a
|
||||
link to a website on which this source-code is hosted along with that executable. This ensures that there is no way the
|
||||
code could go closed-source, because it can't even be shipped without the source-code.
|
||||
|
||||
Note that they don't however usually forbid the software from being commercialized and sold for a profit, but whenever
|
||||
someone would decide to buy this software, they would receive it along with it's source-code and the copy-left license,
|
||||
and after that they could simply make their own derivative works and distribute those for free if they wanted to, since
|
||||
the license allows that. This makes it really easy for anyone to just buy the software and then distribute the exact
|
||||
same copy of that source-code for free to anyone, making it mostly pointless to even sell it in the first place,
|
||||
however it is important to mention that it's possible nevertheless.
|
||||
|
||||
What's perhaps a bit unintuitive though is the fact that it actually is possible for a copy-left licensed software to
|
||||
be kept private for example just to a company that's using that software internally. However keeping it private is
|
||||
quite difficult as by being copy-left, the source code and the license will have to be shipped with the executable,
|
||||
even internally. This means that any employee could just take a look at that source code and decide to publish it as
|
||||
the license allows them to do that. Another way to keep a copy-left licensed code private would be to just use it
|
||||
personally, because the code is available to you when you made the executable, you're following the license and yet
|
||||
you've just made a private copy-left licensed code, though that's only the case as long as you don't distribute it, or
|
||||
if you do, as long as that person doesn't decide to release it publicly, as the license shipped with that software
|
||||
allows them to do that. Although there are actually some licenses which prohibit even something like this, those
|
||||
requirements make these licenses really hard to follow so there aren't that many people actually using them.
|
||||
Usually, if your project is compilable into a single executable file (or multiple executables) copy-left licenses will
|
||||
also require shipping the license and the entire source-code that was used to compile it (or at least a link to a
|
||||
website where this source-code and license's fulltext is accessible, which is often done because the source code might
|
||||
be pretty big). This ensures that anyone wanting to use this binary will always have access to the source code it was
|
||||
made from, and are free to change this code and to then use their own modified versions if they want to (this is often
|
||||
called creating "derivatives"). For example they might make a version without any intrusive telemetry.
|
||||
|
||||
There can be many little caveats to these licenses and you should always make sure you understand what that license is
|
||||
allowing/denying before you decide to use them.
|
||||
|
||||
The most popular copy-left license is the GNU General Public License version 3 (GPL v3), but version 2 is also still
|
||||
quite popular. Another a bit less commonly used is the Mozilla Public License (MPL).
|
||||
quite popular.
|
||||
|
||||
### Permissive licenses
|
||||
|
||||
Similarly to copy-left licenses, this type of licenses allows usage of the original code in almost any way
|
||||
(derivatives, using small chunks, using code as library, ...), however unlike licenses in the copy-left category,
|
||||
permissive licenses do allow almost any form of sublicensing.
|
||||
Similarly to copy-left licenses, this type of license allows usage of the original code in almost any way (derivatives,
|
||||
using small chunks, using code as library, ...), however unlike with copy-left, permissive licenses will allow other
|
||||
projects using the code under them to be relicensed under a completely different license, we call this allowing
|
||||
"sublicensing".
|
||||
|
||||
This said, even though sublicensing may be allowed, it doesn't mean there aren't any conditions which may need to be
|
||||
met before the code can be sublicensed. Most notably the requirement to mention the original copyright holder(s) and
|
||||
perhaps to ensure the original author won't be held liable for any issues with the source or clauses which can forbid
|
||||
things like patenting.
|
||||
However even though these licenses are generally very "weak", in that they allow the code to be used very easily and
|
||||
without many restrictions, it doesn't mean there can't be any extra conditions to gain these rights. One example of a
|
||||
very common requirement in permissive licenses is to mention the original copyright holder(s), or a requirement that
|
||||
prevents making software patents, requires listing all changes made to the original code, or various other things.
|
||||
|
||||
This means that permissive licenses give others a lot more freedom because they allow changing the license of a project
|
||||
that's using parts of your code, but this means that anybody could simply take your entire project, change it a bit and
|
||||
close-source it, while just respecting the terms of your license (most likely just being the original author mention),
|
||||
after that the person/company utilizing your code could easily release the product as a payed software without having
|
||||
to show what the code is actually doing at all. And since the code is now closed-sourced they could even decide to add
|
||||
all kinds of trackers constantly sending everything you do with that software to them and perhaps even some nefarious
|
||||
things, such as integrating a full-blown crypto-currency miner that's running in the background at all times while
|
||||
you're using this project.
|
||||
This means that permissive licenses give others a lot more freedom because they allow anyone to use your code under any
|
||||
license they like, usually even a proprietary one. This could then mean that someone might simply take your entire
|
||||
project, and make it close-sourced. Perhaps with some added features, this version can then be sold for profit.
|
||||
|
||||
Things like these are unavoidable with a license allowing this much freedom, and even though it may require the project
|
||||
to follow some guidelines, they usually aren't that strict and if it's just mentioning the source, this mention can
|
||||
easily be lost along with thousands of other mentions because the project may rely on many other things too.
|
||||
|
||||
However the proponents of this license like this fact because even though it may mean their software will be used along
|
||||
with these non-privacy respecting things added on top, at least it means that a big part of this new project is
|
||||
open-sourced and it may even bring the companies/people using this open-sourced software to contribute back to it,
|
||||
therefore helping it to grow and improve the features it supports. While they could do this on their own in their
|
||||
versions of that software, they usually don't do that simply because it gives them more code to maintain, while
|
||||
contributing it to an open-sourced project that they will then use will mean others will maintain that code for them,
|
||||
whether that's other people, or even other companies following the same logic.
|
||||
However the proponents of this license like this fact because even though it may mean their software will be used in
|
||||
closed-sourced repositories, it at least means that there is a big chunk of open code in these projects, promoting the
|
||||
open-source idea, rather than having the companies write their own internal tooling resulting in existence of even more
|
||||
proprietary code. A big advantage here is also that companies using this code often end up contributing to these open
|
||||
repositories, hence helping them to grow.
|
||||
|
||||
The most commonly used permissive licenses are the MIT License and the Apache 2.0 License. Another really popular
|
||||
set of licenses are the BSD licenses, most notably the BSD 2-Clause license.
|
||||
|
||||
### Public domain licenses
|
||||
|
||||
There are also the so called "public domain licenses", which are actually technically a subtype of permissive licenses,
|
||||
however when we talk about permissive licenses, we generally don't really refer to the public domain ones, even though
|
||||
they technically meet the definition of a permissive license. This is why I separated this category since it's quite
|
||||
different from the general permissive licenses.
|
||||
There are also the so called "public domain licenses", which are actually a subcategory of permissive licenses, however
|
||||
when we talk about permissive licenses, we generally don't mean the public domain ones, even though they do technically
|
||||
meet the definition of a permissive license. This is why I separated this category as it's really quite different from
|
||||
what people would expect from usual permissive licenses.
|
||||
|
||||
Public domain licenses essentially strip the copyright away completely. This basically gives everybody the rights to do
|
||||
pretty much anything with the code. They don't impose any extra restrictions (such as mentioning the original
|
||||
source/author) and they obviously allow sublicensing.
|
||||
Public domain licenses essentially strip the copyright away completely. They don't impose any extra restrictions (such
|
||||
as requirement to mention the author) at all. This means giving everyone the right to do absolutely anything with that
|
||||
code, and anyone using them can essentially consider themselves as the owners of that works.
|
||||
|
||||
Depending on the country you're in, these licenses may act a bit differently as not all countries allow "removing" the
|
||||
copyright from your work, instead you can "assign" the copyright to the public domain on an equivalent of that in other
|
||||
countries. This could basically mean that everyone is the copyright holder of said work giving everyone the rights to
|
||||
do absolutely anything with that work as they're basically considered as the owners of that work.
|
||||
copyright from your work, instead you can "assign" the copyright to the public domain, or give all rights to everyone
|
||||
without imposing any restrictions.
|
||||
|
||||
The most notable public domain license is the "Unlicense" license.
|
||||
The most notable public domain licenses are: "Unlicense" license, Creative Commons CC0 1.0 Universal, and WTFPL.
|
||||
|
||||
### Strong and weak copy-left
|
||||
|
||||
These are subtypes of the wide copy-left licenses category. I didn't initially include it in the copy-left section
|
||||
because it was already quite big and I wanted to just describe the category itself before getting to some specifics,
|
||||
also I wanted to describe the permissive licenses before getting to the definition of these subcategories as it does
|
||||
rely on this definition.
|
||||
Coming back to copy-left licenses, they're actually split into 2 sub-categories, which further define how strict they
|
||||
are. The main problem with copy-left is that people who like permissive licenses will often simply refuse to use
|
||||
copy-left projects, because they don't want to be forced to also license all of the code in their project under a
|
||||
copy-left license. For that reason, copy-left licenses needed a bit of a change, adding another category.
|
||||
|
||||
Basically, the "strength" of a copyleft license is determined by the extent of the license's provisions on the
|
||||
different kinds of derivative works. This sounds complex, but the difference isn't actually that hard to understand.
|
||||
Simply the "stronger" the copy-left license is, the less exceptions are there for a derivative work to not inherit that
|
||||
copyleft and with it the requirement of propagating the license.
|
||||
This new weaker form of copy-left is essentially the same as normal copy-left, but with some exceptions that allow
|
||||
using the code as if it was permissively licensed. The most common case for this is an exception for using the
|
||||
copy-left licensed software as a library. This means that code licensed like this can be used in any other projects
|
||||
under a weaker set of rules (essentially under permissive rules), when the project is used as a library dependency.
|
||||
This would then even allow use in closed-sourced projects. However this weaker ruleset only applies if the project is
|
||||
being used as a library. If you wanted to make an actual fork of the project, or use some part of the source-code
|
||||
directly in your code-base, this exception doesn't apply and the copy-left still needs to be propagated. The more
|
||||
exceptions to this there are, the "weaker" that copy-left license is considered.
|
||||
|
||||
In other words, the "weak" copy-left licenses are those where there are exceptions to inheriting a copy-left and there
|
||||
can therefore be some derivative works made which won't actually fall under the copy-left guidelines of that license.
|
||||
For these derivatives, the license actually becomes permissive and they can be sublicensed, and even become closed. As
|
||||
opposed to "strong" copy-left licenses, which don't carry any exceptions like these and every single derivative work,
|
||||
no matter how little of the original project's code was used, or in what manner it was used, will inherit the copy-left
|
||||
and will be forced to be license under the same (or compatible) copy-left license.
|
||||
With this change, to distinguish between these licenses, original copy-left was classified as "strong copy-left", and
|
||||
this new weaker form of copy-left licenses was called "weak copy-left".
|
||||
|
||||
This makes weak copy-left licenses somewhat of a compromise between strong copy-left and permissive licenses where you
|
||||
may want to allow sublicensing if a derivative meets some criteria, such as if someone just wants to use your work as a
|
||||
library, in which case they could sublicense and use your code as if it were under a permissive license, but in other
|
||||
cases, such as someone wanting to make a full-fledged alternative where they're going to be making changes to your code
|
||||
and building on it, they will be required to inherit the copy-left and use the same license.
|
||||
{{< notice warning >}}
|
||||
Weak copy-left licenses could end up causing some legal "gray zones" when that copy-left license isn't clear about when
|
||||
the copy-left should propagate, and when it can be permissive, and it is important to say that these **weak copy-left
|
||||
licenses weren't yet tested in court**.
|
||||
|
||||
Another way a weak copy-left can behave is a file-based copyleft. This means that any file containing copy-left code
|
||||
will inherit that copy-left and will therefore need to be licensed and distributed accordingly to the terms of that
|
||||
license, however your derivative project may only include one file out of thousands in a codebase under this weak
|
||||
copy-left license, this would mean instead of you having to license the entire project as copy-left, you'd only need to
|
||||
license that file(s) in which that copy-left code is present, everything else can still stay permissive, or even closed
|
||||
sourced in this project.
|
||||
Nevertheless, many people and companies do use them and they're generally trusted to be quite safe (that is, if you
|
||||
pick one that has been checked by a lawyer and is used commonly, ideally one of those listed in the OSI or FSF's
|
||||
approved list of licenses).
|
||||
{{< /notice >}}
|
||||
|
||||
Do note that this could end up causing some legal "gray zones" when that copy-left license isn't clear about when the
|
||||
copy-left should propagate, and when it can be permissive, and it is important to say that these weak copy-left
|
||||
licenses weren't yet tested in court.
|
||||
#### Most commonly used strong copyleft licenses
|
||||
|
||||
- The most commonly used weak copyleft licenses are the
|
||||
- **Lesser General Public License (LGPL):** Libraries are treated permissively, major derivatives inherit copy-left
|
||||
- **Mozilla Public License (MPL):** File-based copy-left that ensures all of the copy-left licensed parts remain
|
||||
copy-left licensed, even though they could end up being a part of a proprietary closed-sourced project. It also
|
||||
allows the project's contributors to terminate the license for their copyright code only (the code that was
|
||||
contributed by this author under this license) by sending a written notice to the projects using this MPLed code,
|
||||
but only to the parts of the MPLed code copyrighted by that author. This license treats files as the boundaries
|
||||
between MPL-licensed and proprietary parts, meaning either all code in a file will be MPL licensed, or none of it
|
||||
will. (i.e. using just a bit of MPLed code in a file makes the whole file fall under MPL).
|
||||
- The most commonly used strong copyleft licenses are the
|
||||
- **General Public license (GPL):** The license that defined copy-left
|
||||
- **Affero General Public License (AGPL):** Extension of the GPL (an even stronger copy-left) that enforces source code
|
||||
publishing even for a "service" use case (I won't get into details about that here, look it up if you're interested)
|
||||
- **Sybase Open Watcom Public License:** One of the strongest copy-left licenses which prevents the "private usage"
|
||||
loophole of the GPL (which allows source-code modification when you "deploy" the software for private use only,
|
||||
even for testing while developing a project covered by this license.) and requires source code publishing in any
|
||||
use-case. However this can be way too limiting and basically makes it really hard to even develop the software
|
||||
covered by it because each time an executable is built, the srouce-code has to be made available, which lead to
|
||||
FSF not accepting this license as "free software license". Therefore usage of it, while making the project
|
||||
"open-sourced", does not make the project a "free and open-sourced" project.
|
||||
- **Design Science License:** The interesting thing about this license is that it can apply to any work, not just
|
||||
software/documentation, but also literature, artworks, music, ... (however it became irrelevant after the creation
|
||||
of "creative commons" licenses.)
|
||||
- **General Public license (GPL):** The license that defined copy-left.
|
||||
- **Affero General Public License (AGPL):** Extension of the GPL (an even stronger copy-left) that enforces source
|
||||
code publishing even for a "service" use case (I won't get into details about that here, look it up if you're
|
||||
interested).
|
||||
- **Sybase Open Watcom Public License:** One of the strongest copy-left licenses which prevents the "private usage"
|
||||
loophole of the GPL (which allows source-code modification when you "deploy" the software for private use only,
|
||||
even for testing while developing a project covered by this license) and requires source code publishing in any
|
||||
use-case. However this can be way too limiting and basically makes it really hard to even develop the software
|
||||
covered by it because each time an executable is built, the srouce-code has to be made available, which lead to
|
||||
FSF not accepting this license as "free software license".
|
||||
- **Design Science License:** The interesting thing about this license is that it can apply to any work, not just
|
||||
software/documentation, but also literature, artworks, music, ..., however it became irrelevant after the
|
||||
creation of "creative commons" licenses.
|
||||
|
||||
## How are these licenses enforced
|
||||
#### Most commonly used weak copyleft licenses
|
||||
|
||||
It is important to understand how exactly the software licenses actually work. How does simply having a text file with
|
||||
some legal gibberish allow others to use that project and contribute to it?
|
||||
|
||||
Essentially, these licenses extend the copyright of the person who submitted some code under that license. By doing so,
|
||||
they and allow using of said code in other places, it's modifications, and other things, depending on the actual
|
||||
license. But that license is usually the only thing that give others the right to use that code in these ways.
|
||||
|
||||
These licenses are therefore able to enforce themselves, because the moment you violate the terms of that license, it
|
||||
no longer applies to you. At that point, you still have the copyright law to consider. It's entirely possible that you
|
||||
could've had a permission from the original author to use the code in the way you did, even if it isn't following that
|
||||
project's license. This is because that person explicitly gave you some rights to do certain things with their
|
||||
copyrighted work, so basically, they extended their copyright of that work to give you some additional rights. But if
|
||||
this agreement also didn't happen and you were in violation of the main license, you don't have any other legal
|
||||
permission allowing you to use the copyrighted work, which puts you in violation of the copyright law.
|
||||
|
||||
Whenever you're in such copyright law violation, the significance of such violation will depend on where you live. Some
|
||||
countries don't even respect the copyright law, allowing you to use whatever code you want as there's no law to violate
|
||||
if your country doesn't actually have the copyright law at all, however most developed countries do respect copyright.
|
||||
If you live in one of the copyright-respecting countries, you'll just need to learn how they handle copyright
|
||||
violations. It may be the case that before any legal case can be made, the author must send you a copyright violation
|
||||
letter (so called: `ciese and desist letter`). However if your country doesn't require that, you may simply find
|
||||
yourself facing a lawsuit for copyright infringement without any prior warning.
|
||||
|
||||
As you can see, you can't actually "violate" a software license, rather if you do not meet the conditions of said
|
||||
license, then the license doesn't apply to you and you do not acquire the permissions granted by it. Unless you've
|
||||
acquired these permissions by some other means, you are violating copyright, but you aren't violating the actual
|
||||
software license as it isn't a license that you've signed or anything like that, it's just something giving you the
|
||||
possibility to use that work, if you follow it. That said though, in practice you often hear about a license being
|
||||
"violated", but what's really meant by that is that since you didn't meet the conditions of that license, hence you're
|
||||
violating copyright.
|
||||
|
||||
So remember, a software license can only ever give the recipient of the creative works additional rights, it can never
|
||||
takes away rights.
|
||||
- **Lesser General Public License (LGPL):** Libraries are treated permissively, major derivatives and direct source
|
||||
usage forces inheriting copy-left.
|
||||
- **Adaptive Public License (APL):** An incredibly detailed license which provides a template for users to slightly
|
||||
modify it to their exact needs.
|
||||
- **Mozilla Public License (MPL):** Uses files as the boundaries between MPL-licensed, and proprietary/otherwise
|
||||
licensed parts. If a file contains MPL code, copy-left is propagated to that file only.
|
||||
- **Eclipse Public License (EPL):** This license is made to be very similar to GPL, but with the intention of being
|
||||
more business-friendly, by allowing to link code under under it to proprietary applications, and licensing binaries
|
||||
under a proprietary license, as long as the source code is available under EPL.
|
||||
|
||||
## Picking your license
|
||||
|
||||
While you aren't required to add a license of any kind to any of your source-available projects, it's a bit weird to
|
||||
have a project's source code available without any license giving others rights to actually improve it and use it. At
|
||||
the moment, all of the contributors to such projects are actually breaking the copyright law which isn't ideal (unless
|
||||
they live in a country which doesn't respect copyright, but again, that's very rare). Even though I'm sure most people
|
||||
with projects like these don't actually have the intention to sue it's contributors, authors of these projects
|
||||
technically could. That's a bit unexpected for the contributors and it could make contributing to projects like these a
|
||||
bit scary, and it would certainly discourage many people from not just contributing, but possibly also using this
|
||||
project at all.
|
||||
Whenever you make a new project, you should also figure out how will you want to license it category-wise. Should it be
|
||||
permissive? Should it be copy-left? Is it a library? If so, should it be weak copyleft? So on and so forth. After you
|
||||
know that, you should start considering the possible licenses in the category of your choosing, so for example if you
|
||||
ended up on strong copy-left, should it be GPL-3, GPL-2, AGPL, or maybe something else entirely.
|
||||
|
||||
**Some great websites:**
|
||||
- There is a [page from GitHub](https://choosealicense.com/) that may help you pick the correct license for your
|
||||
project.
|
||||
- Another website to help you pick a license is the [license picker from heathermeeker](https://heathermeeker.com/open-source-license-picker/).
|
||||
- You can also check out a post in the GitHub docs about licensing projects
|
||||
[here](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository)
|
||||
- Yet another wonderful site you should check out is <https://tldrlegal.com>, which can quickly show you the details about
|
||||
what a given license requires from others when they use your code, and what rights it gives them.
|
||||
{{< notice tip >}}
|
||||
If you need some help on picking the license, check out some of these pages, which are made to simplify this process a
|
||||
bit:
|
||||
|
||||
- [The healthermeeker's license picker](https://heathermeeker.com/open-source-license-picker/) gives you a bunch of
|
||||
questions about your project, and shows you the license you'll want based on your answers
|
||||
- [TLDRLegal](https://tldrlegal.com) allows you to quickly see some key points about a given license, without the need
|
||||
to read the entire license's full-text.
|
||||
- [Choosealicense](https://choosealicense.com/licenses/) is a webpage made by GitHub, which can show you points about
|
||||
some of the most commonly used licenses helping you pick the right one.
|
||||
{{< /notice >}}
|
||||
|
||||
{{< notice warning >}}
|
||||
If you want to add a license to an existing project, which didn't have any license before, or if you want to change the
|
||||
license, depending on many factors, you may face some difficulties. To understand how to go about this, check out [my
|
||||
other post]({{< ref "posts/changing-license" >}}) that talks specifically about changing licenses, or adding licenses
|
||||
to previously unlicensed code.
|
||||
{{< /notice >}}
|
||||
|
||||
## Limitations
|
||||
|
||||
Before picking your license, you should be aware of the limitations it may create for your project. While you can
|
||||
obviously pick any license for your projects whatsoever (including no license at all), if you pick a permissive
|
||||
license, you immediately loose the right to use any copy-left licensed code (unless it's a weak copy-left and you're in
|
||||
the exception). It is therefore very important to know your dependencies and the licenses of the code you're using in
|
||||
your codebase directly.
|
||||
|
||||
You as the author of that project do need to follow the licenses of the other projects you're using in your project.
|
||||
Even with permissive licenses, there may be certain terms you need to follow in order to meet the conditions of that
|
||||
license and be allowed to use the code from that project. Most commonly this will be the requirement to mention the
|
||||
usage of said code/mention it's copyright holder/mention the original source repository/...
|
||||
license, you immediately loose the right to use any copy-left licensed code _(unless it's a weak copy-left and you're
|
||||
in the exception, or unless you [relicense]({{< ref "posts/changing-license" >}}))_. It is therefore very important to
|
||||
know the licenses of your dependencies and of the code you're going to be using in the codebase directly.
|
||||
|
||||
In vast majority of cases, if you're using a packaging system (such as pip for python, npm for node, cargo for rust,
|
||||
...) these will create dependency listings, which will often fulfill the requirement and it's possible to get it's
|
||||
source url because of that package manager. Luckily, most libraries are generously licensed under weak copy-left or
|
||||
permissive licenses, and they don't really have any other terms that would make things more complicated apart from just
|
||||
a simple mention, even if that's just done by the package manager in the project's dependencies. However it may not
|
||||
always be the case, and for those cases, you may need to do something special apart from/other than just a mention like
|
||||
this to fulfill that license, and if you aren't willing to do that, you simply can't use that project.
|
||||
|
||||
Even if you're licensed under a copy-left license and you're using some copy-left repositories code licensed under the
|
||||
exact same license, just having that license may not be enough to fulfill it's terms, in fact in most of the cases it
|
||||
won't be. You will often need to mention the original source (again, if it's a dependency, a simple listing may be
|
||||
enough for this), not make any software patents with that license, not use the project's trademark, state the changes
|
||||
from the original project, etc. So no matter if your licenses are permissive or copy-left, there may be other terms and
|
||||
you need to make sure they're followed, otherwise you may be violating that license.
|
||||
|
||||
To avoid things from getting too messy, you may want to make a file that will explicitly mention which parts of your
|
||||
codebase aren't actually licensed under the main license, but instead belong to someone else and are licensed
|
||||
differently. In fact some licenses even require your project to have such a file. In there, you'll often want to
|
||||
include full text of that other license and then below (or above) the copyright holders/links to original sources/other
|
||||
stuff which said license requires. This can make it a lot easier to keep track of which parts of your code-base aren't
|
||||
actually covered by your main license, but are instead using some other license. It can also keep you from making
|
||||
mistakes if you wanted to change a license as you'll immediately see if you have some code that isn't compatible with
|
||||
some new license you'd like to relicense to (more in the changing license category).
|
||||
|
||||
## Changing the license
|
||||
|
||||
If you initially licensed your code under a certain license, and after reading this (or really for any reason and at
|
||||
any point) you decided you want to change that license, you may run into some problems.
|
||||
|
||||
### The easy part
|
||||
|
||||
If nobody else owns the copyright to your code and you don't have any internally used incompatible code with the new
|
||||
license (copy-left dependency or code), you can relicense, your code is yours to do whatever you like with. But once
|
||||
other contributors are added to the equation, things get a lot more complicated. If that's the case, follow the messy
|
||||
part below.
|
||||
|
||||
If your code was initially licensed under a permissive license, you're usually fine as you can sublicense because of
|
||||
that permissive license, no matter if the next license is going to also be permissive, or if it will now be copy-left,
|
||||
or even a proprietary license. Of course the licenses of all of your dependencies are most likely also permissive if
|
||||
your main license is permissive so they should also be compatible, but again, permissive licenses may have some
|
||||
exceptions to relicensing and while this is pretty much never the case with FSF approved ones, you should always make
|
||||
sure.
|
||||
|
||||
### The messy part
|
||||
|
||||
However if your project has multiple contributors and it's licensed as copy-left, you will have more work to do. First
|
||||
of all, check if you have some copy-left licensed dependencies/parts included in your codebase, and if you do, ensure
|
||||
all of them will be compatible with this new license (most likely they won't be as just a slight change to a copy-left
|
||||
license usually means it's no longer compatible, but there may be some compatibility clauses in your license allowing
|
||||
this). Note that even if the license you're switching to is compatible with your main project's license, it doesn't
|
||||
necessarily means it's also compatible with the copy-left dependencies, since they could've only been compatible with
|
||||
your current (old) license because of some compatibility clauses, which however don't also extend to that new license,
|
||||
even though your current license has a compatibility clause with it. This can sometimes get really complicated, however
|
||||
luckily most people usually stick to only a few common copy-left licenses and compatibility questions about them were
|
||||
already answered, just look them up.
|
||||
|
||||
If some of your dependencies aren't compatible though, you'll need to remove them and use something else, or write it
|
||||
yourself. Otherwise, the next step will be to check if your main project's license is compatible with the new one, if
|
||||
it is, it's completely safe to change the license, just like it would be with a permissive licensed project.
|
||||
|
||||
However, if the main license isn't compatible, which will basically always happen if you're going from copy-left to
|
||||
permissive, but also if you're just going to different copy-left license without an explicit compatibility clause, you
|
||||
will face some issues.
|
||||
|
||||
If you are the sole copyright owner and all of the dependencies/code parts are compatible, you can just switch as an
|
||||
owner of that code, but that's often not the case. In which case, you will have some other contributors, which hold the
|
||||
copyright to certain parts of your project. Each line of code added by someone else will mean the copyright will belong
|
||||
to them (unless it's explicitly stated otherwise) and you can't simply change the license as these other copyright
|
||||
holders originally submitted their code under the terms of the main project's license, which didn't allow you to change
|
||||
it.
|
||||
|
||||
Don't worry though, there is a way around that, but it's not particularly easy to achieve. Your next step now will be
|
||||
to find a legal way to still change the license, which is only achievable in 2 ways. First way is to just remove all of
|
||||
the code by any other contributors, which will most likely mean you'll need to rewrite a lot of the project yourself
|
||||
without using any of the code from those contributors, the other way is to get their written consent that alters their
|
||||
copyright on that work and allows you to sublicense. This can be done by either them assigning their copyright to that
|
||||
code to you completely, or by them extending their copyright to also include a different license terms being the new
|
||||
license you want to sublicense under (or some other license which allows sublicensing like that). This won't be easy as
|
||||
you'll need to find out some way to contact all of these contributors, and even if you can achieve that, getting their
|
||||
written consent to relicense can be very difficult.
|
||||
|
||||
This is why in most realistic scenarios, if you will be relicensing with a lot of contributors, you'll end up having to
|
||||
go with a mixture of those two options and rewrite the code of the people you weren't able to reach/didn't give you the
|
||||
consent to relicense, and use the written consent of the rest.
|
||||
|
||||
It's probably clear by now that changing a license of a copy-left licensed work is really hard, but that's very much
|
||||
intentional, after all copy-left is here to prevent license changes unless the contributors agreed to it, either via a
|
||||
clause in that license directly stating that it allows sublicensing to some other license (usually next version of
|
||||
itself), or via an explicit permission from said contributor.
|
||||
|
||||
## Common legal documents about licensing
|
||||
|
||||
In many projects you'll find out that before you're allowed to contribute something to an open-sourced, you'll be
|
||||
required to sign a document stating certain things. This is mostly the case of contributing to projects maintained by
|
||||
big companies, but what are these documents for, and should you be signing them?
|
||||
|
||||
### Contributor's license agreement
|
||||
|
||||
Following the relicensing category, it should be clear that any copy-left licensed project wishing to relicense won't
|
||||
have it easy and it may take years to gather the consents of all of the contributors to actually achieve that
|
||||
relicensing. Because of this, many companies chose to instead just get this consent beforehand, with what's called a
|
||||
["CLA"](https://en.wikipedia.org/wiki/Contributor_License_Agreement), which is a short for "Contributor's License
|
||||
Agreement".
|
||||
|
||||
CLA is a legal document that each contributor is required to sign before the company will allow any code from said
|
||||
contributor to get into their (usually copy-left licensed) codebase. This agreement states that all code contributed by
|
||||
the person who signed it will have it's copyright transferred over to that company. Making this company the single
|
||||
copyright owner and therefore making it really easy for them to change the project's license if the current license
|
||||
became inadequate.
|
||||
|
||||
But know that signing an agreement like this is very dangerous if you care about that code staying open-sourced. The
|
||||
copy-left licenses are great because they're enforced by the combination of various small copyrights present in that
|
||||
codebase, but the holders of these copyright each agreed to distribute their work, so long as the conditions of given
|
||||
copy-left license will be followed. But when there is a single owner of the entire project, as I said before, it's
|
||||
their work, they can relicense under anything they want. This includes closing down the project and licensing under a
|
||||
proprietary license, and you as a contributor, even if you wrote over 50% of that code, because you've assigned your
|
||||
copyright to that company, won't be able to do absolutely anything about this relicensing.
|
||||
|
||||
This is why if you're going to be signing a CLA, you should at least make sure that they include a "transfer
|
||||
back/nullation" clause that doesn't allow them to relicense the code under any closed source proprietary license, so
|
||||
you at least make sure the code-base will always end up being open-sourced, even though it may not end up being under
|
||||
the same license. These nullation clauses can be as specific as desired and can even enforce staying on copy-left
|
||||
licenses, or staying on some specific type of open-sourced licenses. But most companies wont' actually include clauses
|
||||
like these in their CLAs and while you can ask them to include it, you most likely won't have much success with that
|
||||
and instead your contributions will just be declined.
|
||||
|
||||
So just be aware what signing a CLA really means and that after you do so, you've given that company the rights to do
|
||||
absolutely anything with your code, no matter the initial license that code was released under.
|
||||
|
||||
It is also very common for employees with a clause in their contract that states that all of the work they do while
|
||||
inside of that building/while using the companies computers/while contributing to company-owned source code/..., you as
|
||||
an owner of that creative work you made assign the copyright which you automatically gained to that company, therefore
|
||||
making it the sole owner of all of the source-code (and other things) maintained by them even though it wasn't written
|
||||
by them.
|
||||
|
||||
This is basically a CLA, except it's usually way more invasive, i.e. it doesn't just apply to the work you submit to
|
||||
companies projects, but also personal work, if you worked on it on their machines/in their building/... This is often
|
||||
the reason why many people who developed their own projects which grew a bit bigger got legally transferred over to
|
||||
some company they once worked in, just because they wrote even just a single line of that project on that companies
|
||||
computer, immediately giving your copyright to that project over to that company. So be careful to inspect the terms of
|
||||
your contract when getting a job as a programmer, and make sure if you're working on some personal project to not do so
|
||||
while on the job.
|
||||
|
||||
### Developer Certificate of Origin
|
||||
|
||||
A ["DCO"](https://en.wikipedia.org/wiki/Developer_Certificate_of_Origin), or Developer Certificate of Origin is a legal
|
||||
document that deals with ensuring that all of the code you submit to some codebase is indeed owned by you, or you have
|
||||
a legal right to use it and contribute it to that codebase. It also requires you to have the right to assign this
|
||||
contributed work to the license of that project, which extends the copyright of that code accordingly to the terms of
|
||||
that license.
|
||||
|
||||
This kind of document is pretty important because without it, it would be the owners of that repository who would face
|
||||
legal issues if their project contained some code it wasn't allowed to use and especially for bigger projects, but for
|
||||
smaller ones too, it can be very difficult to verify that the code a contributor wants to add is actually their code to
|
||||
begin with. Making all contributors sign this document before allowing them to contribute to the repository is a way to
|
||||
ensure that the project's maintainers won't be the ones facing the legal issues for having code that they didn't have
|
||||
right to use in their project, but instead it will be the person who contributed it who will be held liable. Of course,
|
||||
this code will still be required to be removed from this project, even though it wasn't the fault of the maintainers
|
||||
that it got included, but at least they won't be facing any fines or things like that and instead it will be the
|
||||
contributor facing these.
|
||||
|
||||
This solution isn't full-proof and the project maintainers may still be the ones held liable even though a DCO was in
|
||||
place, however it will at least mean that the maintainers themselves can then hold the contributor liable which usually
|
||||
does a good enough job of scaring anyone who'd want to add a code they don't have the rights to into a codebase as
|
||||
they'll now know that they could be facing lawsuits after doing so.
|
||||
|
||||
I think it makes sense for projects to include this document and you generally shouldn't be afraid to sign it (so long
|
||||
as you're not submitting any stolen code, which you really shouldn't be doing even if there isn't a DCO in place). It
|
||||
gives the maintainers at least some level of certainty that the submitted code isn't stolen and unlike a CLA, it
|
||||
doesn't really do anything with your copyright rights to that project, it just confirms that you do in fact hold them.
|
||||
...) these will create dependency listings, which will often fulfill the license's mention requirement since it's
|
||||
source url will be mentioned by the package manager, and the original source is often included somewhere along with the
|
||||
license, fulfilling the include license requirement.
|
||||
|
||||
In many cases, it is therefore enough to just add these libraries via the package manager without any worries.
|
||||
Especially since most utility libraries are generally going to be licensed under weak copy-left allowing library usage
|
||||
or permissive licenses. However it may not always be the case, and when that happens, you may need to do something
|
||||
extra to comply with that license (like making sure you're not using any software patents, not using the project's
|
||||
trademark, etc. For that reason, you should ALWAYS make sure that you are in fact following the licenses of your
|
||||
dependencies.
|
||||
|
||||
## My personal preference
|
||||
|
||||
In my opinion, to truly support open-source as much as possible, I try to stick with copy-left licenses, because it
|
||||
prevents my code from ever becoming proprietary as anyone wanting to use my copy-left licensed code will need to
|
||||
distribute it's source-code along with the executable and they will need to follow the exact terms of the license which
|
||||
I've picked.
|
||||
In most cases, I prefer strong copy-left, specifically I usually stick to the simple GPL v3 license, as it meets all of
|
||||
the things I'd want from a license, however when I'm making libraries which I know many people may end up using, I
|
||||
don't want to discourage that usage by forcing them to propagate my license as many people simply don't like licensing
|
||||
their code under a copy-left license, so weak copy-left works better for me there, specifically I choose LGPL v3 for
|
||||
cases like that.
|
||||
|
||||
In most cases, I go with strong copy-left, specifically with the simple GPL v3 license, as it meets all of the things
|
||||
I'd want from a license, however when I'm making libraries which I know many people may end up using, I don't want to
|
||||
discourage that usage by propagating the copy-left and requiring these projects to also use GPL as many people don't
|
||||
like licensing their code under something copy-left, so I use weak copy-left there, specifically LGPL. Although to
|
||||
truly support open-source, it can sometimes make sense to use strong copy-left even on libraries, as it forces everyone
|
||||
using it to also keep their project open, and therefore this could really help grow the open-source community even
|
||||
more. Also, do keep in mind that LGPLed code isn't GPL compatible and therefore if you do make an LGPLed library, you
|
||||
won't be able to use any GPLed code/library in it!
|
||||
Although to truly support open-source, it can sometimes make sense to use strong copy-left even on libraries, as it
|
||||
forces everyone using it to also keep their project open, and therefore this could really significantly help grow the
|
||||
open-source community, by forcing even companies to make their code open, because otherwise they just won't be able to
|
||||
use your library. Depending on how complex this library is, they might end up reimplementing it themselves, bypassing
|
||||
you entirely though, but if doing that is not so easy, it might simply not be worth it, and the company will instead
|
||||
decide to just go open-source, following your license.
|
||||
|
||||
Another great license to consider is the Mozilla Public License which came up with the very interesting file-based
|
||||
copy-left propagation and therefore enforces all of your code to always stay open, even if it lives in an otherwise
|
||||
proprietary codebase. I also find the clause allowing individual copyright holders being able to withdraw all code
|
||||
covered by their copyright licensed under MPL from a given code-base simply by sending a written notice to do so really
|
||||
interesting, however it could also be somewhat risky, both for people deciding to use your MPL code in their codebase,
|
||||
as that project could basically immediately be destroyed by someone owning the copyright to a lot of the code of that
|
||||
project but also to your project specifically because of the same reason. If you have someone interested in your
|
||||
project who has already contributed a lot of code into your codebase suddenly change their mind (perhaps because they
|
||||
now want to make their own competing project, or really any other reason), suddenly you may be forced to take out all
|
||||
of their code from the code-base of your own project, which is why I'm hesitant to use it in many places, however it
|
||||
remains very interesting to me and I may change this opinion over time.
|
||||
Another benefit with using full GPL on libraries is that you get to utilize code from other GPLed code-bases, while
|
||||
with LGPL, this actually isn't possible, because GPL isn't compatible with it (you can't relicense GPL code into LGPL).
|
||||
|
||||
I'm generally against permissive licenses though as in my opinion, they well .. give out too many permissions. I get
|
||||
the people who license their code under these licenses, interested in bigger companies using their code/libraries in
|
||||
their projects and perhaps getting some contributions from these companies back into your codebase, improving your
|
||||
project, I feel like it's too much of a threat to open-source. The thing is, if we didn't use any permissive licenses
|
||||
and instead only used strong copy-left everywhere, these companies with their proprietary code-bases would either need
|
||||
to write and maintain everything from scratch, which would be near impossible even for really big companies, or simply
|
||||
be forced into also using these copy-left licenses and make their code open, which would be, at least in my opinion, a
|
||||
really nice thing, as it would allow us to make derivatives of those works because of these freedom respecting
|
||||
copy-left licenses, allowing us to make alternative versions to basically all software out there that's completely for
|
||||
free and without any telemetry at all. Of course, this is quite unrealistic to actually happen anytime soon, but if you
|
||||
think it's a nice idea, you can at least do a little bit by keeping your code copy-left licensed.
|
||||
I'm generally against fully permissive licenses, as in my opinion, they simply give out too many permissions, and while
|
||||
in the ideal world, this would be fine, that's just not the world we're in. I get the people who license their code
|
||||
under these licenses, since they at least mean that the bigger companies will have a lot of open code in their
|
||||
code-bases, but I'm just fundamentally against my code being used in a proprietary project, at least without being
|
||||
compensated appropriately for it.
|
||||
|
||||
Then again, this is purely my stance on this and you should make up your own mind and decide what works best for you,
|
||||
I'm not here to force my opinion on anyone, but I did want to express why I feel the way I feel about permissive
|
||||
licenses and what I like using, in hopes that someone will perhaps not have considered these arguments and may be
|
||||
persuaded to also use copy-left and expand the open-source community by it, but again, I wouldn't want to force that on
|
||||
anyone, it's your work and you can license it any way you want.
|
||||
When I publish my code, I do it so that everyone can use it freely, to support the open-source community. I don't do it
|
||||
to support big companies, only to use have my code used in their closed-sourced projects, or even worse, to have my
|
||||
entire project copied and relicensed, with a bunch of added telemetry and other user-intrusive features, to the point
|
||||
where it's basically spyware, with them then happily releasing it under their banner, selling and advertising it to
|
||||
everyone, without having any say in it, since my license allowed it.
|
||||
|
||||
Instead, I just use a license which allows anyone to use my code, as long as they give out the same guarantees as I
|
||||
did with my project, allowing anyone to modify it, etc. And if some company would want to use my code in a different
|
||||
way, they can always contact me and we could discuss me giving them a different license over it (see [post about
|
||||
multi-licensing]({{< ref "posts/multi-licensing" >}})), for some compensation. I don't want to write code for companies
|
||||
which I'm not gonna be payed for. But I'm absolutely for writing code for people like me, who just want to use it in
|
||||
their own open-sourced projects, and for giving back to the community as a whole.
|
||||
|
||||
{{< notice tip >}}
|
||||
Another great license to consider is the [**Mozilla Public License**](https://www.mozilla.org/en-US/MPL/2.0/) which
|
||||
uses a very interesting **file-based weak copy-left** propagation and therefore enforces all of your code to always
|
||||
stay open, even if it lives in an otherwise proprietary codebase, by requiring the file with MPLed code be MPLed in
|
||||
it's entirety, but the rest of the files, even if they then use the code (via imports/linking) won't be affected.
|
||||
|
||||
I still personally prefer strong copy-left, because it has this "give-back" property, but for people who just want their
|
||||
code to stay open, without caring as much about it being in a project that abuses it, this may be an amazing choice
|
||||
instead of going full permissive.
|
||||
{{< /notice >}}
|
||||
|
||||
Then again, this is purely my stance and you should make up your own mind and decide what works best for you, I'm not
|
||||
here to force my opinion on anyone, it's your code and I firmly believe that you should be able to do anything you want
|
||||
with it, but I did want to express why I feel this way about permissive licenses and what I like using, in hopes that
|
||||
someone will perhaps not have considered these arguments against permissive licenses. But again, I wouldn't want to
|
||||
force that on anyone, it's your work and you can license it in any way you want.
|
||||
|
|
Loading…
Reference in a new issue