Topics

Plan to allow specification projects as well as projects with code, per project #180 (ODPi specifications)


David A. Wheeler
 

The badging project was designed for “FLOSS projects” - and we had expected only projects with *code* would be asking for a badge. However, project #180 takes an unexpected new direction: it’s a project to develop a *specification* for code.

I think this makes sense – and I intend to allow it – but I thought it’d be important to post here for discussion. So, please reply if you have thoughts about this (pro or con).

Project #180, “ODPi specifications”, is described as follows: “ODPi is an effort led by Apache Hadoop distros, application vendors, and end users in the Apache Hadoop ecosystem for building a standard specification for Hadoop distros to adhere to. This for the benefit of all application vendors, solutions providers, and end users such that they have a base level of expectations when working with an ODPi compliant Apache Hadoop distribution.” Its badge entry is here:
https://bestpractices.coreinfrastructure.org/projects/180

It does tend to meet the criteria. For example, its license is CC-BY-4.0, so its results meet the Open Source Definition and Free Software Definition. It specifically allows for FLOSS implementations.

This wasn’t what I expected, but I don’t see any harms, and a few people I privately asked didn’t see any harms either.

What’s more, there are potential benefits, e.g.:
* It should help them avoid specifying poor security practices, including poor crypto or insecure design
* If they add a reference implementation, it should help them use best practices from the start
* It encourages collaboration focusing on security
* It encourages open standards in general, including the use of OSD-compliant licenses and open specification development processes.

Interestingly enough, the only thing they’re not claiming, and prevents them from getting a badge, is [documentation_interface]. This says, “The project MUST include reference documentation that describes its interface.” But I think a specification *is* a reference document that describes its interface – almost by definition. So while I think it’d be important to include some justification text, I think this is one they could easily claim – and thus actually get the (passing) badge.

I haven't walked through each criterion (yet) to see if there's an incorrect claim. I didn't anticipate this, so it's not clear how well it really works. If anyone sees a problem with something, I'd love to know. But before I looked at this in more detail, I thought it'd be important to determine if this was in scope at *all*.

If anyone has thoughts about this, please reply. If I don't hear many strong objections I think we'll just carry on.

--- David A. Wheeler


Dale Visser
 

I see no harm in allowing this kind of project. The badge is then asserting secure, accountable workflows for the evolution of the specification. The only downside is that it requires a sort of "double-think", since normally what is of concern is code that can actually run (or easily be built to run). Even that isn't too much of an issue: Specifications can have security flaws, too, which need to be corrected.

-----Original Message-----
From: cii-badges-bounces@lists.coreinfrastructure.org [mailto:cii-badges-bounces@lists.coreinfrastructure.org] On Behalf Of Wheeler, David A
Sent: Wednesday, June 08, 2016 11:09 AM
To: cii-badges@lists.coreinfrastructure.org
Subject: [CII-badges] Plan to allow specification projects as well as projects with code, per project #180 (ODPi specifications)

The badging project was designed for “FLOSS projects” - and we had expected only projects with *code* would be asking for a badge. However, project #180 takes an unexpected new direction: it’s a project to develop a *specification* for code.

I think this makes sense – and I intend to allow it – but I thought it’d be important to post here for discussion. So, please reply if you have thoughts about this (pro or con).

Project #180, “ODPi specifications”, is described as follows: “ODPi is an effort led by Apache Hadoop distros, application vendors, and end users in the Apache Hadoop ecosystem for building a standard specification for Hadoop distros to adhere to. This for the benefit of all application vendors, solutions providers, and end users such that they have a base level of expectations when working with an ODPi compliant Apache Hadoop distribution.” Its badge entry is here:
https://bestpractices.coreinfrastructure.org/projects/180

It does tend to meet the criteria. For example, its license is CC-BY-4.0, so its results meet the Open Source Definition and Free Software Definition. It specifically allows for FLOSS implementations.

This wasn’t what I expected, but I don’t see any harms, and a few people I privately asked didn’t see any harms either.

What’s more, there are potential benefits, e.g.:
* It should help them avoid specifying poor security practices, including poor crypto or insecure design
* If they add a reference implementation, it should help them use best practices from the start
* It encourages collaboration focusing on security
* It encourages open standards in general, including the use of OSD-compliant licenses and open specification development processes.

Interestingly enough, the only thing they’re not claiming, and prevents them from getting a badge, is [documentation_interface]. This says, “The project MUST include reference documentation that describes its interface.” But I think a specification *is* a reference document that describes its interface – almost by definition. So while I think it’d be important to include some justification text, I think this is one they could easily claim – and thus actually get the (passing) badge.

