Re: Latest OpenChain Specification 2.0 draft (Feb 3rd)
I believe I was one of the people tasked with gathering input for and drafting the definition in question here. Perhaps I can shed some light on the background relevant to Gustavo’s questions and also provide some reasons as to why the definition is not “poor”.
It is usually lawyers who draft definitions - be they in legal documents or specifications such as this - and, let’s face it, lawyers can get a bit wordy (perhaps some of them are paid by the word or the hour or something, I don’t know anything about that! ;) A well-drafted definition that is too “thorough” risks causing confusion, being redundant, or contradicting itself. Of course, a definition that is too concise may leave too much to interpretation. It is a very fine balance.
In the open source community, we are actually quite lucky to have two long-standing and well-known definitions of open source, which also are consistent with each other. Thus, it was thought wise to rest upon those. I believe an early draft had a bit of a definition itself as well as reference to the OSD and 4 freedoms, but that was removed; to include such language might imply that one has to explain the FSF or OSD, or might be seen as augmenting or replacing those - this would not be helpful.
Regarding the Open Source Definition (OSD): I have seen people confuse or conflate the OSD with OSI-approved. As Mark pointed out below - there are plenty of licenses that conform to the OSD, but have not been submitted to the OSI for review/approval. This is why the OpenChain definition states, "meet the Open Source Definition. . . “ - a license can meet the OSD, without being OSI-approved.
Arguably, one could refer to one of these definitions instead of both, but I think both were included with “or” for reasons of broader reach and not playing favorites among community orgs. I still think that is the appropriate approach.
Now that I’m looking at this part of the definition more closely, it may help to make the parenthetical consistent and remove the opensource.org link:
As for Gustavo’s key question regarding “or similar licenses” - those words do add some squishiness. My memory / thinking on that is that there are some licenses - for example for open data, open hardware - that may not exactly fit the OSD or the FSF 4 freedoms, but are, in spirit the same thing or fit the relevant analogous definition (e.g., the open hardware definition). It could be argued to simply remove them, I suppose.
When we drafted this, the Commons Clause, SSPL, and the other wolf-in-sheep’s-clothing licenses didn’t exist. Today, I can see where “or similar licenses” might make one a bit uncomfortable - could the “Commons Clause” be considered a “similar license”? (Of course, if a license is submitted to and rejected by the OSI, then it surely fails the meet the OSD, but is it still a “similar license"). In light of these more recent events, I could see an argument for simply removing those words. It would leave less room to wiggle around.
Finally, in many years now of drafting or explaining or otherwise defining things in the open source realm, I can say one thing with absolute confidence: there is no perfect, black and white definition. If lawyers (or others) want to fight on the specific wording and meaning of a word or group of words, room to argue can always be found (even if not successful). I still think that relying on the definitions that have existed and are pretty well-understood is our best bet. Those definitions are not perfect either, but they have some mileage. And I’d wager that if you somehow end up in court, fighting over what the wording of the OpenChain specification’s definition of open source software means… well, you’ve got bigger problems to solve (and nothing the OpenChain working group can do will solve those)!