In March, the License-Discuss mailing list discussed:
- the Cryptographic Autonomy License
- its interactions with the GDPR
- how public performance applies to software
- the License-Review process
- views on tone and conduct on the list
- the list’s role in the license review process
- problems with email, and alternative tools
- whether a PEP-style process might help
- whether licenses should be drafted without legal assistance
- and more
The summary can also be read online at
https://opensource.org/LicenseDiscuss032019
The corresponding License-Review summary is online at
https://opensource.org/LicenseReview032019 and covers the SSPL’s retraction
from review, as well as discussion of a set of GPLv3 additional terms.
*Cryptographic Autonomy License*
Van Lindberg requests comments on his Cryptographic Autonomy License (CAL),
a network copyleft license motivated by blockchain-based software. He also
wrote a blog post
<https://www.processmechanics.com/2019/03/15/the-cryptographic-autonomy-license/>
explaining the license’s background and rationale in detail.
*User Data and the GDPR*
The CAL has provisions that ensure user’s access to their data, which goes
in a similar direction as the EU’s GDPR – it even references the GDPR in an
interpretation clause. The CAL defines a concept of Lawful Interest as the
trigger for user access rights.
Henrik Ingo notes that this grants rights to third parties, which is fairly
novel and could raise OSD issues. Van Lindberg says these are just third
party beneficiaries that receive no rights other than access to the Source
and to their own User Data. The data protection in the CAL is not a grant
of rights to third parties, but a limitation on the grant to the licensee,
similar to the GPLv3’s anti-Tivoization clause.
Henrik Ingo dives a bit deeper into the CAL ↔ GDPR relationship, and finds
CAL User Data to be inconsistent the GDPR personal data concept.
Van Lindberg responds that the CAL and GDPR have different angles: GDPR is
primarily concerned about privacy, the CAL primarily about User Autonomy.
Lawful Interest is intended to not only capture rights through ownership or
the GDPR, but also things like the right to an ebook the user possesses or
has licensed. The CAL’s User Data concept is more broad than the GDPR’s
Personal Data. Based on Ingo’s feedback, Lindberg updates the wording of
the CAL to clarify its relationship with the GDPR.
*Public Performance*
The CAL triggers some license obligations on “Public Performance”, an
aspect of copyright not explicitly discussed by existing Open Source
licenses. This is intended to create a network-copyleft license like the
AGPL, while being less specific to a medium or technology.
Henrik Ingo is a bit put off by this unusual term, similar to the usage of
Conveyance in the GPLv3. The CAL also doesn’t make it clear what “Publicly
Performing an interface” means. Is there any precedent for applying public
performance to software? What is an interface? How would this apply to a
library API? Ingo is also concerned that public performance could be too
broad so that it would cover way more than SaaS style use.
Van Lindberg points out that Public Performance is a well-established term
in copyright law, but concedes that its application to software is less
well defined. Lindberg intends “interface” to be interpreted broadly, from
GUIs to APIs – as long as it can be protected by IP law. This should
definitely cover more than just SaaS use. After all, the CAL tries to
ensure user autonomy in distributed software systems.
Henrik Ingo thinks the lack of clarity around public performance is a major
weakness of the CAL – maybe specific uses should be always allowed, similar
to how the GPL gives unlimited permission to run the unmodified program?
Bruce Perens isn’t sure whether the U.S. copyright law provides a
sufficient public performance rights for the CAL to work, in particular
whether software is a literary work. Van Lindberg provides numerous
references for both US and international law that software is treated as a
literary work. (Note: see also the WIPO Copyright Treaty.) It follows that
literary works’ performance rights must also apply to software.
*Other Notes*
Henrik Ingo: isn’t “Compatible Open Source License” just any OSI-approved
license? Van Lindberg responds that the CAL defines Open Source licenses as
both OSI- and FSF-approved, but that compatibility is determined by the
terms of the other license.
The CAL allows a simple LGPL-like exception to be added. Henrik Ingo would
prefer if that was a clearly separate license with its own name. Van
Lindberg doesn’t think this would be a problem, just as there isn’t a
problem with different GPL exceptions like Classpath.
The CAL significantly expands the reach of copyleft licensing, in
particular to public performance. Henrik Ingo thinks this “copyright
maximalist” attitude is regrettable, and echoes Bruce Peren’s opinion that
“Extension of copyright is bad for open source”. Van Lindberg responds that
the CAL tries very hard to fit within the established reach of IP law.
Bruce Perens thinks that restricting the license grant to copyright and
patents may be too narrow for jurisdictions that recognize additional
rights. Perens suggests the license should grant all necessary rights, and
only exclude trademarks. Van Lindberg considers broadening the grant.
Bruce Perens thinks that the CAL’s anti-DRM clause is too narrow as it
focuses on specific techniques like cryptographic keys. This could even be
understood as a OSD #6 usage restriction. Van Lindberg agrees that could be
too narrow by itself, but that the license also contains more general
anti-DRM clauses. The mention of specific technologies was requested by his
client. This isn’t so much a user-restrictiction as a kind of
anti-Tivoization clause made necessary by the environment for which the
license is being developed.
*Discussion of License-Review process*
In the context of the SSPL’s withdrawal from OSI review (see the
License-Review summary), Josh Berkus voices disappointment with the
License-Review process: instead of legal discussions on the contents of the
license, Berkus saw ad-hominem attacks.
[This] was a dramatic failure of the license-review process, and I think
shows that this group needs to be reconstituted. […] We need a real process
around license approval that isn’t “outlast the licensing wonks with the
most free time.”
This sparks extensive discussion on whether there was a problem, how the
SSPL review should have worked instead, how reviews work, what the problems
with email lists are, and whether there might be alternatives (Discourse?).
*Views on tone and conduct of the list*
McCoy Smith and Richard Fontana don’t share Berkus’ view. Discussions about
MongoDB’s business model aren’t ad-hominem attacks, but closely related to
the license’s practical effects. Overall, it remained fairly civil. Fontana
saw “energetic and serious discussion […] from an unusually wide variety of
commenters” and is concerned that curtailing “opinionated, impassioned”
discussion “could have the effect of stifling debate and expression.”
Bruce Perens thinks that discussion remained civil, but that he can’t
respond to some people without it being perceived as a “shouting match”.
Josh Berkus reports that people on the “outside” are baffled and appalled
by conduct around the SSPL discussion.
The OSI only has authority to the extent that we are widely regarded as an
impartial arbiter of what is and is not open source. It’s important. And on
the SSPL, we are *not* widely perceived as fair or impartial.
Richard Fontana points out that License-Review is a public list and
shouldn’t be conflated with the OSI. And OSI didn’t get to be an arbiter on
the SSPL because the license was voluntarily withdrawn. However:
Participants on license-review are expected to adhere to the code of
conduct, but they are not expected to be neutral or non-opinionated[.]
Rick Moen suspects that the discontent with the list’s discussion culture
is just “passive-aggressive kickback against License Committee decisions
they didn’t like”. Richard Fontana shares that suspicion: “this sounds to
me like a complaint that most of the active participants in the
license-review threads on SSPL were hostile to SSPL.”
Perens thinks the problem is that discussion turned repetitious. Lawrence
Rosen responds with an 8-point manifesto with his most-repeated points.
Luis Villa complains about the volume and quality of discussion. Debate is
“only valuable to the extent that they help [and] the current quality and
nature of the discussion don’t do that very well”:
at some point I checked in […] to see that the thread was *literally 100
emails*, considered how negative (and often circular) the earlier parts had
been, and said “nope, life is too short”.
*Should the SSPL review have had a different focus?*
Where Josh Berkus would like to have seen discussions about copyleft and
the OSD in general, Richard Fontana reminds that the license review is not
the place for that. The review should only check whether the license
“conforms to the Open Source Definition and provides software freedom.” But
for Berkus these are not separable: the question of OSD compliance is
directly related to the question how far copyleft can and should be
extended.
To Berkus’ dismay, the recent CopyleftConf didn’t see much discussion
specifically about the SSPL. McCoy Smith summarizes some points from his
talk at the conference which did mention that license and discusses a
hypothetical Extreme Copyleft Public License as a though experiment. Smith
also points out that the AGPL addresses SaaS business models, so it isn’t
like the OSI had an anti-SaaS bias. Smith doesn’t think the community would
have a fundamental objection against extending copyleft beyond AGPLv3.
*The list’s role in the license-review process*
Rick Moen proposes that if the fundamental problem is that License-Review
discussions are mistaken for official OSI position, that could be solved if
people speaking officially self-identify themselves better.
McCoy Smith sees the following criticisms being made here, and discusses
them in more detail:
1. a few loud voices have undue influence on review decisions
2. the voices lack variety, or do not reflect the “silent majority”
3. it is unclear how review decisions take the email discussions into
account
Bruce Perens notes about the latter point that the lists are merely
advisory, and that the decisions are made by the OSI board in a vote. But
there’s a lack of transparency in how the board reaches its decisions. Do
the board members even read the License-Review list? And how did which
director vote? Mike Milinkovich shares his experience as a previous board
member: nearly all license approval votes were unanimous. There is also
more to the board than voting on licenses, so not every board member should
be expected to be a licensing expert.
Richard Fontana adds that most license submitters retract their license if
it’s not clear that it will be approved. This month’s vote on the CFSL
might have been the first rejection. In that sense, the question isn’t
whether loud voices have undue influence on the OSI, but what effect they
have on the submitter. MongoDB retracted the SSPL just a few days before
the board vote, citing a failure to reach a community consensus on the
license (which was more than just the license-review discussion).
Ben Hilburn thinks Fontana’s distinction between influence on OSI vs
influence on license submitters is really important. But while some
disagreement is normal and expected, it may also be important to protect
the submitter and the debate from negative conduct. Hilburn cautions:
*especially* for licenses where License-Review recommends rejection, our
process and debates really needs to be trusted.
*Problems with email, and alternatives*
Bruce Perens mentioned discussion turned repetitious. Andrew DeMarsh too
thinks the medium of mailing lists makes it easy to discuss the same topics
again and again, without being able to easily reference their previous
occurrence. This is boring and tiring for list participants. Maybe a better
front-end to the mailing lists would help.
Luis Villa highlights that the current email-based review process has a
number of issues or limitations:
- limited visibility into the process from the outside
- too easy to generate vasts amounts of discussion
- these monthly summaries are too infrequent to guide discussion
- specific issues are not listed or tracked
- difficult for outsiders to join constructively, not just with drive-by
comments
- no way to silently signal agreement
- McCoy Smith adds: archives are difficult to search
Villa suggests that the Discourse software might offer a better platform,
but really that any other tool than email would be an improvement. Any tool
will have *some* drawback, but Villa believes Discourse will reduce the
barrier of entry to the discussions.
Rick Moen provides a critical summary of his experience with Discourse, for
example mentioning the lack of threaded discussion. In contrast, John
Sullivan notes that the FSF is happily using Discourse.
Richard Fontana thinks Discourse would be worth trying, although it may be
geared to different kinds of discussions. Fontana doesn’t think that “new
tools will solve what are fundamentally social or political problems.”
Villa responds that tools do ease the symptoms.
Rick Moen and Thorsten Glaser are concerned that using Discourse would
require discussion participants to enter a contract with a third party
hosting company. Kevin Fleming and Michael Downey responds this wouldn’t be
the case.
Bruce Perens suggests that at least, the list archive software could be
upgraded to something better than Pipermail, which only supports plain text
emails.
Responding to an offhand mention of Bugzilla or GitHub, Fontana argues that
they would be elitist and keep non-technical people out. “several years ago
I entertained the idea that it would be obviously beneficial for license
drafting to adopt the preferred tools of developers. […] I see now that […]
involved a lot of romanticization of developers and open source
development.”
Ben Hilburn agrees with some of the problems around email, but appreciates
that email lets the user choose their clients and workflows. Some web-based
tools can be integrated with an email-based workflow, which may be
desirable.
*Would a PEP-style process help?*
John Sullivan suggests that the process could be improved without having to
change the tools. For example, each license application could be assigned a
(volunteer) caretaker who maintains a dossier with the salient points of
the discussion. In the end, any process will rely on individuals, and no
process will be able to prevent louder voices or individuals with agendas.
Chris Jerdonek draws a comparison to Python’s PEP model (Python Enhancement
Proposal <https://www.python.org/dev/peps/pep-0001/>) where discussion is
summarized in a central document. Such a document would also be useful for
further reference. Van Lindberg and Ben Hilburn concur.
Bruce Perens and Jerdonek caution that discussion in the PEP process is
still mailing-list based with all the drawbacks of the medium. John
Sullivan and Jerdonek explain that having the central PEP document helps to
keep the discussion on track and makes it easier to join the conversation
later.
Bruce Perens is concerned that a PEP-like process might have difficulty
achieving consensus for political decisions like license approval. Perens
points at the W3C, which used to make consensus decisions until patent
policy issues caused insurmountable disagreements. Chris Jerdonek sees PEP
more as a documentation thing, not as a consensus-building process.
Approval decisions are made externally (Note: compare the role of the OSI
board).
Van Lindberg illustrates how the PEP process relates to the review of his
CAL license (see below). Here, Lindberg tracks various arguments in a
PEP-like blog post.
Who should maintain the PEP summary? Pamela Chestek suggests the license
submitter could be be tasked with this in order to avoid burdening
volunteers. Luis Villa thinks it might be hard for submitters to determine
the useful and important arguments that should be covered in the summary.
Bruce Perens thinks a process editor (or group of editors) can be useful.
That might be a job for legal professionals, but not for volunteers on the
list who might have a stake in the outcome.
Richard Fontana is concerned about possible bias in the summary, both if it
is maintained by volunteer editors but especially if the license submitter
were responsible. Having a group of editors might help though. Perens
thinks submitter-written summaries could work if the summary document has a
clear version history, and the submitter is paired with an unaffiliated
editor.
Luis Villa suggests more collaborative Wiki-ish approaches, or that
revisions of the summary would have to be approved by an independent
person. Villa is less concerned about bias, more that a useful summary is
written at all.
Chris Jerdonek explains that submitter-written summaries can work if
bad/biased summary will be cause for a license rejection. Version control
etc. is important, though.
*The pro-se license constructor*
The License-Review list saw a submission of a license that didn’t have
previous legal review. That raises the question whether it is safe and
acceptable for non-lawyers to create and submit licenses.
Bruce Perens argues that it is dangerous to promote “Crayon Licenses”.
Without legal review, the actual effects of that licenses are unknown. “I
thus feel all such things should be rejected, although the reason is
entirely outside of the OSD.”
As an example, Perens points to the Jacobsen v Katzer case about the
Artistic License, which Larry Wall had drafted pro-se. The case could have
set “an absolutely horrid precedent […]: that the license was tantamount to
a dedication to the public domain.”
McCoy Smith warns that requiring prior legal review would be a barrier to
entry, could cause the review discussion to be dominated by lawyers, and
wouldn’t guarantee license quality. Perens suggests the barrier could be
avoided if the OSI would assign a lawyer like a “public defender”. Henrik
Ingo doesn’t see an issue with a barrier to entry: There are plenty of
approved licenses already available. And the license-review process isn’t
zero-cost either, the cost is just born by OSI. (Note: and the community!)
Brendan Hickey digs into the purpose of barriers and legal review. Hickey
doesn’t think that legal review would be suitable to protect end users of
the license. And legal probably shouldn’t be the first step: “No one should
be hiring an attorney to draft a license that will be rejected out of hand.”
Nigel Tzeng claims that advice from lawyers would be ignored anyway, which
seems to reference the NOSA review. John Cowan points out that a license
may be a fine legal document but still fail to conform to the OSD. Tzeng
and Bruce Perens rehash some of the discussion around the NOSA. After a
while that argument flows into the more general discussion about the
license-review process, covered above.
Van Lindberg discusses different aspects of license review. On one hand
there are policy choices and community considerations, but determining
whether a license is legally sound and complies with the OSD is “strongly
legally inflected”. Richard Fontana takes issue with that: The OSD is not a
legal document but “a statement of philosophy and policy aimed at
nonlawyers.” Determining OSD compliance might require lawyer-style
thinking, but “a nonlawyer who is steeped in free/open source legal policy
[…] might be much better qualified to interpret the OSD”. Lawyers might
also be biased, for example when they are representing a client. While
input on the legal soundness of a license is valuable and requires legal
specialists, e.g. in case of the SSPL the policy arguments were ultimately
more important.
*Leftovers*
Thorsten Glaser cross-posts a discussion from the Fedora-Legal list about
whether the Open Motif license can be considered open source. Open Motif
has an unusual license that restricts its use to “open source” operating
systems. Bruce Perens considers this OSD #9 and #10 violations. Florian
Weimer points out that RHEL nevertheless ships Open Motif, and he doesn’t
think this restriction would be problematic.
The GPLv3 allows additional terms that prohibit misrepresentation or
decline trademarks. Patrick Schleizer asks: Does that mean the GPL grants
such rights by default? John Cowan argues that failure to prohibit
something is not permission. Similarly, Bruce Perens points out the lack of
affirmative statements that would grant these rights. And the licenses
don’t have to cover everything in detail: they are embedded in a wider
legal context.
End users of open source licenses typically don’t explicitly accept the
license. Patrick Schleizer asks: Doesn’t that mean any limitations of
liability are ineffective because the end user never *waived* their rights?
Or can warranties be unilaterally *disclaimed* by the author? Does this
differ between common law and civil law jurisdictions? Thorsten Glaser
suggests that disclaimers are a condition on the copyright license. Van
Lindberg points to the difference between licenses and contracts (Note:
which may be an US-centric viewpoint).
Chris Lamb links to the discussion on the Debian bug tracker
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905674> about the
“citationware” requirement of Ole Tange’s GNU Parallel utility: the utility
prints out a demand to cite the software or to pay the author a lump sum.
Jonathon contrasts academic conventions around citation with the wording of
that requirement. Bruce Perens notes that in the meanwhile, the citation
requirement has been reduced to a non-compulsory request.
Responding to January’s discussion about “intimacy”, Florian Weimer adds
that AGPL compliance is particularly unproblematic for quine-like programs
that can provide their own source code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20190401/e06d0e16/attachment-0001.html>