I haven't walked through each criterion (yet) to see if there's an incorrect claim. I didn't anticipate this, so it's not clear how well it really works. If anyone sees a problem with something, I'd love to know. But before I looked at this in more detail, I thought it'd be important to determine if this was in scope at *all*.

If anyone has thoughts about this, please reply. If I don't hear many strong objections I think we'll just carry on.

--- David A. Wheeler

_______________________________________________
CII-badges mailing list
CII-badges@lists.coreinfrastructure.org
https://lists.coreinfrastructure.org/mailman/listinfo/cii-badges


Kevin W. Wall
 

I'm in favor of it, with this caveat... just because a specification project uses a FLOSS approved license like CC-BY-4.0 as David mentioned,  that would not necessarily imply that resulting spec would be vendor neutral and FOSS friendly. E.g., suppose a spec that mandates functionality that is covered by one or more vendor patents.

Aside from that sort of thing (which, by the way, I would never expect from Apache), I think this is a great natural extension to CII badges.

-kevin
Sent from my Droid; please excuse typos.

On Jun 8, 2016 11:08 AM, "Wheeler, David A" <dwheeler@...> wrote:
The badging project was designed for “FLOSS projects” - and we had expected only projects with *code* would be asking for a badge.  However, project #180 takes an unexpected new direction: it’s a project to develop a *specification* for code.

I think this makes sense – and I intend to allow it – but I thought it’d be important to post here for discussion.  So, please reply if you have thoughts about this (pro or con).

Project #180, “ODPi specifications”, is described as follows: “ODPi is an effort led by Apache Hadoop distros, application vendors, and end users in the Apache Hadoop ecosystem for building a standard specification for Hadoop distros to adhere to. This for the benefit of all application vendors, solutions providers, and end users such that they have a base level of expectations when working with an ODPi compliant Apache Hadoop distribution.”  Its badge entry is here:
https://bestpractices.coreinfrastructure.org/projects/180

It does tend to meet the criteria.  For example, its license is CC-BY-4.0, so its results meet the Open Source Definition and Free Software Definition.  It specifically allows for FLOSS implementations.

This wasn’t what I expected, but I don’t see any harms, and a few people I privately asked didn’t see any harms either.

What’s more, there are potential benefits, e.g.:
* It should help them avoid specifying poor security practices, including poor crypto or insecure design
* If they add a reference implementation, it should help them use best practices from the start
* It encourages collaboration focusing on security
* It encourages open standards in general, including the use of OSD-compliant licenses and open specification development processes.

Interestingly enough, the only thing they’re not claiming, and prevents them from getting a badge, is [documentation_interface].  This says, “The project MUST include reference documentation that describes its interface.”  But I think a specification *is* a reference document that describes its interface – almost by definition.  So while I think it’d be important to include some justification text, I think this is one they could easily claim – and thus actually get the (passing) badge.

I haven't walked through each criterion (yet) to see if there's an incorrect claim.  I didn't anticipate this, so it's not clear how well it really works.  If anyone sees a problem with something, I'd love to know.  But before I looked at this in more detail, I thought it'd be important to determine if this was in scope at *all*.

If anyone has thoughts about this, please reply.  If I don't hear many strong objections I think we'll just carry on.

--- David A. Wheeler

_______________________________________________
CII-badges mailing list
CII-badges@...
https://lists.coreinfrastructure.org/mailman/listinfo/cii-badges


David A. Wheeler
 

Kevin W. Wall [mailto:kevin.w.wall@gmail.com]:
I'm in favor of it, with this caveat... just because a specification project uses a FLOSS approved license like CC-BY-4.0 as David mentioned,  that would not necessarily imply that resulting spec would be vendor neutral and FOSS friendly. E.g., suppose a spec that mandates functionality that is covered by one or more vendor patents.
Aside from that sort of thing (which, by the way, I would never expect from Apache), I think this is a great natural extension to CII badges.
That's a good point.

Perhaps we could add a new criteria for 2017. Something like this:
"If it defines a new specification intended to be implemented by others, the specification MUST comply with the Open Standards Requirement for Software <https://opensource.org/osr>;".

Some challenges:
* If someone documents an *existing* interface, we *do* want to encourage that... which is why I used "new". Thoughts?
* The US patent system is broken, and we can't fix it just by writing some criteria. I believe the USPTO shouldn't allow software patents at all. Instead, *no* one understands the scope of the software patents granted, and all too often they cover obvious and already-invented things. In addition, court costs are so high that owners of worthless patents can extort others. As proof, here's an article from yesterday where someone is being sued merely for submitting their application to the Google app store <http://www.technobuffalo.com/2016/06/07/x-plane-flight-simulator-patent-troll-uniloc/>;. I can't speak to other countries, but my understanding is that other locations also have this problem.

--- David A. Wheeler