From b213a687876756985782fd20f7ff901788ab8df1 Mon Sep 17 00:00:00 2001 From: ItsDrike Date: Mon, 24 Jan 2022 00:50:21 +0100 Subject: [PATCH] Add post about software licenses --- content/posts/software-licenses.md | 505 +++++++++++++++++++++++++++++ 1 file changed, 505 insertions(+) create mode 100644 content/posts/software-licenses.md diff --git a/content/posts/software-licenses.md b/content/posts/software-licenses.md new file mode 100644 index 0000000..814fffc --- /dev/null +++ b/content/posts/software-licenses.md @@ -0,0 +1,505 @@ +--- +title: Software Licenses +date: 2022-01-23 +tags: [programming] +--- + +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. Not choosing a proper 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. + +## Why are licenses important + +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. + +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. + +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. + +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. + +## 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. + +### 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. + +But 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 a 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). + +This is a way to enforce that your code will always stay under the same licensing terms and every other project using +it will need to be open-sourced along with your code. If any other project contains any parts from copy-left licensed +project(s) without itself being copy-left licensed, it is in violation in this license causing it to no longer apply. +But this license was the only thing giving that project a legal right to use code of some other copyrighted code, +without it, that project is now using copyrighted code without permission, making it violate the copyright law and any +of the copyright holders who had their code used by this other project without following the terms of this license can +sue the authors of such project. + +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 is 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 of them) copy-left licenses often +also 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. Though there are some licenses which actually prohibit even something like this, +but because of that, these licenses can end up being really hard to follow. + +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 also the version 2. +Another a bit less commonly used is the Mozilla Public License (MPL). + +### 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. While there can be some licenses which are still +considered permissive even though they forbid sublicensing to certain kind of licenses, this is pretty rare and can +only go so far. Licenses that do this may be considered permissive, but they're usually refused to be accepted as "free +software licenses" because of these restrictions which may limit the freedom of others to truly use and do whatever +they may want to with that software. + +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. + +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. This means they could improve the software a bit, add all kinds of +trackers constantly sending everything you do with their 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 sending the mined profit to them. Things like these are unavoidable with a license allowing this much freedom, +and even though it may require that project to mention 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. + +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. + +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. + +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. + +The most notable public domain license is the "Unlicense" license. + +### 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 this subcategory as it does rely +on this definition. + +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. + +In other words, the "weak" copy-left licenses are those where there can 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. 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 license under the same (or compatible) copy-left license. + +This makes weak copy-left licenses somewhat of a compromise between strong copy-left and permissive licenses where you +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. + +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. + +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. + +- 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.) + +## How are these licenses enforced + +It is important to understand how exactly the open-source 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 those 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). 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" an open-source 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 +open-source 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, in fact what they mean is that since you didn't meet the conditions of +that license, you're violating copyright. + +So remember, a software license can only ever give the recipient of the creative works additional rights, it can never +takes away rights. + +## Picking your license + +While you aren't required to add a license of any kind to any of your source-available projects, it's a bit weird to +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 possible also using this +project. + +**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. + +## 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 still need to follow the licenses of the other projects you're using in your project. +Even with permissive licenses, there may be certain terms you need to follow in order to meet the conditions of that +license and be allowed to use the code from that project. Most commonly this will be the requirement to mention the +usage of said code/mention it's copyright holder/mention the original source repository/... In vast majority of cases, +if you're using a packaging system (such as pip for python, npm for node, cargo for rust, ...) these will create +dependency listings, which will often fulfill the requirement and it's possible to get it's 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 sharing the 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. + +If you wanted to, or if the license of a project you're using requires it, you may want to make a file that +explicitly mentions which parts of your codebase aren't actually licensed under the main license but instead belong to +someone else and are licensed differently. 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 you've licensed under copy-left, you will 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 your 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 dependencies 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 is 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 often 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 probably not the case since you'd have stopped +reading as I've already said that. So the other option is that you 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, or you'll need to get their written consent that allows you to +sublicense. This can be done by either them assigning you their copyright to that code, or by giving you a one-time +consent to just relicense to certain license you asked for. 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 won't +be very easy. + +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. + +This is also why it is very common for employees to have a clause in their contract that states that all of the work +they do while inside of that building, or while using the companies computers, or while contributing to company-owned +source code, by signing it you as an owner of whatever creative work you create that meets these criteria sign over the +copyright you automatically gained as it's owner to that company, therefore giving them the rights to be the sole +owners 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 involved, i.e. not just including 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. + + +## 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 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! + +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. + +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. + +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.