[od-discuss] Open Definition 2.0 - dangling reference to FLOSS

Mon Dec 8 14:10:58 UTC 2014

Hi Stefano (et al) (copying to the OD-discuss list),

I think the concern is valid, but I do not agree exactly with the
specific fix. First, we've already discussed adapting the particular
clause to more strongly require open formats, and I support that change.
But this is a complementary fix.

I support the way we do it at Snowdrift.coop — we do not simply say
"under an approved license" but instead say that the software must meet
the *definition* of Free Software or Open Source according to FSF or
OSI. That basically means the license, but it emphasizes the definition
over the licenses. Note that the GFDL does not meet the definition of
Free Software as it is not a software license and the invariant sections
violate the 4 freedoms. There is no software that meets the FSF's Free
Software Definition that violates the Open Definition.

My only other thought would be to more strongly tie in the Open
Definition, i.e. make it clear somehow that the the OSI and FSF
definitions are compatible with the Open Definition whereas some other
definitions of free/open may not be compatible.

Given those statements, I support the added clarity. It should be
explicitly clear that (e.g.) Binpress's "open source" proprietary
software is totally unacceptable here.

-Aaron

On 12/08/2014 03:00 AM, Stefano Zacchiroli wrote:
> Dear Mike, Aaron,
>   reviewing the Open Definition 2.0, I've noticed what I consider to be
> a potential issue: the notion of "free/libre/open-source software tool"
> (section §1.3 - Open Format) is not defined and left to the reader's
> interpretation. I've discussed this matter with Luis (Cc:-ed) in the
> context of our work on the OSI Board, and I'm now approaching you all as
> OKFN advisors to have feedback on a proposed fix.
> 
> First of all: why is this a problem? Based on our experience at OSI, we
> routinely encounter projects that claim to be "open source" in their
> marketing, but that often are not. Sometime that is due to honest
> mistakes; sometime that is full blown "open washing", in an attempt to
> mislead users. I think it would be very unfortunate for such situations
> to have the additional negative consequence of making people conclude
> that a given standard is "open" (according to OD 2.0) whereas that is
> not the case. That is the problem I'd like to solve.
> 
> A possible way to solve the issue would be to apply the following patch:
> 
> ------------------------------------------------------------------------
> diff --git a/od/index.markdown b/od/index.markdown
> index e0142a4..1bad4b3 100644
> --- a/od/index.markdown
> +++ b/od/index.markdown
> @@ -47,7 +47,9 @@ licensed rights. Specifically, data should be machine-readable, available in
>  bulk, and provided in an open format (i.e., a format with a freely available
>  published specification which places no restrictions, monetary or otherwise, upon
>  its use) or, at the very least, can be processed with at least one free/libre/open-source
> -software tool.
> +software tool (for the purpose of satisfying this requirement, any software
> +tool licensed under an [open source license](http://opensource.org/licenses)
> +would qualify).
> ------------------------------------------------------------------------
>        
> which I'll be happy to submit as a pull request on GitHub, if you
> consider it good enough. A few comments are in order though, and mainly
> about the fact that it focuses on the OSI license list:
> 
> - the suggested text is open-ended to allow adding other license lists
>   as authorities (e.g. the FSF list of *software* licenses)
> 
> - a problem with the FSF license list in this context, though, is that
>   it contains licenses that OKFN would not consider Free (e.g., GFDL
>   with invariant sections). So we will need to be precise and specify
>   that we are talking about FSF *software* licenses
> 
> - given the historical background, OKFN might be more inclined to use
>   OSI's list, but that's arguably just guess work on my part
> 
> What do you think about this issue and the fix above?
> 
> TIA,
> Cheers.
> 