April 2019 License-Review Summary
In April, the License-Review mailing list
saw extensive debate on the Cryptographic Autonomy License,
in particular:
* its user data clause, and how it affects user freedom
* obligations placed on the software operator
* API copyright
* strategic concerns for the OSI
* public performance rights for software
The corresponding License-Discuss summary is online
at
and covers discussions about
non-commercial licenses,
license revocability,
and LGPL/Apache compatibility.
## Cryptographic Autonomy License {#cal}
[Van Lindberg][vanl:cal]
submits his Cryptographic Autonomy License (CAL) to the review process.
This is a network copyleft license, but with a broader scope than the AGPL.
The CAL is motivated by ensuring user autonomy in blockchain-based applications.
Lindberg has also written an [in-depth blog post][vanl:blog_rationale]
that serves as a rationale document.
Last month, there had already been preliminary discussion about the license
on the license-discuss list (see the [summary][LR:03:cal]).
[Lindberg][vanl:cal:api2] and [Pamela Chestek][chestek:cal:api2]
summarize the core goals of the CAL:
* that derivative works are handled in a copyleft manner
* that any software offering the same API is under a compatible license
* that user data is portable
Note: this summary uses the term “operator”
to describe a user who runs the software
so that other end users can interact with it.
### Summary of Opinions {#cal-opinions}
While the license presents welcome innovation in the network copyleft licensing space,
there is also major criticism:
* operators are subject to unacceptable restrictions regarding user data
* it is not in OSI’s interest to approve an API-copyleft license
* the novel use of public performance is unclear, untested, unnecessary, and possibly ineffective
[Bruce Perens][perens:cal:market] does not recommend approval.
Henrik Ingo [[1][ingo:cal:api],[2][ingo:cal:pperf]]
thinks that a “revised, less hazardous version of this license” could eventually get approved.
[vanl:cal]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004028.html
[LR:03:cal]: https://opensource.org/LicenseDiscuss032019#cal
[vanl:blog_rationale]: https://www.processmechanics.com/2019/03/15/the-cryptographic-autonomy-license/
### Meta {#cal-meta}
While [Perens][perens:cal:meta] was eager to get his concerns heard early,
[Richard Fontana][fontana:cal:meta] reminds that no urgency exists:
as per the review process, new licenses get an initial 60 days of discussion
before any decision.
[Simon Phipps][phipps:cal:meta] adds that
since Fontana’s tenure as license committee director has ended,
any review progress will be stalled until a replacement is appointed at the next board meeting.
[berkus:cal:meta]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004037.html
[perens:cal:meta]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004038.html
[fontana:cal:meta]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004041.html
[phipps:cal:meta]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004043.html
### License Purpose {#cal-purpose}
[Bruce Perens][perens:cal:market]
is concerned that the CAL goes beyond licensing *software*,
but tries to establish some *market*.
Perens [suggests][perens:cal:userdata]
that the license’s business purpose
might better be reached through an ordinary contract.
Van Lindberg [[1][vanl:cal:market],[2][vanl:cal:userdata]]
responds that
while the CAL is being drafted because of a business purpose,
its terms are independent of that purpose.
The terms only cover licensing of the software,
under some conditions.
Ultimately, every license has some purpose behind it.
In the case of the CAL,
the business purpose required a network copyleft license.
[Perens][perens:cal:misapprehension]
argues that while other licenses may have their own purpose,
they are not specific to some application.
In contrast, the CAL seems specific to blockchain applications.
### Lawful Interest in User Data {#cal-lawful-interest}
The CAL requires that operators must provide user data
to which an end user has a lawful interest.
For example,
a user might have a ownership interest
in the photos they upload to a photo storage service.
Bruce Perens [[1][perens:cal:market],[2][perens:cal:userdata],[3][perens:cal:misapprehension]] thinks that
“lawful interest” is not sufficiently defined,
and would require novel theories of data ownership:
“There are opinions, and little case law.”
This could even require disclosure to third parties if they establish a lawful interest.
Van Lindberg [[1][vanl:cal:market],[2][vanl:cal:userdata],[3][vanl:cal:locking]] responds that
lawful interest is defined using known legal terms.
The CAL does not grant new rights to user data:
either the law recognizes some kind of data ownership or it does not.
You can’t end up with rights that you didn’t already have.
[Lindberg][vanl:cal:userdata] clarifies
that the CAL references the GDPR not to define lawful interest,
but to clarify how an operator must provide user data.
[Perens][perens:cal:misapprehension] points out:
if the users already have a right to their data,
why does the license need terms to that effect?
[Lindberg][vanl:cal:locking] responds:
“Just because I have ownership of data
does not mean that you have an existing legal responsibility to give it to me.
This is exactly the problem addressed by the CAL.”
### User Freedom and Data {#cal-freedom-data}
Van Lindberg [[1][vanl:cal:userdata],[2][vanl:cal:locking]]
explains why he believes provisions about user data to be necessary.
Preserving user freedom is core to Free Software.
User data must be protected for that freedom to be effective:
> The insight is that, increasingly,
> the data and the code are needed together to realize the program’s function.
> Existing open source licenses, such as the GPLv3 family, recognize this and
> requires the provision of cryptographic keys that would prevent the execution of the code.
> The CAL recognizes that user freedom also includes the provision of the user’s data
> so that the program functions completely and fully in a context of the user’s choice.
>
> […] I may *own* my data.
> I may be able to get a copy of the source code.
> But […] unless I can use the software to process my own data,
> I also don’t have effective freedom.
The CAL does not encumber or restrict user data,
it just prevents it from being locked into a platform
– similar to GPLv3’s anti-Tivoization clause.
Such a clause is necessary
because hashchain applications offer new ways to lock down a program.
[Bruce Perens][perens:cal:misapprehension]
is not convinced that end user freedom requires the disclosure of this user data.
And the license must protect freedom not only for end users but also for operators,
so why should it be acceptable to compel operator actions?
[Pamela Chestek][chestek:cal:tivo] and [Bruce Perens][perens:cal:misapprehension]
disagree with the comparison to the GPL’s anti-Tivoization clause.
It applies when a device with embedded software changes ownership,
so that the new owner can install modified software on their hardware.
In contrast, the CAL’s user data provisions burden the operator of the software
to provide access to user data.
This is a fundamentally different kind of obligation.
### Operator Obligations {#cal-operator-obligations}
Bruce Perens [[1][perens:cal:market],[2][perens:cal:userdata],[3][perens:cal:misapprehension]]
is concerned that the operator’s obligations regarding user data
are unclear and excessive:
* The CAL’s requirements trigger on mere use of the software,
which looks like an OSD #6 and #9 violation.
How can forbidding or compelling an action not be a usage restriction?
* It should be fine to just run software under an OSI-approved license,
without having to read it.
The CAL’s user data requirements break this expectation.
Operators have to hire a lawyer to understand the extent of their obligations.
This is an unreasonable burden that limits their freedom.
* The CAL affects data that is processed with the software.
Van Lindberg [[1][vanl:cal:userdata],[2][vanl:cal:locking],[3][vanl:cal:freedom]] counters:
* The CAL’s user data requirements are about as restrictive
as the AGPL’s source disclosure requirements:
“The license compels an action by the licensee
– to make the source code and data available.
This is exactly the same type of action required under every copyleft license.”
* The CAL does not extend to data:
“No rights or obligations are created in any other work.”
* The CAL does not restrict usage.
It only requires user data to be provided to the extent that it is available.
E.g. data may have to be decrypted for a user with a lawful interest,
but the CAL is careful to not require disclosure of private keys.
* The CAL only compels actions while the operator provides a service.
They are free to stop at any time.
[Lindberg][vanl:cal:freedom] appreciates the point
that users should be able to run the software without reading the license.
But with the CAL, the legal load for end users is still zero.
Extra burdens are only placed on operators who want to provision the software as a service to others,
which is the same scenario where the AGPL applies extra requirements.
And anyway: “if you are providing services to others,
you have already taken upon you substantial legal liability.”
[Lindberg][vanl:cal:freedom] is amazed that Peren’s examples
boil down to preserving operator’s freedom to lock down their user’s data.
“That freedom is definitely granted under some more permissive licenses,
but preserving the rights of users is a core aspect of Free Software,
which is the tradition addressed by the CAL.”
[Henrik Ingo][ingo:cal:pperf]
points out that open source licenses generally grant rights to users
*and* shield them from legal risks.
For example, restrictions on DRM are “a great example of protecting user rights”.
Peren’s objections seem to be problematic primarily with P2P software
where end users simultaneously act as operators.
### Solving Social Issues {#cal-social}
Bruce Perens [[1][perens:cal:locking]]
agrees that data being hold hostage is a legitimate problem
– but it is a *social* problem.
OSI has previously rejected licenses that try to address social issues beyond the software.
While OSI-approved licenses sometimes require disclosure of source code,
also requiring disclosure of user data would be overreach.
[Van Lindberg][vanl:cal:freedom] disagrees.
The CAL is not in the same bucket of (non-free) licenses like 996 or JSON “do no evil”.
The CAL tries to address an issue (user autonomy)
“in the exact same way the GPL addresses the social issue of software freedom.”
### API Copyright {#cal-api}
Pamela Chestek [[1][chestek:cal:api],[2][chestek:cal:api2],[3][chestek:cal:sas]]
summarizes the CAL’s relationship to API copyright:
Any reimplementation of a CAL-covered API
must be offered under the CAL or a compatible license.
The CAL does not have a copyleft effect on software that merely uses/consumes the APIs.
Assuming API copyright (Oracle v. Google) is overturned,
the CAL will not be affected
since the CAL is about public performance of APIs and not their reproduction.
But without that precedent, how could other implementations be restricted?
Van Lindberg [[1][vanl:cal:api],[2][vanl:cal:api2]]
confirms that Chestek’s analysis is correct,
but thinks the chances of API copyright being overturned are rather slim.
Even then, CAL hooks into patent rights as a secondary means of enforcing copyleft.
Richard Fontana [[1][fontana:cal:apileft],[2][fontana:cal:apileft2]]
notes that API reimplementations have to be open-sourced when
their binaries are distributed or their interfaces are publicly performed.
He criticizes the concept of “publicly performing an interface” as unclear,
and thinks the relevant clause is written ambiguously.
This launches a side discussion about the Oxford Comma.
[Richard Fontana][fontana:cal:apileft]
asks about the legal situation of API copyright in the EU
under the 2012 [SAS Institute Inc. v. World Programming Ltd.][sascase] decision.
[Carlo Piana][piana:cal:sas]
explains that the SAS ruling excludes
language APIs, programming languages, and file formats
from copyrightability in the EU.
[sascase]: https://en.wikipedia.org/wiki/SAS_Institute_Inc_v_World_Programming_Ltd
### Strategic Concerns on API Copyright {#cal-strategy}
Richard Fontana warns that the CAL would be the first license
to intentionally expand copyleft to APIs.
Henrik Ingo is aghast at Lindberg’s explanations:
“this couldn’t possibly be your intention”.
They call some strategic concerns to attention.
[Fontana][fontana:cal:apileft] believes that
current community consensus is opposed to API copyleft.
He sees “a deep-rooted policy
against […] restrictive application of interface copyright
in free software/open source […]
that ought to be read into the OSD and our understanding of software freedom”.
This “is supported by widespread hostility in the [community] to the result in Oracle v. Google”
and the FSF’s policy of opposing API copyrightability.
While a license might acknowledge API copyrightability,
it should only do so under highly permissive terms
and not use it to impose copyleft requirements.
[Henrik Ingo][ingo:cal:api]
hopes the OSI “won’t and can’t approve of” such copyright-maximalist features.
Instead, the open source community has an interest in promoting the view
that interface implementations always or typically are fair use.
Maybe, many years later APIs do become widely copyrighted.
Only then would it be in the interest of the community to wield this power as well.
Ingo also mentions that right now,
OSI approval of a license with API copyright elements would be highly undesirable
as this could be used by Oracle lawyers as evidence
that such views were widely accepted in the industry and open source community.
[Van Lindberg][vanl:cal:pperf] understands the strategic objections,
but doesn’t think “it is an extension to use legal terminology and case law
which already presumptively applies to software.”
[Bruce Perens][perens:cal:scholarship]
asks whether it is in OSI’s interest to approve licenses
that use public performance rights
“for purposes *other* than requiring publication of the source code”.
There is also the matter of precedent.
[Perens][perens:cal:scholarship] notes the FSF
(although disapproving of software public performance)
did something similar with the AGPL, and the OSI eventually approved it.
[Pamela Chestek][chestek:cal:scholarship] thinks this leads to
“the understandable complaint that the OSI decisionmaking process can be unpredictable”,
especially since no one has claimed that the CAL’s API/public-performance aspects
would violate the OSD.
### Public Performance {#cal-public-performance}
Henrik Ingo [[1][ingo:cal:pperf],[2][ingo:cal:pperf2]] cautions that the
“use of public performance in a software license is novel and untested.”
This is risky for users.
The license doesn’t even need public performance rights to work
but could use “legal methods that are more boring, but better tested and safer”.
So for what reason should the license rely on public performance,
other than maximizing its copyright power?
Van Lindberg [[1][vanl:cal:pperf],[2][vanl:cal:pperf2]]
fundamentally disagrees here, and considers public performance key to the CAL.
Practically speaking, the AGPL is the only available network copyleft license.
But Lindberg found its network copyleft provisions lacking:
* they do not trigger for unmodified versions
* they can be gamed by using proxies
* they are unsuitable to ensure user data access
* they are unclear in a corporate context
Lindberg thinks [[1][vanl:cal:pperf2],[2][vanl:cal:corporate]]
that it’s better to use *public performance*
– an established right in copyright law –
than to define a unique term like “network interaction”.
The use of public performance paired with some other definitions
also clarifies corporate compliance.
[Henrik Ingo][ingo:cal:agpl] agrees with Lindberg’s analysis of the AGPL,
and welcomes alternatives.
Ingo criticizes the proxy loophole,
and its GPL-like mindset that software will be executed
as a single process on a single computer
which accepts network connections.
However, [Ingo][ingo:cal:agpl] vehemently disputes that public performance would be a solution.
This is completely uncharted territory,
and the CAL fails to bound its implications.
Public performance “only adds uncertainty, but little practical value.”
The AGPL protects users by giving explicit and unlimited permission to run the program.
Instead of restricting public performance,
it uses an awkward construction that compels features of the software
but not actions by the operator.
Other licenses don’t have to use that approach,
but simple and clear legal terms help protect users.
Perhaps the AGPL could be fixed
by merely replacing “network interaction” with “interaction”.
[Bruce Perens][perens:cal:fud]
is confused why, if public performance rights are given,
the AGPL went through the trouble of synthesizing a separate public performance-like right.
[Pamela Chestek][chestek:cal:pperf]
wonders how the CAL would work in the EU, where no equivalent public performance right might exist.
[Lukas Atkinson][atkinson:cal:pperf] points to “communication to the public”,
and suggests that the CAL could reference the WIPO treaty where it is defined.
Scott Peterson [[1][peterson:cal:fud],[2][peterson:cal:fud2]]
is concerned that the CAL tries to introduce the notion
that software interoperation could be the copyright holder’s exclusive right.
This would attract FUD.
Actions that impact the interpretation of copyright law
should be considered for their broader impact.
[Bruce Perens][perens:cal:fud] refers to Lindberg’s argument
that public performance is an existing right for software
because software is a literary work.
[McCoy Smith][smith:cal:scholarship]
links to an article that argues that public performance rights do *exist* for software,
but would not generally *apply*
(Lothar Determann (2015):
*What Happens in the Cloud: Software as a Service and Copyrights.*
In: 29 Berkeley Tech. L.J.
DOI:
### Other points {#cal-other}
[Pamela Chestek][chestek:cal:comments]
provides a careful analysis of unclear language in the license.
Henrik Ingo is concerned that the anti-DRM provision might not be effective,
which leads to some comparisons with the GPLv3
[[1][ingo:cal:pperf],[2][vanl:cal:pperf],[3][ingo:cal:pperf2],[4][vanl:cal:pperf2]].
[perens:cal:market]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004029.html
[vanl:cal:market]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004031.html
[perens:cal:userdata]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004032.html
[vanl:cal:userdata]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004033.html
[perens:cal:misapprehension]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004034.html
[vanl:cal:locking]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004035.html
[perens:cal:locking]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004036.html
[vanl:cal:freedom]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004044.html
[chestek:cal:tivo]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004052.html
[chestek:cal:api]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004053.html
[vanl:cal:api]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004056.html
[chestek:cal:api2]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004057.html
[vanl:cal:api2]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004061.html
[fontana:cal:apileft]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004062.html
[fontana:cal:apileft2]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004063.html
[piana:cal:sas]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004064.html
[chestek:cal:sas]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004067.html
[ingo:cal:api]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004059.html
[ingo:cal:pperf]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004040.html
[vanl:cal:pperf]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004045.html
[ingo:cal:pperf2]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004046.html
[vanl:cal:pperf2]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004047.html
[vanl:cal:gpl]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004048.html
[fleming:cal:corporate]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004049.html
[vanl:cal:corporate]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004050.html
[ingo:cal:agpl]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004058.html
[chestek:cal:pperf]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004054.html
[atkinson:cal:pperf]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004055.html
[chestek:cal:comments]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004051.html
[peterson:cal:fud]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004070.html
[peterson:cal:fud2]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004071.html
[perens:cal:fud]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004072.html
[smith:cal:scholarship]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004075.html
[perens:cal:scholarship]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004076.html
[chestek:cal:scholarship]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004079.html