Affirmation of the Open Source Definition(opensource.org)
opensource.org
Affirmation of the Open Source Definition
https://opensource.org/node/966
67 comments
> Are they saying I can't trust what I read in the license files of a project?
That's not quite what they're saying. They're asking what's stopping anyone from claiming their project is "open source", but actually meaning something most people won't recognize as such -- for example, "my project is open source because its source code is public. But if you want to legally do anything with it other than look, you have to pay me."
If there isn't a standardized definition, someone can claim the above, and all you could really argue is that their definition of "open source" is different from yours (and they'll probably ask "who made you the arbiter of what's open and what's not?"). Once there is a standardized definition, the position instead becomes "your definition doesn't meet the international standard", which is a much weightier argument.
As for hubris -- in much the same way that even with an international definition for something like a kilogram, nothing stops you from creating your own, different measurement, and claiming you're selling stuff "by your own measure of kilogram" to whoever will buy it, there will never be anything stopping you from creating your own definition of "open source" and carefully defining it in a license file. It's just that if that definition differs from the standardized one, developers will either have to carefully read your license (or have their lawyers do that), or choose to use a project with a standard license that's already been vetted a thousand times over.
That's not quite what they're saying. They're asking what's stopping anyone from claiming their project is "open source", but actually meaning something most people won't recognize as such -- for example, "my project is open source because its source code is public. But if you want to legally do anything with it other than look, you have to pay me."
If there isn't a standardized definition, someone can claim the above, and all you could really argue is that their definition of "open source" is different from yours (and they'll probably ask "who made you the arbiter of what's open and what's not?"). Once there is a standardized definition, the position instead becomes "your definition doesn't meet the international standard", which is a much weightier argument.
As for hubris -- in much the same way that even with an international definition for something like a kilogram, nothing stops you from creating your own, different measurement, and claiming you're selling stuff "by your own measure of kilogram" to whoever will buy it, there will never be anything stopping you from creating your own definition of "open source" and carefully defining it in a license file. It's just that if that definition differs from the standardized one, developers will either have to carefully read your license (or have their lawyers do that), or choose to use a project with a standard license that's already been vetted a thousand times over.
I suggest that you read through the archives of the debian-legal mailing list to see how far the rabbit hole can go. Custom licenses are frequently fraught with problems that make them non-free by the DFSG (which also happens to be the template for the Open Source Definition).
From from extreme hubris, it is a valuable service that they provide to the community. Thanks to them, its easy and practical to pick from a spectrum of open source licenses that reflect your views as an author. Its also easy for you as a consumer to evaluate the usability of some piece of source code when the author chose from that same spectrum.
From from extreme hubris, it is a valuable service that they provide to the community. Thanks to them, its easy and practical to pick from a spectrum of open source licenses that reflect your views as an author. Its also easy for you as a consumer to evaluate the usability of some piece of source code when the author chose from that same spectrum.
The problem is when the readme file (or other marketing speak) says open source, so people think it's something that gives them the rights that OSI approved licences give, and then the license file says something else. For example, MongoDb's SSPL v1 or licenses with the commons clause.
People are free to use whatever license they want. They should own up to it though instead of trying to paint their license as something else.
People are free to use whatever license they want. They should own up to it though instead of trying to paint their license as something else.
[deleted]
"Trust" goes beyond just reading licenses. Actually I would say that if I have to hire a lawyer to read license files to tell me what is meant and how it's enforceable, I have quite the opposite of trust.
"Trust" means that members of a community generally presume good faith in each other (because of a record of past successful interactions, not because they believe in presuming good faith as a virtue) and believes they're working towards the same goal. This requires having some form of shared values. You don't need trust to implement a system of contract law, which is all you need if you're reading licenses. But then you merely have a civil society, not a community.
"Trust" means not only that you can expect other people to write open-source code but you can expect them to share the belief that writing open-source code is valuable.
"Trust" means that members of a community generally presume good faith in each other (because of a record of past successful interactions, not because they believe in presuming good faith as a virtue) and believes they're working towards the same goal. This requires having some form of shared values. You don't need trust to implement a system of contract law, which is all you need if you're reading licenses. But then you merely have a civil society, not a community.
"Trust" means not only that you can expect other people to write open-source code but you can expect them to share the belief that writing open-source code is valuable.
Reading through new licenses, and getting them approved by your legal departament isn't fun to anyone, plus some licenses are very subtly non-free - see the JSON license with its "do no evil" clause as an example.
Definitions don't belong to committees.
"open source" isn't a trademarked or otherwise protected phrase, it does not belong to the OSI, it is not synonymous with (has an)"open source initiative Approved License".
Coining a term or being among the first to use it does not mean that term belongs to you.
There are many people that disagree with the OSI about what "open source" means, and that is what it takes for a definition.
There is a certain irony in the OSI talking about open source like they own it.
"open source" isn't a trademarked or otherwise protected phrase, it does not belong to the OSI, it is not synonymous with (has an)"open source initiative Approved License".
Coining a term or being among the first to use it does not mean that term belongs to you.
There are many people that disagree with the OSI about what "open source" means, and that is what it takes for a definition.
There is a certain irony in the OSI talking about open source like they own it.
> "Definitions don't belong to committees"
> "[...]irony in the OSI talking about open source like they own it[...]"
The definition (and it's authority/legitimacy) belongs to (i.e. owned by) a community of contributors, very much like an open source project, not a committee (i.e. the OSI Board of Directors). Currently there are 508 members in the OSI's "License Discuss", and 266 members in the "License Review" communities. These are open to anyone to join, and participate in. These groups define "open source" as expressed trough licensing.
The Open Source Definition, as well as OSI Approved Open Source Licenses have been modified through the consensus of these communities (e.g. the addition of a 10th criterion to the OSD, and work around open source license proliferation).
(Full disclosure, I am currently the General Manager at the OSI).
> "[...]irony in the OSI talking about open source like they own it[...]"
The definition (and it's authority/legitimacy) belongs to (i.e. owned by) a community of contributors, very much like an open source project, not a committee (i.e. the OSI Board of Directors). Currently there are 508 members in the OSI's "License Discuss", and 266 members in the "License Review" communities. These are open to anyone to join, and participate in. These groups define "open source" as expressed trough licensing.
The Open Source Definition, as well as OSI Approved Open Source Licenses have been modified through the consensus of these communities (e.g. the addition of a 10th criterion to the OSD, and work around open source license proliferation).
(Full disclosure, I am currently the General Manager at the OSI).
> Coining a term or being among the first to use it does not mean that term belongs to you.
I wish that people would understand this not only in the context of definitions but also in the context of culture. Neither definitions nor culture belong to anyone. At the same time, they "belong" to everyone.
I wish that people would understand this not only in the context of definitions but also in the context of culture. Neither definitions nor culture belong to anyone. At the same time, they "belong" to everyone.
Self-replying to nail down what I strongly disagree with:
>Can I call my program "Open Source" even if I don't use an approved license?
>Please don't do that. If you call it "Open Source" without using an approved license, you will confuse people. This is not merely a theoretical concern — we have seen this confusion happen in the past, and it's part of the reason we have a formal license approval process. See also our page on license proliferation for why this is a problem.
This is from their FAQ and an example of the OSI explicitly acting like they own "open source". I am fine with proprietary terms being owned and controlled, for example "USB". I am not fine with organizations trying to usurp the language to try to push forward their agenda regardless of their intentions (and generally I approve of the mission of OSI)
>Can I call my program "Open Source" even if I don't use an approved license?
>Please don't do that. If you call it "Open Source" without using an approved license, you will confuse people. This is not merely a theoretical concern — we have seen this confusion happen in the past, and it's part of the reason we have a formal license approval process. See also our page on license proliferation for why this is a problem.
This is from their FAQ and an example of the OSI explicitly acting like they own "open source". I am fine with proprietary terms being owned and controlled, for example "USB". I am not fine with organizations trying to usurp the language to try to push forward their agenda regardless of their intentions (and generally I approve of the mission of OSI)
> This is from their FAQ and an example of the OSI explicitly acting like they own "open source"
No, if they were acting like they owned the term, they’d say “No, and we'll take coercive action to stop you if you do.”
What they are actually saying is (in short) “Please don't, experience has shown it causes confusion.”
No, if they were acting like they owned the term, they’d say “No, and we'll take coercive action to stop you if you do.”
What they are actually saying is (in short) “Please don't, experience has shown it causes confusion.”
They're not usurping it. They literally created it as a term (and "brand") rather than simply two words. They weren't granted a trademark, so their creation of it has no legal weight, but that doesn't mean they can't claim authority over what it means, and ask that their original intent be respected.
They don't own the trademark, but they could have, had the USPTO ruled differently. Much less exclusive terms, like Apple, have been trademarked.
To many in the open source community, myself included, when we hear open source we think of the open source initiative, opensource.org, and/or their logo.
I'm not bothered by your viewpoint. Sure, we don't own the trademark, but to me, open source is and long has been the culture that emerged out of the early days of building an open source operating system (Linux, GNU/Linux, *BSD, etc).
If you want "open source" to be a meaningless term, I'd first suggest trying to convince OSI to part ways with opensource.org. I don't think it's for sale, but maybe you could infiltrate the organization. Many have tried.
To many in the open source community, myself included, when we hear open source we think of the open source initiative, opensource.org, and/or their logo.
I'm not bothered by your viewpoint. Sure, we don't own the trademark, but to me, open source is and long has been the culture that emerged out of the early days of building an open source operating system (Linux, GNU/Linux, *BSD, etc).
If you want "open source" to be a meaningless term, I'd first suggest trying to convince OSI to part ways with opensource.org. I don't think it's for sale, but maybe you could infiltrate the organization. Many have tried.
English is not a prescriptive language: there is no committee with whom you can register a meaning.
But that means that meanings are determined by how people use the term, and the OSI is claiming that what people generally mean by the term is the OSD, and backing up that claim with signatories.
It's of course possible to choose to mean something different by "kilogram." Nobody has trademarked the word. But the word nonetheless has a clear and well-accepted meaning, and someone who uses "kilogram" to mean "the weight of a liter of water from my tap right now" is using a nonstandard and potentially confusing definition. That's the point of their analogy.
But that means that meanings are determined by how people use the term, and the OSI is claiming that what people generally mean by the term is the OSD, and backing up that claim with signatories.
It's of course possible to choose to mean something different by "kilogram." Nobody has trademarked the word. But the word nonetheless has a clear and well-accepted meaning, and someone who uses "kilogram" to mean "the weight of a liter of water from my tap right now" is using a nonstandard and potentially confusing definition. That's the point of their analogy.
>It's of course possible to choose to mean something different by "kilogram." Nobody has trademarked the word. But the word nonetheless has a clear and well-accepted meaning, and someone who uses "kilogram" to mean "the weight of a liter of water from my tap right now" is using a nonstandard and potentially confusing definition. That's the point of their analogy.
This is a very bad example.
If I were to go to your grocery store and buy a kilogram of apples from you, but your "kilogram" was a weight invented by you, you would be breaking the law. More or less every country has legal definitions of weights and measures. They are not "common usage" but very strictly prescribed.
OSI is trying hard to prescribe the meaning of a term they have no rights to.
This is a very bad example.
If I were to go to your grocery store and buy a kilogram of apples from you, but your "kilogram" was a weight invented by you, you would be breaking the law. More or less every country has legal definitions of weights and measures. They are not "common usage" but very strictly prescribed.
OSI is trying hard to prescribe the meaning of a term they have no rights to.
It's not a "de jure" standard, but it is a "de facto" standard. In every meaningful sense, the OSD is the definition of "Open Source".
> There are many people that disagree with the OSI about what "open source" means, and that is what it takes for a definition.
> There is a certain irony in the OSI talking about open source like they own it.
They defined it, there are many people that disagree that the Earth is spherical -it's still doesn't make it true.
> There is a certain irony in the OSI talking about open source like they own it.
They defined it, there are many people that disagree that the Earth is spherical -it's still doesn't make it true.
Arguably OSI took the DFSG, which was understood to only apply to Debian, renamed it the OSD, and then tried to apply it to the whole OSS movement.
So this is yet another comments thread where I see numerous people not agreeing with OSI definition of "Open Source" and it got me wondering again, has there always been such a sentiment, or is it a recent one?
I don't recall seeing it as much even a couple of years ago. Has there been some anti-OSI movement, and if so is there somewhere I could read about arguments against OSI? It seems most comments seem to be boiling down to "you are not going to tell me what I can do" but that's perhaps unfair.
As mentioned elsewhere, the original debates around "open source", as both a term and movement, centered around "free" vs. "open", or the value, benefits, ethics, etc. of copyleft/reciprocal licenses vs. permissive licensing. Interestingly, while there is no trademark protection (i.e. ownership) of the term "free software", the founders of the OSI, recognized and honored that label's definition as described by RMS, GNU, and FSF--as well as their authority as stewards--and created another label, "open source software". There are many, many contemporaneous documents that reflect this debate.
Today, I believe those issues have been resolved (i.e. clearly understood), with both the free software and open source communities agreeing that both labels and communities support software freedom: to study, use, modify, and redistribute.
I personally feel, and in my experience as General Manager at the OSI, there is an increase of people/organizations raising issues over the open source label, it's definition, and the OSI's role as steward. My sense is, as open source software and communities that create it--both non-profit foundations and businesses--realize the benefits of collaborative co-creation, and see greater success, more people/organizations are enticed. You can see this in other "open" initiatives like "Open Content", "Open Source Hardware", "Open Data", "Open Educational Resources", etc. Clearly there is value in communities of practice collaborating around shared interests, and indeed these communities can operate in a variety of ways to generate artifacts defined by those communities, e.g. what is "open content"?
As a corollary, success has raised the profile of open source projects and developers, so there are simply more discussions happening now across more communities. When free and open source software was less popular (with the debate focused on, how can this be good if it is developed by non-professionals, is unsecured, poor quality, etc.), there simply may have been fewer discussions.
Now that "open source has won", many may be debating what about open source makes it a winner, and thus, what is open source.
Today, I believe those issues have been resolved (i.e. clearly understood), with both the free software and open source communities agreeing that both labels and communities support software freedom: to study, use, modify, and redistribute.
I personally feel, and in my experience as General Manager at the OSI, there is an increase of people/organizations raising issues over the open source label, it's definition, and the OSI's role as steward. My sense is, as open source software and communities that create it--both non-profit foundations and businesses--realize the benefits of collaborative co-creation, and see greater success, more people/organizations are enticed. You can see this in other "open" initiatives like "Open Content", "Open Source Hardware", "Open Data", "Open Educational Resources", etc. Clearly there is value in communities of practice collaborating around shared interests, and indeed these communities can operate in a variety of ways to generate artifacts defined by those communities, e.g. what is "open content"?
As a corollary, success has raised the profile of open source projects and developers, so there are simply more discussions happening now across more communities. When free and open source software was less popular (with the debate focused on, how can this be good if it is developed by non-professionals, is unsecured, poor quality, etc.), there simply may have been fewer discussions.
Now that "open source has won", many may be debating what about open source makes it a winner, and thus, what is open source.
It's not new.
OSI was spawned as a more business friendly reaction to the "moralizing" of Richard Stallman and other "Free Software" believers. There will always be argument over definitional identities, especially of basically philosophical movements.
OSI was spawned as a more business friendly reaction to the "moralizing" of Richard Stallman and other "Free Software" believers. There will always be argument over definitional identities, especially of basically philosophical movements.
I'm proud to see an organization I'm active in, the Rensselaer Center for Open Source, on this list! Just last week a representative from the OSI came to my university (RPI) to talk about what it means to be OSI affiliate members.
Isn't this what trademarks are for? If they want to enforce what the meaning of a term is in a a given domain they could come up with a new term and trademark it.
The term "open source" is not a trademark and at this point it probably cannot be trademarked by anyone. In uncontroversial cases people are happy to let the OSI be the arbiter of open sourceness but in controversial cases people tend to decide that OSI doesn't control the meaning of open source.
That's my point. It isn't a trademark. They should come up with something new that is. 'OSI Approved' would be fine.
The term "open source" can not be trademarked (just like Kilogram can not); the mark is too "descriptive." The OSI does have trademarks for "OSI Approved Open Source License", as well of course for its own branding, e.g. the "OSI Keyhole Logo" and the name "Open Source Initiative."
> The OSI does have trademarks for "OSI Approved Open Source License"
So why don't they encourage people to use that then?
Rather than telling people how to use another exiting term with a debated definition?
So why don't they encourage people to use that then?
Rather than telling people how to use another exiting term with a debated definition?
Nobody would ever care about new terminology.
OSI actually attempted to trademark "open source" and failed.
In uncontroversial cases, it is not that people let the OSI be the arbiter, but rather, they have no need to argue with the OSI about the use of the term in those cases because their goals are aligned. The controversial cases make this clear - many people do not see the OSI as the authority on the term, and never have.
Yes, but open source was already used before the OSI came about. I don't think anyone knows exactly who coined it and when. OSI is trademarked, and they are in their rights to defend that trademark, but that obviously does not extend to "open source." This statement is an attempted protectionist power grab to assert control over the term and prevent competing initiatives from using it.
It's pretty well known who coined open source and why. It's also known shortly thereafter OSI started protecting the definition.
https://opensource.com/article/18/2/coining-term-open-source...
https://opensource.org/history
https://opensource.com/article/18/2/coining-term-open-source...
https://opensource.org/history
It may have been used before they did in the context of computer software, but if so such usage seems to have been very sparse. I tried to research it once, a long time ago, and my recollection is that I found maybe one or two possible examples on Usenet but nothing else.
> It may have been used before they did in the context of computer software
I'm pretty sure the use in intelligence jargon long predates the software use. But that's disambiguated easily by context, it's not really a conflicting use.
I'm pretty sure the use in intelligence jargon long predates the software use. But that's disambiguated easily by context, it's not really a conflicting use.
They're not trying to enforce it in the sense of sending the police after you for misusing it. They're just trying to establish that it has one well-accepted definition.
The definition is not well-accepted. For example, why does the AGPL get a free pass but the SSPL does not?
When it comes down to it, there are just a bunch of people who make arbitrary decisions about what is to be included.
But what they include should not matter to you. You should not be making your decision to use software based on whether or not the OSI approved it - unless you don't have the means or expertise to decipher the specific requirements of a language and are more than happy to take the word of this organization for it.
Ultimately, the OSI is a protectionist organization which is attempting to prevent a competing organization from using the term "open source" because they don't quite agree on some subtle details that an innovative licensor has chosen to attempt to gain approval of. Whether they gain approval is for the market to decide - not the OSI.
When it comes down to it, there are just a bunch of people who make arbitrary decisions about what is to be included.
But what they include should not matter to you. You should not be making your decision to use software based on whether or not the OSI approved it - unless you don't have the means or expertise to decipher the specific requirements of a language and are more than happy to take the word of this organization for it.
Ultimately, the OSI is a protectionist organization which is attempting to prevent a competing organization from using the term "open source" because they don't quite agree on some subtle details that an innovative licensor has chosen to attempt to gain approval of. Whether they gain approval is for the market to decide - not the OSI.
The definition is well-accepted; the interpretation of the definition in difficult (and perhaps intentionally-difficult) cases is not. That seems perfectly reasonable and pretty common. The existence of cyan doesn't mean the definition of blue isn't well-accepted.
And in any case, I'm not making my decision based on the OSI approving it. I'm making my decision based on my personal consideration that the DFSG expresses principles that are important to me, and the OSD is basically the same thing. (The DFSG, however, does clarify that certain licenses are "a compromise," which seems to have been dropped in the OSD, and I think it's perfectly valid for a definition to have this level of nuance.) I'm making my decision based on my personal belief that "innovating" on these principles isn't great, and the market is the exact opposite of the entity I want deciding on how free/open source software works.
For the record, I do actually see the AGPL as "innovating" against the spirit of the DFSG/OSI, although I don't think there's a strong argument that they're non-compliant with the letter of the OSD/DFSG, and I personally avoid it. There's a practical problem that AGPL code becomes unusable when embedded in contexts that don't admit an obvious way to offer source through network interactions (e.g., you can't incorporate something into OpenSSL). But it is innovating in a different way from the SSPL.
And in any case, I'm not making my decision based on the OSI approving it. I'm making my decision based on my personal consideration that the DFSG expresses principles that are important to me, and the OSD is basically the same thing. (The DFSG, however, does clarify that certain licenses are "a compromise," which seems to have been dropped in the OSD, and I think it's perfectly valid for a definition to have this level of nuance.) I'm making my decision based on my personal belief that "innovating" on these principles isn't great, and the market is the exact opposite of the entity I want deciding on how free/open source software works.
For the record, I do actually see the AGPL as "innovating" against the spirit of the DFSG/OSI, although I don't think there's a strong argument that they're non-compliant with the letter of the OSD/DFSG, and I personally avoid it. There's a practical problem that AGPL code becomes unusable when embedded in contexts that don't admit an obvious way to offer source through network interactions (e.g., you can't incorporate something into OpenSSL). But it is innovating in a different way from the SSPL.
In what way does the agpl even compare to the sspl? The agpl doesn't extend itself to any other software you're running.
The AGPL has the requirement that all "derived works" are equivalently licensed.
The SSPL does the same, except it has a different definition of what a derived work is, based on a more modern understanding of how software is used and distributed mainly through cloud services. People are using semantic loopholes to sidestep their AGPL requirements (the intended requirements, even if not enforcible).
Whether something is a "derived work" is not black and white, but for a court to decide. It isn't at the whim of a panel of OSI judges to decide.
The SSPL does the same, except it has a different definition of what a derived work is, based on a more modern understanding of how software is used and distributed mainly through cloud services. People are using semantic loopholes to sidestep their AGPL requirements (the intended requirements, even if not enforcible).
Whether something is a "derived work" is not black and white, but for a court to decide. It isn't at the whim of a panel of OSI judges to decide.
The gpl is defined by the same metrics, so I don't understand what issue you take with the agpl.
Moreover, "they're the same because the sspl redefined a term to mean something entirely different" is intellectually dishonest.
Moreover, "they're the same because the sspl redefined a term to mean something entirely different" is intellectually dishonest.
You're still missing my point. The AGPL closed a loophole of GPL software that people did not need to release the source code because they never actually released the software (but made it available through a server). We can agree that the AGPL is the successor in spirit of the GPL because it tries to close such loophole and make the software and derived works be required to be published under the license as the author intended.
The use of cloud services to sidestep the AGPL requirements is the newest loophole to try and avoid the requirements that the software author intended. The SSPL is in that sense, the spiritual successor to the AGPL attempting to close the loophole, just as the AGPL closed the GPL loophole before it.
The problem here is, that we're in unexplored territory. MongoDB is attempting something new and innovative to try and establish what the author of a piece of software expects from the users of that software. Some might argue that the purpose is to extract money, which may or may not be true, but it is beside the point. They should be able to test such licensing and have the market decide whether or not it is acceptable - whether people want stronger copyleft or whether they AGPL is the limit of copyleftness they're willing to accept.
"Derived work" has no concrete definition. It is mostly a case of examining previous legal cases for comparison, and coming to a judgement which takes previous cases and the nuances of the specific situation into account. We have a legal system which handles these cases, so that specific organizations don't become the arbitrary rule makers of society.
In my opinion, if you're making a user interface which merely wraps an existing database, then you're creating a derived work. The technicalities of whether or not you're "making available" the software shouldn't be the deciding factor. The AGPL, in spirit, requires that people release derived works under it, even if the precise legalese allows you to sidestep it.
Work licensed under the SSPL has almost all of the same freedoms AGPL works have, unless you are a cloud provider attempting to wiggle your way around the licensing requirements for derived works, and only then the additional clause steps in.
So they have every right to label it as "open source", because the source code is open, and restrictions on its use are few, or irrelevant to most users. The OSI is not the judge of whether or not they are open source. Everyone is their own judge and can call it what they want.
This movement by the OSI is clearly an attempt to assert control over the term "open source," to prevent Mongo and others using it if it does not fit their definition. IMO, such efforts should be resisted because they prevent licensing innovation. The OSI would become the obstacle to trying new open licensing schemes. They are not an unbiased party like a legal court - they have a vested interest in their current licensing definition and are protectionist in not wanting competing definitions.
The use of cloud services to sidestep the AGPL requirements is the newest loophole to try and avoid the requirements that the software author intended. The SSPL is in that sense, the spiritual successor to the AGPL attempting to close the loophole, just as the AGPL closed the GPL loophole before it.
The problem here is, that we're in unexplored territory. MongoDB is attempting something new and innovative to try and establish what the author of a piece of software expects from the users of that software. Some might argue that the purpose is to extract money, which may or may not be true, but it is beside the point. They should be able to test such licensing and have the market decide whether or not it is acceptable - whether people want stronger copyleft or whether they AGPL is the limit of copyleftness they're willing to accept.
"Derived work" has no concrete definition. It is mostly a case of examining previous legal cases for comparison, and coming to a judgement which takes previous cases and the nuances of the specific situation into account. We have a legal system which handles these cases, so that specific organizations don't become the arbitrary rule makers of society.
In my opinion, if you're making a user interface which merely wraps an existing database, then you're creating a derived work. The technicalities of whether or not you're "making available" the software shouldn't be the deciding factor. The AGPL, in spirit, requires that people release derived works under it, even if the precise legalese allows you to sidestep it.
Work licensed under the SSPL has almost all of the same freedoms AGPL works have, unless you are a cloud provider attempting to wiggle your way around the licensing requirements for derived works, and only then the additional clause steps in.
So they have every right to label it as "open source", because the source code is open, and restrictions on its use are few, or irrelevant to most users. The OSI is not the judge of whether or not they are open source. Everyone is their own judge and can call it what they want.
This movement by the OSI is clearly an attempt to assert control over the term "open source," to prevent Mongo and others using it if it does not fit their definition. IMO, such efforts should be resisted because they prevent licensing innovation. The OSI would become the obstacle to trying new open licensing schemes. They are not an unbiased party like a legal court - they have a vested interest in their current licensing definition and are protectionist in not wanting competing definitions.
> The use of cloud services to sidestep the AGPL requirements is the newest loophole to try and avoid the requirements that the software author intended.
See, I disagree with you wholly here. Cloud-based services are literally what the AGPL was designed to "counter". Changes to the application _itself_ need to be released, but anything supporting said application is out-of-scope of the license.
> "Derived work" has no concrete definition.
I think the definition given by the copyright office is as close as we'll get. [2]
>> A derivative work is a work based on or derived from one or more already exist-ing works. Common derivative works include translations, musical arrange-ments, motion picture versions of literary material or plays, art reproductions, abridgments, and condensations of preexisting works. Another common type of derivative work is a “new edition” of a preexisting work in which the edito-rial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work.
>> To be copyrightable, a derivative work must incorporate some or all of a preexisting “work” and add new original copyrightable authorship to that work.
Specifically that last sentence quoted. Management software that does not contain the original code is not a derived work.
> Work licensed under the SSPL has almost all of the same freedoms AGPL works have, unless you are a cloud provider attempting to wiggle your way around the licensing requirements for derived works, and only then the additional clause steps in.
I also wholly disagree with you here. SSPL violates the 4 Freedoms [1], and as such is substantially different. It's not something that you can go, "well, but I don't like that, so I'm not going to include it in my definition of equal".
Freedom 0 ("The freedom to run the program as you wish, for any purpose") cannot be "qualified with "conditions", otherwise it is not a freedom. Freedom 0 is also fundamental for the other Freedoms to even be meaningful.
[1] https://www.gnu.org/philosophy/free-sw.en.html
[2] https://www.copyright.gov/circs/circ14.pdf
See, I disagree with you wholly here. Cloud-based services are literally what the AGPL was designed to "counter". Changes to the application _itself_ need to be released, but anything supporting said application is out-of-scope of the license.
> "Derived work" has no concrete definition.
I think the definition given by the copyright office is as close as we'll get. [2]
>> A derivative work is a work based on or derived from one or more already exist-ing works. Common derivative works include translations, musical arrange-ments, motion picture versions of literary material or plays, art reproductions, abridgments, and condensations of preexisting works. Another common type of derivative work is a “new edition” of a preexisting work in which the edito-rial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work.
>> To be copyrightable, a derivative work must incorporate some or all of a preexisting “work” and add new original copyrightable authorship to that work.
Specifically that last sentence quoted. Management software that does not contain the original code is not a derived work.
> Work licensed under the SSPL has almost all of the same freedoms AGPL works have, unless you are a cloud provider attempting to wiggle your way around the licensing requirements for derived works, and only then the additional clause steps in.
I also wholly disagree with you here. SSPL violates the 4 Freedoms [1], and as such is substantially different. It's not something that you can go, "well, but I don't like that, so I'm not going to include it in my definition of equal".
Freedom 0 ("The freedom to run the program as you wish, for any purpose") cannot be "qualified with "conditions", otherwise it is not a freedom. Freedom 0 is also fundamental for the other Freedoms to even be meaningful.
[1] https://www.gnu.org/philosophy/free-sw.en.html
[2] https://www.copyright.gov/circs/circ14.pdf
> A derivative work is a work based on or derived from one or more already exist-ing works.
A management software might be considered a derived work, depending on how coupled it is with the underlying software. There is no black and white definition. The FSF state[1]
>> Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).
>> So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.
[1]:https://www.gnu.org/licenses/gpl-faq.html#MereAggregation
> Freedom 0 ("The freedom to run the program as you wish, for any purpose")
How does the SSPL violate the freedom in a way that the AGPL does not?
The AGPL places a condition on this freedom. The condition that if you make the work available through a public server, then you must make the source code available too.
The SSPL is attempting to do the same for what it perceives as derived works (the management software, which is useless without the underlying software). It doesn't place any restriction on use, because you are still free to use it. You just have the condition that you make the code of your derived works available too, similar to the AGPL.
A management software might be considered a derived work, depending on how coupled it is with the underlying software. There is no black and white definition. The FSF state[1]
>> Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).
>> So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.
[1]:https://www.gnu.org/licenses/gpl-faq.html#MereAggregation
> Freedom 0 ("The freedom to run the program as you wish, for any purpose")
How does the SSPL violate the freedom in a way that the AGPL does not?
The AGPL places a condition on this freedom. The condition that if you make the work available through a public server, then you must make the source code available too.
The SSPL is attempting to do the same for what it perceives as derived works (the management software, which is useless without the underlying software). It doesn't place any restriction on use, because you are still free to use it. You just have the condition that you make the code of your derived works available too, similar to the AGPL.
> The AGPL closed a loophole of GPL software
No, it didn't, if it closed a GPL loophole, it would have been a subsequent version of the GPL. It provided an alternative to serve slightly different interests while remaining compatible with Free Software principles and the copyleft mechanism of preventing proprietary derivative works.
> We can agree that the AGPL is the successor in spirit of the GPL
No, we can't, they are licenses maintained in parallel by the same entity. The successor in spirit to the GPL is the subsequent version of the GPL. The AGPL is a related alternative—not a successor, spiritual or otherwise—to the GPL.
> The use of cloud services to sidestep the AGPL requirements is the newest loophole
Cloud services are pretty much exactly what the AGPL is aimed at (well, remotely hosted web services; whether they are dynamically provisioned as implied by “cloud” is immaterial, both to the AGPL and to the incorrect allegation of sidestepping.) Cloud services do not enable sidestepping any intended feature of the AGPL, because they do nothing relevant to it's operation that the initial environment to which the AGPL was targeted did not.
Now, there may be things MongoDB authors want that the AGPL creators did not intend to provide, but that's not a loophole in the AGPL, but a fundamental divergence of purpose.
> The problem here is, that we're in unexplored territory.
No, we aren't.
> MongoDB is attempting something new and innovative to try and establish what the author of a piece of software expects from the users of that software.
This is true only in the trivial sense that it is true of every new (whether completely original or slightly modified from some other) license, proprietary or FOSS.
> Some might argue that the purpose is to extract money, which may or may not be true, but it is beside the point.
It may be beside the point that you want people to focus on, but neither the express fact that the intent is both to extract money and to do so by restricting other party’s freedom to use the software is precisely the point for people who care about the ethos of either the Free Software or Open Source communities (or, even for those who don't care about the ethos, but are sold on the practical benefits of the freedom provided by licenses inspired by the ethos of those communities.)
> Work licensed under the SSPL has almost all of the same freedoms AGPL works have
And a braindead body kept on life support has almost all of the same functions as a living body. But, in either case, there are rather critical differences hidden under “almost”.
> So they have every right to label it as "open source",
“open source” has a well established and understood use in software, and calling the SSPL open source conflicts with that in a way which is deceptive, and the only reason for making the claim is to commercially capitalize on that deception. Established usage in the field is one of the things looked at to determine if the kind of deception required for fraud is present, and I think a case can be made that making this deceptive representation in promotion of commercial products and services is fraudulent.
No, it didn't, if it closed a GPL loophole, it would have been a subsequent version of the GPL. It provided an alternative to serve slightly different interests while remaining compatible with Free Software principles and the copyleft mechanism of preventing proprietary derivative works.
> We can agree that the AGPL is the successor in spirit of the GPL
No, we can't, they are licenses maintained in parallel by the same entity. The successor in spirit to the GPL is the subsequent version of the GPL. The AGPL is a related alternative—not a successor, spiritual or otherwise—to the GPL.
> The use of cloud services to sidestep the AGPL requirements is the newest loophole
Cloud services are pretty much exactly what the AGPL is aimed at (well, remotely hosted web services; whether they are dynamically provisioned as implied by “cloud” is immaterial, both to the AGPL and to the incorrect allegation of sidestepping.) Cloud services do not enable sidestepping any intended feature of the AGPL, because they do nothing relevant to it's operation that the initial environment to which the AGPL was targeted did not.
Now, there may be things MongoDB authors want that the AGPL creators did not intend to provide, but that's not a loophole in the AGPL, but a fundamental divergence of purpose.
> The problem here is, that we're in unexplored territory.
No, we aren't.
> MongoDB is attempting something new and innovative to try and establish what the author of a piece of software expects from the users of that software.
This is true only in the trivial sense that it is true of every new (whether completely original or slightly modified from some other) license, proprietary or FOSS.
> Some might argue that the purpose is to extract money, which may or may not be true, but it is beside the point.
It may be beside the point that you want people to focus on, but neither the express fact that the intent is both to extract money and to do so by restricting other party’s freedom to use the software is precisely the point for people who care about the ethos of either the Free Software or Open Source communities (or, even for those who don't care about the ethos, but are sold on the practical benefits of the freedom provided by licenses inspired by the ethos of those communities.)
> Work licensed under the SSPL has almost all of the same freedoms AGPL works have
And a braindead body kept on life support has almost all of the same functions as a living body. But, in either case, there are rather critical differences hidden under “almost”.
> So they have every right to label it as "open source",
“open source” has a well established and understood use in software, and calling the SSPL open source conflicts with that in a way which is deceptive, and the only reason for making the claim is to commercially capitalize on that deception. Established usage in the field is one of the things looked at to determine if the kind of deception required for fraud is present, and I think a case can be made that making this deceptive representation in promotion of commercial products and services is fraudulent.
A noble effort, but futile in my opinion. Trying to get the tech world to agree on something is like trying to herd cats. It's not going to work. What's to prevent another organization(s) from "forking" their own definition of open source. And good luck trying to get the differing major license camps ( MIT, GNU, etc ) to agree on anything.
Count us (Fogbeam Labs) in! The OSD is the de facto definition of Open Source, and we're proud to back the OSI on this.
"Open source" is just English words you can look up in a dictionary; it can mean any number of things.
If we disconnect one end of a field effect transistor, the one opposite to the "drain", we have an "open source".
If we disconnect one end of a field effect transistor, the one opposite to the "drain", we have an "open source".
If we disconnect one end of a field effect transistor, the one opposite to the "drain", we have an "open source".
True, but totally irrelevant here.
Context matters.
True, but totally irrelevant here.
Context matters.
> Context matters.
That's actually the point. In the context of software source code, "open source" still doesn't mean whatever these guys say it means.
Only in the very narrow context of their specific organization and affiliates.
That's actually the point. In the context of software source code, "open source" still doesn't mean whatever these guys say it means.
Only in the very narrow context of their specific organization and affiliates.
Only in the very narrow context of their specific organization and affiliates.
That's not even close to true. There's a small niche group of people who don't acknowledge / accept that the OSD is, in every meaningful sense, the definition of Open Source.
That's not even close to true. There's a small niche group of people who don't acknowledge / accept that the OSD is, in every meaningful sense, the definition of Open Source.
Most people who use "open source" in reference to software have never heard of OSI or its OSD, and could not recite its detailed points. Their understanding might not be in conflict with the OSD, but it's not in precise conformance with it.
For instance, oh, "The license may restrict source-code from being distributed in modified form only if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. " Most people, including developers, don't know what a "patch file" is, so how can this be part of their definition when they use the term "open source".
Here are much more authoritative definitions, which are far briefer than the OSD's seven points:
https://en.oxforddictionaries.com/definition/us/open-source
https://www.merriam-webster.com/dictionary/open-source
(Both would have us hyphenate the term.)
For instance, oh, "The license may restrict source-code from being distributed in modified form only if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. " Most people, including developers, don't know what a "patch file" is, so how can this be part of their definition when they use the term "open source".
Here are much more authoritative definitions, which are far briefer than the OSD's seven points:
https://en.oxforddictionaries.com/definition/us/open-source
https://www.merriam-webster.com/dictionary/open-source
(Both would have us hyphenate the term.)
"open source" is just two words. "open" and "source", the latter being short for source code. I hate to break it to you, but language does not work by having people sign statements to declare that you think certain words can only be used in certain contexts that you think are worthy of your cause.
The people signing such statements are wasting their time. Their signature does not, and cannot prevent people from using "open" and "source" together, to mean something where the source code is open for inspection, if it doesn't quite fit their over-engineered definition.
"open source" and "OSI approved" are simply not synonymous and hopeful wishing will never make it so.
The people signing such statements are wasting their time. Their signature does not, and cannot prevent people from using "open" and "source" together, to mean something where the source code is open for inspection, if it doesn't quite fit their over-engineered definition.
"open source" and "OSI approved" are simply not synonymous and hopeful wishing will never make it so.
Like all symbols (e.g., statues, logos, sounds, buildings, etc.), there is no innate meaning for words. We are completely free to attach any arbitrary meaning to a word and use it to convey that meaning. That doesn't mean it is without problems and that's the case with open source.
The existing community in which open source is used largely understands "open" to refer to freedom in the broadest means possible. That's the word's denotative sense. It also carries a strong connotative sense in which it is viewed as a positive for business and society.
What's happening is that you have a small group of people who desire to benefit from the connotative sense of the word while changing denotative sense. That creates problems when they're not clear that they don't mean open source in the same way that it's understand commonly amongst the technical community.
It's underhanded and dishonest.
If they want to create a quasi-open source license, that's fine. They simply should be very clear that it's not open source in the traditional/common sense.
The existing community in which open source is used largely understands "open" to refer to freedom in the broadest means possible. That's the word's denotative sense. It also carries a strong connotative sense in which it is viewed as a positive for business and society.
What's happening is that you have a small group of people who desire to benefit from the connotative sense of the word while changing denotative sense. That creates problems when they're not clear that they don't mean open source in the same way that it's understand commonly amongst the technical community.
It's underhanded and dishonest.
If they want to create a quasi-open source license, that's fine. They simply should be very clear that it's not open source in the traditional/common sense.
Common meaning behind open source is not actually OSI approved open source and never was by the way. OSI, for example, rejects public domain, while for pretty much everyone else public domain is open source. Broad freedom is even trickier to talk about. FSF, for example, built an entire ideology on the meaning of freedom.
Public domain isn't open source, that concept doesn't exist in every country.
Not sure how any of this would contradict anything I've mentioned. Perhaps you don't mean it to do so? If you do, you'll have to explain more because I'm not really following.
Copyleft licenses are not necessarily "free in the broadest sense possible." They place certain restrictions on what you must do with software you publish which contains code licensed under such licenses. There are several such copyleft licenses approved by the OSI which clearly do not fit your all-encompassing freedom definition. You also have approved license which place restrictions on use of branding and trademarks, and no effort is made by OSI to restrict licenses to those which also include a patent grant.
So if someone creates another kind of copyleft license, which is not quite the same as say, the GPL, but has the same spirit of the GPL, including a patent grant, then are they not allowed to use the term "open source" or "free software" because a protectionist organization declares itself the arbiter?
So if someone creates another kind of copyleft license, which is not quite the same as say, the GPL, but has the same spirit of the GPL, including a patent grant, then are they not allowed to use the term "open source" or "free software" because a protectionist organization declares itself the arbiter?
Even if I accept your reasoning here, it still doesn't change my main point.
What we have is a group of people (e.g., Lerna, etc.) trying to ride on the coattails of success of "open source" without being forthcoming about what they're doing.
We could be charitable and assume they're doing so out of ignorance, but I've seen way too many discussions on this issue where it's pointed out. I simply don't think they're ignorant. I've think they're being actively dishonest.
What we have is a group of people (e.g., Lerna, etc.) trying to ride on the coattails of success of "open source" without being forthcoming about what they're doing.
We could be charitable and assume they're doing so out of ignorance, but I've seen way too many discussions on this issue where it's pointed out. I simply don't think they're ignorant. I've think they're being actively dishonest.
>The existing community in which open source is used largely understands "open" to refer to freedom in the broadest means possible.
And yet nobody disputes that copyleft licenses, not just permissive licenses, are open source.
And yet nobody disputes that copyleft licenses, not just permissive licenses, are open source.
Bourbon is just a just a name. Champagne is just a region. But whiskeys and wines have to fit narrow qualifications to be Champagne sparkling wine, or Bourbon whiskey. You can, of course, call any software you want open source regardless if it fits the OSI definition, just like you can call any sparkling wine you want Champagne. It doesn't mean you'd be correct in doing so.
> But whiskeys and wines have to fit narrow qualifications to be Champagne sparkling wine, or Bourbon whiskey.
Isn't that because there's laws and treaties enforcing that? For example the US isn't a signatory to any treaties about Champagne so you do get American wine labelled as Champagne in American shops I believe.
There's no law enforcing the OSI's definition of 'open source'.
Isn't that because there's laws and treaties enforcing that? For example the US isn't a signatory to any treaties about Champagne so you do get American wine labelled as Champagne in American shops I believe.
There's no law enforcing the OSI's definition of 'open source'.
I wasn't referring to legality, only replying to the idea that "open" and "source" are "just two words". For an example closer to the subject at hand, the Free Software Foundation makes it clear what does and what does not fit the Free Software definition and that does not rely on the force of law.
No, the OSI is acting like it has legal rights to tell people how to use the phrase as much as is possible without actually saying they own the term. This is the problem. They aren't sharing opinions but giving orders.
Where in the article does the OSI mention or hint at anything about threat of law? The OSI does have the legal right to tell you what they think Open Source is. You have the legal right to ignore it. All OSI did is say "here is our definition of Open Source, and these are the people that agree with us, and you should agree with us too."
The laws and treaties exist because people believe words to have specific meanings, not the other way around. "Bourbon" and "champagne" meant something concrete before there were laws about what could be sold as bourbon and champagne.
Those are just protectionist legalities.
Are they saying I can't trust what I read in the license files of a project? This is beyond hubris...