Rewrite software-licensing & publish pending posts

2024-11-09 21:49:41 +00:00 · 2023-12-10 00:55:16 +01:00 · 2023-12-10 00:55:16 +01:00 · 2c65ecc4b4
parent 7f89d1586a
commit 2c65ecc4b4
4 changed files with 855 additions and 434 deletions
--- a/content/posts/changing-license.md
+++ b/content/posts/changing-license.md
@ -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.
--- a/content/posts/licensing-documents.md
+++ b/content/posts/licensing-documents.md
@ -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.
--- a/content/posts/multi-licensing.md
+++ b/content/posts/multi-licensing.md
@ -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.
--- a/content/posts/software-licenses.md
+++ b/content/posts/software-licenses.md
@ -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
+I've recently been coming across more and more developers which had no idea about the importance of software licensing,
-they really important to know about and to know which one you like the most. Choosing a wrong license for your projects
+how it works and what options there even are. What's worse, this lack of knowledge means people often end up not
-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
+choosing a license at all, thinking it means anyone can just use that code without limitations, when in fact no-one
-even have a way to really do anything about it. It is also important so that you personally won't misuse any code.
+can.
 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.
-## 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
+## Why even have a license?
 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.
-This means that everybody who would be interested in improving this code, or making derivative works from it would
+Many people often assume that unlicensed code is free, and anyone can use it anywhere they want, because there is no
-actually be breaking this copyright law. Even if they made no changes to it, just creating a "fork" is already a
+license prohibiting that use. This is a big misconception which has lead to many lawsuits against small developers, who
-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
+just didn't know any better.
 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.
-Most people interested in making their source code available are actually also interested in getting others to use
+The reason you can't use unlicensed code is simple, whenever you publish essentially anything, not just source code,
-their project in their own source-code perhaps integrated as a library, or in any other way, and more importantly, they
+you automatically gain copyright over that published work. This copyright then imposes some pretty big legal
-are looking for others to help them with their projects and contribute to them to make these projects better for
+restrictions to others on this published content, including preventing you from simply using it in your own code.
 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.
-But there are many types of licenses that allow others to use your code with different kinds of permissions and
+Generally, this means that when publishing your code without a license you are the sole copyright holder and no one
-restrictions imposed on them while using this code, most commonly for example the need to mention the usage of the
+else has any rights to that code. We often call public code like this "source-available", instead of "open-source",
-original project in a derivative work.
+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
+Because there are thousands of very different open source licenses, we split them into several categories, which
-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
+describe the main goal of the license. While the individual licenses in the same category can still be quite different,
-the open-source licences and explain what these categories represent, but once again, don't just blindly trust some
+these differences are mostly minor details.
-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.
+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
+The main point of copy-left licenses is to ensure that the code licensed under them will never go closed-sourced, and
-differently from your original code, but still uses a lot of the original code-base, or just utilizing a few snippets
+will always remain free and accessible to anyone.
 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 this type of licenses is that they require all projects using work that's licensed under them to also
+To achieve this, copy-left licenses require everyone who would want to use the code licensed under them to publish
-use that same copy-left license. This is called propagating the copy-left. This basically means that if some other
+their code under the same (or a compatible) license. This basically means that if some other project would like to use
-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
+a part of copy-left licensed code, that other project would need to itself become entirely copy-left. We often call
-the whole project, used as a library, they would need to license their code under the same license that your original
+this "propagating the copy-left".
 code code has, or at least a compatible license (propagate the copy-left).
-This behavior of copy-left licenses propagating themselves and prohibiting being licensed under any other
+Usually, if your project is compilable into a single executable file (or multiple executables) copy-left licenses will
-(non-compatible) license is called forbidding sublicensing. Some copy-left licenses do actually allow you to change the
+also require shipping the license and the entire source-code that was used to compile it (or at least a link to a
-license, but only to a selection of a few other copy-left licenses with similar terms, even though they wouldn't
+website where this source-code and license's fulltext is accessible, which is often done because the source code might
-necessarily be "compatible" licenses legally, as they may enforce different set of rules, they can still include a
+be pretty big). This ensures that anyone wanting to use this binary will always have access to the source code it was
-clause allowing for such sublicensing. This is often done to allow for easily updating the license to a new version of
+made from, and are free to change this code and to then use their own modified versions if they want to (this is often
-it. As without a clause like that, changing licenses may get tricky, I will talk about this in another section later as
+called creating "derivatives"). For example they might make a version without any intrusive telemetry.
 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.
 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
