Affirmation of the Open Source Definition
opensource.org
opensource.org
Are they saying I can't trust what I read in the license files of a project? This is beyond hubris...
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.
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.
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.
"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.
"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.
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.
>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)
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.”
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.
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.
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.
> 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.
> "[...]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).
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.
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.
https://opensource.com/article/18/2/coining-term-open-source...
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.
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?
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 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.
Moreover, "they're the same because the sspl redefined a term to mean something entirely different" is intellectually dishonest.
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.
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.
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.
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.
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.
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.
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 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.
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.)
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.
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'.
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.
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?
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.
And yet nobody disputes that copyleft licenses, not just permissive licenses, are open source.