Re: Latest OpenChain Specification 2.0 draft (Feb 3rd)


J Lovejoy
 

also - when lawyers aren’t ‘over-drafting’, we tend to be rampant plagiarizers. I had hoped (and still do) that OpenChain’s definition of open source might get some traction among lawyers elsewhere.  I’m sure many of you, like me, have seen some truly horrible definitions out there!*

* like defining open source as software under only OSI-approved licenses, or only copyleft licenses, or other dodgy descriptions that serve to reveal how little the drafter understood. I’ve even seen the same bad or variations of a certain definition get copied and pasted since 2010!! make it stop!!

… but I digress… ;)

On Feb 8, 2019, at 12:15 AM, J Lovejoy <opensource@...> wrote:

Hi all,

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:

- software subject to one or more licenses that meet the Open Source Definition (published by the Open Source Initiative) or the Free Software Definition (published by the Free Software Foundation) or similar license.

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)!

Thanks,
Jilayne



On Feb 7, 2019, at 9:48 PM, Gisi, Mark <Mark.Gisi@...> wrote:

Hi Gustavo,
 
Thanks for the feedback. I would be one of the first to admit – the OpenChain spec definition of Open Source Software is a poor one. Actually the idea that the definition of Open Source software is determined by the whether the software is available under an open source license is sound. The problem of lies with the definition of what an “open source license” is. We have tried to come up with a more formal definition but it was challenging to obtain community consensus. That does not mean we should not keep trying to do better.  
 
>> Probably this question have a simple answer based on US industry practice,
>> but for those that we are little far from that perspective it would be really
>>  helpful to understand the rationale behind the term "similar licenses".
 
There are many other licenses that have not been blessed by the OSI and FSF yet are understood to be open source licenses by their common acceptance. For instance, to name a few:
Curl license
 
Apple MIT License
 
BSD 2-Clause NetBSD License
 
bzip2 License
 
Beerware
 
MIT-Zero License
 
Creative common licenses, e.g.:
 
FSF Unlimited License
 
libpng License
 
CMU License
 
Open Government Licence v3.0
 
TCL/TK License
 
>> So, very respectfully, if the mission of section 2 would be to provide "definitions"
>> to be used in the specification, do not you think that the term "similar licenses"
>> should be defined?
 
I agree a definition for "similar licenses" would be beneficial but not easily obtainable (via consensus). A desirable long term solution is to come up with a simple yet general definition that covers the OSI, FSF and similar licenses. If there is sufficient interested I can re-initiate the discussion with the understanding we are unlikely to obtain closure for the version 2.0 release and that we could run into a wall again.
 
- Mark
 
From: openchain-bounces@... [mailto:openchain-bounces@...] On Behalf Of Gustavo G. Mármol Alioto
Sent: Thursday, February 07, 2019 1:36 PM
To: openchain@...
Subject: Re: [OpenChain] Latest OpenChain Specification 2.0 draft (Feb 3rd)
 

Hi Mark,

Many thanks for sending the links below. 

I have reviewed both, and from the mark up version, and without the intention to re-opened past discussion that you probably may had, so, apologies in advance, I would like to ask you about "Section 2 Definitions" and  the meaning of "similar licenses". The "Update change log" section 0) states: Standardized on the term Open Source. The previous specification uses both terms “Open Source” and the “FOSS (Free and Open Source)” interchangeable. It was acknowledged that the term Open Source is more widely recognized and understood for the following reasons: i) Some users of current the specification have pointed out there was confusion between the term OpenSource Software and FOSS. This was particularly true for first time readers; ii) Open Source represents a superset (inclusive); iii) The large majority of major foundations use the de facto term Open Source (e.g., Apache, Eclipse, OSI, Linux, OpenStack, Cloud Foundry, …); iv) Most commercial organizations externally use the de facto term Open Source; v) It is also consistent with the term “Open Source Program Office” which represents a major target audience of the specification; vi) The term Open Source is de facto in Asia, largely used in North America and mixed yet dominant in Europe; Translations would be simplified by the use of a single term;

In other hand, section 2, Definitions, Draft version 2.0 states:

Open Source Software (Open Source) FOSS (Free and Open Source Software) - software subject to one or more licenses that meet the Open Source Definition published by the Open Source Initiative (OpenSource.org) or the Free Software Definition (published by the Free Software Foundation) or similar license.

I am aware that the expression "or similar license" was not changed from the version 1.2, and being the only change the deletion of the term "FOSS (Free Open Source Software)", (that´s why my apologies in advance above).

Therefore, what would be the right meaning according to section 2 for "similar licenses" to software subject to one or more licenses that meet the Open Source Definition published by the Open Source Initiative (OpenSource.org) or the Free Software Definition (published by the Free Software Foundation). Would it cover software subject to licenses not submitted to OSI but that could possible meet the OSI standard? or maybe software subject to licenses not listed by FSF but probably respectful to the four/five freedoms? 

Probably this question have a simple answer based on US industry practice, but for those that we are little far from that perspective it would be really helpful to understand the rationale behind the term "similar licenses".

So, very respectfully, if the mission of section 2 would be to provide "definitions" to be used in the specification, do not you think that the term "similar licenses" should be defined?.

Many thanks in advance,

Gustavo G. Mármol Alioto.      

 

On 03-02-2019 16:22, Gisi, Mark wrote:
The latest draft of the next version of OpenChain Specification can be found here:
 
A marked up version can be found here:
 
The introduction was rewritten to be more concise and up to date.
 
Next
-------
We will discuss the Introduction rewrite in the upcoming working group meeting. After that we will circulate the draft for final input from the OpenChain community before sending it out for wider public review.
 
best,
- Mark
 
Mark Gisi | Wind River | Director, IP & Open Source
 

 

_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain
_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain

_______________________________________________
OpenChain mailing list
OpenChain@...
https://lists.linuxfoundation.org/mailman/listinfo/openchain

Join main@lists.openchainproject.org to automatically receive all group messages.