[Open question] Why are so many open-source projects, particularly projects written in Rust, MIT licensed?
Technology
14
Beiträge
9
Kommentatoren
71
Aufrufe
-
cross-posted from: https://programming.dev/post/30924455
A few people pointed out that many [R]ust projects were MIT licensed and since then I indeed have seen MIT licensed projects everywhere in Rust. Then I found the link of this post and it looks like MIT was by far the most popular license in all of opensource in 2023.
Any ideas why?
The most popular licenses for each language in 2023
The 2023 report of the licenses in use by the biggest package managers highlights the need to educate developers on the importance of licensing information. While many developers know that…
Open Source Initiative (opensource.org)
-
cross-posted from: https://programming.dev/post/30924455
A few people pointed out that many [R]ust projects were MIT licensed and since then I indeed have seen MIT licensed projects everywhere in Rust. Then I found the link of this post and it looks like MIT was by far the most popular license in all of opensource in 2023.
Any ideas why?
The most popular licenses for each language in 2023
The 2023 report of the licenses in use by the biggest package managers highlights the need to educate developers on the importance of licensing information. While many developers know that…
Open Source Initiative (opensource.org)
If you want to put an idea out there, permissive licenses are the most likely to promote it. Any individual or organization can use it without restrictions (or restrictions that aren't unpalatable to most). So if what you're trying to promote is an idea, a technique, or a standard, this type of license allows it to have the greatest reach.
-
cross-posted from: https://programming.dev/post/30924455
A few people pointed out that many [R]ust projects were MIT licensed and since then I indeed have seen MIT licensed projects everywhere in Rust. Then I found the link of this post and it looks like MIT was by far the most popular license in all of opensource in 2023.
Any ideas why?
The most popular licenses for each language in 2023
The 2023 report of the licenses in use by the biggest package managers highlights the need to educate developers on the importance of licensing information. While many developers know that…
Open Source Initiative (opensource.org)
It's an easy license to reason about, allows for basically any project to use it, and you don't need to worry about trying to enforce it (Because the GPL is only as good as your lawyers are)
-
cross-posted from: https://programming.dev/post/30924455
A few people pointed out that many [R]ust projects were MIT licensed and since then I indeed have seen MIT licensed projects everywhere in Rust. Then I found the link of this post and it looks like MIT was by far the most popular license in all of opensource in 2023.
Any ideas why?
The most popular licenses for each language in 2023
The 2023 report of the licenses in use by the biggest package managers highlights the need to educate developers on the importance of licensing information. While many developers know that…
Open Source Initiative (opensource.org)
The crux of it is that it allows for commercial use without needing to distribute the source code. Whether that's a good thing or not depends on who you ask. There's basically a continuum for open source software with GPLv3 at one end and MIT at the other.
GPLv3 guarantees that corporations can't play games with patents or weird DRM to hobble an open source library and tie it to their closed source product. A lot of corporations will specifically bar employees from using GPLv3 code out of fear it could force them to open source their proprietary code as well.
At the other extreme you've got MIT which basically says do what you want with it. Fork it, embed it in your projects, sell copies of it if you want. Anything goes as long as you include a copy of the MIT license along with your software.
Rust tends to get a lot of commercial usage so GPLv2 or MIT tend to be chosen over GPlv3, and between them most companies feel more comfortable with MIT.
-
If you want to put an idea out there, permissive licenses are the most likely to promote it. Any individual or organization can use it without restrictions (or restrictions that aren't unpalatable to most). So if what you're trying to promote is an idea, a technique, or a standard, this type of license allows it to have the greatest reach.
People seem to forget that most of the open source language library code out there is written by people working for companies, being sponsored by companies or writing it so they can use it where they work. Some might start out as hobbiest projects but if it survives and grows it eventually will be sponsored in some form. Even if indirectly by some guy that wants to use it where he works.
-
People seem to forget that most of the open source language library code out there is written by people working for companies, being sponsored by companies or writing it so they can use it where they work. Some might start out as hobbiest projects but if it survives and grows it eventually will be sponsored in some form. Even if indirectly by some guy that wants to use it where he works.
From what i understand if you wrote it you can just license the public version via GPL and license the private version that you wrote for your job what ever you want since you own it.
This assumes you wrote the project without company tools and on your free time.
-
From what i understand if you wrote it you can just license the public version via GPL and license the private version that you wrote for your job what ever you want since you own it.
This assumes you wrote the project without company tools and on your free time.
You can always use your own code however you want. However, if your project starts to get contributions from other people, that's where it can start to become more muddy.
-
From what i understand if you wrote it you can just license the public version via GPL and license the private version that you wrote for your job what ever you want since you own it.
This assumes you wrote the project without company tools and on your free time.
The company you work for will likely not like that. Needs a special case license to be drawn up would probably need to involve lawyers and cost far more then is worth the hassle. Vastly easier just to give it a MIT license.
-
From what i understand if you wrote it you can just license the public version via GPL and license the private version that you wrote for your job what ever you want since you own it.
This assumes you wrote the project without company tools and on your free time.
If you license your project under GPL, and somebody submits some code (like through a pull request) that ends up in the library you use, you are now also bound by the GPL license, meaning you also have to publish the source of any derivatives.
The way to avoid it is to use something like a CLA, requiring every contributor to sign an agreement giving you special rights to their code, so you can ignore the GPL license in relation to the code they wrote. This works, but is obviously exploitative, taking rights to contributions while giving out less.
It also means if somebody forks the project, you can't pull in their changes (if you can't meet GPL terms, of course), unlike with MIT, where by default everybody can make their own versions, public or private, for any purpose.
Though it's worth noting, if you license your code under MIT, a fork can still add the GPL license on top, which means if you wanted to pull in their changes you'd be bound to both licenses and thus GPL terms. I believe this is also by design in the GPL license, to give open-source an edge, though that can be a bit of a dick move when done to a good project, since it lets the GPL fork pull in changes from MIT versions without giving back to them.
-
If you license your project under GPL, and somebody submits some code (like through a pull request) that ends up in the library you use, you are now also bound by the GPL license, meaning you also have to publish the source of any derivatives.
The way to avoid it is to use something like a CLA, requiring every contributor to sign an agreement giving you special rights to their code, so you can ignore the GPL license in relation to the code they wrote. This works, but is obviously exploitative, taking rights to contributions while giving out less.
It also means if somebody forks the project, you can't pull in their changes (if you can't meet GPL terms, of course), unlike with MIT, where by default everybody can make their own versions, public or private, for any purpose.
Though it's worth noting, if you license your code under MIT, a fork can still add the GPL license on top, which means if you wanted to pull in their changes you'd be bound to both licenses and thus GPL terms. I believe this is also by design in the GPL license, to give open-source an edge, though that can be a bit of a dick move when done to a good project, since it lets the GPL fork pull in changes from MIT versions without giving back to them.
In my case, the repository does not allow pull requests so it's fine.
-
The crux of it is that it allows for commercial use without needing to distribute the source code. Whether that's a good thing or not depends on who you ask. There's basically a continuum for open source software with GPLv3 at one end and MIT at the other.
GPLv3 guarantees that corporations can't play games with patents or weird DRM to hobble an open source library and tie it to their closed source product. A lot of corporations will specifically bar employees from using GPLv3 code out of fear it could force them to open source their proprietary code as well.
At the other extreme you've got MIT which basically says do what you want with it. Fork it, embed it in your projects, sell copies of it if you want. Anything goes as long as you include a copy of the MIT license along with your software.
Rust tends to get a lot of commercial usage so GPLv2 or MIT tend to be chosen over GPlv3, and between them most companies feel more comfortable with MIT.
A lot of corporations will specifically bar employees from using GPLv3 code out of fear it could force them to open source their proprietary code as well.
That's based on a fundamental misunderstanding of GPLv3, or (more likely) bad faith.
-
If you want to put an idea out there, permissive licenses are the most likely to promote it. Any individual or organization can use it without restrictions (or restrictions that aren't unpalatable to most). So if what you're trying to promote is an idea, a technique, or a standard, this type of license allows it to have the greatest reach.
And if you're trying to maintain an open ecosystem, use GPL.
-
From what i understand if you wrote it you can just license the public version via GPL and license the private version that you wrote for your job what ever you want since you own it.
This assumes you wrote the project without company tools and on your free time.
This assumes you wrote the project without company tools and on your free time.
Even then. some employment contracts try to take the piss and claim ownership of anything you produce while you're employed. Clauses like that are unenforceable in many jurisdictions, but I've taken the liberty of redlining them before signing the contract. That means another half-day wating for Legal to look at it, but it's worth it for the removal of ambiguity about what I intend to do. By the way, I've never had an offer withdrawn for doing that.
-
It's an easy license to reason about, allows for basically any project to use it, and you don't need to worry about trying to enforce it (Because the GPL is only as good as your lawyers are)
you don’t need to worry about trying to enforce it (
By the simple expedient of there being essentially nothing you can enforce.
