[License-review] For Approval: The Cryptographic Autonomy License

Bruce Perens bruce at perens.com
Wed May 1 04:04:24 UTC 2019

On Tue, Apr 30, 2019 at 6:58 PM Richard Fontana <rfontana at redhat.com> wrote:

> It discriminates against
> the class of persons that wish to create re-implementations of APIs,
> that wish not to be forced to distribute the source code for such
> implementations, and that (if they do distribute the source code) that
> wish not to be restricted in terms of the licenses they can use.

Terms that require modifications to our own software to be shared are
viewed very differently than terms that require other things, because
sharing modifications achieves the goal of Free Software / Open Source, and
sharing modifications to our own software is something that it's fair for
us to ask for. Before Open Source came about, we drew a line in the sand
about *running* software for any purpose, etc., and codified that in the
licenses that Debian was using when the DFSG was written. That our rules
don't have total sympathy for proprietary software developers is necessary.
But they have sympathy for everyone else.

What I am finding bothersome about most of the network copyright proposals
is that they change the fundamental deal of Free Software / Open Source. No
more running for any use, no more sympathy for eveyone but proprietary
software makers - there is a new set of evils including, in this case, data
hoarders. Approving the network copyright licenses would be a slippery
slope to approving a whole family of worse ones and IMO, people would
abscond and we would end with FSF being looked to as the arbiter of
licenses. Which wouldn't be so bad for the community and FSF, just for OSI.
The new generation of leadership at FSF and SFC is pretty cool.

API copyrights are politically a bad idea for us to stand behind right now,
because we don't want them used against us. However, if we do end up being
forced to live with API copyrights, we will in turn adopt licenses that
require that people who copy our APIs share their software. It's going to
be our only defense. The asymmetry of having everyone else share our APIs
with impunity while we can share none of theirs would be unworkable for
Open Source / Free Software. So, the Supreme Court might fundamentally
change Open Source / Free Software. Be warned.

> Also, the OSI has clarified recently that the purpose of the license
> approval process is to "Ensure approved licenses conform to the Open
> Source Definition and provide software freedom".

And I will say as someone who
> was on the board at the time that one of the reasons that language was
> used was because of growing concern about "gaming" of the license
> review process through literalist or legalistic readings of the OSD.

So, we can do this in one of two ways: we can have a court and legislature
and a "living" OSD that is treated like a body of law, have the court
interpret it literally to approve licenses and the legislature add to it
every time somebody games the process and gets a license by us. Or we can
be intelligent interpreters rather than literal ones. We aren't a court or
legislature and aren't compelled to act as one.

>  it seems really unlikely that this license --
> which is relatively complex, seemingly special-purpose and proposed by
> a business entity -- would see any adoption by any other licensors
> (perhaps not itself a reason for nonapproval but I think worth
> thinking about).

The danger here is that people see its probable non-use by anyone but Van's
customer as a reason to approve it because it won't do much harm. OSI
should guard its imprimatur better than that.

> Also I am fairly sure I heard Van say at CopyleftConf
> that his client was contemplating using this license as the basis of a
> proprietary/copyleft dual-licensing scheme (Van if I misheard that
> please correct me). If that's so, then the only likely user of this
> license will be using it not in the hope that it will result in more
> open source software but rather that it will result in *less* open
> source software, and may even strategize to make that the more likely
> outcome. See Chris Webber's recent license-discuss posting, where he
> points out that "proprietary relicensors" want noncompliance, not
> compliance.

If the vendor covenants to keep issuing all of their work as Open Source,
they are being paid by people who want proprietary software to make more
Open Source. This is not necessarily a bad thing.

I don't think it's frivolous in a litigant argument sense. However, I
> question what it could possibly mean to publicly perform an *API*.

To use it at all.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20190430/fd1c5786/attachment-0001.html>

More information about the License-review mailing list