[License-discuss] [License-review] For Approval: The Cryptographic Autonomy License

[Bruce Perens]

I have brought this discussion to license-discuss, as requested by Pam.

*The mechanism of “public performance”: The health of an open source
software project relies on a predictable and consistent understanding of
what the license permits and what it requires for compliance. However,
this license uses a term specific to US law, which is “public performance.”*

There are a few issues here.

1. The license is being held to a standard for universal applicability of
terms of art that I am not aware has been applied to Open Source licenses
before. That said, license quality is important, and this may simply
reflect the fact that more trained attorneys are participating in
license-review.
But where are globally-accepted terms defined? Shall OSI at least
informally adopt a particular dictionary of Legal English? Will the
objection to local terms of art influence license drafters to avoid terms
of art in general, and would that detrimental?

2. In the Affero family of licenses, the drafters went to some lengths to
synthesize a public performance right, I think in the belief that no such
thing applied to software in at least one administration. At the time I
thought that administration was the USA. I heard, during consideration of
this license, continuing disagreement among attorneys regarding whether a
protected public performance right exists for software today in US law.
Larry Rosen can give you a lecture on his use of "External Deployment" in
OSL.

3. I don't personally find it objectionable for license terms requiring
source code distribution to trigger upon public performance. It seems
reasonable in the age of SaaS, and licenses with some form of this right
have been previously accepted by OSI.

*Until now, the principle of copyleft has only been applied to literal
> code, not APIs. The license submitter’s proposal is for a copyleft effect
> that would apply to new implementations of the API even when the underlying
> has been written from
> scratch. 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>.
> The license also makes this extension even if the legal system would not
> extend copyright (and therefore copyleft) so far. During the license-review
> process some commentators objected to this extension of the copyleft
> principle this far. However, the license review committee does not believe
> that there was sufficient discussion representing all points of view on
> the license-review list and so does not reject the license for this reason.
> The license submitter should also be aware that the OSI was a signatory on
> a brief submitted to the U.S. Supreme Court advocating against the
> copyrightability of APIs. APIs are also known to be outside the scope of
> copyright under European law. We are consequently uncomfortable endorsing
> an application of copyright law to APIs in any form without further
> discussion.*
>

The successful application of copyright to APIs would be a disaster for
Open Source software, in that we would no longer be able to create Open
versions of existing APIs or languages. Consider that the GNU C compiler is
the bootstrap tool of Open Source. Now, consider what would have happened
if copyright protection had prevented independent implementations of the C
language.

So, it's a bad idea for us to in any way accept the application of API
copyright today.

If we actually *get *API copyrights enforced against us broadly, we would
obviously have to change our strategy. But until then, we shouldn't go
there.


>
> 2.    *At what point the licensor can oblige licensee behavior*.
> The trigger for meeting license obligations can differ across licenses.
> The most common, almost universal trigger, is distribution of software. The
> AGPL license triggers upon allowing network interaction with modified
> software. The CAL license implements a new trigger, which is the
> obligation to make unmodified software available to anyone interacting with
> an interface for the software. In other words, someone might install a
> program that allows for interaction with the website (perhaps providing a
> webform to sign up for a newsletter) and would now be obliged to make the
> source code available to any person who filled out the webform.
> http://lists.opensource.org/pipermail/license
> -review_lists.opensource.org/2019-May/004113.html The License Review
> Committee does not believe that there has been adequate airing of this
> issue from a variety of viewpoints on the license-review discussion about
> this aspect of the license, so has not reached a conclusion about at what
> point imposing license obligations is appropriate.
>

I'm not sure I agree with the committee here, this is the public
performance issue and a *synthetic *public performance right exists in an
accepted license.


> 3.    *A license that requires data portability*.
> Section 2.3(b) obliges the user of a software to “provide to any third
> party with which you have an enforceable legal agreement, a no-charge copy
> … of the User Data in your possession in which that third party has a
> Lawful Interest ….” The license submitter confirmed in this sequence of
> emails that the intent of this provision is to expand the scope of software
> freedom:
> http://lists.opensource.org/pipermail/license
> -review_lists.opensource.org/2019-May/004123.html
> http://lists.opensource.org/pipermail/license
> -review_lists.opensource.org/2019-May/004124.html
> http://lists.opensource.org/pipermail/license
> -review_lists.opensource.org/2019-May/004126.html
> The members of the License Review Committee do not agree whether this is
> appropriate for an open source license. It therefore requires extensive
> additional public discussion before the OSI will be able to reach a
> conclusion on this point.
>

It's my opinion that this is out of scope for an Open Source license. My
argument is on the record above and I'm glad to elaborate. I think Arthur
(Van's customer) could explain what he wants to do with this and why he
thinks it's important. But even if I end up approving of the sentiment, so
far I think it would remain out of scope for an OSI approved Open Source
license. Of course, you don't need OSI's approval to use any license you
wish.

    Thanks

    Bruce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20190628/c5e3534f/attachment-0001.html>