<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
I would also comment that I think you have underplayed the
significance of the scope of copyleft question by characterizing it
as a "legal mechanism" question. You have not mentioned below that
this license requires that any newly-written software that
implements the same APIs must also be under and open source license.
<a class="moz-txt-link-freetext" href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004056.html">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004056.html</a>
That is a new concept; no copyleft license requirement has been
applied to code written from scratch. I don't read the thread,
particularly Richard and Henrik's emails, as suggesting that public
performance is per se the problem, but rather the concept altogether
is, no matter how it is implemented.<br>
<br>
Pam<br>
<br>
<div class="moz-signature">Pamela S. Chestek<br>
Chestek Legal<br>
PO Box 2492<br>
Raleigh, NC 27602<br>
919-800-8033<br>
<a class="moz-txt-link-abbreviated" href="mailto:pamela@chesteklegal.com">pamela@chesteklegal.com</a><br>
<a class="moz-txt-link-abbreviated" href="http://www.chesteklegal.com">www.chesteklegal.com</a><br>
</div>
<div class="moz-cite-prefix"><br>
On 5/13/2019 5:02 PM, VanL wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAFQvZENsA5brxmDhVGTFbRPgcq2wtfCM9wcMkeykzLVrWCzNew@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div>Hello
all, <br>
</div>
<div><br>
</div>
<div>I wanted
to stop for a
minute and
provide a
checkpoint: a
good faith
summary of
what I see as
the arguments
and
counterarguments
about the CAL.
Please correct
me if I am
misrepresenting
anyone's
arguments. <br>
</div>
<div><br>
</div>
<div>As far as
I see it,
there are two
substantive
debates
occurring over
the CAL: <br>
</div>
<div> 1)
Can data
portability
can be
guaranteed as
part of
software
freedom/under
the OSD?</div>
<div> 2) Is
the legal
mechanism of
using "public
performance"
effective,
compliant with
the OSD, and
good policy?<br>
</div>
<div><br>
</div>
<div>These
issues are
fundamental.
Regardless of
how well (or
how poorly)
the CAL is
drafted, these
cannot be
resolved
through more
precise
wording or
better
examples.
Other issues
of wording, or
clarifications
about the role
of patent
rights have
been raised,
but those seem
to have been
resolved
through
explanation or
changes to the
wording. There
is also a
third line of
argument that
the CAL is too
complicated,
and that
complexity <i>per
se</i> should
be
disqualifying.
With regard to
this third
argument
regarding
complexity, it
seems
subordinate to
the
substantive
debates above.
(For an
example, see
Perens, ; also
in rebuttal,
Villa, <a
href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004143.html"
moz-do-not-send="true">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004143.html</a>)<br>
</div>
<div><br>
</div>
<div>The
substantive
arguments
above
generally only
apply to the
"operator" use
case, where
the software
is being run
by a first
user (the
"operator") to
provide
services to
one or more
second users
(the "end
users").
Note that the
linked
messages below
are
*representative*,
not
comprehensive.</div>
<div><br>
</div>
<div>
<b>1.
Arguments
about data
portability:</b>
The CAL
conditions the
exercise of
copyright and
patent
permissions on
providing data
portability
for end users
of the
software in
the operator
context. This
is for "User
Data" as
defined in the
CAL, which is
scoped to data
that is input
to or output
from the
software in
which a user
as a
preexisting
interest.</div>
<div><br>
</div>
<div>-
Argument: The
data
portability
provisions
violate
freedom zero.
(Perens, <a
href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004121.html"
moz-do-not-send="true">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004121.html</a>)<br>
</div>
<div>-
Response: Data
portability is
in line with
traditional
notions of
software
freedom
(Lindberg, <a
href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004123.html"
moz-do-not-send="true">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004123.html</a>),
see also "CAL
is a net
positive
contribution
to software
freedom"
(Ingo, <a
href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004148.html"
moz-do-not-send="true">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004148.html</a>)
</div>
<div><br>
</div>
<div>-
Argument: It
is a use
restriction
(prohibited
under OSD 6)
to deny
operators the
ability to
withhold user
data from end
users because
it applies
more
particularly
in the
operator case.
(Perens, <a
href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004081.html"
moz-do-not-send="true">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004081.html</a>,
<a
href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004036.html"
moz-do-not-send="true">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004036.html</a>)</div>
<div>-
Response:
Operators are
free to use
the software
in any way
they see fit -
there is
nothing in the
CAL that
denies them
the ability to
use the
software in
any particular
way. They just
have to take
the additional
action of
providing data
portability
along with
source.</div>
<div><br>
</div>
<div>-
Argument: This
encumbers data
that is
outside the
scope of the
license.
(Perens, <a
href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004032.html"
moz-do-not-send="true">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004032.html</a>)<br>
</div>
<div>-
Response: The
CAL does not
create any
rights that
did not
previously
exist. It does
not change the
license for
any work or
data.
(Lindberg, <a
href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004033.html"
moz-do-not-send="true">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004033.html</a>)<br>
</div>
<div><br>
</div>
<div>-
Argument: Data
is not
copyrightable,
so not
reachable by
the license.
(Rosen, <a
href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004137.html"
moz-do-not-send="true">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004137.html</a>)</div>
<div>-
Response: The
copyrightability or not of data is not relevant to the license; the CAL
does not
create new
ownership
interests or
licensing
rights. (<a
href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004139.html"
moz-do-not-send="true">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004139.html</a>)</div>
<div><br>
</div>
<div>-
Argument (Ingo
vs Ingo!): CAL
may fail OSD
#6, in similar
fashion to
license
zero... "I
also agree
with Bruce
that this
whole topic is
a can of
worms"
</div>
<div>-
Response:
Having
"Freedom to
run the
program for
any purpose"
includes both
operator and
end user as
people
"running" the
program - this
is the idea
behind all
network
copyleft....
CAL is scoped
"in a way that
is quite
defensible"
</div>
<div>(Both are
Ingo, same
message: <a
href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004148.html"
moz-do-not-send="true">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004148.html</a>)</div>
<div><br>
</div>
<div>-
Argument: Data
portability is
an ethical
restriction
which doesn't
belong in a
license.
(Cowan, <a
href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004140.html"
moz-do-not-send="true">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004140.html</a>)</div>
<div>-
Response: The
CAL limits
itself to
permissions
for the work
and does not
invoke ethical
duties (<a
href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004108.html"
moz-do-not-send="true">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004108.html</a>)<br>
</div>
<div><br>
</div>
<div><b>2.
Arguments
about the
legal
mechanism:</b>
Open source
software
licenses rely
on
intellectual
property law
to enforce
their rules
concerning the
licensing of
derived works.
Most existing
FOSS licenses
have used the
ability to
distribute the
work and to
create
derivative
works (both
under
copyright) as
the
traditional
"hook" for
enforcement.
Some
alternatives
do exist: the
third party
beneficiary
language in
NASA 1.3, and
the "network
interaction"
with a
modified work
in AGPL.The
CAL also uses
distribution
and the
ability to
create
derivative
works as hooks
for copyleft
enforcement.
The CAL also
uses "public
performance"
(either as
included in
the copyright
statute or as
defined in the
included
definition),
as well as
patent rights
(specifically
"use", "sale,"
and "offer for
sale").</div>
<div><br>
</div>
<div>Most of
the arguments
have to do
with the use
of public
performance:</div>
<div>-
Argument: This
is legally
untested and
not necessary
(e.g. Ingo, <a
href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004046.html"
moz-do-not-send="true">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004046.html</a>)</div>
<div>-
Response: The
only other
license
applicable in
an operator
context is the
AGPL, which
uses legally
novel terms,
is gameable
relative to
enforcement,
and ambiguous
in a corporate
context
(Lindberg, <a
href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004047.html"
moz-do-not-send="true">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004047.html</a>,
see also
Fleming, <a
href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004049.html"
moz-do-not-send="true">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004049.html</a>)</div>
<div><br>
</div>
<div>-
Argument:
Public
performance is
US-centric and
may not be
applicable in
the
international
context.
(Chestek, <a
href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004054.html"
moz-do-not-send="true">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004054.html</a>)</div>
<div>-
Response: WIPO
"Communication
to the public"
appears
analogous
(Atkinson, <a
href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004055.html"
moz-do-not-send="true">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004055.html</a>,
see also Ingo,
<a
href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004060.html"
moz-do-not-send="true">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004060.html</a>),
and "Public
performance is
also a defined
term"
(Lindberg, <a
href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004108.html"
moz-do-not-send="true">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004108.html</a>)<br>
</div>
<div><br>
</div>
<div>-
Argument:
Public
performance
extends
copyright ("is
copyright
maximalist")
and so should
be rejected as
a matter of
policy.
(example:
Henrik Ingo, <a
href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004059.html"
moz-do-not-send="true">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004059.html</a>,
see also
Peterson, <a
href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004092.html"
moz-do-not-send="true">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004092.html</a>).
<br>
</div>
<div>-
Response:
"Public
performance is
recognized
under
copyright" and
it is better
to use
existing legal
terms
(Lindberg, <a
href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004095.html"
moz-do-not-send="true">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004095.html</a>,
see also
Rosen, <a
href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004137.html"
moz-do-not-send="true">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004137.html</a>,
but Rosen
mentions that
it may be
limited in
application)</div>
<div><br>
</div>
<div>-
Argument: The
CAL uses
Oracle v.
Google-based
logic
regarding API
reimplementation, this is premature
(Fontana, <a
href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004062.html"
moz-do-not-send="true">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004062.html</a>)
<br>
</div>
<div>-
Response:
These rights
already exist,
this is not an
extension
(Lindberg, <a
href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004108.html"
moz-do-not-send="true">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004108.html</a>,
<a
href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004089.html"
moz-do-not-send="true">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004089.html</a>).
Also, the
structure of
the CAL does
not make it
dependent upon
a particular
outcome in OvG
(Chestek, <a
href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004067.html"
moz-do-not-send="true">http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-April/004067.html</a>)<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
License-review mailing list
<a class="moz-txt-link-abbreviated" href="mailto:License-review@lists.opensource.org">License-review@lists.opensource.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a>
</pre>
</blockquote>
<br>
</body>
</html>