[License-discuss] Can OSI take stance that U.S. public domain is open source?

[Richard Fontana]

On Sun, 04 May 2014 11:48:13 -0500
Karl Fogel <kfogel at red-bean.com> wrote:

> IMHO it would be a long-term problem for the OSI (and for open source
> in general, given the useful standardization/certification role OSI
> plays) to have there be licenses that we call "open source" but don't
> certify.
> 
> After all, the *definition* of "open source" is supposed to be just
> "whatever complies with the OSD".  And our certification process is
> also "Does this comply with the OSD?"...  So the two shouldn't
> diverge; to the extent that they do, we have a problem.
[...]
> But in the long run I think we have two
> mutually exclusive choices:
> 
>   1) Have licenses out in the world that are OSD-compliant, and that
> we informally agree are "open source", but that we don't certify.
>      This will cause growing divergence between "what is open source"
>      and "what the OSI has approved".  That would be very, very bad.

I consider it important to understand, and acknowledge, that this
divergence already exists in most people's minds (i.e. those people who
have enough knowledge of what's going on in the real world).
It exists in my own mind. 

I don't know offhand the current count of OSI-approved licenses but I
think it is around 70. In a typical traditional server/desktop Linux
distro, the numbers of distinct licenses regarded *reasonably* by the
communities of users and distributors of that distro as "open
source" must number at least in the several hundreds. (Think of
the universe of licenses covering packages considered
DFSG-conformant in Debian, since the criteria are at least superficially
very similar to the OSD, its descendant.)  

To me the bigger problem has always been the use of "open source" to
label things that are not reasonably considered OSD-compliant
(regardless of whether a license has been certified by the OSI). 

>   2) Officially certify any license (or PD status / PD dedication)
> that is OSD-compliant as open source, but for most of them attach
>      commentary explaining why most people probably shouldn't use it
> and why one should one of the popular licenses instead.
> 
> (1) is a disaster.  It will defeat much of the point of the OSI, in
> the long run.

But (1) is where we are today, and where we always have been, except
that the OSI is the one institution that can't easily admit this. 

> We're sort of doing the complement of (2) right now, with the "Popular
> Licenses" section. 

Sort of except that OSI does not consider the issue of certification if
no one (or no one with authority, in the typical case) submits a
license for approval. One effect of this is that legacy licenses are
unlikely to be OSI-approved (although we've seen a few license
submissions of this sort), which may be fine. But we shouldn't pretend
that just because a license was never submitted for OSI approval, it
must fail the OSD. An interesting example someone brought up some time
ago is that the OSI apparently never certified GPLv1, not surprisingly
since it's seen little (explicit) use since 1991, though usage is not
zero. 

> ...but I think we do need to come to some sort of solution soon.  The
> U.S. government is going to keep releasing what is (obviously) open
> source software into the public domain; CC0 is also becoming more
> popular in non-software works and will inevitably make inroads into
> software too.

I'm going to out myself here and say that I believe CC0 is obviously
lowercase-o, lowercase-s open source despite the clause about patents.
That doesn't mean the OSI should have approved it, that doesn't mean
the OSI should recommend its use in its current form or cease its
current practice of recommending against its use. I have a similar view
of US government public domain works (with the added problem that it is
clear that many intellectual property lawyers working across different
US government agencies are confused over what 17 USC 105 means). 

Yes, US works that are public domain worldwide are obviously open
source, but as with CC0 this has some implications for how licenses that
explicitly mention disposition of patent rights should be treated.
 
> I completely agree, by the way, that we can be active about requiring
> certain kinds of patent promises.  E.g., maybe we wouldn't certify PD
> itself for software works, but would certify PD *when accompanied by*
> a particular patent non-assertion text.  We'd have a lot of leverage
> to do so, given that refusing to make that non-assertion promise,
> when asked for it, would draw attention to the fact that the party
> has now publicly decided not to be open source enough for the OSI.
> So I'm not saying we should just certify PD and CC0 and be done with
> it -- it's more complex than that.

I agree.

- RF