+Similarly to copy-left licenses, this type of license allows usage of the original code in almost any way (derivatives,
-(derivatives, using small chunks, using code as library, ...), however unlike licenses in the copy-left category,
+using small chunks, using code as library, ...), however unlike with copy-left, permissive licenses will allow other
-permissive licenses do allow almost any form of sublicensing.
+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
+However even though these licenses are generally very "weak", in that they allow the code to be used very easily and
-met before the code can be sublicensed. Most notably the requirement to mention the original copyright holder(s) and
+without many restrictions, it doesn't mean there can't be any extra conditions to gain these rights. One example of a
-perhaps to ensure the original author won't be held liable for any issues with the source or clauses which can forbid
+very common requirement in permissive licenses is to mention the original copyright holder(s), or a requirement that
-things like patenting.
+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
+This means that permissive licenses give others a lot more freedom because they allow anyone to use your code under any
-that's using parts of your code, but this means that anybody could simply take your entire project, change it a bit and
+license they like, usually even a proprietary one. This could then mean that someone might simply take your entire
-close-source it, while just respecting the terms of your license (most likely just being the original author mention),
+project, and make it close-sourced. Perhaps with some added features, this version can then be sold for profit.
 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.
-Things like these are unavoidable with a license allowing this much freedom, and even though it may require the project
+However the proponents of this license like this fact because even though it may mean their software will be used in
-to follow some guidelines, they usually aren't that strict and if it's just mentioning the source, this mention can
+closed-sourced repositories, it at least means that there is a big chunk of open code in these projects, promoting the
-easily be lost along with thousands of other mentions because the project may rely on many other things too.
+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
-However the proponents of this license like this fact because even though it may mean their software will be used along
+repositories, hence helping them to grow.
 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.
 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,
+There are also the so called "public domain licenses", which are actually a subcategory of permissive licenses, however
-however when we talk about permissive licenses, we generally don't really refer to the public domain ones, even though
+when we talk about permissive licenses, we generally don't mean the public domain ones, even though they do technically
-they technically meet the definition of a permissive license. This is why I separated this category since it's quite
+meet the definition of a permissive license. This is why I separated this category as it's really quite different from
-different from the general permissive licenses.
+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
+Public domain licenses essentially strip the copyright away completely. They don't impose any extra restrictions (such
-pretty much anything with the code. They don't impose any extra restrictions (such as mentioning the original
+as requirement to mention the author) at all. This means giving everyone the right to do absolutely anything with that
-source/author) and they obviously allow sublicensing.
+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
+copyright from your work, instead you can "assign" the copyright to the public domain, or give all rights to everyone
-countries. This could basically mean that everyone is the copyright holder of said work giving everyone the rights to
+without imposing any restrictions.
 do absolutely anything with that work as they're basically considered as the owners of that work.
-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
+Coming back to copy-left licenses, they're actually split into 2 sub-categories, which further define how strict they
-because it was already quite big and I wanted to just describe the category itself before getting to some specifics,
+are. The main problem with copy-left is that people who like permissive licenses will often simply refuse to use
-also I wanted to describe the permissive licenses before getting to the definition of these subcategories as it does
+copy-left projects, because they don't want to be forced to also license all of the code in their project under a
-rely on this definition.
+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
+This new weaker form of copy-left is essentially the same as normal copy-left, but with some exceptions that allow
-different kinds of derivative works. This sounds complex, but the difference isn't actually that hard to understand.
+using the code as if it was permissively licensed. The most common case for this is an exception for using the
-Simply the "stronger" the copy-left license is, the less exceptions are there for a derivative work to not inherit that
+copy-left licensed software as a library. This means that code licensed like this can be used in any other projects
-copyleft and with it the requirement of propagating the license.
+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
+With this change, to distinguish between these licenses, original copy-left was classified as "strong copy-left", and
-can therefore be some derivative works made which won't actually fall under the copy-left guidelines of that license.
+this new weaker form of copy-left licenses was called "weak copy-left".
 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.
-This makes weak copy-left licenses somewhat of a compromise between strong copy-left and permissive licenses where you
+{{< notice warning >}}
-may want to allow sublicensing if a derivative meets some criteria, such as if someone just wants to use your work as a
+Weak copy-left licenses could end up causing some legal "gray zones" when that copy-left license isn't clear about when
-library, in which case they could sublicense and use your code as if it were under a permissive license, but in other
+the copy-left should propagate, and when it can be permissive, and it is important to say that these **weak copy-left
-cases, such as someone wanting to make a full-fledged alternative where they're going to be making changes to your code
+licenses weren't yet tested in court**.
 and building on it, they will be required to inherit the copy-left and use the same license.
