6 ms·

> Without this single, standard definition of "open source," software development as we know it would not be possible. There is no trust in a world where anyone

> Without this single, standard definition of "open source," software development as we know it would not be possible. There is no trust in a world where anyone can invent their own definition for open source, and without trust there is no community, no collaboration, and no innovation. Are they saying I can't trust what I read in the license files of a project? This is beyond hubris...

Iolaum 8y ago
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.
- deleted 8y ago
  [deleted]
kklimonda 8y ago
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.
mithr 8y ago
> 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.
brandmeyer 8y ago
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.
geofft 8y ago
"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.

Iolaum 8y ago

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.

deleted 8y ago
[deleted]

kklimonda 8y ago

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.

mithr 8y ago

> 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.

brandmeyer 8y ago

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.

geofft 8y ago

"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.