Is the Maximum Use License for Everybody (MULE) a FOSS license?
I encountered an obscure software license called the Maximum Use License for Everybody (MULE). (I have used text from version 4 below, but my concerns also apply to version 3.) The license first states:
- This software is "free" or "open source" software. It doesn't matter which of these names you call it. […]
but subsequent sections then state (emphasis added):
- You may use this software in any way you wish, subject to all applicable laws and to the provisions of this Maximum Use License for Everyone. You may copy and distribute all or part of this software, without cost, at will.
[…]
- You may give away, or sell at cost, an aggregate software distribution containing this software and software from other sources, without remunerating the copyright holder. If you give away, or sell at cost, a fully functional and readily available aggregate software distribution containing this software and software from other sources, then you may also include this software in an enhanced version of the same aggregate software distribution which may be sold for profit, without remunerating the copyright holder. However, if you sell copies of all or part of this software under any other circumstances, either alone or together with other works, you must reach an agreement with the copyright holder as to a reasonable rate of remuneration per copy (or a waiver of remuneration).
[…]
You may copy and distribute other software containing all or part of this software, in modified or unmodified form, without cost under this Maximum Use License for Everyone, or under any other "free" or "open source" software license consistent with the Open Source Definition promoted by the Open Source Initiative http://opensource.org/. However, if you sell any copies of such software (except as part of an aggregate software distribution under the circumstances specified in paragraph 4 of this license), you must reach an agreement with the copyright holder of this software as to a reasonable rate of remuneration per copy (or a waiver of remuneration).
You may also copy and distribute other software containing all or part of this software, in modified or unmodified form, under any software license that is not among the "free" or "open source" licenses to which paragraph 6 of this license refers, but only after reaching an agreement with the copyright holder as to a reasonable rate of remuneration per copy (or a waiver of remuneration).
I'm inclined to think this is not a legitimate FOSS (free or open source software) license due to contradictions with FOSS definitions, which prohibit licenses from restricting the sale of the software by any party. Overall, I think the author of this license is interpreting "free software" and "open source software" too broadly if not incorrectly throughout this license.
I also think that ability to relicense under a (recognized) FOSS license in paragraph 6 is impossible in practice, because recognized FOSS licenses will not allow the "without cost" provision to be enforced; the copyright holder of a MULE-licensed project would essentially have to allow sale by anybody without remuneration.
licensing relicensing restrictions crayon-licenses
add a comment |
I encountered an obscure software license called the Maximum Use License for Everybody (MULE). (I have used text from version 4 below, but my concerns also apply to version 3.) The license first states:
- This software is "free" or "open source" software. It doesn't matter which of these names you call it. […]
but subsequent sections then state (emphasis added):
- You may use this software in any way you wish, subject to all applicable laws and to the provisions of this Maximum Use License for Everyone. You may copy and distribute all or part of this software, without cost, at will.
[…]
- You may give away, or sell at cost, an aggregate software distribution containing this software and software from other sources, without remunerating the copyright holder. If you give away, or sell at cost, a fully functional and readily available aggregate software distribution containing this software and software from other sources, then you may also include this software in an enhanced version of the same aggregate software distribution which may be sold for profit, without remunerating the copyright holder. However, if you sell copies of all or part of this software under any other circumstances, either alone or together with other works, you must reach an agreement with the copyright holder as to a reasonable rate of remuneration per copy (or a waiver of remuneration).
[…]
You may copy and distribute other software containing all or part of this software, in modified or unmodified form, without cost under this Maximum Use License for Everyone, or under any other "free" or "open source" software license consistent with the Open Source Definition promoted by the Open Source Initiative http://opensource.org/. However, if you sell any copies of such software (except as part of an aggregate software distribution under the circumstances specified in paragraph 4 of this license), you must reach an agreement with the copyright holder of this software as to a reasonable rate of remuneration per copy (or a waiver of remuneration).
You may also copy and distribute other software containing all or part of this software, in modified or unmodified form, under any software license that is not among the "free" or "open source" licenses to which paragraph 6 of this license refers, but only after reaching an agreement with the copyright holder as to a reasonable rate of remuneration per copy (or a waiver of remuneration).
I'm inclined to think this is not a legitimate FOSS (free or open source software) license due to contradictions with FOSS definitions, which prohibit licenses from restricting the sale of the software by any party. Overall, I think the author of this license is interpreting "free software" and "open source software" too broadly if not incorrectly throughout this license.
I also think that ability to relicense under a (recognized) FOSS license in paragraph 6 is impossible in practice, because recognized FOSS licenses will not allow the "without cost" provision to be enforced; the copyright holder of a MULE-licensed project would essentially have to allow sale by anybody without remuneration.
licensing relicensing restrictions crayon-licenses
I apologize if the obscurity of this license makes it off-topic; my hope is that any answer is rather straightforward. Others raised similar concerns about version 3 of this license a long time ago. I understand there's likely nothing stopping someone from calling something "free" or "open source" even if it isn't. And even if software projects have legitimate concerns about users or redistributors unfairly profiting from their work, my impression is that FOSS disagrees or at least refuse its licenses be used to address that.
– chrstphrchvz
Feb 23 at 5:31
add a comment |
I encountered an obscure software license called the Maximum Use License for Everybody (MULE). (I have used text from version 4 below, but my concerns also apply to version 3.) The license first states:
- This software is "free" or "open source" software. It doesn't matter which of these names you call it. […]
but subsequent sections then state (emphasis added):
- You may use this software in any way you wish, subject to all applicable laws and to the provisions of this Maximum Use License for Everyone. You may copy and distribute all or part of this software, without cost, at will.
[…]
- You may give away, or sell at cost, an aggregate software distribution containing this software and software from other sources, without remunerating the copyright holder. If you give away, or sell at cost, a fully functional and readily available aggregate software distribution containing this software and software from other sources, then you may also include this software in an enhanced version of the same aggregate software distribution which may be sold for profit, without remunerating the copyright holder. However, if you sell copies of all or part of this software under any other circumstances, either alone or together with other works, you must reach an agreement with the copyright holder as to a reasonable rate of remuneration per copy (or a waiver of remuneration).
[…]
You may copy and distribute other software containing all or part of this software, in modified or unmodified form, without cost under this Maximum Use License for Everyone, or under any other "free" or "open source" software license consistent with the Open Source Definition promoted by the Open Source Initiative http://opensource.org/. However, if you sell any copies of such software (except as part of an aggregate software distribution under the circumstances specified in paragraph 4 of this license), you must reach an agreement with the copyright holder of this software as to a reasonable rate of remuneration per copy (or a waiver of remuneration).
You may also copy and distribute other software containing all or part of this software, in modified or unmodified form, under any software license that is not among the "free" or "open source" licenses to which paragraph 6 of this license refers, but only after reaching an agreement with the copyright holder as to a reasonable rate of remuneration per copy (or a waiver of remuneration).
I'm inclined to think this is not a legitimate FOSS (free or open source software) license due to contradictions with FOSS definitions, which prohibit licenses from restricting the sale of the software by any party. Overall, I think the author of this license is interpreting "free software" and "open source software" too broadly if not incorrectly throughout this license.
I also think that ability to relicense under a (recognized) FOSS license in paragraph 6 is impossible in practice, because recognized FOSS licenses will not allow the "without cost" provision to be enforced; the copyright holder of a MULE-licensed project would essentially have to allow sale by anybody without remuneration.
licensing relicensing restrictions crayon-licenses
I encountered an obscure software license called the Maximum Use License for Everybody (MULE). (I have used text from version 4 below, but my concerns also apply to version 3.) The license first states:
- This software is "free" or "open source" software. It doesn't matter which of these names you call it. […]
but subsequent sections then state (emphasis added):
- You may use this software in any way you wish, subject to all applicable laws and to the provisions of this Maximum Use License for Everyone. You may copy and distribute all or part of this software, without cost, at will.
[…]
- You may give away, or sell at cost, an aggregate software distribution containing this software and software from other sources, without remunerating the copyright holder. If you give away, or sell at cost, a fully functional and readily available aggregate software distribution containing this software and software from other sources, then you may also include this software in an enhanced version of the same aggregate software distribution which may be sold for profit, without remunerating the copyright holder. However, if you sell copies of all or part of this software under any other circumstances, either alone or together with other works, you must reach an agreement with the copyright holder as to a reasonable rate of remuneration per copy (or a waiver of remuneration).
[…]
You may copy and distribute other software containing all or part of this software, in modified or unmodified form, without cost under this Maximum Use License for Everyone, or under any other "free" or "open source" software license consistent with the Open Source Definition promoted by the Open Source Initiative http://opensource.org/. However, if you sell any copies of such software (except as part of an aggregate software distribution under the circumstances specified in paragraph 4 of this license), you must reach an agreement with the copyright holder of this software as to a reasonable rate of remuneration per copy (or a waiver of remuneration).
You may also copy and distribute other software containing all or part of this software, in modified or unmodified form, under any software license that is not among the "free" or "open source" licenses to which paragraph 6 of this license refers, but only after reaching an agreement with the copyright holder as to a reasonable rate of remuneration per copy (or a waiver of remuneration).
I'm inclined to think this is not a legitimate FOSS (free or open source software) license due to contradictions with FOSS definitions, which prohibit licenses from restricting the sale of the software by any party. Overall, I think the author of this license is interpreting "free software" and "open source software" too broadly if not incorrectly throughout this license.
I also think that ability to relicense under a (recognized) FOSS license in paragraph 6 is impossible in practice, because recognized FOSS licenses will not allow the "without cost" provision to be enforced; the copyright holder of a MULE-licensed project would essentially have to allow sale by anybody without remuneration.
licensing relicensing restrictions crayon-licenses
licensing relicensing restrictions crayon-licenses
asked Feb 23 at 5:31
chrstphrchvzchrstphrchvz
1654
1654
I apologize if the obscurity of this license makes it off-topic; my hope is that any answer is rather straightforward. Others raised similar concerns about version 3 of this license a long time ago. I understand there's likely nothing stopping someone from calling something "free" or "open source" even if it isn't. And even if software projects have legitimate concerns about users or redistributors unfairly profiting from their work, my impression is that FOSS disagrees or at least refuse its licenses be used to address that.
– chrstphrchvz
Feb 23 at 5:31
add a comment |
I apologize if the obscurity of this license makes it off-topic; my hope is that any answer is rather straightforward. Others raised similar concerns about version 3 of this license a long time ago. I understand there's likely nothing stopping someone from calling something "free" or "open source" even if it isn't. And even if software projects have legitimate concerns about users or redistributors unfairly profiting from their work, my impression is that FOSS disagrees or at least refuse its licenses be used to address that.
– chrstphrchvz
Feb 23 at 5:31
I apologize if the obscurity of this license makes it off-topic; my hope is that any answer is rather straightforward. Others raised similar concerns about version 3 of this license a long time ago. I understand there's likely nothing stopping someone from calling something "free" or "open source" even if it isn't. And even if software projects have legitimate concerns about users or redistributors unfairly profiting from their work, my impression is that FOSS disagrees or at least refuse its licenses be used to address that.
– chrstphrchvz
Feb 23 at 5:31
I apologize if the obscurity of this license makes it off-topic; my hope is that any answer is rather straightforward. Others raised similar concerns about version 3 of this license a long time ago. I understand there's likely nothing stopping someone from calling something "free" or "open source" even if it isn't. And even if software projects have legitimate concerns about users or redistributors unfairly profiting from their work, my impression is that FOSS disagrees or at least refuse its licenses be used to address that.
– chrstphrchvz
Feb 23 at 5:31
add a comment |
2 Answers
2
active
oldest
votes
Forbidding sale of the software has precedent in OSI-approved licenses, for example SIL-OFL 1.1 says:
Neither the Font Software nor any of its individual components, in Original or Modified Versions, may be sold by itself.
But there is reason to believe the OFL is an outlier and wouldn't be OSI-approved if submitted today. Also, the OFL is only intended for fonts, not for software in general.
Back to the license at hand:
- MULE has never been put before the OSI for approval. Calling it an open source license is therefore a bit premature.
- MULE's author disagrees with the Debian Free Software Guidelines. However, the DFSG are the root of the Open Source Definition, and continue to be relevant in license evaluation. I would expect OSI to be hesitant to approve a license that would be shunned by Debian.
- MULE's royalty sharing provisions violate the DFSG's desert island test: How could a seller be able to reach a royalty agreement with the copyright holder unless they have communication channels and money transfer channels available? This is not necessarily a given, e.g. consider a potential seller in an isolated dictatorship.
- MULE's royalty sharing provision requires an agreement to be reached with the copyright holder. But there can be many copyright holders, because any contributor is a copyright holder as well. Reaching a royalty agreement with all of them would be unworkable.
- This is the main reason why this license fails to be open source: The license itself does not allow unrestricted commercial use of the software, it just allows arrangements to be made outside of the license. This aspect is indistinguishable from “all rights reserved“. Thus we have an OSD #6 “No Discrimination Against Fields of Endeavor” violation.
- The author's references to the OSD try to lawyer around its particular phrasing (e.g. regarding “aggregate”), without taking into account the intention of this definition.
- MULE's relicensing provision is badly thought out. For example, MULE is clearly GPL-incompatible. Since the anti-monetization clause is supposed to stick around after relicensing, this relicensing mechanism is not sufficient to save the license from being non-open.
I therefore believe that it is incorrect to consider the MULE license to be open source, believe that it would never be approved as open source by the OSI, and believe no one should ever use this license.
Interesting, I was aware the OSD has changed over time, but not that there could still be approved licenses that seemingly violate its prohibition on (re)sale restrictions. I'm not sure if the license spread beyond the software written by MULE's author, or if they accepted contributions for their MULE-licensed projects, but this license and existing MULE-licensed software seem all but forgotten at this point.
– chrstphrchvz
Feb 23 at 12:22
@chrstphrchvz the OSD has not yet been changed since it was originally drafted (directly based on the DFSG), but its role has changed over time. The OSD is not an exhaustive checklist that license must fulfil but a codification of values. Recently, OSI president Simon Phipps has clarified: “Stallman's four freedoms are an assumed precondition for evaluation … [users should be safe] knowing that a level playing field of rights delivering the four freedoms are ensured by OSI approved licenses.”
– amon
Feb 23 at 12:40
Ahh, I was looking at the annotated OSD, which has a version number.
– chrstphrchvz
Feb 23 at 12:49
1
The OFL was approved because it does not define "software", so a simple "Hello, world" Python script will satisfy that requirement.
– EMBLEM
Feb 23 at 20:58
I'm inclined to mark this answer as accepted if no one else chimes in, even though I initially felt this answer was heavy on specific/"practical" reasons over general/definition-based ones (the answerer has argued OSS licenses need not reflect all the specifics of the OSD). For example, "Not OSS by virtue of not being authoritatively vetted/listed as one" is indeed a good enough reason in practice, but I see how the MULE author and a few others would find that alone unsatisfactory.
– chrstphrchvz
Feb 24 at 0:21
|
show 1 more comment
Oh, good; yet another attempt by the crayon-wielding world to mesh free software ideology with the idea of non-commercial use. How well they all work.
IANAL/IANYL, but I agree with you that the licence is non-free, for the reasons you have stated.
However, I notice that s6, the section that allows re-distribution under any OSI-approved licence provided it is done at no cost, does not require a similar condition to be imposed on the recipient. So if you absolutely had to use some code licenced under MULE, my advice is to have a friend download it, and (per s6) convey it to you under GPLv3 (or, if (s)he must, some non-copyleft licence) without charge. At this point you have a properly-freely-licenced copy with no weird commercial restrictions, and life can proceed. However, it's probably best to avoid using this code if you can.
Going through a peer to get rid of MULE's restrictions on another license seems like a rather perverse workaround/loophole; why can't I immediately relicense software "to myself" in this case with no restriction? Compare this to implicitly relicensing permissive to copyleft, or choosing the explicit option of "any later version", as well as dual-license scenarios; aren't the restrictions I abide by are only the ones imposed by the one license I chose, and not any others?
– chrstphrchvz
Feb 23 at 12:16
I'm also not quite convinced relicensing eliminates the possibility of the original copyright holder being able to go after anyone selling their work without permission. I personally am not inclined to try relicensing anything away from MULE because of its ambiguity/incoherence.
– chrstphrchvz
Feb 23 at 12:17
You do have a point that poorly licensed software might not be fit for use or adoption. Possibly separate question (and could apply to EULAs in general/has been asked before): if a license has void or contradicting claims, how much of the license is void/can I no longer agree to it in its entirety? Taken to an extreme, does relicensing it this way effectively acknowledge the "without cost" provision is void, and by rejecting that part of the license means rejecting the whole license (MULE paragraph 11), meaning you can't relicense it?
– chrstphrchvz
Feb 23 at 12:25
@chrstphrchvz To your last point, this will vary by jurisdiction, but see "Contra proferentem" in opensource.stackexchange.com/q/1445/50
– apsillers♦
Feb 23 at 18:27
@chrstphrchvz to your first comment, you can't do that because you're you. Once you've accepted a copy under MULE's terms and conveyed it onward, you're bound by those terms. You don't unbind yourself by receiving a copy without the corresponding obligations; you already accepted them, in order to have the right to have made your first copy. Using a third party removes this problem.
– MadHatter
Feb 23 at 22:30
|
show 1 more comment
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "619"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fopensource.stackexchange.com%2fquestions%2f7989%2fis-the-maximum-use-license-for-everybody-mule-a-foss-license%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Forbidding sale of the software has precedent in OSI-approved licenses, for example SIL-OFL 1.1 says:
Neither the Font Software nor any of its individual components, in Original or Modified Versions, may be sold by itself.
But there is reason to believe the OFL is an outlier and wouldn't be OSI-approved if submitted today. Also, the OFL is only intended for fonts, not for software in general.
Back to the license at hand:
- MULE has never been put before the OSI for approval. Calling it an open source license is therefore a bit premature.
- MULE's author disagrees with the Debian Free Software Guidelines. However, the DFSG are the root of the Open Source Definition, and continue to be relevant in license evaluation. I would expect OSI to be hesitant to approve a license that would be shunned by Debian.
- MULE's royalty sharing provisions violate the DFSG's desert island test: How could a seller be able to reach a royalty agreement with the copyright holder unless they have communication channels and money transfer channels available? This is not necessarily a given, e.g. consider a potential seller in an isolated dictatorship.
- MULE's royalty sharing provision requires an agreement to be reached with the copyright holder. But there can be many copyright holders, because any contributor is a copyright holder as well. Reaching a royalty agreement with all of them would be unworkable.
- This is the main reason why this license fails to be open source: The license itself does not allow unrestricted commercial use of the software, it just allows arrangements to be made outside of the license. This aspect is indistinguishable from “all rights reserved“. Thus we have an OSD #6 “No Discrimination Against Fields of Endeavor” violation.
- The author's references to the OSD try to lawyer around its particular phrasing (e.g. regarding “aggregate”), without taking into account the intention of this definition.
- MULE's relicensing provision is badly thought out. For example, MULE is clearly GPL-incompatible. Since the anti-monetization clause is supposed to stick around after relicensing, this relicensing mechanism is not sufficient to save the license from being non-open.
I therefore believe that it is incorrect to consider the MULE license to be open source, believe that it would never be approved as open source by the OSI, and believe no one should ever use this license.
Interesting, I was aware the OSD has changed over time, but not that there could still be approved licenses that seemingly violate its prohibition on (re)sale restrictions. I'm not sure if the license spread beyond the software written by MULE's author, or if they accepted contributions for their MULE-licensed projects, but this license and existing MULE-licensed software seem all but forgotten at this point.
– chrstphrchvz
Feb 23 at 12:22
@chrstphrchvz the OSD has not yet been changed since it was originally drafted (directly based on the DFSG), but its role has changed over time. The OSD is not an exhaustive checklist that license must fulfil but a codification of values. Recently, OSI president Simon Phipps has clarified: “Stallman's four freedoms are an assumed precondition for evaluation … [users should be safe] knowing that a level playing field of rights delivering the four freedoms are ensured by OSI approved licenses.”
– amon
Feb 23 at 12:40
Ahh, I was looking at the annotated OSD, which has a version number.
– chrstphrchvz
Feb 23 at 12:49
1
The OFL was approved because it does not define "software", so a simple "Hello, world" Python script will satisfy that requirement.
– EMBLEM
Feb 23 at 20:58
I'm inclined to mark this answer as accepted if no one else chimes in, even though I initially felt this answer was heavy on specific/"practical" reasons over general/definition-based ones (the answerer has argued OSS licenses need not reflect all the specifics of the OSD). For example, "Not OSS by virtue of not being authoritatively vetted/listed as one" is indeed a good enough reason in practice, but I see how the MULE author and a few others would find that alone unsatisfactory.
– chrstphrchvz
Feb 24 at 0:21
|
show 1 more comment
Forbidding sale of the software has precedent in OSI-approved licenses, for example SIL-OFL 1.1 says:
Neither the Font Software nor any of its individual components, in Original or Modified Versions, may be sold by itself.
But there is reason to believe the OFL is an outlier and wouldn't be OSI-approved if submitted today. Also, the OFL is only intended for fonts, not for software in general.
Back to the license at hand:
- MULE has never been put before the OSI for approval. Calling it an open source license is therefore a bit premature.
- MULE's author disagrees with the Debian Free Software Guidelines. However, the DFSG are the root of the Open Source Definition, and continue to be relevant in license evaluation. I would expect OSI to be hesitant to approve a license that would be shunned by Debian.
- MULE's royalty sharing provisions violate the DFSG's desert island test: How could a seller be able to reach a royalty agreement with the copyright holder unless they have communication channels and money transfer channels available? This is not necessarily a given, e.g. consider a potential seller in an isolated dictatorship.
- MULE's royalty sharing provision requires an agreement to be reached with the copyright holder. But there can be many copyright holders, because any contributor is a copyright holder as well. Reaching a royalty agreement with all of them would be unworkable.
- This is the main reason why this license fails to be open source: The license itself does not allow unrestricted commercial use of the software, it just allows arrangements to be made outside of the license. This aspect is indistinguishable from “all rights reserved“. Thus we have an OSD #6 “No Discrimination Against Fields of Endeavor” violation.
- The author's references to the OSD try to lawyer around its particular phrasing (e.g. regarding “aggregate”), without taking into account the intention of this definition.
- MULE's relicensing provision is badly thought out. For example, MULE is clearly GPL-incompatible. Since the anti-monetization clause is supposed to stick around after relicensing, this relicensing mechanism is not sufficient to save the license from being non-open.
I therefore believe that it is incorrect to consider the MULE license to be open source, believe that it would never be approved as open source by the OSI, and believe no one should ever use this license.
Interesting, I was aware the OSD has changed over time, but not that there could still be approved licenses that seemingly violate its prohibition on (re)sale restrictions. I'm not sure if the license spread beyond the software written by MULE's author, or if they accepted contributions for their MULE-licensed projects, but this license and existing MULE-licensed software seem all but forgotten at this point.
– chrstphrchvz
Feb 23 at 12:22
@chrstphrchvz the OSD has not yet been changed since it was originally drafted (directly based on the DFSG), but its role has changed over time. The OSD is not an exhaustive checklist that license must fulfil but a codification of values. Recently, OSI president Simon Phipps has clarified: “Stallman's four freedoms are an assumed precondition for evaluation … [users should be safe] knowing that a level playing field of rights delivering the four freedoms are ensured by OSI approved licenses.”
– amon
Feb 23 at 12:40
Ahh, I was looking at the annotated OSD, which has a version number.
– chrstphrchvz
Feb 23 at 12:49
1
The OFL was approved because it does not define "software", so a simple "Hello, world" Python script will satisfy that requirement.
– EMBLEM
Feb 23 at 20:58
I'm inclined to mark this answer as accepted if no one else chimes in, even though I initially felt this answer was heavy on specific/"practical" reasons over general/definition-based ones (the answerer has argued OSS licenses need not reflect all the specifics of the OSD). For example, "Not OSS by virtue of not being authoritatively vetted/listed as one" is indeed a good enough reason in practice, but I see how the MULE author and a few others would find that alone unsatisfactory.
– chrstphrchvz
Feb 24 at 0:21
|
show 1 more comment
Forbidding sale of the software has precedent in OSI-approved licenses, for example SIL-OFL 1.1 says:
Neither the Font Software nor any of its individual components, in Original or Modified Versions, may be sold by itself.
But there is reason to believe the OFL is an outlier and wouldn't be OSI-approved if submitted today. Also, the OFL is only intended for fonts, not for software in general.
Back to the license at hand:
- MULE has never been put before the OSI for approval. Calling it an open source license is therefore a bit premature.
- MULE's author disagrees with the Debian Free Software Guidelines. However, the DFSG are the root of the Open Source Definition, and continue to be relevant in license evaluation. I would expect OSI to be hesitant to approve a license that would be shunned by Debian.
- MULE's royalty sharing provisions violate the DFSG's desert island test: How could a seller be able to reach a royalty agreement with the copyright holder unless they have communication channels and money transfer channels available? This is not necessarily a given, e.g. consider a potential seller in an isolated dictatorship.
- MULE's royalty sharing provision requires an agreement to be reached with the copyright holder. But there can be many copyright holders, because any contributor is a copyright holder as well. Reaching a royalty agreement with all of them would be unworkable.
- This is the main reason why this license fails to be open source: The license itself does not allow unrestricted commercial use of the software, it just allows arrangements to be made outside of the license. This aspect is indistinguishable from “all rights reserved“. Thus we have an OSD #6 “No Discrimination Against Fields of Endeavor” violation.
- The author's references to the OSD try to lawyer around its particular phrasing (e.g. regarding “aggregate”), without taking into account the intention of this definition.
- MULE's relicensing provision is badly thought out. For example, MULE is clearly GPL-incompatible. Since the anti-monetization clause is supposed to stick around after relicensing, this relicensing mechanism is not sufficient to save the license from being non-open.
I therefore believe that it is incorrect to consider the MULE license to be open source, believe that it would never be approved as open source by the OSI, and believe no one should ever use this license.
Forbidding sale of the software has precedent in OSI-approved licenses, for example SIL-OFL 1.1 says:
Neither the Font Software nor any of its individual components, in Original or Modified Versions, may be sold by itself.
But there is reason to believe the OFL is an outlier and wouldn't be OSI-approved if submitted today. Also, the OFL is only intended for fonts, not for software in general.
Back to the license at hand:
- MULE has never been put before the OSI for approval. Calling it an open source license is therefore a bit premature.
- MULE's author disagrees with the Debian Free Software Guidelines. However, the DFSG are the root of the Open Source Definition, and continue to be relevant in license evaluation. I would expect OSI to be hesitant to approve a license that would be shunned by Debian.
- MULE's royalty sharing provisions violate the DFSG's desert island test: How could a seller be able to reach a royalty agreement with the copyright holder unless they have communication channels and money transfer channels available? This is not necessarily a given, e.g. consider a potential seller in an isolated dictatorship.
- MULE's royalty sharing provision requires an agreement to be reached with the copyright holder. But there can be many copyright holders, because any contributor is a copyright holder as well. Reaching a royalty agreement with all of them would be unworkable.
- This is the main reason why this license fails to be open source: The license itself does not allow unrestricted commercial use of the software, it just allows arrangements to be made outside of the license. This aspect is indistinguishable from “all rights reserved“. Thus we have an OSD #6 “No Discrimination Against Fields of Endeavor” violation.
- The author's references to the OSD try to lawyer around its particular phrasing (e.g. regarding “aggregate”), without taking into account the intention of this definition.
- MULE's relicensing provision is badly thought out. For example, MULE is clearly GPL-incompatible. Since the anti-monetization clause is supposed to stick around after relicensing, this relicensing mechanism is not sufficient to save the license from being non-open.
I therefore believe that it is incorrect to consider the MULE license to be open source, believe that it would never be approved as open source by the OSI, and believe no one should ever use this license.
edited Feb 26 at 15:05
answered Feb 23 at 8:55
amonamon
12.1k11532
12.1k11532
Interesting, I was aware the OSD has changed over time, but not that there could still be approved licenses that seemingly violate its prohibition on (re)sale restrictions. I'm not sure if the license spread beyond the software written by MULE's author, or if they accepted contributions for their MULE-licensed projects, but this license and existing MULE-licensed software seem all but forgotten at this point.
– chrstphrchvz
Feb 23 at 12:22
@chrstphrchvz the OSD has not yet been changed since it was originally drafted (directly based on the DFSG), but its role has changed over time. The OSD is not an exhaustive checklist that license must fulfil but a codification of values. Recently, OSI president Simon Phipps has clarified: “Stallman's four freedoms are an assumed precondition for evaluation … [users should be safe] knowing that a level playing field of rights delivering the four freedoms are ensured by OSI approved licenses.”
– amon
Feb 23 at 12:40
Ahh, I was looking at the annotated OSD, which has a version number.
– chrstphrchvz
Feb 23 at 12:49
1
The OFL was approved because it does not define "software", so a simple "Hello, world" Python script will satisfy that requirement.
– EMBLEM
Feb 23 at 20:58
I'm inclined to mark this answer as accepted if no one else chimes in, even though I initially felt this answer was heavy on specific/"practical" reasons over general/definition-based ones (the answerer has argued OSS licenses need not reflect all the specifics of the OSD). For example, "Not OSS by virtue of not being authoritatively vetted/listed as one" is indeed a good enough reason in practice, but I see how the MULE author and a few others would find that alone unsatisfactory.
– chrstphrchvz
Feb 24 at 0:21
|
show 1 more comment
Interesting, I was aware the OSD has changed over time, but not that there could still be approved licenses that seemingly violate its prohibition on (re)sale restrictions. I'm not sure if the license spread beyond the software written by MULE's author, or if they accepted contributions for their MULE-licensed projects, but this license and existing MULE-licensed software seem all but forgotten at this point.
– chrstphrchvz
Feb 23 at 12:22
@chrstphrchvz the OSD has not yet been changed since it was originally drafted (directly based on the DFSG), but its role has changed over time. The OSD is not an exhaustive checklist that license must fulfil but a codification of values. Recently, OSI president Simon Phipps has clarified: “Stallman's four freedoms are an assumed precondition for evaluation … [users should be safe] knowing that a level playing field of rights delivering the four freedoms are ensured by OSI approved licenses.”
– amon
Feb 23 at 12:40
Ahh, I was looking at the annotated OSD, which has a version number.
– chrstphrchvz
Feb 23 at 12:49
1
The OFL was approved because it does not define "software", so a simple "Hello, world" Python script will satisfy that requirement.
– EMBLEM
Feb 23 at 20:58
I'm inclined to mark this answer as accepted if no one else chimes in, even though I initially felt this answer was heavy on specific/"practical" reasons over general/definition-based ones (the answerer has argued OSS licenses need not reflect all the specifics of the OSD). For example, "Not OSS by virtue of not being authoritatively vetted/listed as one" is indeed a good enough reason in practice, but I see how the MULE author and a few others would find that alone unsatisfactory.
– chrstphrchvz
Feb 24 at 0:21
Interesting, I was aware the OSD has changed over time, but not that there could still be approved licenses that seemingly violate its prohibition on (re)sale restrictions. I'm not sure if the license spread beyond the software written by MULE's author, or if they accepted contributions for their MULE-licensed projects, but this license and existing MULE-licensed software seem all but forgotten at this point.
– chrstphrchvz
Feb 23 at 12:22
Interesting, I was aware the OSD has changed over time, but not that there could still be approved licenses that seemingly violate its prohibition on (re)sale restrictions. I'm not sure if the license spread beyond the software written by MULE's author, or if they accepted contributions for their MULE-licensed projects, but this license and existing MULE-licensed software seem all but forgotten at this point.
– chrstphrchvz
Feb 23 at 12:22
@chrstphrchvz the OSD has not yet been changed since it was originally drafted (directly based on the DFSG), but its role has changed over time. The OSD is not an exhaustive checklist that license must fulfil but a codification of values. Recently, OSI president Simon Phipps has clarified: “Stallman's four freedoms are an assumed precondition for evaluation … [users should be safe] knowing that a level playing field of rights delivering the four freedoms are ensured by OSI approved licenses.”
– amon
Feb 23 at 12:40
@chrstphrchvz the OSD has not yet been changed since it was originally drafted (directly based on the DFSG), but its role has changed over time. The OSD is not an exhaustive checklist that license must fulfil but a codification of values. Recently, OSI president Simon Phipps has clarified: “Stallman's four freedoms are an assumed precondition for evaluation … [users should be safe] knowing that a level playing field of rights delivering the four freedoms are ensured by OSI approved licenses.”
– amon
Feb 23 at 12:40
Ahh, I was looking at the annotated OSD, which has a version number.
– chrstphrchvz
Feb 23 at 12:49
Ahh, I was looking at the annotated OSD, which has a version number.
– chrstphrchvz
Feb 23 at 12:49
1
1
The OFL was approved because it does not define "software", so a simple "Hello, world" Python script will satisfy that requirement.
– EMBLEM
Feb 23 at 20:58
The OFL was approved because it does not define "software", so a simple "Hello, world" Python script will satisfy that requirement.
– EMBLEM
Feb 23 at 20:58
I'm inclined to mark this answer as accepted if no one else chimes in, even though I initially felt this answer was heavy on specific/"practical" reasons over general/definition-based ones (the answerer has argued OSS licenses need not reflect all the specifics of the OSD). For example, "Not OSS by virtue of not being authoritatively vetted/listed as one" is indeed a good enough reason in practice, but I see how the MULE author and a few others would find that alone unsatisfactory.
– chrstphrchvz
Feb 24 at 0:21
I'm inclined to mark this answer as accepted if no one else chimes in, even though I initially felt this answer was heavy on specific/"practical" reasons over general/definition-based ones (the answerer has argued OSS licenses need not reflect all the specifics of the OSD). For example, "Not OSS by virtue of not being authoritatively vetted/listed as one" is indeed a good enough reason in practice, but I see how the MULE author and a few others would find that alone unsatisfactory.
– chrstphrchvz
Feb 24 at 0:21
|
show 1 more comment
Oh, good; yet another attempt by the crayon-wielding world to mesh free software ideology with the idea of non-commercial use. How well they all work.
IANAL/IANYL, but I agree with you that the licence is non-free, for the reasons you have stated.
However, I notice that s6, the section that allows re-distribution under any OSI-approved licence provided it is done at no cost, does not require a similar condition to be imposed on the recipient. So if you absolutely had to use some code licenced under MULE, my advice is to have a friend download it, and (per s6) convey it to you under GPLv3 (or, if (s)he must, some non-copyleft licence) without charge. At this point you have a properly-freely-licenced copy with no weird commercial restrictions, and life can proceed. However, it's probably best to avoid using this code if you can.
Going through a peer to get rid of MULE's restrictions on another license seems like a rather perverse workaround/loophole; why can't I immediately relicense software "to myself" in this case with no restriction? Compare this to implicitly relicensing permissive to copyleft, or choosing the explicit option of "any later version", as well as dual-license scenarios; aren't the restrictions I abide by are only the ones imposed by the one license I chose, and not any others?
– chrstphrchvz
Feb 23 at 12:16
I'm also not quite convinced relicensing eliminates the possibility of the original copyright holder being able to go after anyone selling their work without permission. I personally am not inclined to try relicensing anything away from MULE because of its ambiguity/incoherence.
– chrstphrchvz
Feb 23 at 12:17
You do have a point that poorly licensed software might not be fit for use or adoption. Possibly separate question (and could apply to EULAs in general/has been asked before): if a license has void or contradicting claims, how much of the license is void/can I no longer agree to it in its entirety? Taken to an extreme, does relicensing it this way effectively acknowledge the "without cost" provision is void, and by rejecting that part of the license means rejecting the whole license (MULE paragraph 11), meaning you can't relicense it?
– chrstphrchvz
Feb 23 at 12:25
@chrstphrchvz To your last point, this will vary by jurisdiction, but see "Contra proferentem" in opensource.stackexchange.com/q/1445/50
– apsillers♦
Feb 23 at 18:27
@chrstphrchvz to your first comment, you can't do that because you're you. Once you've accepted a copy under MULE's terms and conveyed it onward, you're bound by those terms. You don't unbind yourself by receiving a copy without the corresponding obligations; you already accepted them, in order to have the right to have made your first copy. Using a third party removes this problem.
– MadHatter
Feb 23 at 22:30
|
show 1 more comment
Oh, good; yet another attempt by the crayon-wielding world to mesh free software ideology with the idea of non-commercial use. How well they all work.
IANAL/IANYL, but I agree with you that the licence is non-free, for the reasons you have stated.
However, I notice that s6, the section that allows re-distribution under any OSI-approved licence provided it is done at no cost, does not require a similar condition to be imposed on the recipient. So if you absolutely had to use some code licenced under MULE, my advice is to have a friend download it, and (per s6) convey it to you under GPLv3 (or, if (s)he must, some non-copyleft licence) without charge. At this point you have a properly-freely-licenced copy with no weird commercial restrictions, and life can proceed. However, it's probably best to avoid using this code if you can.
Going through a peer to get rid of MULE's restrictions on another license seems like a rather perverse workaround/loophole; why can't I immediately relicense software "to myself" in this case with no restriction? Compare this to implicitly relicensing permissive to copyleft, or choosing the explicit option of "any later version", as well as dual-license scenarios; aren't the restrictions I abide by are only the ones imposed by the one license I chose, and not any others?
– chrstphrchvz
Feb 23 at 12:16
I'm also not quite convinced relicensing eliminates the possibility of the original copyright holder being able to go after anyone selling their work without permission. I personally am not inclined to try relicensing anything away from MULE because of its ambiguity/incoherence.
– chrstphrchvz
Feb 23 at 12:17
You do have a point that poorly licensed software might not be fit for use or adoption. Possibly separate question (and could apply to EULAs in general/has been asked before): if a license has void or contradicting claims, how much of the license is void/can I no longer agree to it in its entirety? Taken to an extreme, does relicensing it this way effectively acknowledge the "without cost" provision is void, and by rejecting that part of the license means rejecting the whole license (MULE paragraph 11), meaning you can't relicense it?
– chrstphrchvz
Feb 23 at 12:25
@chrstphrchvz To your last point, this will vary by jurisdiction, but see "Contra proferentem" in opensource.stackexchange.com/q/1445/50
– apsillers♦
Feb 23 at 18:27
@chrstphrchvz to your first comment, you can't do that because you're you. Once you've accepted a copy under MULE's terms and conveyed it onward, you're bound by those terms. You don't unbind yourself by receiving a copy without the corresponding obligations; you already accepted them, in order to have the right to have made your first copy. Using a third party removes this problem.
– MadHatter
Feb 23 at 22:30
|
show 1 more comment
Oh, good; yet another attempt by the crayon-wielding world to mesh free software ideology with the idea of non-commercial use. How well they all work.
IANAL/IANYL, but I agree with you that the licence is non-free, for the reasons you have stated.
However, I notice that s6, the section that allows re-distribution under any OSI-approved licence provided it is done at no cost, does not require a similar condition to be imposed on the recipient. So if you absolutely had to use some code licenced under MULE, my advice is to have a friend download it, and (per s6) convey it to you under GPLv3 (or, if (s)he must, some non-copyleft licence) without charge. At this point you have a properly-freely-licenced copy with no weird commercial restrictions, and life can proceed. However, it's probably best to avoid using this code if you can.
Oh, good; yet another attempt by the crayon-wielding world to mesh free software ideology with the idea of non-commercial use. How well they all work.
IANAL/IANYL, but I agree with you that the licence is non-free, for the reasons you have stated.
However, I notice that s6, the section that allows re-distribution under any OSI-approved licence provided it is done at no cost, does not require a similar condition to be imposed on the recipient. So if you absolutely had to use some code licenced under MULE, my advice is to have a friend download it, and (per s6) convey it to you under GPLv3 (or, if (s)he must, some non-copyleft licence) without charge. At this point you have a properly-freely-licenced copy with no weird commercial restrictions, and life can proceed. However, it's probably best to avoid using this code if you can.
answered Feb 23 at 7:19
MadHatterMadHatter
9,2271836
9,2271836
Going through a peer to get rid of MULE's restrictions on another license seems like a rather perverse workaround/loophole; why can't I immediately relicense software "to myself" in this case with no restriction? Compare this to implicitly relicensing permissive to copyleft, or choosing the explicit option of "any later version", as well as dual-license scenarios; aren't the restrictions I abide by are only the ones imposed by the one license I chose, and not any others?
– chrstphrchvz
Feb 23 at 12:16
I'm also not quite convinced relicensing eliminates the possibility of the original copyright holder being able to go after anyone selling their work without permission. I personally am not inclined to try relicensing anything away from MULE because of its ambiguity/incoherence.
– chrstphrchvz
Feb 23 at 12:17
You do have a point that poorly licensed software might not be fit for use or adoption. Possibly separate question (and could apply to EULAs in general/has been asked before): if a license has void or contradicting claims, how much of the license is void/can I no longer agree to it in its entirety? Taken to an extreme, does relicensing it this way effectively acknowledge the "without cost" provision is void, and by rejecting that part of the license means rejecting the whole license (MULE paragraph 11), meaning you can't relicense it?
– chrstphrchvz
Feb 23 at 12:25
@chrstphrchvz To your last point, this will vary by jurisdiction, but see "Contra proferentem" in opensource.stackexchange.com/q/1445/50
– apsillers♦
Feb 23 at 18:27
@chrstphrchvz to your first comment, you can't do that because you're you. Once you've accepted a copy under MULE's terms and conveyed it onward, you're bound by those terms. You don't unbind yourself by receiving a copy without the corresponding obligations; you already accepted them, in order to have the right to have made your first copy. Using a third party removes this problem.
– MadHatter
Feb 23 at 22:30
|
show 1 more comment
Going through a peer to get rid of MULE's restrictions on another license seems like a rather perverse workaround/loophole; why can't I immediately relicense software "to myself" in this case with no restriction? Compare this to implicitly relicensing permissive to copyleft, or choosing the explicit option of "any later version", as well as dual-license scenarios; aren't the restrictions I abide by are only the ones imposed by the one license I chose, and not any others?
– chrstphrchvz
Feb 23 at 12:16
I'm also not quite convinced relicensing eliminates the possibility of the original copyright holder being able to go after anyone selling their work without permission. I personally am not inclined to try relicensing anything away from MULE because of its ambiguity/incoherence.
– chrstphrchvz
Feb 23 at 12:17
You do have a point that poorly licensed software might not be fit for use or adoption. Possibly separate question (and could apply to EULAs in general/has been asked before): if a license has void or contradicting claims, how much of the license is void/can I no longer agree to it in its entirety? Taken to an extreme, does relicensing it this way effectively acknowledge the "without cost" provision is void, and by rejecting that part of the license means rejecting the whole license (MULE paragraph 11), meaning you can't relicense it?
– chrstphrchvz
Feb 23 at 12:25
@chrstphrchvz To your last point, this will vary by jurisdiction, but see "Contra proferentem" in opensource.stackexchange.com/q/1445/50
– apsillers♦
Feb 23 at 18:27
@chrstphrchvz to your first comment, you can't do that because you're you. Once you've accepted a copy under MULE's terms and conveyed it onward, you're bound by those terms. You don't unbind yourself by receiving a copy without the corresponding obligations; you already accepted them, in order to have the right to have made your first copy. Using a third party removes this problem.
– MadHatter
Feb 23 at 22:30
Going through a peer to get rid of MULE's restrictions on another license seems like a rather perverse workaround/loophole; why can't I immediately relicense software "to myself" in this case with no restriction? Compare this to implicitly relicensing permissive to copyleft, or choosing the explicit option of "any later version", as well as dual-license scenarios; aren't the restrictions I abide by are only the ones imposed by the one license I chose, and not any others?
– chrstphrchvz
Feb 23 at 12:16
Going through a peer to get rid of MULE's restrictions on another license seems like a rather perverse workaround/loophole; why can't I immediately relicense software "to myself" in this case with no restriction? Compare this to implicitly relicensing permissive to copyleft, or choosing the explicit option of "any later version", as well as dual-license scenarios; aren't the restrictions I abide by are only the ones imposed by the one license I chose, and not any others?
– chrstphrchvz
Feb 23 at 12:16
I'm also not quite convinced relicensing eliminates the possibility of the original copyright holder being able to go after anyone selling their work without permission. I personally am not inclined to try relicensing anything away from MULE because of its ambiguity/incoherence.
– chrstphrchvz
Feb 23 at 12:17
I'm also not quite convinced relicensing eliminates the possibility of the original copyright holder being able to go after anyone selling their work without permission. I personally am not inclined to try relicensing anything away from MULE because of its ambiguity/incoherence.
– chrstphrchvz
Feb 23 at 12:17
You do have a point that poorly licensed software might not be fit for use or adoption. Possibly separate question (and could apply to EULAs in general/has been asked before): if a license has void or contradicting claims, how much of the license is void/can I no longer agree to it in its entirety? Taken to an extreme, does relicensing it this way effectively acknowledge the "without cost" provision is void, and by rejecting that part of the license means rejecting the whole license (MULE paragraph 11), meaning you can't relicense it?
– chrstphrchvz
Feb 23 at 12:25
You do have a point that poorly licensed software might not be fit for use or adoption. Possibly separate question (and could apply to EULAs in general/has been asked before): if a license has void or contradicting claims, how much of the license is void/can I no longer agree to it in its entirety? Taken to an extreme, does relicensing it this way effectively acknowledge the "without cost" provision is void, and by rejecting that part of the license means rejecting the whole license (MULE paragraph 11), meaning you can't relicense it?
– chrstphrchvz
Feb 23 at 12:25
@chrstphrchvz To your last point, this will vary by jurisdiction, but see "Contra proferentem" in opensource.stackexchange.com/q/1445/50
– apsillers♦
Feb 23 at 18:27
@chrstphrchvz To your last point, this will vary by jurisdiction, but see "Contra proferentem" in opensource.stackexchange.com/q/1445/50
– apsillers♦
Feb 23 at 18:27
@chrstphrchvz to your first comment, you can't do that because you're you. Once you've accepted a copy under MULE's terms and conveyed it onward, you're bound by those terms. You don't unbind yourself by receiving a copy without the corresponding obligations; you already accepted them, in order to have the right to have made your first copy. Using a third party removes this problem.
– MadHatter
Feb 23 at 22:30
@chrstphrchvz to your first comment, you can't do that because you're you. Once you've accepted a copy under MULE's terms and conveyed it onward, you're bound by those terms. You don't unbind yourself by receiving a copy without the corresponding obligations; you already accepted them, in order to have the right to have made your first copy. Using a third party removes this problem.
– MadHatter
Feb 23 at 22:30
|
show 1 more comment
Thanks for contributing an answer to Open Source Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fopensource.stackexchange.com%2fquestions%2f7989%2fis-the-maximum-use-license-for-everybody-mule-a-foss-license%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
I apologize if the obscurity of this license makes it off-topic; my hope is that any answer is rather straightforward. Others raised similar concerns about version 3 of this license a long time ago. I understand there's likely nothing stopping someone from calling something "free" or "open source" even if it isn't. And even if software projects have legitimate concerns about users or redistributors unfairly profiting from their work, my impression is that FOSS disagrees or at least refuse its licenses be used to address that.
– chrstphrchvz
Feb 23 at 5:31