-Another way a weak copy-left can behave is a file-based copyleft. This means that any file containing copy-left code
+Nevertheless, many people and companies do use them and they're generally trusted to be quite safe (that is, if you
-will inherit that copy-left and will therefore need to be licensed and distributed accordingly to the terms of that
+pick one that has been checked by a lawyer and is used commonly, ideally one of those listed in the OSI or FSF's
-license, however your derivative project may only include one file out of thousands in a codebase under this weak
+approved list of licenses).
-copy-left license, this would mean instead of you having to license the entire project as copy-left, you'd only need to
+{{< /notice >}}
 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.
-Do note that this could end up causing some legal "gray zones" when that copy-left license isn't clear about when the
+#### Most commonly used strong copyleft licenses
 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.
- The most commonly used weak copyleft licenses are the 
+- **General Public license (GPL):** The license that defined copy-left.
-    - **Lesser General Public License (LGPL):** Libraries are treated permissively, major derivatives inherit copy-left
+- **Affero General Public License (AGPL):** Extension of the GPL (an even stronger copy-left) that enforces source
-    - **Mozilla Public License (MPL):** File-based copy-left that ensures all of the copy-left licensed parts remain
+  code publishing even for a "service" use case (I won't get into details about that here, look it up if you're
-    copy-left licensed, even though they could end up being a part of a proprietary closed-sourced project. It also
+  interested).
-    allows the project's contributors to terminate the license for their copyright code only (the code that was
+- **Sybase Open Watcom Public License:** One of the strongest copy-left licenses which prevents the "private usage"
-    contributed by this author under this license) by sending a written notice to the projects using this MPLed code,
+  loophole of the GPL (which allows source-code modification when you "deploy" the software for private use only,
-    but only to the parts of the MPLed code copyrighted by that author. This license treats files as the boundaries
+  even for testing while developing a project covered by this license) and requires source code publishing in any
-    between MPL-licensed and proprietary parts, meaning either all code in a file will be MPL licensed, or none of it
+  use-case. However this can be way too limiting and basically makes it really hard to even develop the software
-    will. (i.e. using just a bit of MPLed code in a file makes the whole file fall under MPL).
+  covered by it because each time an executable is built, the srouce-code has to be made available, which lead to
- The most commonly used strong copyleft licenses are the 
+  FSF not accepting this license as "free software license".
-    - **General Public license (GPL):** The license that defined copy-left
+- **Design Science License:** The interesting thing about this license is that it can apply to any work, not just
-    - **Affero General Public License (AGPL):** Extension of the GPL (an even stronger copy-left) that enforces source code
+  software/documentation, but also literature, artworks, music, ..., however it became irrelevant after the
-    publishing even for a "service" use case (I won't get into details about that here, look it up if you're interested)
+  creation of "creative commons" licenses.
    - **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.)
-## 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
+- **Lesser General Public License (LGPL):** Libraries are treated permissively, major derivatives and direct source
-some legal gibberish allow others to use that project and contribute to it?
+  usage forces inheriting copy-left.
-
+- **Adaptive Public License (APL):** An incredibly detailed license which provides a template for users to slightly
-Essentially, these licenses extend the copyright of the person who submitted some code under that license. By doing so,
+  modify it to their exact needs.
-they and allow using of said code in other places, it's modifications, and other things, depending on the actual
+- **Mozilla Public License (MPL):** Uses files as the boundaries between MPL-licensed, and proprietary/otherwise
-license. But that license is usually the only thing that give others the right to use that code in these ways. 
+  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
-These licenses are therefore able to enforce themselves, because the moment you violate the terms of that license, it
+  more business-friendly, by allowing to link code under under it to proprietary applications, and licensing binaries
-no longer applies to you. At that point, you still have the copyright law to consider. It's entirely possible that you
+  under a proprietary license, as long as the source code is available under EPL.
 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.
 ## 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
+Whenever you make a new project, you should also figure out how will you want to license it category-wise. Should it be
-have a project's source code available without any license giving others rights to actually improve it and use it. At
+permissive? Should it be copy-left? Is it a library? If so, should it be weak copyleft? So on and so forth. After you
-the moment, all of the contributors to such projects are actually breaking the copyright law which isn't ideal (unless
+know that, you should start considering the possible licenses in the category of your choosing, so for example if you
-they live in a country which doesn't respect copyright, but again, that's very rare). Even though I'm sure most people
+ended up on strong copy-left, should it be GPL-3, GPL-2, AGPL, or maybe something else entirely.
 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.
