[License-review] OSI, legal conditions outside the "four corners" of the license, and PD/CC 0 [was Re: Can OSI specify that public domain is open source?]

[Luis Villa]

[Happy new year! Bringing this up again in part because Red Hat
recently, and in my opinion correctly, reevaluated their position on
public domain in Fedora:
http://lists.fedoraproject.org/pipermail/announce/2011-December/003025.html]

Some time ago, there was a thread about certifying some variation on
"public domain" licenses as OSI-approved. The thread died out shortly
after the email these quotes were clipped from. The tl;dr position of
those opposing PD was basically to ignore the actual text of the PD
statements and instead look to things outside the "four corners" of
the license; notably that (1) PD doesn't work in all jurisdictions
and/or (2) many things that are labeled PD are not actually PD.

My tl;dr position, laid out in more detail below, is that OSI should
be in the business of evaluating specific licenses, and not (to the
greatest extent possible) external conditions around those licenses.
As a result, OSI should evaluate and accept at least one PD license
(ideally the CC0 PD dedication, and any other well-drafted dedication
of similar style) as an OSI-approved license.

On Wed, Sep 7, 2011 at 5:20 PM, Rick Moen <rick at linuxmafia.com> wrote:
> Quoting Chad Perrin (perrin at apotheon.com):
>
>> I'd say, rather, that it should be conditionally recognized as open
>> source -- under circumstances where it applies.  Otherwise, it looks to
>> me like you're setting a precedent for crypto software distributed under
>> the terms of an open source license should not be considered open source
>> simply because some countries prohibit the use of (strong) crypto.
>
> That boat sailed long ago.
>
> A reasonable functional definition of 'open source software' is

Functional definitions of open source software are related to, but
distinctly different from, a definition of an "open source license."
OSI is not in the business of certifying whether specific software is
open source software; rather, it certifies whether licenses are open
source licenses.

> 'software concerning which any recipient can exercise all the rights
> outlined in the Open Source Definition', OSD being an attempt to
> formally detail the common-sense notion of what it means for a codebase
> to be forkable, independently maintainable with the right to create and
> distribute derivative works, and to use it without impediment for any
> purpose.
>
> If local law prevents you from exercising those rights concerning a
> strong crypto codebase, then by a functional definition that codebase is
> (locally) not open source, irrespective if licensing and irrespective of
> source code availability.  Same principle applies for enforced patents
> and other legal impediments.
>
> If we'd have been holding this discussion before the RSA patent expired
> just a bit over 11 years ago, I'd have said that mod_ssl was not open
> source in the USA, irrespective of its BSD licence.  (I'd have footnoted
> that, of course, like any self-respecting pedant.)

I don't think that's a sustainable position for OSI to base its
analysis on. Any non-trivial software has patent issues these days,
but OSI can't be in the business of saying "well, this particular
piece of software has patent issues, so it is not open source." OSI
can only reasonably say "this particular license, taken at face value,
gives the permissions necessary for the license to qualify as an open
source license."

Similarly, except for the most trivial cases, OSI can't say " ...
unless of course, there are moral rights, or reversion rights, or
grants of rights the licensor didn't actually have, or
$JURISDICTION_SPECIFIC_LANDMINE." That's why OSI has always certified
/licenses/, not /software/, because a thorough analysis of any
specific piece of software has to involve a lot more than just the
license- it must involve questions of jurisdiction, questions of
patents, questions of provenance, etc., etc., etc.

I think the objections to stating public domain disclaimers are open
source licenses fall into the same category. Yes, there are issues
with public domain in some jurisdictions, and yes, some specific
pieces of software nominally under PD may in fact be under other
licenses. But I don't see that how that is significantly different
from the problems of any other combination of abstract license and
specific software: there are always pitfalls that can happen there,
and OSI can't and shouldn't be in the business of evaluating those
external factors.

This doesn't mean that OSI should accept all PD-like statements as
open source licenses, any more than OSI should approve the "crayon
licenses" discussed in another recent thread. Instead, it should
accept specific, well-drafted statements of public domain. FSF took
this route by endorsing CC0, a well-drafted PD dedication with a
fallback to a full rights disclaimer. OSI should follow this example.
I'm not aware of any other well-drafted PD dedications[1] designed for
use by the authors of a work, so I would stop there, but if there are
others, OSI should look into them as well.

[Mind you, this is all modulo the caveat that I believe that OSI
should only approve licenses with patent grants. But since that isn't
currently a criteria for OSI, I think CC0 clearly qualifies.]

Luis

[1] I would rule out the CC PD "mark", because, while well-drafted, it
is essentially intended for application by third parties, and as such
isn't a license.