diff --git a/content/posts/changing-license.md b/content/posts/changing-license.md new file mode 100644 index 0000000..2b13ee2 --- /dev/null +++ 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. diff --git a/content/posts/licensing-documents.md b/content/posts/licensing-documents.md new file mode 100644 index 0000000..2ded496 --- /dev/null +++ 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. diff --git a/content/posts/multi-licensing.md b/content/posts/multi-licensing.md new file mode 100644 index 0000000..18cf4a2 --- /dev/null +++ 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: + - + - +--- + +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. diff --git a/content/posts/software-licenses.md b/content/posts/software-licenses.md index 1f077f3..50951d1 100644 --- 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 -they really important to know about and to know which one you like the most. Choosing a wrong license for your projects -may lead to your code being used by others in ways you don't like and depending on the license you chose, you may not -even have a way to really do anything about it. It is also important so that you personally won't misuse any code. -Stealing code is illegal and you may get in trouble for it, so it is always good to know what you can and can't do with -the code of others. +I've recently been coming across more and more developers which had no idea about the importance of software licensing, +how it works and what options there even are. What's worse, this lack of knowledge means people often end up not +choosing a license at all, thinking it means anyone can just use that code without limitations, when in fact no-one +can. -## Why are licenses important +I've always been very interested in software licenses, and have accumulated a lot of knowledge about them over time, so +I've decided to share this knowledge and explain the basics of how licenses work, what enforces them, what different +types of licenses we have, and perhaps most importantly, why you need to use a license if you want to maintain an +open-source project. Along with just explanations, I've also included some of my personal thoughts on what I like to +use. -Whenever you publish essentially anything, not just source code, you automatically gain copyright over that content (at -least in most countries, there are some which don't really respect the copyright law, but that's very rare). This -copyright imposes pretty big legal restrictions on that content. Essentially, this means that even though you may have -decided to publish your code on a website like GitLab or GitHub, you only made it "source-available", not -"open-sourced". This is because for a project to be considered open-sourced, it must meet some very specific criteria, -namely, it needs an open-source license. The reason we don't call source-available code open-source is because even -though the author of these projects as the copyright owner have published his work for anyone to look at, this doesn't -give others the legal permission to actually re-use this code or alter it in any way. +## Why even have a license? -This means that everybody who would be interested in improving this code, or making derivative works from it would -actually be breaking this copyright law. Even if they made no changes to it, just creating a "fork" is already a -violation of this law. Think of it as if you were keeping a copy of some movie on your machine, or even hosted on the -internet somewhere without any permission from the company that made this movie. Obviously, you can't do that, it's -illegal, and so is doing the same with source-code without a license from the copyright owner that allows it. +Many people often assume that unlicensed code is free, and anyone can use it anywhere they want, because there is no +license prohibiting that use. This is a big misconception which has lead to many lawsuits against small developers, who +just didn't know any better. -Most people interested in making their source code available are actually also interested in getting others to use -their project in their own source-code perhaps integrated as a library, or in any other way, and more importantly, they -are looking for others to help them with their projects and contribute to them to make these projects better for -everyone. This is precisely what an open-source license allows. There's countless amount of these licenses, and many of -them are written by individuals without any legal knowledge, which may be dangerous. For that reason, the Free Software -Foundation (FSF) has a curated list of [FSF approved -licenses](https://software.fandom.com/wiki/List:FSF_approved_software_licenses) out of which all of them are guaranteed -by the FSF to legally make sense and to indeed allow this source code sharing, so you should really only pick one of -these licenses unless you have a good lawyer who can confirm that the license you decided to use, even though it wasn't -on this list does make legal sense and is legally enforcible. +The reason you can't use unlicensed code is simple, whenever you publish essentially anything, not just source code, +you automatically gain copyright over that published work. This copyright then imposes some pretty big legal +restrictions to others on this published content, including preventing you from simply using it in your own code. -But there are many types of licenses that allow others to use your code with different kinds of permissions and -restrictions imposed on them while using this code, most commonly for example the need to mention the usage of the -original project in a derivative work. +Generally, this means that when publishing your code without a license you are the sole copyright holder and no one +else has any rights to that code. We often call public code like this "source-available", instead of "open-source", +because while people can look at the code, inspect it, perhaps even find and report issues about it, they can't use +this code in almost any other way. This means that an unlicensed project can't have any (legal) contributors, because +even the action of making a fork will be considered illegal, since the contributor will be copying your code without +permission. + +{{< notice note >}} +The exact restrictions will vary from country to country, because each country can have their own copyright law, and +there are even some countries which don't respect any form of international copyright law (but that's quite rare). + +Even though in most of the cases the copyright law is pretty similar with only minor differences in punishments and +enforcement, it does not mean that there can't be any differences. Because of that, the info above may not necessarily +be true for every country, and as always, you should do your own research (or delegate it to a lawyer you trust). +{{< /notice >}} + +For these unlicensed repositories, it leads to losing many potential contributors, who would like to make some changes +to this project to improve it, but decide not to, because by doing so, they would put themselves in danger of getting +sued for copyright infringement. That's why whenever I see a project without a license, unless it was intentional, I +open an issue, or try to otherwise contact the author to inform them about this. + +{{< notice warning >}} +The worst case scenario that you can get into with an unlicensed code-base is that people do in fact decide to +contribute, and you accept that contribution. + +Not only did the contributor just break the copyright law by modifying your code without legal permission, now that +their unlicensed code is in your project, you can't legally modify it either. So it's not just the contributor who may +get in trouble, it's also you who the contributor can now press charges against for violation of their copyrighted +code. + +You as the author can't even go and add a license now, since there is code from others that you don't own, and so you +can't simply relicense them. Solving this could then be very difficult, see my: [relicensing post]({{< ref +"posts/changing-license#unintentionally-proprietary" >}}) for more details. + +This is why you should steer far away from any unlicensed projects, and make absolutely certain that your project +always have a license, or if they should be proprietary, make sure to explicitly mention that in your `README` file, +and don't accept any contributions. +{{< /notice >}} + +## How can a license make code open-sourced + +In order to make your source code classify as "open-source", it needs to be made freely available for anyone to copy +and modify, without the contributors worrying that they might in legal trouble just for trying to improve the project. + +To give someone these rights, you can use a license which specifies that you, as the owner of the copyright to your +code, freely give out certain rights to everyone. This license is here to essentially "weaken" your copyright in that +you reduce the restrictions it generally imposes on others, because they were freely given out through the terms of +your software license. + +These licenses can then also specify certain conditions, which limit when can the code be used by others. Picking a +good license for your projects then means understanding what freedoms does the license give out, and under what +conditions. + +## How are these licenses enforced + +It is important to understand how exactly the software licenses really work. How does simply having a text file with +some legal gibberish allow others to use that project and contribute to it? After all, they didn't need to legally sign +anything, so why should they be forced to follow that license's terms? + +Well, the answer to that is simple, you don't need to follow the terms. The only issue is that if you decide not to, +you lose the only thing giving you the extended copyright permissions to use that code, so while you don't have to +follow the license, if you don't, you won't be able to use the code. You can think of it as the copyright over that +code itself being extended to be usable by anyone who meets certain conditions. So it extends over that category of +people. If you're in that category, you can use the code, if you're not, you don't have those right. + +However, in some cases, you might have a different license given to you by the copyright holder, or maybe you are the +copyright owner (copyright ownership can even be transferred, and it's often sold), in which case, you already have +these rights even without following the license, so you can actually completely ignore it. + +It's actually very common for many projects to be licensed under a stricter license for general usage, that doesn't +allow using this code in closed-sourced projects, with the authors selling a more permissive license for profit to +corporations which do need to use this project in their proprietary code bases. In many cases, this is the main way +these open-sourced projects make money. I explain this a bit further in my [post about multi-licensing]({{< ref +"posts/multi-licensing" >}}) + +So essentially, licenses aren't enforced, nobody will force you to follow them, you just need to do so if you want to +gain the rights that license grants you. + +## Contributing to a licensed project + +A question that you might have now is about how will your code be licensed if you contribute to a project. The answer +to this may be pretty obvious, but it is important to explain nevertheless. + +Basically, if you pick a repository under say a GPL v3 license, fork it, change some things and make a pull-request +back to the original repo, you're offering this code to that project under the same (GPL v3) license. This is because +the LICENSE file in that project generally applies to the entire project, and you've added some code to a project with +this LICENSE file, meaning just as if you added this file to your own project, you've contributed to this project and +hence offering your code to it under this license. + +However this isn't the only way to do it. There may be cases when you want to explicitly state that the code you've +contributed is actually under some other license, like MIT for example. To do that, projects generally use another +file, like `LICENSE-THIRD-PARTY`, where all of the differently licensed code chunks are stated, along with the +copyright holder (usually a name and an email) and the full-text of this differing license. + +However you can do this in different ways, all that's necessary is to clearly mark that the code you've added is under +a different license, the way to do so is more or less just a convention (although some licenses to have specific +requirements on where they need to be mentioned, be careful with those). Another pretty common way to do it is to add a +comment at the start or end of the source code file containing the fulltext of the license, or a reference to the +license. + +There's a lot of reasons why you may want to contribute to a project under a different license, for example it might be +that the code you're contributing isn't yours, but is instead from another project, with a license that requires you to +do something specific. However it could also just be personal preference, maybe you like another license, and you're +only willing to give out your code under that license, not under the one the project uses everywhere else. + +## Available licenses + +There are countless amount of licenses, each with different set of conditions and different rights they give out. As an +author of your project, it is up to you to pick a license which best suits your needs, or if you can't find a license +you like, perhaps even write your own. + +But know that picking some random license, which could've just been written by some individual without any legal +knowledge may be dangerous, because of the potential for some legal loop-holes which it may contain. For that reason, +if you're making your own license, or picking one which isn't commonly used, you should always consult a lawyer. +Usually, you will likely just want to stick to an already well-established license, verified by thousands, if not +millions of users. + +### Open-Source software licenses + +I've mentioned before that the distinction between "source-available" and "open-sourced" code was having a license that +allows the user to do some additional things (like modifying the code and using it in different projects). However it's +not just as simple as having any license that does this. It's technically up to anyone to make their own mind about +what they'd consider open-sourced, but it's probably fair to say that if your license is discriminating against some +group of people, most probably wouldn't consider it as open-source license. + +To address this, an organization called the "Open Source Initiative" (OSI) came up with their list of approved +licenses, which were fact-checked by their lawyers and are commonly used by tons of people already. You can find this +curated list of OSI-Approved licenses [here](https://opensource.org/licenses). All of these are generally considered to +be open-sourced by almost everyone. + +### Free software licenses + +> “Free software” means software that respects users' freedom and community. Roughly, it means that **the users have +> the freedom to run, copy, distribute, study, change and improve the software**. Thus, “free software” is a matter of +> liberty, not price. To understand the concept, you should think of “free” as in “free speech,” not as in “free beer.” +> We sometimes call it “libre software,” borrowing the French or Spanish word for “free” as in freedom, to show we do +> not mean the software is gratis. +> +> -- [Explanation of "free software" by the Free Software Foundation](https://www.gnu.org/philosophy/free-sw.html) + +As seen in the quote above, free software is essentially about software that has a license which guarantees you certain +freedoms. Unlike the simple "open-source" software, which is merely about a project having a license which allows +others to fearlessly contribute to it, "free" software extends that and also guarantees contributors the freedoms +mentioned above. + +Really, all you need in an open-sourced license is the ability for the contributor to change the code and pull-request +it back. The rights to distribute the software on their own, use this code in a different project, or do a bunch of +other things aren't all that necessary for pure open-source projects. So, to signify that these freedoms are being +respected, we often call such projects "free and open-sourced", instead of just "open-sourced". + +To easily recognize which licenses do follow this ideology, the Free Software Foundation (FSF) also has [their own list +of licenses](https://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses) that they confirm do meets these +guarantees. ## License types -Learning about different licenses may be a bit confusing at first, and I would always suggest to do your own research -as I am not a lawyer and I do not offer any legal advice here. All I will do is try to explain the basic categories of -the open-source licences and explain what these categories represent, but once again, don't just blindly trust some -random guy on the internet, do your own research before picking a license and ensure it will really be exactly what you -want it to be. +Because there are thousands of very different open source licenses, we split them into several categories, which +describe the main goal of the license. While the individual licenses in the same category can still be quite different, +these differences are mostly minor details. + +This categorization allows us to only remember what category a license is, and already know with fairly good confidence +what the general guidelines of that license will be. Knowing what license category you prefer can save you a lot of +time in finding a license you like, since you'll just need to look for licenses your preferred category. ### Copy-Left licenses -These licenses allow others to use your code, whether it means building a derivative project that can do certain things -differently from your original code, but still uses a lot of the original code-base, or just utilizing a few snippets -of your code-base for example just a single function, or even just using this project as a library, being integrated in -some bigger scoped project which needs the logic of your project internally. +The main point of copy-left licenses is to ensure that the code licensed under them will never go closed-sourced, and +will always remain free and accessible to anyone. -The main point of this type of licenses is that they require all projects using work that's licensed under them to also -use that same copy-left license. This is called propagating the copy-left. This basically means that if some other -project would like to include some part of your code into their code-base, no matter how big the part is, or if it's -the whole project, used as a library, they would need to license their code under the same license that your original -code code has, or at least a compatible license (propagate the copy-left). +To achieve this, copy-left licenses require everyone who would want to use the code licensed under them to publish +their code under the same (or a compatible) license. This basically means that if some other project would like to use +a part of copy-left licensed code, that other project would need to itself become entirely copy-left. We often call +this "propagating the copy-left". -This behavior of copy-left licenses propagating themselves and prohibiting being licensed under any other -(non-compatible) license is called forbidding sublicensing. Some copy-left licenses do actually allow you to change the -license, but only to a selection of a few other copy-left licenses with similar terms, even though they wouldn't -necessarily be "compatible" licenses legally, as they may enforce different set of rules, they can still include a -clause allowing for such sublicensing. This is often done to allow for easily updating the license to a new version of -it. As without a clause like that, changing licenses may get tricky, I will talk about this in another section later as -it can be a pretty involved process. However be careful with this as even though one license may have a clause allowing -you to sublicense your content under another, that other license may not have the same clause allowing you to go back. - -Usually, if your project is compilable into a single executable file (or multiple executables) copy-left licenses can -require shipping the license and the entire source-code (or at least the parts covered by this license), or at least a -link to a website on which this source-code is hosted along with that executable. This ensures that there is no way the -code could go closed-source, because it can't even be shipped without the source-code. - -Note that they don't however usually forbid the software from being commercialized and sold for a profit, but whenever -someone would decide to buy this software, they would receive it along with it's source-code and the copy-left license, -and after that they could simply make their own derivative works and distribute those for free if they wanted to, since -the license allows that. This makes it really easy for anyone to just buy the software and then distribute the exact -same copy of that source-code for free to anyone, making it mostly pointless to even sell it in the first place, -however it is important to mention that it's possible nevertheless. - -What's perhaps a bit unintuitive though is the fact that it actually is possible for a copy-left licensed software to -be kept private for example just to a company that's using that software internally. However keeping it private is -quite difficult as by being copy-left, the source code and the license will have to be shipped with the executable, -even internally. This means that any employee could just take a look at that source code and decide to publish it as -the license allows them to do that. Another way to keep a copy-left licensed code private would be to just use it -personally, because the code is available to you when you made the executable, you're following the license and yet -you've just made a private copy-left licensed code, though that's only the case as long as you don't distribute it, or -if you do, as long as that person doesn't decide to release it publicly, as the license shipped with that software -allows them to do that. Although there are actually some licenses which prohibit even something like this, those -requirements make these licenses really hard to follow so there aren't that many people actually using them. +Usually, if your project is compilable into a single executable file (or multiple executables) copy-left licenses will +also require shipping the license and the entire source-code that was used to compile it (or at least a link to a +website where this source-code and license's fulltext is accessible, which is often done because the source code might +be pretty big). This ensures that anyone wanting to use this binary will always have access to the source code it was +made from, and are free to change this code and to then use their own modified versions if they want to (this is often +called creating "derivatives"). For example they might make a version without any intrusive telemetry. There can be many little caveats to these licenses and you should always make sure you understand what that license is allowing/denying before you decide to use them. The most popular copy-left license is the GNU General Public License version 3 (GPL v3), but version 2 is also still -quite popular. Another a bit less commonly used is the Mozilla Public License (MPL). +quite popular. ### Permissive licenses -Similarly to copy-left licenses, this type of licenses allows usage of the original code in almost any way -(derivatives, using small chunks, using code as library, ...), however unlike licenses in the copy-left category, -permissive licenses do allow almost any form of sublicensing. +Similarly to copy-left licenses, this type of license allows usage of the original code in almost any way (derivatives, +using small chunks, using code as library, ...), however unlike with copy-left, permissive licenses will allow other +projects using the code under them to be relicensed under a completely different license, we call this allowing +"sublicensing". -This said, even though sublicensing may be allowed, it doesn't mean there aren't any conditions which may need to be -met before the code can be sublicensed. Most notably the requirement to mention the original copyright holder(s) and -perhaps to ensure the original author won't be held liable for any issues with the source or clauses which can forbid -things like patenting. +However even though these licenses are generally very "weak", in that they allow the code to be used very easily and +without many restrictions, it doesn't mean there can't be any extra conditions to gain these rights. One example of a +very common requirement in permissive licenses is to mention the original copyright holder(s), or a requirement that +prevents making software patents, requires listing all changes made to the original code, or various other things. -This means that permissive licenses give others a lot more freedom because they allow changing the license of a project -that's using parts of your code, but this means that anybody could simply take your entire project, change it a bit and -close-source it, while just respecting the terms of your license (most likely just being the original author mention), -after that the person/company utilizing your code could easily release the product as a payed software without having -to show what the code is actually doing at all. And since the code is now closed-sourced they could even decide to add -all kinds of trackers constantly sending everything you do with that software to them and perhaps even some nefarious -things, such as integrating a full-blown crypto-currency miner that's running in the background at all times while -you're using this project. +This means that permissive licenses give others a lot more freedom because they allow anyone to use your code under any +license they like, usually even a proprietary one. This could then mean that someone might simply take your entire +project, and make it close-sourced. Perhaps with some added features, this version can then be sold for profit. -Things like these are unavoidable with a license allowing this much freedom, and even though it may require the project -to follow some guidelines, they usually aren't that strict and if it's just mentioning the source, this mention can -easily be lost along with thousands of other mentions because the project may rely on many other things too. - -However the proponents of this license like this fact because even though it may mean their software will be used along -with these non-privacy respecting things added on top, at least it means that a big part of this new project is -open-sourced and it may even bring the companies/people using this open-sourced software to contribute back to it, -therefore helping it to grow and improve the features it supports. While they could do this on their own in their -versions of that software, they usually don't do that simply because it gives them more code to maintain, while -contributing it to an open-sourced project that they will then use will mean others will maintain that code for them, -whether that's other people, or even other companies following the same logic. +However the proponents of this license like this fact because even though it may mean their software will be used in +closed-sourced repositories, it at least means that there is a big chunk of open code in these projects, promoting the +open-source idea, rather than having the companies write their own internal tooling resulting in existence of even more +proprietary code. A big advantage here is also that companies using this code often end up contributing to these open +repositories, hence helping them to grow. The most commonly used permissive licenses are the MIT License and the Apache 2.0 License. Another really popular set of licenses are the BSD licenses, most notably the BSD 2-Clause license. ### Public domain licenses -There are also the so called "public domain licenses", which are actually technically a subtype of permissive licenses, -however when we talk about permissive licenses, we generally don't really refer to the public domain ones, even though -they technically meet the definition of a permissive license. This is why I separated this category since it's quite -different from the general permissive licenses. +There are also the so called "public domain licenses", which are actually a subcategory of permissive licenses, however +when we talk about permissive licenses, we generally don't mean the public domain ones, even though they do technically +meet the definition of a permissive license. This is why I separated this category as it's really quite different from +what people would expect from usual permissive licenses. -Public domain licenses essentially strip the copyright away completely. This basically gives everybody the rights to do -pretty much anything with the code. They don't impose any extra restrictions (such as mentioning the original -source/author) and they obviously allow sublicensing. +Public domain licenses essentially strip the copyright away completely. They don't impose any extra restrictions (such +as requirement to mention the author) at all. This means giving everyone the right to do absolutely anything with that +code, and anyone using them can essentially consider themselves as the owners of that works. Depending on the country you're in, these licenses may act a bit differently as not all countries allow "removing" the -copyright from your work, instead you can "assign" the copyright to the public domain on an equivalent of that in other -countries. This could basically mean that everyone is the copyright holder of said work giving everyone the rights to -do absolutely anything with that work as they're basically considered as the owners of that work. +copyright from your work, instead you can "assign" the copyright to the public domain, or give all rights to everyone +without imposing any restrictions. -The most notable public domain license is the "Unlicense" license. +The most notable public domain licenses are: "Unlicense" license, Creative Commons CC0 1.0 Universal, and WTFPL. ### Strong and weak copy-left -These are subtypes of the wide copy-left licenses category. I didn't initially include it in the copy-left section -because it was already quite big and I wanted to just describe the category itself before getting to some specifics, -also I wanted to describe the permissive licenses before getting to the definition of these subcategories as it does -rely on this definition. +Coming back to copy-left licenses, they're actually split into 2 sub-categories, which further define how strict they +are. The main problem with copy-left is that people who like permissive licenses will often simply refuse to use +copy-left projects, because they don't want to be forced to also license all of the code in their project under a +copy-left license. For that reason, copy-left licenses needed a bit of a change, adding another category. -Basically, the "strength" of a copyleft license is determined by the extent of the license's provisions on the -different kinds of derivative works. This sounds complex, but the difference isn't actually that hard to understand. -Simply the "stronger" the copy-left license is, the less exceptions are there for a derivative work to not inherit that -copyleft and with it the requirement of propagating the license. +This new weaker form of copy-left is essentially the same as normal copy-left, but with some exceptions that allow +using the code as if it was permissively licensed. The most common case for this is an exception for using the +copy-left licensed software as a library. This means that code licensed like this can be used in any other projects +under a weaker set of rules (essentially under permissive rules), when the project is used as a library dependency. +This would then even allow use in closed-sourced projects. However this weaker ruleset only applies if the project is +being used as a library. If you wanted to make an actual fork of the project, or use some part of the source-code +directly in your code-base, this exception doesn't apply and the copy-left still needs to be propagated. The more +exceptions to this there are, the "weaker" that copy-left license is considered. -In other words, the "weak" copy-left licenses are those where there are exceptions to inheriting a copy-left and there -can therefore be some derivative works made which won't actually fall under the copy-left guidelines of that license. -For these derivatives, the license actually becomes permissive and they can be sublicensed, and even become closed. As -opposed to "strong" copy-left licenses, which don't carry any exceptions like these and every single derivative work, -no matter how little of the original project's code was used, or in what manner it was used, will inherit the copy-left -and will be forced to be license under the same (or compatible) copy-left license. +With this change, to distinguish between these licenses, original copy-left was classified as "strong copy-left", and +this new weaker form of copy-left licenses was called "weak copy-left". -This makes weak copy-left licenses somewhat of a compromise between strong copy-left and permissive licenses where you -may want to allow sublicensing if a derivative meets some criteria, such as if someone just wants to use your work as a -library, in which case they could sublicense and use your code as if it were under a permissive license, but in other -cases, such as someone wanting to make a full-fledged alternative where they're going to be making changes to your code -and building on it, they will be required to inherit the copy-left and use the same license. +{{< notice warning >}} +Weak copy-left licenses could end up causing some legal "gray zones" when that copy-left license isn't clear about when +the copy-left should propagate, and when it can be permissive, and it is important to say that these **weak copy-left +licenses weren't yet tested in court**. -Another way a weak copy-left can behave is a file-based copyleft. This means that any file containing copy-left code -will inherit that copy-left and will therefore need to be licensed and distributed accordingly to the terms of that -license, however your derivative project may only include one file out of thousands in a codebase under this weak -copy-left license, this would mean instead of you having to license the entire project as copy-left, you'd only need to -license that file(s) in which that copy-left code is present, everything else can still stay permissive, or even closed -sourced in this project. +Nevertheless, many people and companies do use them and they're generally trusted to be quite safe (that is, if you +pick one that has been checked by a lawyer and is used commonly, ideally one of those listed in the OSI or FSF's +approved list of licenses). +{{< /notice >}} -Do note that this could end up causing some legal "gray zones" when that copy-left license isn't clear about when the -copy-left should propagate, and when it can be permissive, and it is important to say that these weak copy-left -licenses weren't yet tested in court. +#### Most commonly used strong copyleft licenses -- The most commonly used weak copyleft licenses are the - - **Lesser General Public License (LGPL):** Libraries are treated permissively, major derivatives inherit copy-left - - **Mozilla Public License (MPL):** File-based copy-left that ensures all of the copy-left licensed parts remain - copy-left licensed, even though they could end up being a part of a proprietary closed-sourced project. It also - allows the project's contributors to terminate the license for their copyright code only (the code that was - contributed by this author under this license) by sending a written notice to the projects using this MPLed code, - but only to the parts of the MPLed code copyrighted by that author. This license treats files as the boundaries - between MPL-licensed and proprietary parts, meaning either all code in a file will be MPL licensed, or none of it - will. (i.e. using just a bit of MPLed code in a file makes the whole file fall under MPL). -- The most commonly used strong copyleft licenses are the - - **General Public license (GPL):** The license that defined copy-left - - **Affero General Public License (AGPL):** Extension of the GPL (an even stronger copy-left) that enforces source code - publishing even for a "service" use case (I won't get into details about that here, look it up if you're interested) - - **Sybase Open Watcom Public License:** One of the strongest copy-left licenses which prevents the "private usage" - loophole of the GPL (which allows source-code modification when you "deploy" the software for private use only, - even for testing while developing a project covered by this license.) and requires source code publishing in any - use-case. However this can be way too limiting and basically makes it really hard to even develop the software - covered by it because each time an executable is built, the srouce-code has to be made available, which lead to - FSF not accepting this license as "free software license". Therefore usage of it, while making the project - "open-sourced", does not make the project a "free and open-sourced" project. - - **Design Science License:** The interesting thing about this license is that it can apply to any work, not just - software/documentation, but also literature, artworks, music, ... (however it became irrelevant after the creation - of "creative commons" licenses.) +- **General Public license (GPL):** The license that defined copy-left. +- **Affero General Public License (AGPL):** Extension of the GPL (an even stronger copy-left) that enforces source + code publishing even for a "service" use case (I won't get into details about that here, look it up if you're + interested). +- **Sybase Open Watcom Public License:** One of the strongest copy-left licenses which prevents the "private usage" + loophole of the GPL (which allows source-code modification when you "deploy" the software for private use only, + even for testing while developing a project covered by this license) and requires source code publishing in any + use-case. However this can be way too limiting and basically makes it really hard to even develop the software + covered by it because each time an executable is built, the srouce-code has to be made available, which lead to + FSF not accepting this license as "free software license". +- **Design Science License:** The interesting thing about this license is that it can apply to any work, not just + software/documentation, but also literature, artworks, music, ..., however it became irrelevant after the + creation of "creative commons" licenses. -## How are these licenses enforced +#### Most commonly used weak copyleft licenses -It is important to understand how exactly the software licenses actually work. How does simply having a text file with -some legal gibberish allow others to use that project and contribute to it? - -Essentially, these licenses extend the copyright of the person who submitted some code under that license. By doing so, -they and allow using of said code in other places, it's modifications, and other things, depending on the actual -license. But that license is usually the only thing that give others the right to use that code in these ways. - -These licenses are therefore able to enforce themselves, because the moment you violate the terms of that license, it -no longer applies to you. At that point, you still have the copyright law to consider. It's entirely possible that you -could've had a permission from the original author to use the code in the way you did, even if it isn't following that -project's license. This is because that person explicitly gave you some rights to do certain things with their -copyrighted work, so basically, they extended their copyright of that work to give you some additional rights. But if -this agreement also didn't happen and you were in violation of the main license, you don't have any other legal -permission allowing you to use the copyrighted work, which puts you in violation of the copyright law. - -Whenever you're in such copyright law violation, the significance of such violation will depend on where you live. Some -countries don't even respect the copyright law, allowing you to use whatever code you want as there's no law to violate -if your country doesn't actually have the copyright law at all, however most developed countries do respect copyright. -If you live in one of the copyright-respecting countries, you'll just need to learn how they handle copyright -violations. It may be the case that before any legal case can be made, the author must send you a copyright violation -letter (so called: `ciese and desist letter`). However if your country doesn't require that, you may simply find -yourself facing a lawsuit for copyright infringement without any prior warning. - -As you can see, you can't actually "violate" a software license, rather if you do not meet the conditions of said -license, then the license doesn't apply to you and you do not acquire the permissions granted by it. Unless you've -acquired these permissions by some other means, you are violating copyright, but you aren't violating the actual -software license as it isn't a license that you've signed or anything like that, it's just something giving you the -possibility to use that work, if you follow it. That said though, in practice you often hear about a license being -"violated", but what's really meant by that is that since you didn't meet the conditions of that license, hence you're -violating copyright. - -So remember, a software license can only ever give the recipient of the creative works additional rights, it can never -takes away rights. +- **Lesser General Public License (LGPL):** Libraries are treated permissively, major derivatives and direct source + usage forces inheriting copy-left. +- **Adaptive Public License (APL):** An incredibly detailed license which provides a template for users to slightly + modify it to their exact needs. +- **Mozilla Public License (MPL):** Uses files as the boundaries between MPL-licensed, and proprietary/otherwise + licensed parts. If a file contains MPL code, copy-left is propagated to that file only. +- **Eclipse Public License (EPL):** This license is made to be very similar to GPL, but with the intention of being + more business-friendly, by allowing to link code under under it to proprietary applications, and licensing binaries + under a proprietary license, as long as the source code is available under EPL. ## Picking your license -While you aren't required to add a license of any kind to any of your source-available projects, it's a bit weird to -have a project's source code available without any license giving others rights to actually improve it and use it. At -the moment, all of the contributors to such projects are actually breaking the copyright law which isn't ideal (unless -they live in a country which doesn't respect copyright, but again, that's very rare). Even though I'm sure most people -with projects like these don't actually have the intention to sue it's contributors, authors of these projects -technically could. That's a bit unexpected for the contributors and it could make contributing to projects like these a -bit scary, and it would certainly discourage many people from not just contributing, but possibly also using this -project at all. +Whenever you make a new project, you should also figure out how will you want to license it category-wise. Should it be +permissive? Should it be copy-left? Is it a library? If so, should it be weak copyleft? So on and so forth. After you +know that, you should start considering the possible licenses in the category of your choosing, so for example if you +ended up on strong copy-left, should it be GPL-3, GPL-2, AGPL, or maybe something else entirely. -**Some great websites:** -- There is a [page from GitHub](https://choosealicense.com/) that may help you pick the correct license for your - project. -- Another website to help you pick a license is the [license picker from heathermeeker](https://heathermeeker.com/open-source-license-picker/). -- You can also check out a post in the GitHub docs about licensing projects - [here](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository) -- Yet another wonderful site you should check out is , which can quickly show you the details about -what a given license requires from others when they use your code, and what rights it gives them. +{{< notice tip >}} +If you need some help on picking the license, check out some of these pages, which are made to simplify this process a +bit: + +- [The healthermeeker's license picker](https://heathermeeker.com/open-source-license-picker/) gives you a bunch of + questions about your project, and shows you the license you'll want based on your answers +- [TLDRLegal](https://tldrlegal.com) allows you to quickly see some key points about a given license, without the need + to read the entire license's full-text. +- [Choosealicense](https://choosealicense.com/licenses/) is a webpage made by GitHub, which can show you points about + some of the most commonly used licenses helping you pick the right one. + {{< /notice >}} + +{{< notice warning >}} +If you want to add a license to an existing project, which didn't have any license before, or if you want to change the +license, depending on many factors, you may face some difficulties. To understand how to go about this, check out [my +other post]({{< ref "posts/changing-license" >}}) that talks specifically about changing licenses, or adding licenses +to previously unlicensed code. +{{< /notice >}} ## Limitations Before picking your license, you should be aware of the limitations it may create for your project. While you can obviously pick any license for your projects whatsoever (including no license at all), if you pick a permissive -license, you immediately loose the right to use any copy-left licensed code (unless it's a weak copy-left and you're in -the exception). It is therefore very important to know your dependencies and the licenses of the code you're using in -your codebase directly. - -You as the author of that project do need to follow the licenses of the other projects you're using in your project. -Even with permissive licenses, there may be certain terms you need to follow in order to meet the conditions of that -license and be allowed to use the code from that project. Most commonly this will be the requirement to mention the -usage of said code/mention it's copyright holder/mention the original source repository/... +license, you immediately loose the right to use any copy-left licensed code _(unless it's a weak copy-left and you're +in the exception, or unless you [relicense]({{< ref "posts/changing-license" >}}))_. It is therefore very important to +know the licenses of your dependencies and of the code you're going to be using in the codebase directly. In vast majority of cases, if you're using a packaging system (such as pip for python, npm for node, cargo for rust, -...) these will create dependency listings, which will often fulfill the requirement and it's possible to get it's -source url because of that package manager. Luckily, most libraries are generously licensed under weak copy-left or -permissive licenses, and they don't really have any other terms that would make things more complicated apart from just -a simple mention, even if that's just done by the package manager in the project's dependencies. However it may not -always be the case, and for those cases, you may need to do something special apart from/other than just a mention like -this to fulfill that license, and if you aren't willing to do that, you simply can't use that project. - -Even if you're licensed under a copy-left license and you're using some copy-left repositories code licensed under the -exact same license, just having that license may not be enough to fulfill it's terms, in fact in most of the cases it -won't be. You will often need to mention the original source (again, if it's a dependency, a simple listing may be -enough for this), not make any software patents with that license, not use the project's trademark, state the changes -from the original project, etc. So no matter if your licenses are permissive or copy-left, there may be other terms and -you need to make sure they're followed, otherwise you may be violating that license. - -To avoid things from getting too messy, you may want to make a file that will explicitly mention which parts of your -codebase aren't actually licensed under the main license, but instead belong to someone else and are licensed -differently. In fact some licenses even require your project to have such a file. In there, you'll often want to -include full text of that other license and then below (or above) the copyright holders/links to original sources/other -stuff which said license requires. This can make it a lot easier to keep track of which parts of your code-base aren't -actually covered by your main license, but are instead using some other license. It can also keep you from making -mistakes if you wanted to change a license as you'll immediately see if you have some code that isn't compatible with -some new license you'd like to relicense to (more in the changing license category). - -## Changing the license - -If you initially licensed your code under a certain license, and after reading this (or really for any reason and at -any point) you decided you want to change that license, you may run into some problems. - -### The easy part - -If nobody else owns the copyright to your code and you don't have any internally used incompatible code with the new -license (copy-left dependency or code), you can relicense, your code is yours to do whatever you like with. But once -other contributors are added to the equation, things get a lot more complicated. If that's the case, follow the messy -part below. - -If your code was initially licensed under a permissive license, you're usually fine as you can sublicense because of -that permissive license, no matter if the next license is going to also be permissive, or if it will now be copy-left, -or even a proprietary license. Of course the licenses of all of your dependencies are most likely also permissive if -your main license is permissive so they should also be compatible, but again, permissive licenses may have some -exceptions to relicensing and while this is pretty much never the case with FSF approved ones, you should always make -sure. - -### The messy part - -However if your project has multiple contributors and it's licensed as copy-left, you will have more work to do. First -of all, check if you have some copy-left licensed dependencies/parts included in your codebase, and if you do, ensure -all of them will be compatible with this new license (most likely they won't be as just a slight change to a copy-left -license usually means it's no longer compatible, but there may be some compatibility clauses in your license allowing -this). Note that even if the license you're switching to is compatible with your main project's license, it doesn't -necessarily means it's also compatible with the copy-left dependencies, since they could've only been compatible with -your current (old) license because of some compatibility clauses, which however don't also extend to that new license, -even though your current license has a compatibility clause with it. This can sometimes get really complicated, however -luckily most people usually stick to only a few common copy-left licenses and compatibility questions about them were -already answered, just look them up. - -If some of your dependencies aren't compatible though, you'll need to remove them and use something else, or write it -yourself. Otherwise, the next step will be to check if your main project's license is compatible with the new one, if -it is, it's completely safe to change the license, just like it would be with a permissive licensed project. - -However, if the main license isn't compatible, which will basically always happen if you're going from copy-left to -permissive, but also if you're just going to different copy-left license without an explicit compatibility clause, you -will face some issues. - -If you are the sole copyright owner and all of the dependencies/code parts are compatible, you can just switch as an -owner of that code, but that's often not the case. In which case, you will have some other contributors, which hold the -copyright to certain parts of your project. Each line of code added by someone else will mean the copyright will belong -to them (unless it's explicitly stated otherwise) and you can't simply change the license as these other copyright -holders originally submitted their code under the terms of the main project's license, which didn't allow you to change -it. - -Don't worry though, there is a way around that, but it's not particularly easy to achieve. Your next step now will be -to find a legal way to still change the license, which is only achievable in 2 ways. First way is to just remove all of -the code by any other contributors, which will most likely mean you'll need to rewrite a lot of the project yourself -without using any of the code from those contributors, the other way is to get their written consent that alters their -copyright on that work and allows you to sublicense. This can be done by either them assigning their copyright to that -code to you completely, or by them extending their copyright to also include a different license terms being the new -license you want to sublicense under (or some other license which allows sublicensing like that). This won't be easy as -you'll need to find out some way to contact all of these contributors, and even if you can achieve that, getting their -written consent to relicense can be very difficult. - -This is why in most realistic scenarios, if you will be relicensing with a lot of contributors, you'll end up having to -go with a mixture of those two options and rewrite the code of the people you weren't able to reach/didn't give you the -consent to relicense, and use the written consent of the rest. - -It's probably clear by now that changing a license of a copy-left licensed work is really hard, but that's very much -intentional, after all copy-left is here to prevent license changes unless the contributors agreed to it, either via a -clause in that license directly stating that it allows sublicensing to some other license (usually next version of -itself), or via an explicit permission from said contributor. - -## Common legal documents about licensing - -In many projects you'll find out that before you're allowed to contribute something to an open-sourced, you'll be -required to sign a document stating certain things. This is mostly the case of contributing to projects maintained by -big companies, but what are these documents for, and should you be signing them? - -### Contributor's license agreement - -Following the relicensing category, it should be clear that any copy-left licensed project wishing to relicense won't -have it easy and it may take years to gather the consents of all of the contributors to actually achieve that -relicensing. Because of this, many companies chose to instead just get this consent beforehand, with what's called a -["CLA"](https://en.wikipedia.org/wiki/Contributor_License_Agreement), which is a short for "Contributor's License -Agreement". - -CLA is a legal document that each contributor is required to sign before the company will allow any code from said -contributor to get into their (usually copy-left licensed) codebase. This agreement states that all code contributed by -the person who signed it will have it's copyright transferred over to that company. Making this company the single -copyright owner and therefore making it really easy for them to change the project's license if the current license -became inadequate. - -But know that signing an agreement like this is very dangerous if you care about that code staying open-sourced. The -copy-left licenses are great because they're enforced by the combination of various small copyrights present in that -codebase, but the holders of these copyright each agreed to distribute their work, so long as the conditions of given -copy-left license will be followed. But when there is a single owner of the entire project, as I said before, it's -their work, they can relicense under anything they want. This includes closing down the project and licensing under a -proprietary license, and you as a contributor, even if you wrote over 50% of that code, because you've assigned your -copyright to that company, won't be able to do absolutely anything about this relicensing. - -This is why if you're going to be signing a CLA, you should at least make sure that they include a "transfer -back/nullation" clause that doesn't allow them to relicense the code under any closed source proprietary license, so -you at least make sure the code-base will always end up being open-sourced, even though it may not end up being under -the same license. These nullation clauses can be as specific as desired and can even enforce staying on copy-left -licenses, or staying on some specific type of open-sourced licenses. But most companies wont' actually include clauses -like these in their CLAs and while you can ask them to include it, you most likely won't have much success with that -and instead your contributions will just be declined. - -So just be aware what signing a CLA really means and that after you do so, you've given that company the rights to do -absolutely anything with your code, no matter the initial license that code was released under. - -It is also very common for employees with a clause in their contract that states that all of the work they do while -inside of that building/while using the companies computers/while contributing to company-owned source code/..., you as -an owner of that creative work you made assign the copyright which you automatically gained to that company, therefore -making it the sole owner of all of the source-code (and other things) maintained by them even though it wasn't written -by them. - -This is basically a CLA, except it's usually way more invasive, i.e. it doesn't just apply to the work you submit to -companies projects, but also personal work, if you worked on it on their machines/in their building/... This is often -the reason why many people who developed their own projects which grew a bit bigger got legally transferred over to -some company they once worked in, just because they wrote even just a single line of that project on that companies -computer, immediately giving your copyright to that project over to that company. So be careful to inspect the terms of -your contract when getting a job as a programmer, and make sure if you're working on some personal project to not do so -while on the job. - -### Developer Certificate of Origin - -A ["DCO"](https://en.wikipedia.org/wiki/Developer_Certificate_of_Origin), or Developer Certificate of Origin is a legal -document that deals with ensuring that all of the code you submit to some codebase is indeed owned by you, or you have -a legal right to use it and contribute it to that codebase. It also requires you to have the right to assign this -contributed work to the license of that project, which extends the copyright of that code accordingly to the terms of -that license. - -This kind of document is pretty important because without it, it would be the owners of that repository who would face -legal issues if their project contained some code it wasn't allowed to use and especially for bigger projects, but for -smaller ones too, it can be very difficult to verify that the code a contributor wants to add is actually their code to -begin with. Making all contributors sign this document before allowing them to contribute to the repository is a way to -ensure that the project's maintainers won't be the ones facing the legal issues for having code that they didn't have -right to use in their project, but instead it will be the person who contributed it who will be held liable. Of course, -this code will still be required to be removed from this project, even though it wasn't the fault of the maintainers -that it got included, but at least they won't be facing any fines or things like that and instead it will be the -contributor facing these. - -This solution isn't full-proof and the project maintainers may still be the ones held liable even though a DCO was in -place, however it will at least mean that the maintainers themselves can then hold the contributor liable which usually -does a good enough job of scaring anyone who'd want to add a code they don't have the rights to into a codebase as -they'll now know that they could be facing lawsuits after doing so. - -I think it makes sense for projects to include this document and you generally shouldn't be afraid to sign it (so long -as you're not submitting any stolen code, which you really shouldn't be doing even if there isn't a DCO in place). It -gives the maintainers at least some level of certainty that the submitted code isn't stolen and unlike a CLA, it -doesn't really do anything with your copyright rights to that project, it just confirms that you do in fact hold them. +...) these will create dependency listings, which will often fulfill the license's mention requirement since it's +source url will be mentioned by the package manager, and the original source is often included somewhere along with the +license, fulfilling the include license requirement. +In many cases, it is therefore enough to just add these libraries via the package manager without any worries. +Especially since most utility libraries are generally going to be licensed under weak copy-left allowing library usage +or permissive licenses. However it may not always be the case, and when that happens, you may need to do something +extra to comply with that license (like making sure you're not using any software patents, not using the project's +trademark, etc. For that reason, you should ALWAYS make sure that you are in fact following the licenses of your +dependencies. ## My personal preference -In my opinion, to truly support open-source as much as possible, I try to stick with copy-left licenses, because it -prevents my code from ever becoming proprietary as anyone wanting to use my copy-left licensed code will need to -distribute it's source-code along with the executable and they will need to follow the exact terms of the license which -I've picked. +In most cases, I prefer strong copy-left, specifically I usually stick to the simple GPL v3 license, as it meets all of +the things I'd want from a license, however when I'm making libraries which I know many people may end up using, I +don't want to discourage that usage by forcing them to propagate my license as many people simply don't like licensing +their code under a copy-left license, so weak copy-left works better for me there, specifically I choose LGPL v3 for +cases like that. -In most cases, I go with strong copy-left, specifically with the simple GPL v3 license, as it meets all of the things -I'd want from a license, however when I'm making libraries which I know many people may end up using, I don't want to -discourage that usage by propagating the copy-left and requiring these projects to also use GPL as many people don't -like licensing their code under something copy-left, so I use weak copy-left there, specifically LGPL. Although to -truly support open-source, it can sometimes make sense to use strong copy-left even on libraries, as it forces everyone -using it to also keep their project open, and therefore this could really help grow the open-source community even -more. Also, do keep in mind that LGPLed code isn't GPL compatible and therefore if you do make an LGPLed library, you -won't be able to use any GPLed code/library in it! +Although to truly support open-source, it can sometimes make sense to use strong copy-left even on libraries, as it +forces everyone using it to also keep their project open, and therefore this could really significantly help grow the +open-source community, by forcing even companies to make their code open, because otherwise they just won't be able to +use your library. Depending on how complex this library is, they might end up reimplementing it themselves, bypassing +you entirely though, but if doing that is not so easy, it might simply not be worth it, and the company will instead +decide to just go open-source, following your license. -Another great license to consider is the Mozilla Public License which came up with the very interesting file-based -copy-left propagation and therefore enforces all of your code to always stay open, even if it lives in an otherwise -proprietary codebase. I also find the clause allowing individual copyright holders being able to withdraw all code -covered by their copyright licensed under MPL from a given code-base simply by sending a written notice to do so really -interesting, however it could also be somewhat risky, both for people deciding to use your MPL code in their codebase, -as that project could basically immediately be destroyed by someone owning the copyright to a lot of the code of that -project but also to your project specifically because of the same reason. If you have someone interested in your -project who has already contributed a lot of code into your codebase suddenly change their mind (perhaps because they -now want to make their own competing project, or really any other reason), suddenly you may be forced to take out all -of their code from the code-base of your own project, which is why I'm hesitant to use it in many places, however it -remains very interesting to me and I may change this opinion over time. +Another benefit with using full GPL on libraries is that you get to utilize code from other GPLed code-bases, while +with LGPL, this actually isn't possible, because GPL isn't compatible with it (you can't relicense GPL code into LGPL). -I'm generally against permissive licenses though as in my opinion, they well .. give out too many permissions. I get -the people who license their code under these licenses, interested in bigger companies using their code/libraries in -their projects and perhaps getting some contributions from these companies back into your codebase, improving your -project, I feel like it's too much of a threat to open-source. The thing is, if we didn't use any permissive licenses -and instead only used strong copy-left everywhere, these companies with their proprietary code-bases would either need -to write and maintain everything from scratch, which would be near impossible even for really big companies, or simply -be forced into also using these copy-left licenses and make their code open, which would be, at least in my opinion, a -really nice thing, as it would allow us to make derivatives of those works because of these freedom respecting -copy-left licenses, allowing us to make alternative versions to basically all software out there that's completely for -free and without any telemetry at all. Of course, this is quite unrealistic to actually happen anytime soon, but if you -think it's a nice idea, you can at least do a little bit by keeping your code copy-left licensed. +I'm generally against fully permissive licenses, as in my opinion, they simply give out too many permissions, and while +in the ideal world, this would be fine, that's just not the world we're in. I get the people who license their code +under these licenses, since they at least mean that the bigger companies will have a lot of open code in their +code-bases, but I'm just fundamentally against my code being used in a proprietary project, at least without being +compensated appropriately for it. -Then again, this is purely my stance on this and you should make up your own mind and decide what works best for you, -I'm not here to force my opinion on anyone, but I did want to express why I feel the way I feel about permissive -licenses and what I like using, in hopes that someone will perhaps not have considered these arguments and may be -persuaded to also use copy-left and expand the open-source community by it, but again, I wouldn't want to force that on -anyone, it's your work and you can license it any way you want. +When I publish my code, I do it so that everyone can use it freely, to support the open-source community. I don't do it +to support big companies, only to use have my code used in their closed-sourced projects, or even worse, to have my +entire project copied and relicensed, with a bunch of added telemetry and other user-intrusive features, to the point +where it's basically spyware, with them then happily releasing it under their banner, selling and advertising it to +everyone, without having any say in it, since my license allowed it. + +Instead, I just use a license which allows anyone to use my code, as long as they give out the same guarantees as I +did with my project, allowing anyone to modify it, etc. And if some company would want to use my code in a different +way, they can always contact me and we could discuss me giving them a different license over it (see [post about +multi-licensing]({{< ref "posts/multi-licensing" >}})), for some compensation. I don't want to write code for companies +which I'm not gonna be payed for. But I'm absolutely for writing code for people like me, who just want to use it in +their own open-sourced projects, and for giving back to the community as a whole. + +{{< notice tip >}} +Another great license to consider is the [**Mozilla Public License**](https://www.mozilla.org/en-US/MPL/2.0/) which +uses a very interesting **file-based weak copy-left** propagation and therefore enforces all of your code to always +stay open, even if it lives in an otherwise proprietary codebase, by requiring the file with MPLed code be MPLed in +it's entirety, but the rest of the files, even if they then use the code (via imports/linking) won't be affected. + +I still personally prefer strong copy-left, because it has this "give-back" property, but for people who just want their +code to stay open, without caring as much about it being in a project that abuses it, this may be an amazing choice +instead of going full permissive. +{{< /notice >}} + +Then again, this is purely my stance and you should make up your own mind and decide what works best for you, I'm not +here to force my opinion on anyone, it's your code and I firmly believe that you should be able to do anything you want +with it, but I did want to express why I feel this way about permissive licenses and what I like using, in hopes that +someone will perhaps not have considered these arguments against permissive licenses. But again, I wouldn't want to +force that on anyone, it's your work and you can license it in any way you want.