-**Some great websites:**
+{{< notice tip >}}
- There is a [page from GitHub](https://choosealicense.com/) that may help you pick the correct license for your
+If you need some help on picking the license, check out some of these pages, which are made to simplify this process a
-  project.
+bit:
- 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
+- [The healthermeeker's license picker](https://heathermeeker.com/open-source-license-picker/) gives you a bunch of
-  [here](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository)
+  questions about your project, and shows you the license you'll want based on your answers
- Yet another wonderful site you should check out is <https://tldrlegal.com>, which can quickly show you the details about
+- [TLDRLegal](https://tldrlegal.com) allows you to quickly see some key points about a given license, without the need
-what a given license requires from others when they use your code, and what rights it gives them.
+  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
+license, you immediately loose the right to use any copy-left licensed code _(unless it's a weak copy-left and you're
-the exception). It is therefore very important to know your dependencies and the licenses of the code you're using in
+in the exception, or unless you [relicense]({{< ref "posts/changing-license" >}}))_. It is therefore very important to
-your codebase directly.
+know the licenses of your dependencies and of the code you're going to be using in the 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/... 
 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
+...) these will create dependency listings, which will often fulfill the license's mention requirement since it's
-source url because of that package manager. Luckily, most libraries are generously licensed under weak copy-left or
+source url will be mentioned by the package manager, and the original source is often included somewhere along with the
-permissive licenses, and they don't really have any other terms that would make things more complicated apart from just
+license, fulfilling the include license requirement.
 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.
 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
+In most cases, I prefer strong copy-left, specifically I usually stick to the simple GPL v3 license, as it meets all of
-prevents my code from ever becoming proprietary as anyone wanting to use my copy-left licensed code will need to
+the things I'd want from a license, however when I'm making libraries which I know many people may end up using, I
-distribute it's source-code along with the executable and they will need to follow the exact terms of the license which
+don't want to discourage that usage by forcing them to propagate my license as many people simply don't like licensing
-I've picked.
+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
+Although to truly support open-source, it can sometimes make sense to use strong copy-left even on libraries, as it
-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
+forces everyone using it to also keep their project open, and therefore this could really significantly help grow the
-discourage that usage by propagating the copy-left and requiring these projects to also use GPL as many people don't
+open-source community, by forcing even companies to make their code open, because otherwise they just won't be able to
-like licensing their code under something copy-left, so I use weak copy-left there, specifically LGPL. Although to
+use your library. Depending on how complex this library is, they might end up reimplementing it themselves, bypassing
-truly support open-source, it can sometimes make sense to use strong copy-left even on libraries, as it forces everyone
+you entirely though, but if doing that is not so easy, it might simply not be worth it, and the company will instead
-using it to also keep their project open, and therefore this could really help grow the open-source community even
+decide to just go open-source, following your license.
 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!
-Another great license to consider is the Mozilla Public License which came up with the very interesting file-based
+Another benefit with using full GPL on libraries is that you get to utilize code from other GPLed code-bases, while
-copy-left propagation and therefore enforces all of your code to always stay open, even if it lives in an otherwise
+with LGPL, this actually isn't possible, because GPL isn't compatible with it (you can't relicense GPL code into LGPL).
 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.
-I'm generally against permissive licenses though as in my opinion, they well .. give out too many permissions. I get
+I'm generally against fully permissive licenses, as in my opinion, they simply give out too many permissions, and while
-the people who license their code under these licenses, interested in bigger companies using their code/libraries in
+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
-their projects and perhaps getting some contributions from these companies back into your codebase, improving your
+under these licenses, since they at least mean that the bigger companies will have a lot of open code in their
-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
+code-bases, but I'm just fundamentally against my code being used in a proprietary project, at least without being
-and instead only used strong copy-left everywhere, these companies with their proprietary code-bases would either need
+compensated appropriately for it.
 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.
-Then again, this is purely my stance on this and you should make up your own mind and decide what works best for you,
+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
-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
+to support big companies, only to use have my code used in their closed-sourced projects, or even worse, to have my
-licenses and what I like using, in hopes that someone will perhaps not have considered these arguments and may be
+entire project copied and relicensed, with a bunch of added telemetry and other user-intrusive features, to the point
-persuaded to also use copy-left and expand the open-source community by it, but again, I wouldn't want to force that on
+where it's basically spyware, with them then happily releasing it under their banner, selling and advertising it to
-anyone, it's your work and you can license it any way you want.
+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.