[License-discuss] [License-review] For approval: The Cryptographic Autonomy License (Beta 4)

[Henrik Ingo]

On Sun, Jan 5, 2020 at 7:38 AM Richard Fontana <rfontana at redhat.com> wrote:
>
> (Moved to license-discuss)
>
> On Thu, Jan 2, 2020 at 5:06 PM VanL <van.lindberg at gmail.com> wrote:
>
> >  Is one takeaway here that people should start by ignoring the OSI process and just start using the license?
>
> Maybe. Not ignoring, but postponing.
>

6 years is a long time. In practical effect, postponing here means
ignoring. Also, if people start using a license because it is "open
source just not approved yet", they are not going to uninstall it 6
years later. Especially as there won't be a solid deadline when the
trial phase ends, so the postponing really is indefinite.


> The handful or so of the first licenses recognized by the OSI as 'open
> source' had already been in wide use for years at the time the OSI was
> founded in 1998. Looking back (over a ~21 year period), I believe the
> OSI may have taken the wrong path very early on by developing a
> process that encouraged submission of novel, community-untested
> licenses. This gave us, at various points in history, the corporate
> vanity licenses, the "crayon" and bad-thought-experiment licenses, and
> possibly licenses motivated largely by individual-author ego.
>
> Maybe it would be better for OSI to have the expectation that license
> review will only take place some months or years after a license is
> already in practical use. Users of new licenses could be expected to
> make clear that the licenses are not OSI-approved.
>

I want to make two comments here, the second with several parts:

First... The suggestion that OSI would only certify licenses that have
already seen years of use is a major, 180 degree policy change.
Related to the current discussion, my wish is that such a policy
change not be made in the margins of, or as a side effect of, one
particular license being reviewed. If anything, this is the case where
a broad and lengthy discussion would be needed!

As for the CAL, I think Van has followed the existing process,
including all the unwritten rules, very much by the book. It seems
only fair to expect that he will be able to complete the process he
has started over a year ago. I don't agree that there's anything
fundamentally wrong with the current OSI that giving up and admitting
defeat right now is the wise decision. Essentially that would then be
the policy change without discussion, and THAT decision does come with
a risk of adverse consequences.


Second...

While I can see there's a lot of support for this new idea, I
personally think you are focusing on the wrong things in your
analysis. The problems you list aren't real problems in practice. At
all. More importantly, you are completely forgetting the huge
victories the current OSI approach has had in defending software
freedom. For the OSI to allow new licenses to call themselves "open
source but we didn't submit it to OSI (yet/ever)", would be a retreat
from these positions. It would be exactly what all those rejected open
core licenses wished for all the time.


1. In reality, all of those IBM, Nokia, Sun licenses are not a
problem. (Today, at least.) Nobody uses them. They never were a
significant problem - if anything Sun only hurt itself with the SISSL.

Yes, it may seem schizophrenic to advocate against license
proliferation while at the same time approving every new license that
conforms to the OSD. But if we want to claim that software can only be
called "open source" if it is under an OSI approved license, then this
is the only way. The moment OSI admits that a license may be open
source but we just don't want to approve more licenses, then OSI has
lost any monopoly it may still have in policing that term.


2. OSI is not the supreme court of software freedom. These are not
life or death decisions where the open source world will implode if
someone presses the wrong button.

The FSF maintains a similar list of licenses considered free software.
(And as this thread has shown, that process can be very fast and
lightweight!) At least Debian and Fedora actively maintain their own
lists anyway. And importantly, many companies have a list of approved
licenses from their own legal departments. Where, for example, the
AGPL might not be approved, even if we clearly believe it conforms to
the OSD in every way.

When I evaluate whether software is open source, I would consider at
least the OSI and FSF lists, but possibly even other sources on
commentary for the license. In 99% of cases I expect these bodies to
agree. And when they don't, the software in question usually isn't
important anyway.

And to provide even more of a reality check: While I belong to the
group of people who highly value OSIs authority both in defining open
source and approving licenses, most people out there are rather on the
level of "Microsoft will close source Github". So really, I don't
think the OSI has that much at risk here. The only thing I worry about
is that OSI becomes paralyzed and stops doing what it has been doing
really well for 20+ years!


3. In the discussion about license proliferation, one thing that I
rarely see mentioned is that all those licenses actually served a very
valuable purpose: They provided a channel for big tech lawyers to
become familiar with open source licenses, the OSD, and the community.
At the end of that process they learned not to use their own licenses!
All of this was and is very core to OSIs mission: promoting open
source adoption, especially by commercial corporations. (Which was the
opportunity that opened in 1998.)

I remember when Microsoft submitted the MS-PL. Some people who were
also vocal in this thread, were strongly against approving it, because
although the license was OSD compliant, Microsoft was an evil company.
Luckily it was approved, and look at Microsoft's progress since.

So I really want to endorse Josh Simmons' position in this thread,
that authors of new licenses should engage with the OSI process early
on (including via license-discuss), and the OSI on its part should
continue to facilitate the dialogue and remain at the center of it,
rather than diminishing itself to just rubber stamping licenses after
they have first been approved by some other authority outside the OSI.


On all of the above points, rather than a 180 degree turnabout, maybe
some small refinements to OSI practices could be helpful. For example,
maybe the OSI should start actively retiring licenses. This should
make the approval of new licenses less stressful, as they would not be
irreversible. (The threshold to reverse would of course still be high,
but so is the threshold to approve.) There could also be an "open
source but not recommended" category for licenses that were approved
but only used by 1 or 2 projects/vendors. And maybe we should retry
the effort to primarily highlight a short list of most popular
licenses on the website.

henrik



-- 
henrik.ingo at avoinelama.fi
+358-40-5697354        skype: henrik.ingo            irc: hingo
www.openlife.cc

My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7