I'm not sure the title is the correct response. As in
"stop making software licenses" is not the problem.
Clearly any business can license their software any way they like.
What caused the poster some confusion is that it was marketed as an "open source" product. Once he determined it was not an OSI approved license then that should be the end of it. It's not Open Source. period.
By all means call them out on that - lots of people and companies are not licensing experts, and need guidance. I've helped people with this in the past and encouraged them to change to actual Open Source licenses that are compatible with their goals, and the goals of their community.
If anything the real headline should be "stop calling your product open source when it doesn't have an open source license".
[To be clear - I produce commercial software under not-open-source licenses. I've got no objection to folk doing that. I even ship the source with the product, and accept contributions back. But I don't call it "open source" because it's not "Open Source". It's something, sure, but it's not Open Source.]
I think your take is a much more levelheaded view of events than the authors.
I completely agree with you that we shouldn’t be restricting how people choose to license their code. And agree that the real issue is the marketing: ie people calling something “open source” when it’s actually “source available to read”.
I see quite a few organisations play this game, like Obsidian. I’ve seen highly skilled and intelligent engineers fall for the trap of calling Obsidian open source because they can inspect the code of the Electon app; forgetting that doesn’t actually grant them a license to do anything with the code.
Like yourself, I have no qualms if an organisation wants to build proprietary / for profit stuff. I understand that means they might not even want to share their code. But what I do object to is when those organisations then try to gain some open source “street cred” for something that is proprietary.
> I’ve seen highly skilled and intelligent engineers fall for the trap of calling Obsidian open source because they can inspect the code of the Electon app; forgetting that doesn’t actually grant them a license to do anything with the code.
That's because the terminology is pretty confusing, doubly so for ESL people. If you'd never had the whole open software vs. free software debate, it's easy to think that "open source" means "source code available", as this is pretty much in line with the direct reading of the phrase.
Tangential to licensing, open source in the terms you’re describing is at the very least going to put into question any legal arguments about trade secrets.
And that is a key part of the problem: conflating FS (Free Software) with OS (Open Source) to give F(OS)S.
The thing is that Free software and Open Source _don't_ quite mean the same thing, but we treat them like they do. They are close but not identical.
Also see the recent kerfuffle about RHEL and CentOS.
Free software: do whatever you want with it, including sell it, but give your users the source code. The GPL is a FS license not an OS licence.
Not the world. Not open to all. The GPL 1/2/3 etc only says, clearly and distinctly, users. If you sell your free software, then it's only the customers that get the source, and that is 100% fine and OK.
OS is a different emphasis: it was designed to appeal to companies, businessmen and managers. You get the source, so we are giving you control, agency: you can't have it stolen from you.
But it was phrased in terms of sharing and openness.
That's what OS means, because the OSI says it is.
So BSL licenses say "you can have the source, and you can contribute back changes, but we still own it, and you can't use it in prod without paying or re-sell it."
That's a restriction of use. That's neither OS nor FS.
Whereas RH's use is 100% FS compliant but gets the OS folks annoyed.
But OS is not the same as FS. What RH is doing with RHEL is FS but not OS. It's not open to the world but the GPL never said it had to be.
I don't know what the best answer is here.
I wonder if it's time for a new term which leans on the English primary meaning of "free", as in at no cost, gratis.
"This software is free to get, free to use, and free to fork, but only so long as you do not charge for whatever purposes you employ it. If you obtain revenue from running it, supplying its output, modifying it, you sell products with it built in, or any other revenue-generating operation you must pay back X% of your revenues/profits/whatever to the creators. This also applies to downstream modified versions."
IANAL. A lawyer could do much better, I am completely sure. It might not be easy but I suspect that there is a way.
And completely non-legal devs stop trying to write software licenses. You talk to the average dev and they've no idea what a license grant is, the difference between copyright and licenses.
Which is fair enough, but any custom made license is extremely unlikely to be written in a way that it can be enforced when need....
Because 90% of people would have no idea what that means. Open source on the other hand is usually something many people have at least heard about or read somewhere.
Yeah The Reference Source License is a "source available" license. It's not "open source" in the OSI sense that it can be contributed to or used for any other purpose. For a security product, "source available" is MUCH better than nothing at all (closed, proprietary). Not sure why these people chose the Microsoft reference license for their product, but I guess if you are in a hurry and you need an example of a source available license then I'd also consider just grabbing one from a megacorp that probably had armies of lawyers go over it.
> Once he determined it was not an OSI approved license then that should be the end of it. It's not Open Source. period.
Where in OSI's "Open Source Definition" [1] does it say a license must be approved by OSI to be Open Source? If that was really part of the definition, they could have had a much shorter definition!
Another thing I find funny is that CC0 isn't "OSI approved" either, because of something about patents. But strangely, the "Definition" never mentions patents. But CC0 is not approved, so apparently CC0 is not open source.
Pretty much this. Using the term "open source" (rather than "shared source", "public source", or "source available") was a good faith mistake, and we fixed that once it was pointed out.
Beyond that, I'm not really sure what the purpose of this post is except to complain about the fact that commercial software exists.
When did people start taking "open source" as a label seriously? The term means nearly nothing in material terms about what you can actually do with the source code. Certainly if you can build a business off it without distributing the source it's not very useful and certainly not much more "open source" than throwing proprietary code on github.
>> When did people start taking "open source" as a label seriously?
In the late 90's.
>> The term means nearly nothing in material terms about what you can actually do with the source code.
correct. The term means nothing in and of itself. The license determines what you can do with the code. there are a bunch of licenses that conform to the OSI definition of Open Source. If a company claims to be "open source", but then does not fit the definition of Open Source then they should expect some push-back.
I will only add that non-standard licenses also hurt adoption, specifically in medium/big businesses/enterprises.
Most organizations understand common open source licenses and there's usually a blank statement that allows teams to use GPL/MIT/whatever-licensed software.
Anything outside that subset of licenses (even if they're permissive, open source or whatnot) requires a legal review and a lot of people won't go through the pain of that process just to use a library/service/app. It's easier to just choose something else.
> The wording still precludes me forking this repo on GitHub.
AFAIK that's irrelevant per GitHub's TOS, which users agree to:
By setting your repositories to be viewed publicly, you agree to allow others to view and "fork" your repositories (this means that others may make their own copies of Content from your repositories in repositories they control).
If you set your pages and repositories to be viewed publicly, you grant each User of GitHub a nonexclusive, worldwide license to use, display, and perform Your Content through the GitHub Service and to reproduce Your Content solely on GitHub as permitted through GitHub's functionality (for example, through forking).
AIUI you therefore always have the right to fork something on GitHub.
Cave-at. If someone shares something on github which they do not have the copyright to, nor license for, then that can impossibly be okay to fork on Github.
You are correct. Github's license terms are a hedge against that sort of thing. They are basically saying "the person making this source available is granting the license to d these particular things" - therefore, the user making the source available takes on the responsibility for making sure they actually have the authority to make this source available. If they do not have this authority then they are the ones that will be sued - not Github nor any users who cloned the code.
I would think the statement "this means that others may make their own copies of Content from your repositories" is referring to cloning the forked repos locally.
Agree it's complex, and when attempting to solve a particular problem you end up with yet another license every time.
What businesses in particular want is a "Yes, you can read the code and yes you help if you want to, but you can't use the code to make your own product" source-available license (because they have devs to pay, and being able to keep doing that is the first thing they need to protect).
I think such licenses do sort of exist but they're fragmented.
The root of this particular argument seems to the definition of Open Source meaning unconstrained use of source code, instead of source-available.
They didn’t really write this license themselves. It was Microsoft license that they slightly adapted after someone complained they couldn’t contribute.
The real issue here is that the product wasn’t open source despite being advertised as such. The licensed they used, Microsoft Reference Source License, isn’t an open source license. It’s more accurately described as “source available”. Ie you can view the source but you’re not really allowed to use it for anything.
The PolyForm Project has a set of standardized source-available licenses.
"The PolyForm Project is a group of experienced licensing lawyers and technologists developing simple, standardized, plain-language software source code licenses. PolyForm aims to fill gaps in the menu of standardized software licenses, like non-commercial, trial, and small-business-only terms."
CC recommends not using their licenses for software. Most of the reasoning is about not exactly matching Open Source concerns, but you're still in uncharted territory applying them to software even when Open Source is not the goal:
I think that label is also already taken, because "source availability" doesn't imply an ability to rebuild it from the source or even make a suggestion.
I guess there should be some compositional keywords for different aspects of non-F/OSS but not completely proprietary licenses. Source available, artifact buildable, artifact distributable under some conditions, etc.
(2020). Also the very existence of 100+ OSI approved licenses means that there are some reasons (or incentives) to invent new software licenses after all.
Making JS frameworks is much cheaper than doing necessary legal works to draft a new license. (Not all OSI-approved licenses are written by lawyers, but many if not most of them should have been eventually reviewed by lawyers at least once.)
Mostly unrelated to the article, but the title stirred up memories.
~20 years ago I stumbled across the "Ё" license, that granted you all rights you can dream of with one condition, you must use the letter "ё" in its right place all the time. It is a Russian story, with some people loving "ё" and whining that outside of children books you can't find it, and other people trolling the first group by arguing that "ё" was a stupid addition from the very beginning, and even more stupid now.
Sadly I cannot google the text of the license now.
I cannot say numbers, because I don't watch for them... So I took a blog I read regularly, and counted top level comments to some post, I got 10 people used it, 4 didn't use, and 8 didn't use words with "ё", so I cannot say, do they use "ё" or not.
So, it seems people use it pretty often. But books "for adults" for some reason use "ё" only when replacing it with "е" leads to ambiguity.
I’ve created a non-toy programming language, and at some point I intend on creating a package manager for it. The official repository for packages will require all code to be open source, and I’ve already decided to be opinionated about what that means. I’ll pick a handful of well known, and actual open source licenses (MIT, GPL, BSD, Apache Commons, etc) and require people that want to upload to this repo to select their license from the finite list. If they want to use another license, they are still free to do so, but they’ll have to stand up their own repository, and get users to add the repo to their sources list.
There’s just too many licenses, each with different (sometimes incompatible) requirements, so one advantage to being so opinionated is that you can add automatic checks to ensure you’re in compliance. For instance, if your library is MIT (only), you can’t use GPL dependencies. Most people probably don’t know this, so having tooling that helps enforce this ought to make things more compliant overall.
Readit News
Clearly any business can license their software any way they like.
What caused the poster some confusion is that it was marketed as an "open source" product. Once he determined it was not an OSI approved license then that should be the end of it. It's not Open Source. period.
By all means call them out on that - lots of people and companies are not licensing experts, and need guidance. I've helped people with this in the past and encouraged them to change to actual Open Source licenses that are compatible with their goals, and the goals of their community.
If anything the real headline should be "stop calling your product open source when it doesn't have an open source license".
[To be clear - I produce commercial software under not-open-source licenses. I've got no objection to folk doing that. I even ship the source with the product, and accept contributions back. But I don't call it "open source" because it's not "Open Source". It's something, sure, but it's not Open Source.]
I completely agree with you that we shouldn’t be restricting how people choose to license their code. And agree that the real issue is the marketing: ie people calling something “open source” when it’s actually “source available to read”.
I see quite a few organisations play this game, like Obsidian. I’ve seen highly skilled and intelligent engineers fall for the trap of calling Obsidian open source because they can inspect the code of the Electon app; forgetting that doesn’t actually grant them a license to do anything with the code.
Like yourself, I have no qualms if an organisation wants to build proprietary / for profit stuff. I understand that means they might not even want to share their code. But what I do object to is when those organisations then try to gain some open source “street cred” for something that is proprietary.
That's because the terminology is pretty confusing, doubly so for ESL people. If you'd never had the whole open software vs. free software debate, it's easy to think that "open source" means "source code available", as this is pretty much in line with the direct reading of the phrase.
Closed/Open, Free/Paid are orthogonal.
That's why a term called FOSS exists.
I have often thought the same recently.
> That's why a term called FOSS exists.
And that is a key part of the problem: conflating FS (Free Software) with OS (Open Source) to give F(OS)S.
The thing is that Free software and Open Source _don't_ quite mean the same thing, but we treat them like they do. They are close but not identical.
Also see the recent kerfuffle about RHEL and CentOS.
Free software: do whatever you want with it, including sell it, but give your users the source code. The GPL is a FS license not an OS licence.
Not the world. Not open to all. The GPL 1/2/3 etc only says, clearly and distinctly, users. If you sell your free software, then it's only the customers that get the source, and that is 100% fine and OK.
OS is a different emphasis: it was designed to appeal to companies, businessmen and managers. You get the source, so we are giving you control, agency: you can't have it stolen from you.
But it was phrased in terms of sharing and openness.
That's what OS means, because the OSI says it is.
So BSL licenses say "you can have the source, and you can contribute back changes, but we still own it, and you can't use it in prod without paying or re-sell it."
That's a restriction of use. That's neither OS nor FS.
Whereas RH's use is 100% FS compliant but gets the OS folks annoyed.
But OS is not the same as FS. What RH is doing with RHEL is FS but not OS. It's not open to the world but the GPL never said it had to be.
I don't know what the best answer is here.
I wonder if it's time for a new term which leans on the English primary meaning of "free", as in at no cost, gratis.
"This software is free to get, free to use, and free to fork, but only so long as you do not charge for whatever purposes you employ it. If you obtain revenue from running it, supplying its output, modifying it, you sell products with it built in, or any other revenue-generating operation you must pay back X% of your revenues/profits/whatever to the creators. This also applies to downstream modified versions."
IANAL. A lawyer could do much better, I am completely sure. It might not be easy but I suspect that there is a way.
The people who "died" are all the dumb, short-sighted companies who use terms like "open source" when their software isn't.
We wouldn't be having this discussion if people would just stop being disingenuous. But no, that's not an option.
You can't trust a company saying they're "open source". That could mean next to nothing. So we look to the OSI and see what they have to say.
Which is fair enough, but any custom made license is extremely unlikely to be written in a way that it can be enforced when need....
Does the OSI own a trademark on the term "Open Source"?
https://opensource.org/trademark-guidelines#Open_Source_Init...
Where in OSI's "Open Source Definition" [1] does it say a license must be approved by OSI to be Open Source? If that was really part of the definition, they could have had a much shorter definition!
Another thing I find funny is that CC0 isn't "OSI approved" either, because of something about patents. But strangely, the "Definition" never mentions patents. But CC0 is not approved, so apparently CC0 is not open source.
[1] https://opensource.org/osd
Beyond that, I'm not really sure what the purpose of this post is except to complain about the fact that commercial software exists.
In the late 90's.
>> The term means nearly nothing in material terms about what you can actually do with the source code.
correct. The term means nothing in and of itself. The license determines what you can do with the code. there are a bunch of licenses that conform to the OSI definition of Open Source. If a company claims to be "open source", but then does not fit the definition of Open Source then they should expect some push-back.
Most organizations understand common open source licenses and there's usually a blank statement that allows teams to use GPL/MIT/whatever-licensed software.
Anything outside that subset of licenses (even if they're permissive, open source or whatnot) requires a legal review and a lot of people won't go through the pain of that process just to use a library/service/app. It's easier to just choose something else.
This is a feature, not a bug.
In my experience: MIT yes, GPL no.
Dead Comment
AFAIK that's irrelevant per GitHub's TOS, which users agree to:
By setting your repositories to be viewed publicly, you agree to allow others to view and "fork" your repositories (this means that others may make their own copies of Content from your repositories in repositories they control).
If you set your pages and repositories to be viewed publicly, you grant each User of GitHub a nonexclusive, worldwide license to use, display, and perform Your Content through the GitHub Service and to reproduce Your Content solely on GitHub as permitted through GitHub's functionality (for example, through forking).
AIUI you therefore always have the right to fork something on GitHub.
https://docs.github.com/en/site-policy/github-terms/github-t...
(Then again, that makes me think: does that mean you could use a modified copy however you want, as long as you only do it over GitHub CI?)
What businesses in particular want is a "Yes, you can read the code and yes you help if you want to, but you can't use the code to make your own product" source-available license (because they have devs to pay, and being able to keep doing that is the first thing they need to protect).
I think such licenses do sort of exist but they're fragmented.
The root of this particular argument seems to the definition of Open Source meaning unconstrained use of source code, instead of source-available.
Something standard and vetted enough that projects like these could adopt instead of having to write themselves.
The real issue here is that the product wasn’t open source despite being advertised as such. The licensed they used, Microsoft Reference Source License, isn’t an open source license. It’s more accurately described as “source available”. Ie you can view the source but you’re not really allowed to use it for anything.
"The PolyForm Project is a group of experienced licensing lawyers and technologists developing simple, standardized, plain-language software source code licenses. PolyForm aims to fill gaps in the menu of standardized software licenses, like non-commercial, trial, and small-business-only terms."
https://polyformproject.org/
https://creativecommons.org/share-your-work/cclicenses/
This covers some of the use cases you describe.
https://creativecommons.org/faq/#can-i-apply-a-creative-comm...
Source Available. Something like Unreal or ONCE.
I guess there should be some compositional keywords for different aspects of non-F/OSS but not completely proprietary licenses. Source available, artifact buildable, artifact distributable under some conditions, etc.
Or does it mean corporate legal teams feel the same impulses that have lead programmers to produce 100+ javascript frameworks?
~20 years ago I stumbled across the "Ё" license, that granted you all rights you can dream of with one condition, you must use the letter "ё" in its right place all the time. It is a Russian story, with some people loving "ё" and whining that outside of children books you can't find it, and other people trolling the first group by arguing that "ё" was a stupid addition from the very beginning, and even more stupid now.
Sadly I cannot google the text of the license now.
So, it seems people use it pretty often. But books "for adults" for some reason use "ё" only when replacing it with "е" leads to ambiguity.
There’s just too many licenses, each with different (sometimes incompatible) requirements, so one advantage to being so opinionated is that you can add automatic checks to ensure you’re in compliance. For instance, if your library is MIT (only), you can’t use GPL dependencies. Most people probably don’t know this, so having tooling that helps enforce this ought to make things more compliant overall.