ItsDrike/itsdrike.com
1
0
Fork 0
mirror of https://github.com/ItsDrike/itsdrike.com.git synced 2025-11-03 19:56:36 +00:00
Code Issues Projects Releases Packages Wiki Activity

Rewrite software-licensing & publish pending posts

Browse source
This commit is contained in:
ItsDrike 2023-12-10 00:55:16 +01:00
parent 7f89d1586a
commit 2c65ecc4b4
Signed by: ItsDrike
GPG key ID: FA2745890B7048C0
4 changed files with 855 additions and 434 deletions
Download patch file Download diff file Expand all files Collapse all files

185
content/posts/changing-license.md Normal file
View 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
View 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
View 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.

785
content/posts/software-licenses.md
View file

@ -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.