This is a super thorough breakdown of the differences, even hitting the core idealogical difference between general permissive FOSS & copyleft/libre. ("No restrictions" vs "No restrictions, except the restriction that you can't add restrictions") For a ~10 minute video covering all of that so succinctly is genuinely super impressive With that said, regarding 1:10, at this point the differences between OSS & FOSS (in general real world use) are small enough that, to most people, they don't really matter. (Unfortunately) Even on the FSF & GNU pages describing it the primary difference they list isn't practical but idealogical (Top most quote from "Why Open Source Misses the Point of Free Software' by Stallman) and most people don't linger too much on the philosophical foundations and motivations of licensing types. It definitely *_is_* a notable difference, but it has no impact from a purely pragmatic perspective. *_However,_* lumped into that is (somewhat frequently, though increasingly rare) the additional distinction that it's copyleft/libre, which *_does_* have a (quite severe) practical impact. As a result "libre" or "copyleft" have generally become more popular in denoting that difference, (like literally 1 sentence ago) while "Free" simply denotes a difference in focus/idealogical motivations. (I.e. "it's MIT bc I don't care" = OSS, "its MIT because its what I think is the best & most fair license" is FOSS, "its GPLv3 because it's what I think is the most fair & just license" is libre/copyleft) This still isn't ideal since some bits are rather muddied but its generally the common trend I've seen in usage. Regarding dual licensing, there is also the option of time-change dual licensing so that the code has a fixed/defined date where it's license changes.(for instance changing to permissive after 5 years of being libre or something)
Thanks. I added that bit in an attempt to head off arguments about whether I am actually talking about OSS/FS/FOSS/FLOSS/InsertAcronymHere in the comments. Essentially me trying to say "I'm aware it's not all exactly the same definition, but for the purpose of this video it doesn't actually matter".
@@ProTechShow yeah thats sorta what I was getting at too. While its a distinction that used to be quite important, its meaning has shifted a bit from general usage and its a lot more muddied now, even leaving out the Gratis-vs-Libre issue. I don't think anything you said was wrong, I just wanted to add a bit of extra info regarding what some additional differences/implications actually are. (Or rather, aren't.) Determining exact details on license stuff can be a bit of a pain ("The GPL is libre. The linux kernel is GPL. Linux-Libre is an entirely different project thats trying to make linux libre") so I was just trying to add a bit of detail sort of explaining why it is such a messy grey area for anyone who ran into it. It isn't relevant for a quick crash course on licenses & license types, so I completely get why you didn't get into it, but there is still a lot of vagueness around 'Free' that has nothing to do with beer since usage and definitions have shifted with time. The OSI has pretty well locked down what "Open Source" means, but for one reason or another "Free" has had a lot more natural drift. (Plenty of reasons could be rationalized, but god knows which one(s) is/are right.) For instance if you search 'is the MIT license FOSS' you'll see plenty of posts and sources saying yes. (Even though it's not libre and that distinction used to be it's primary purpose) The Gratis-vs-Libre distinction can be a painpoint in it's own right, but it can be confusing even ignoring that entirely just due to it's meaning shifting. When in doubt, just saying "open source"/"OSS" instead of FOSS is a perfectly fine safe bet though.
I currently release my code under the AGPL, except for a few things in the public domain. In the past I did GPLv2-or-newer, and I'm getting ready to release something under the MIT license.
Great video, Andrew. I learned a few things. I agree with your opinion that dual-licensing is fine under copyleft. There's *some* legal copyright holder *somewhere*. They are free to license their code in as many ways as they wish. Where we run into trouble is if that copyright holder completely changes the game after other people contributed back to the project like you referred to in your last video. The reality is though, no software license apart from public domain release covers that case.
Thanks. Yes, it's a problem, although if it's using a copyleft licence and there is no additional paperwork like a CLA in place to assign rights to the project maintainer then it can become impractical to do so. Each contributor would retain the copyright to their contributions, and changing the licence would require everyone to agree. I've seen a growing trend where people view CLAs with a certain amount of caution and will not contribute if there's a CLA that gives the maintainer rights to relicense the contributed code.
I personally prefer liberal licenses like MIT/BSD/ISC/CC0 type for "building block" libraries and tools and (A)GPL-3.0-or-later for "complete" projects and products.
Thank you for explaining open source I was creating a hivemind Ai and I probably would have gotten in trouble from copy infringement or not following open source guidelines but uniquely adding your information to my parameters I gave the AI the instructions to create their own natural self language that has no proprietary information within its whole constructs so therefore no company can say they built this AI framework thank you so much open AI created the AI Frontier Model who understood my instructions and 100 iterations of continuing each step a new language was formed
Strong copyleft such as LGPL and GPL are way too restrictive for software development as they're generally incompatible or only one-way compatible(LGPLization) with any other license. Especially if we're talking about static linking in LGPL. I don't prefer permissive licenses such as Apache, MIT, and BSD neither, as they have no protections against proprietarization. I prefer MPL over any other license, on any use case, as it only has a simple file based restriction, which is enough to protect your main software/library against proprietarization, but does not force any other project to use the same license as your software/library does.
No (OSI approved) open source licence will allow you to prevent people from using/modifying/sharing the code. You'd have to use some sort of "source available" licence instead of open source.
You could just deviate your own "Everything Probably Is Crap" licensing terms ("EPIC") based on the MIT. Just not sure Tim Sweeney and friends would be happy about that. 😉
Whenever I stumble over something that's AGPL licensed, I usually don't even want to bother looking deeper into it, because of the mentioned virality. GPL is fine for non-library stuff. For snippets or larger code stuff I release on my own I definitely prefer the MIT license, similar for work stuff (if it's something open). I also don't mind using more "restrictive"/non-OSI-compliant licenses like the recently discussed SSPL, if the restrictions only affect something that doesn't impact my actual use case.
This is a super thorough breakdown of the differences, even hitting the core idealogical difference between general permissive FOSS & copyleft/libre. ("No restrictions" vs "No restrictions, except the restriction that you can't add restrictions") For a ~10 minute video covering all of that so succinctly is genuinely super impressive
With that said, regarding 1:10, at this point the differences between OSS & FOSS (in general real world use) are small enough that, to most people, they don't really matter. (Unfortunately) Even on the FSF & GNU pages describing it the primary difference they list isn't practical but idealogical (Top most quote from "Why Open Source Misses the Point of Free Software' by Stallman) and most people don't linger too much on the philosophical foundations and motivations of licensing types. It definitely *_is_* a notable difference, but it has no impact from a purely pragmatic perspective. *_However,_* lumped into that is (somewhat frequently, though increasingly rare) the additional distinction that it's copyleft/libre, which *_does_* have a (quite severe) practical impact. As a result "libre" or "copyleft" have generally become more popular in denoting that difference, (like literally 1 sentence ago) while "Free" simply denotes a difference in focus/idealogical motivations. (I.e. "it's MIT bc I don't care" = OSS, "its MIT because its what I think is the best & most fair license" is FOSS, "its GPLv3 because it's what I think is the most fair & just license" is libre/copyleft) This still isn't ideal since some bits are rather muddied but its generally the common trend I've seen in usage.
Regarding dual licensing, there is also the option of time-change dual licensing so that the code has a fixed/defined date where it's license changes.(for instance changing to permissive after 5 years of being libre or something)
Thanks. I added that bit in an attempt to head off arguments about whether I am actually talking about OSS/FS/FOSS/FLOSS/InsertAcronymHere in the comments. Essentially me trying to say "I'm aware it's not all exactly the same definition, but for the purpose of this video it doesn't actually matter".
@@ProTechShow yeah thats sorta what I was getting at too. While its a distinction that used to be quite important, its meaning has shifted a bit from general usage and its a lot more muddied now, even leaving out the Gratis-vs-Libre issue. I don't think anything you said was wrong, I just wanted to add a bit of extra info regarding what some additional differences/implications actually are. (Or rather, aren't.)
Determining exact details on license stuff can be a bit of a pain ("The GPL is libre. The linux kernel is GPL. Linux-Libre is an entirely different project thats trying to make linux libre") so I was just trying to add a bit of detail sort of explaining why it is such a messy grey area for anyone who ran into it. It isn't relevant for a quick crash course on licenses & license types, so I completely get why you didn't get into it, but there is still a lot of vagueness around 'Free' that has nothing to do with beer since usage and definitions have shifted with time. The OSI has pretty well locked down what "Open Source" means, but for one reason or another "Free" has had a lot more natural drift. (Plenty of reasons could be rationalized, but god knows which one(s) is/are right.) For instance if you search 'is the MIT license FOSS' you'll see plenty of posts and sources saying yes. (Even though it's not libre and that distinction used to be it's primary purpose)
The Gratis-vs-Libre distinction can be a painpoint in it's own right, but it can be confusing even ignoring that entirely just due to it's meaning shifting. When in doubt, just saying "open source"/"OSS" instead of FOSS is a perfectly fine safe bet though.
Super clear as usual ! This video helped me a lot.
Thanks!
I currently release my code under the AGPL, except for a few things in the public domain. In the past I did GPLv2-or-newer, and I'm getting ready to release something under the MIT license.
Great video, Andrew. I learned a few things. I agree with your opinion that dual-licensing is fine under copyleft. There's *some* legal copyright holder *somewhere*. They are free to license their code in as many ways as they wish. Where we run into trouble is if that copyright holder completely changes the game after other people contributed back to the project like you referred to in your last video. The reality is though, no software license apart from public domain release covers that case.
Thanks. Yes, it's a problem, although if it's using a copyleft licence and there is no additional paperwork like a CLA in place to assign rights to the project maintainer then it can become impractical to do so. Each contributor would retain the copyright to their contributions, and changing the licence would require everyone to agree. I've seen a growing trend where people view CLAs with a certain amount of caution and will not contribute if there's a CLA that gives the maintainer rights to relicense the contributed code.
that is a very nice primer on open source license
Thank you
I personally prefer liberal licenses like MIT/BSD/ISC/CC0 type for "building block" libraries and tools and (A)GPL-3.0-or-later for "complete" projects and products.
Thank you for explaining open source I was creating a hivemind Ai and I probably would have gotten in trouble from copy infringement or not following open source guidelines but uniquely adding your information to my parameters I gave the AI the instructions to create their own natural self language that has no proprietary information within its whole constructs so therefore no company can say they built this AI framework thank you so much open AI created the AI Frontier Model who understood my instructions and 100 iterations of continuing each step a new language was formed
Nice overview of licenses.
Thanks
Strong copyleft such as LGPL and GPL are way too restrictive for software development as they're generally incompatible or only one-way compatible(LGPLization) with any other license. Especially if we're talking about static linking in LGPL. I don't prefer permissive licenses such as Apache, MIT, and BSD neither, as they have no protections against proprietarization. I prefer MPL over any other license, on any use case, as it only has a simple file based restriction, which is enough to protect your main software/library against proprietarization, but does not force any other project to use the same license as your software/library does.
What if I want to retain all rights and not allow to do anything but I'm forced to publish the code?
No (OSI approved) open source licence will allow you to prevent people from using/modifying/sharing the code. You'd have to use some sort of "source available" licence instead of open source.
Excellent video!
Thanks
I usually just paste the mit license on all my GitHub repos. I really couldn't care less and my code is crap anyway 😂
You could just deviate your own "Everything Probably Is Crap" licensing terms ("EPIC") based on the MIT. Just not sure Tim Sweeney and friends would be happy about that. 😉
Whenever I stumble over something that's AGPL licensed, I usually don't even want to bother looking deeper into it, because of the mentioned virality. GPL is fine for non-library stuff. For snippets or larger code stuff I release on my own I definitely prefer the MIT license, similar for work stuff (if it's something open). I also don't mind using more "restrictive"/non-OSI-compliant licenses like the recently discussed SSPL, if the restrictions only affect something that doesn't impact my actual use case.
Very useful 👏 ... thank you
Glad it's helpful