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

Thu Aug 22 20:13:55 UTC 2019

It seems to me that this new submission has repaired some of the more
trivial reasons for rejection of the license, while preserving the main one.

#### 4.2.1. No Withholding User Data

Throughout any period in which You exercise any of the permissions granted to

You under this License, You must also provide to any Recipient to whom you

provide services via the Work, a no-charge copy, provided in a commonly used

electronic form, of the Recipient’s User Data in your possession, to the extent

that such User Data is available to You for use in conjunction with the Work.

The license attaches terms to the data processed through the program,
rather than the software of the program itself. These terms compel a
specific action regarding the data, that the licensee surrender a copy of
that data to a specific third party.

In this case the party may actually have right to that data, having created
it themselves. This, however, is a distraction from the main point, which
is the attempt to expand the copyleft paradigm to include *the data
processed by the program,* such that the licensee must disclose that data
or perform other mandated actions upon it. While this particular submission
places a very narrow limit on what data must be disclosed: giving it back
to "it's owner", it's obvious that it could be followed by licenses
regarding a more significant license term to be placed on the data
processed, for example the one that Kyle Mitchell submitted last year,
which required that data simply processed by the program be placed under an
Open Source license, or the old BitMover license which required that the
running program communicate a public log of the program run to a specific
BitMover log server.

So, I am really most concerned with the precedent that this license would
establish, which would lead to more severe terms being applied to the data
processed. And thus I suggest that OSI not accept any such terms at all.

Regarding how to reject the license within the tems of the OSD: the terms
proposed work out to be a restriction on use. One can not use the program
to sequester the customer's data. Such sequestration is a strategy in the
implementation of software-as-a-service companies - I'm not saying that
it's nice, just that they do it. Thus, I believe this runs awry of OSD#6, *No
Discrimination Against Fields of Endeavor. *#6 has generally been found by
the OSI board to prohibit usage restrictions.

OSI has affirmed that it supports Software Freedom, of the specific form
defined by the Free Software Foundation and OSI's member the Software
Freedom Conservancy. Thus, the Four Freedoms of the Free Software
Foundation apply, and Freedom 0 is more specific to usage restrictions: *The
freedom to run the program as you wish, for any purpose**. *In this case,
the proposed terms withhold the freedom to run the program while
sequestering the information processed.

There are other problems with practical use of the license. Open Source
software is intended for everyone to use, not just everyone who can afford
an attorney and a programming staff. It thus should be the case that the
"naive user", who simply runs Open Source software and does not modify it,
should *not *need to read and understand the license, and certainly should
not need a lawyer to tell them how to run the program in a compliant
manner. The submitted license, however, applies terms to this naive user,
who will potentially need a lawyer to explain to her what data to
distribute and what can be kept, and a programmer to actually extract the
data.

OSI, more than a decade ago, accepted a "badgeware" license, the Common
Public Attribution License, which required attribution on a web site,
potentially making the same demands that the user have a lawyer and at
least a web designer in order to be in compliance. Debian rejected the same
license as being incompatible with the DFSG, which has essentially the same
text as the OSD. The CPAL was not successful, the submitter appears to be
out of business, I can find no evidence of users of the license today, and
searches for "badgeware" yield only decade-old pages. Yet, at the time, one
commentator wrote, entertainingly in retrospect: *Badgeware is certainly
not going away, and my fear is that if the OSI chooses to ignore it, or
worse, refuses to approve the licenses, they will find themselves as
irrelevant as the UN in short time. *(
http://www.royrusso.com/blog/2007/01/11/badgeware-and-open-source/).
Accepting badgeware was a contentious decision for OSI, received a lot of
press coverage, and was ultimately a wrong decision as well as a useless
and ineffective one. OSI should not repeat past mistakes.

The Open Source brand has, so far, stood for licenses which do not include
terms applied to data simply processed by the licensed program. A
significant part of that brand's value is the public perception that Open
Source licenses *don't *do that. Thus, I suggest that the OSI board
maintain the brand by rejecting this license and similar licenses that
apply terms to the data simply processed by the program.

    Thanks

    Bruce

On Tue, Aug 20, 2019 at 5:10 AM Pamela Chestek <
pamela.chestek at opensource.org> wrote:

> We don't think we can get anything ready in time to review the CAL
> license, so unfortunately we shall carry on with email.
>
> Thanks,
>
> Pam
>
> Pamela Chestek
> Chair, License Review Committee
> Open Source Initiative
>
> On 8/19/2019 7:17 PM, Pamela Chestek wrote:
>
> Hi all,
>
> I'd like to pause this discussion for a few days. As everyone knows and I
> think agrees, email is poorly suited for this process. The License
> Committee has been discussing trying out a different tool, probably just a
> simple issue tracker. If y'all could give us a few days to figure out if we
> want to try it out with this discussion, that would be very greatly
> appreciated.
>
> Van, if you would prefer we NOT try a tool other than email, please let me
> know.
>
> Thanks,
> Pam
>
> Pamela Chestek
> Chair, License Review Committee
> Open Source Initiative
>
> On 8/19/2019 5:09 PM, VanL wrote:
>
> Hi Josh,
>
> Looking again, I didn't really address your question about the "offer an
> acceptance" language. So here goes:
>
> License terms such as these are interpreted as contracts. Contracts
> require 1) an offer, 2) an acceptance, and 3) consideration.
>
> > ### 2.2. Offer and Acceptance
> > This License is automatically offered to every person and organization.
>
> This establishes that the license is being offered as-is to every possible
> licensee. This is the "offer" part of contract law.
>
> But because I don't want to individually sign an agreement with every
> possible licensor, I need some way for someone who wants to use software
> under this license to show that they have accepted it. That's the next part:
>
> > You show that you accept this License and agree to its conditions by
> taking any action with the Work that, absent this License, would infringe
> any intellectual property right held by Licensor.
>
> This means that if you do something that, absent the license, you would
> not have the right to do, we will both agree to interpret that as you
> "accepting" the license, including all of its terms.
>
> This also establishes the "consideration" - you get software, I get your
> compliance with the terms.
>
> >### 2.3. Compliance and Remedies
> > Any failure to act according to the terms and conditions of this License
> places Your use of the Work outside the scope of the License and infringes
> the intellectual property rights of the Licensor. In the event of
> infringement, the terms and conditions of this License may be enforced by
> Licensor under the intellectual property laws of any jurisdiction to which
> You are subject.
>
> This sentence ties the enforceability of the license back to intellectual
> property law. IP law has stronger remedies than contract law, so we want to
> be able to use IP as a tool when enforcing the CAL. But note that only the
> IP owner can sue under the IP laws. What about everyone else? What about a
> Recipient - a user - who wants a copy of the source and their data?
>
> > You also agree that either the Licensor or a Recipient (as an intended
> third-party beneficiary) may enforce the terms and conditions of this
> License against You via specific performance.
>
> This calls out to a doctrine in contract law that recognizes that
> sometimes third parties, not named in a contract, also may have a stake in
> the contract being enforced. These are "third party beneficiaries." A third
> party beneficiary doesn't have all the rights that the IP holder does. But
> they can sue, using this clause, for "specific performance" - a legal term
> that means "you must comply with the license terms".
>
> Thanks,
> Van
>
>
> _______________________________________________
> License-review mailing listLicense-review at lists.opensource.orghttp://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>
>
>
> _______________________________________________
> License-review mailing list
> License-review at lists.opensource.org
>
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>

-- 
Bruce Perens - Partner, OSS.Capital.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20190822/353bbb2c/attachment.html>