[License-review] May 2019 Summary

[Lukas Atkinson]

In May, the License-Review mailing list saw extensive debate on the
Cryptographic Autonomy License. The list also discussed a BSD variant used
by the Lawrence Berkeley National Laboratory, and the Master-Console
license.

This summary can also be read online at
https://opensourcde.org/LicenseDiscuss052019

The corresponding License-Discuss summary is online at
https://opensource.org/LicenseDiscuss052019 and covers an announcement
regarding the role of the License-Review list, discussion on the
comprehensiveness of the approved license list, and other topics.

*Cryptographic Autonomy License*

The review of the Cryptographic Autonomy License (CAL) continues. Back in
April, Van Lindberg submitted the CAL as a network copyleft license, but
with broader scope than the AGPL (see the summary
<https://opensource.org/LicenseReview042019#cal>).

While the CAL clearly tries to comply with the OSD, there are widespread
concerns as to whether some fundamental aspects are compatible with open
source and software freedom.

*Public Performance*

Bruce Perens claims that use of public performance rights implies a
field-specific restriction in the sense of OSD #6, e.g. because it would
allow private use but not public use. (Note: the mere use of these rights
does not create such a restriction.)

Scott Peterson argues that software interoperation cannot be a
“performance” in the sense of US copyright law – even if a public
performance right exists for software. The CAL makes software
interoperation more difficult and should not be approved. Van Lindberg
provides his analysis of the term. Notably, Lindberg’s definition does not
require a human audience for the performance.

Chestek finds a potential problem with how public performance interacts
with modified works, as parts of the license only consider public
performance of interfaces. Van Lindberg appreciates this point.

*User Data*

Bruce Perens argues that the CAL’s user data provisions go beyond copyright
law. Users don’t have an a priori right to receive their user data until
the CAL created this right. But this means that the operator’s copyright
license is conditional on fulfilling the user data obligations, which is an
unreasonably far-reaching compulsion.

Pamela Chestek follows up on April’s discussion
<https://opensource.org/LicenseReview042019#cal-freedom-data> on whether
the CAL’s user data clause is comparable with the GPLv3’s anti-Tivoization
clause. Van Lindberg sees a distinction between two of CAL’s clauses: The
CAL forbids locking down the software via cryptographic means, a kind of
Tivoization. The CAL also requires user data to be provided, which is
necessary to ensure user freedom in a SaaS context. Bruce Perens agrees
that this should be fixed – but by some law, not by a license. And anyway,
the user should just keep backups of their data.

Nigel Tzeng thinks the user data obligations are unrealistic and excessive,
for example where the operator has no easy way to make a copy of the data.
This is problematic even with a good faith effort to comply, and makes the
CAL “unworkable for most operators.” How detailed do requests have to be?
Does holding a copyright license imply a possessory interest? But if the
user data only covers the user’s inputs (not modified or intermediate
formats), the right to a copy is also not very useful.

Van Lindberg responds that the user data clauses ensure data portability to
inputs and outputs of the software, and where the user has some possessory
interest in the data. What that encompasses precisely would depend on the
jurisdiction. Having a (public) license for some data does not imply a
possessory interest.

User data requests will typically only cover data that the end user
uploaded. This can be implemented via export functionality in the software
(note: as is already common in GDPR-compliant systems). That does not imply
excessive effort for the operator. Where no such functionality is
implemented this may require some effort, but that is comparable with
having to provide the source code. When the request covers data that they
didn’t upload, they would have to specifically demonstrate their possessory
interest.

Bruce Perens doesn’t buy Lindberg’s argument that providing user data were
easy. In a blockchain setting, providing user data might be as simple as
providing a copy of the blockchain. But in other settings operators have no
guidance or guarantees. Peer to peer applications seem especially
problematic, since every end user would be an operator. Lindberg’s fixation
on certain SaaS settings is not helpful.

*GDPR*

Chestek assumes the GDPR is being referenced because there would otherwise
be a conflict with CAL compliance. Such preferential treatment of the GDPR
would be “facially non-compliant with OSD 6”: it relieves someone complying
with the GDPR from complying with the CAL. Compliance with the CAL might
also be impossible if a jurisdiction has conflicting privacy laws. The
section should be rephrased to avoid being specific to any legal regime, or
removed when no conflict is expected.

Lindberg explains that the reference to GDPR is intended to streamline
compliance: if the operator already complies with the GDPR, that’s already
good enough for compliance with the CAL’s user data requirements. This is
just an interpretive guide, and doesn’t confer special permissions. Given
the amount of confusion that clause has caused, Lindberg considers removing
it.

*Fontana: The CAL is not Free because it encumbers APIs*

In April, Pamela Chestek had asked why specifically the CAL should not be
approved, under the assumption that public performance rights are a thing
for APIs.

Richard Fontana responds:

   -

   it forces reimplementations of a CAL-covered API to be open source
   -

   Joke: any license can be opposed on the grounds that it violates OSD 5/6
   (restricts some persons, or fields of endeavour)
   -

   but here the CAL really looks like such a violation
   -

   not necessarily a problem: even the GPL certainly restricts some persons
   -

   “From a software freedom perspective, extending a copyleft requirement
   to an interfae is unjust.”
   -

   CAL might violate the spirit of OSD 9 (don’t restrict other software),
   similar to the SSPL.
   -

   OSI review should not just check OSD conformance, but also whether the
   license provides software freedom
   -

   the CAL’s unreasonable burden on interface re-implementors violates
   software freedom.
   -

   that the license limits itself to copyright law doesn’t mean it provides
   software freedom
   -

   a copyleft license like the CAL doesn’t necessarily make more software
   available under open licenses.
   - unusual license might see no adoption
      - seems to serve a proprietary dual-licensing business model
      - which would mean it would actually result in *less* open software
   -

   questions what it means to publicly perform an API.
   - could see such a performance for GUIs
      - but APIs are not typically perceived by users

Pamela Chestek responds that she still can’t see the CAL “as even slightly
different from the GPL in reach”, under the assumption that API copyright
exists. Chestek is more concerned about the applicability of public
performance rights outside the US. Chestek is confused by Fontana’s
position that a free software license may not apply copyleft to all aspects
of copyright (such as API copyright).

Chestek does not believe Fontana’s argument that the CAL will result in
less free software. If some copyleft licenses are harmful, where exactly is
the tipping point? Why is AGPL acceptable but CAL not?

Fontana responds that a license may decide to cover API copyright, but no
FOSS license should do so. Fontana thinks that the CAL breaks with the
(A)GPL tradition, and is confident that the FSF would condemn any
interpretation that the CAL were essentially the same as the GPL.

*Perens: Licenses should not cover API copyright*

Bruce Perens summarizes his stance on free software:

   - since the DFSG, it has been clear that running open source software
   for any purpose must be allowed
   - it is necessary that the rules don’t have total sympathy for
   proprietary developers
   - it is fine to require the sharing of modifications
   - many network copyleft licenses change the fundamental deal of open
   source
      - running for any purpose no longer allowed
      - such licenses no longer respect users
   - approving network copyleft licenses is a slippery slope towards losing
   authority
   - supporting API copyright is a bad idea because it can be used against
   the open source community
      - perhaps later API copyright licenses will become necessary as a
      defense

On the interpretation of the OSD, Perens sees two ways forward: Either the
OSD is interpreted literally, but is also amended/clarified regularly. Or,
the OSD is interpreted intelligently.

Van Lindberg argues that “we have already entered the world in which
licenses like the CAL are necessary”: “Put aside the network aspect. How
many reimplementations of the GNU readline interface are there? How many
bashisms have made it into other shells? Under Oracle v Google, those are
derivative works.” Perens disagrees and urges not to “concede the fight
before it is lost.”

Henrik Ingo agrees with Perens that the CAL oversteps some boundaries, in
particular with its user data requirements. However, the age of SaaS makes
strong network copyleft licenses necessary in order to protect end user
freedom. Ingo hopes a scaled-down CAL would get approved.

To Peren’s point that approving non-free licenses could cause the OSI to
lose authority, Ingo adds that failing to approve OSD-compliant licenses
would be harmful as well. “Network copyleft is clearly an area where
currently supply and demand don’t meet”. Perens obviously disagrees and
reminds that approval can cause problems for the community. The community
is also not reliant on OSI approving new licenses, just like the FSF
doesn’t have to write new licenses: “While we are starting to see reasons
for GPL 4, nobody is in a hurry.”

Pamela Chestek questions why involving public performance rights is
necessary to protect APIs. “Public performance” is an US-specific term, and
the CAL might stretch beyond the bounds of copyright. In contrast, the
GPLv3 defines its term “propagate” in terms of copyright law. Chestek
suggests the CAL could borrow this approach. Lindberg doesn’t quite
disagree, but objects on multiple points. The CAL should make its intention
to cover public performance explicit, it already defines the term within
the license, it must also consider IP other than copyright, it doesn’t
stretch beyond copyright, and Lindberg would like to stick to existing
terms.

*Freedom in Website and Blockchain Scenarios*

Pamela Chestek asks whether she would be eligible to receive a CAL-covered
websites source code when she enters a third party’s user data into a form
on the website. Van Lindberg responds that yes, she would be eligible for
the source just as under the AGPL. However, the source code requirement
already triggers due to using the software. Here, the third person’s
personal data is not that third person’s user data, but the user data of
the one entering the data into the website.

Bruce Perens extends the scenario with a blockchain-based example, where
there might be “derivative data”. Perens also thinks the CAL’s definition
of source code includes private keys that were used to manipulate data in
the blockchain. After all, any blockchain participant would be an operator
processing user data. (Note: this may be a misunderstanding of both
blockchain technology and the CAL.)

Van Lindberg provides two detailed replies. The CAL does not have a concept
of derived data. Instead, obligations arise if someone is a Recipient in
the sense of the license. The operator’s obligation to provide data only
extends to the user’s data, and only to the extent that the operator can
retrieve this data. Disclosure of private keys is not required in the
context of user data, although it could be required in the context of the
source code as part of the CAL’s anti-Tivoization clause. In general,
Perens’s hypotheticals “don’t really make sense”, and would result in
roughly the same outcomes as under the AGPL.

Bruce Perens claims that while the CAL may or may not violate the OSD, it
definitely violates the FSF’s Freedom Zero “to run the program as you wish,
for any purpose”. The problematic user data terms even apply to unmodified
software. In Peren’s eyes, Lindberg has arbitrarily redefined the FSF’s
concept of Software Freedom to cover user data. Lindberg insists the CAL
ensures end user freedom the same way the GPL does, this involves
preventing intermediaries/operators from taking rights away. The question
to decide is precisely whether the operator’s freedom to lock down end user
data is more important than the end user’s freedom to run the software with
their own data. Lindberg and Perens just disagree on how to resolve that
dilemma. Lindberg has also asked the FSF for their opinion.

Bruce Perens also thinks the user data terms are unnecessary in the
decentralized context for which the license was drafted. Lindberg argues
that the CAL helps to keep a system decentralized.

Bruce Perens sees an overarching problem with the license: that even
competent attorneys seem to be struggling with its terms, particularly
regarding user data and public performance. Courts might not share
Lindberg’s interpretation. Developers without legal counsel don’t have the
“slightest hope” of applying the license correctly. Lindberg concedes that
fully understanding a legal instrument like the CAL does require counsel.
But the CAL is no more complex than the GPL. The effect of the CAL can be
summarized concisely in a manner that would be understood by an ordinary
developer. Perens Perens disagrees with that summary, and thinks Lindberg’s
stance is deeply unsympathetic to users.

*Other Points*

Re claim by Pamela Chestek: OSI decision making is unpredictable. Bruce
Perens responds that “we like it that way”. OSI review should not
mechanically implement pseudo-laws, but care about the community’s interest.

Bruce Perens asks whether the copyright holder would also be bound by the
conditions of the CAL, e.g. regarding user data. Peren’s understanding is
that they would not be bound, which would privilege them compared to other
operators. Van Lindberg claims that the CAL places no party in a privileged
position.

Van Lindberg argues that the CAL is also necessarily because the AGPL is so
unclear and ambiguous. The CAL would be clearer, and would have applicable
case law “at least by analogy”.

Kevin Fleming asks if the CAL is only fully effective if patents are
involved. Lindberg responds that patents holders will have extra tools, but
that the CAL is based equally on copyright, patents, and contract methods.

Pamela Chestek and Van Lindberg continue their review discussion from last
month.

   -

   Lindberg updated language around the LGPL/MPL-style Combined Works
   exception.
   -

   Chestek thinks the anti-DRM clause is “unintelligible”. Lindberg
   provides a side by side comparison of the clauses in GPLv3 and CAL.
   -

   Chestek thinks the CAL is overly complicated when trying to ensure that
   all permissions are passed to downstream recipients. Isn’t this as simple
   as “cannot impose additional restrictions”? Lindberg responds that this
   isn’t as simple. He doesn’t want to enumerate allowed restrictions like the
   GPL does. However, Lindberg updates relevant language in the CAL.

Henrik Ingo is torn on whether the CAL should be approved. Prima facie, the
CAL violates the OSD – but only due to its well-justified, tightly-scoped
user data requirements that are necessary to ensure end user freedom in
practice: “the CAL is a net positive contribution to software freedom.” The
user data clauses do not violate Freedom Zero if the operator is viewed as
merely running the software *on behalf* of the end user. If this violates
the OSD, maybe the OSD should be amended.

Bruce Perens doesn’t think the OSD can be a comprehensive list of allowed
or disallowed license features. It should not be amended until it can be
interpreted mechanically.

Ingo had invoked the License Zero review as precedent. Richard Fontana
clarifies that L0 was retracted and not rejected, but that the significant
past “hostile receptions” should be treated with some significance.

*Lindberg’s Summary*

Van Lindberg tries to summarize various objections and discussion points,
and provides references to various arguments that have been made. The three
main issues are:

   1. whether data portability can be guaranteed as part of software
   freedom and under the OSD
   2. whether public performance is effective, OSD-compliant, and good
   policy
   3. whether the CAL is too complicated or unclear

The objections mainly apply to the operator of the software, not to end
users. Issues 1 and 2 are fundamental policy questions.

Bruce Perens confirms he believes that “an operator’s ability to lock down
the data they receive from end users is core to the OSD and to the concept
of Free Software” (as phrased by Lindberg). John Cowan thinks Lindberg is
approaching this from the wrong end: the right to commit crimes is not core
to FOSS. But using FOSS licensing to enforce ethical actions is a Very Bad
Idea.

Lawrence Rosen is against approval. While Rosen accepts a public
performance right for software (his own OSL uses it), it has limited value
and has nothing to do with normal execution of the software. Performance
does not include the rendering, display, or execution of a software. Rosen
thinks the CAL’s user data clauses are troubling, since data is not
copyrightable. At most, a confidentiality clause would be appropriate.
Lindberg points out that the CAL has nothing to do with copyrightability of
data, and uses a multi-pronged mechanism of which copyright is only one
part. Lindberg thinks Rosen is reading the definition of public performance
in US law too narrowly, and provides caselaw to bolster his argument.

Luis Villa argues that the CAL is not excessively complex. The CAL and GPL
use similarly complex language, although both are more complex than other
licenses. If objections on the grounds of complexity were to carry any
weight, then “OSI can… only approve long-existing licenses (or trivial
permissives). (If that’s the board’s intent I’d love to hear it; we can all
unsubscribe from this list and call it a day!)” McCoy Smith concurs:
there’s a difference between ambiguity (bad) and inherent complexity
(acceptable) of a license.

Pamela Chestek adds the major objection that the CAL would be the first
open source license to encumber API reimplementations. This is the main
issue, compared to any debates over public performance. Henrik Ingo argues
that both are problematic, and that invoking public performance rights
seems unnecessary except for the CAL’s goal to implement API-copyleft.
Lindberg views these issues as independent. The CAL’s use of public
performance is primarily an alternative to the AGPL’s “network interaction”
mechanism. API copyleft is a reaction to the Oracle vs Google case.

Richard Fontana thinks Lindberg’s summary fails to accurately capture
fundamental objections. The issue is not whether API copyleft could be
premature, the whole concept runs against FOSS and industry conventions. If
a license makes use of API copyright, then please only for maximally
permissive licensing. Henrik Ingo thinks API copyright would be a huge
detriment to the industry – would any readline implementation be copyright
infringement? But if it happens, the FOSS community shouldn’t just cede
that ground. “Still, as long as we’re not there yet, we of course shouldn’t
be the first party to strike.”

*LBNL BSD*

Sebastian Ainslie asks for *legacy approval* of the LBNL-BSD, a 3-clause
BSD variant used at the Lawrence Berkeley National Laboratory (LBNL).
Compared to the common BSD template, it adds a caveat that U.S. Dept. of
Energy approval may be required, presumably required for all DOE labs. It
also adds a paragraph that published modifications fall under the same
license by default. This is a bit like an implied CLA, or like copyleft
with an opt-out. Ainslie explains this is necessary in order to accept
contributions without signed CLAs.

*Legacy approval*

There is some contention on what *legacy approval* signifies.

Bruce Perens raises a license proliferation objection. McCoy Smith wonders
why OSI approval is needed if the license has already been used for over a
decade. Richard Fontana wonders whether actively used licenses are eligible
for legacy approval. Kevin Fleming assumes that the use of legacy-approved
licenses would be discouraged. On further reading, Fontana finds that
legacy approval is just retroactive. It does not require the license to be
unused, and does not imply any discouragement.

Richard Fontana thinks that legacy-approval must generally meet the same
standard as new licenses, especially with regard to OSD conformance. But it
would be a good idea for OSI to take a more active role to explicitly
approve licenses that are commonly used in Linux distributions. Legacy
approval should therefore be more lenient about sloppy or amateurish
drafting. 15 or 30 years ago, licenses simply were not drafted with the
same standards we expect today.

Fontana sees many people who do not accept OSI’s stewardship of the Open
Source definition. They can point to a vast collection of open source
software that does not use OSI-approved licenses. A mass effort to approve
more obviously-FOSS licenses would then have some benefit.

*Actual review*

Fontana sees the added paragraph as unclear or sloppily drafted. It might
not trigger the default license if modified versions are privately given to
third parties, without these modifications being published. This is
different from Apache 2 which just codifies the “inbound = outbound”
expectation. Pamela Chestek wonders whether the paragraph is even relevant:
“inbound = outbound” is the default expectation, with or without that
paragraph. The paragraph mainly affirms that modifications can be published
under a *different* license. Henrik Ingo shares this view (see also below).
John Cowan disagrees: by default the modifications would have no license,
as the BSD would only apply to the original work.

Tom Callaway questions why the paragraph seems to assign different terms to
enhancements than the main BSD license. Richard Fontana too thinks that the
contributor license is broader than the BSD. Ainslie argues that no such
different terms are used, but this seems to confuse the submitted license
with a suggested simplification by Callaway.

McCoy Smith and Henrik Ingo note that OSI usually rejects licenses that
give preferential treatment to one party, or are specific to some entity.
Here, this is not a problem: while the LBNL is mentioned explicitly as a
recipient, it receives the same rights as the public.

Henrik Ingo is slightly concerned about the default license paragraph
acting like an implicit contributor agreement. But this is not a problem in
practice: code added to a BSD-licensed project is considered to be
BSD-licensed as well. The paragraph only seems like a clarification in case
of a standalone patch is sent without explicit license indicators.

Brendan Hickey isn’t sure whether implicit “inbound = outbound” should be
promoted. Hickey points to projects like Linux that expects patches to be
explicitly signed off by the contributor. Hickey also points to the C-FSL
review, where it was discussed that licenses cannot do copyright
assignment. So what kind of licensing terms would actually be necessary in
order to safely accept contributions? Henrik Ingo responds that the license
status of published modified versions is usually clear without having to
take extra steps, and that no copyright assignment is involved.

Richard Fontana suggests a DCO (https://developercertificate.org/) as a
simpler way to ensure that contributions are properly licensed.

Ainslie says that DOE labs cannot use a vanilla BSD license, which made
small changes to the license necessary. Pamela Chestek Pamela Chestek asks
for documents that require these changes and McCoy Smith asks which
specific changes are mandated. Ainslie says they have to attribute their
funding source and add a notice that DOE approval be required. McCoy Smith
questions whether the addition of a notice even creates a new license. It
is unclear to Chestek which of these changes are part of the license that
is under review.

McCoy Smith thinks making the license conditional on DOE approval could be
an OSD 7 issue. But is that a license condition, or just a notice?

Pamela Chestek asks how many projects use this LBNL license. Ainslie says
it’s used by nearly all open source software from Berkeley Lab, adding up
to hundreds of releases.

*Master-Console*

Wayne Rangel Wayne Rangel submits the “Master-Console’s Open Source
Definitive License” for approval. It is difficult to tell, but the
rationale for this license seems to be:

   - that the original author can take down malicious modifications
   - that the source code shall be offered in a specific manner, presumably
   that the source code can be downloaded via a web browser

Lukas Atkinson expresses their frustration that the license seems
impossible to understand, both from a legal perspective and due to the
unidiomatic English. Christoper Sean Morrison thinks “that should be
grounds for rejection alone.” McCoy Smith sees the license terms as an OSD
5/6 violation. The license is also likely non-free, “although the wording
is such that I can’t quite tell.” Bruce Perens points to the Artistic
License as an example where an unclearly drafted license resulted in high
costs to third parties.

Richard Fontana suggests the license is not yet ready for review. Pamela
Chestek asks for the license to be retracted from review.

*Help Wanted!*

Our current editor of the monthly License-Discuss and License-Review
reports, Lukas Atkinson, will not be available to continue in June and
July, and may have limited availability throughout the rest of the year. If
you would like to join the OSI as list editor, or know someone who might,
please contact OSI General Manager Patrick Masson <masson at opensource.org>.
The list editor works on a freelance basis to provide monthly summaries of
the License-Review and License-Discuss mailing lists.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20190604/7f45d5c3/attachment-0001.html>