<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Thanks Pam,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">I was conscious of the scope problem
when I posted, but figured that a short excursion into the novel
benefit claimed of the proposed license was probably reasonable
within the review, given that that claim was the basis for its
design. Do you feel that opening that discussion here instead
would have been a better approach?</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">For the benefit of those not watching
license-review: Viratrace withdrew its proposal without providing
a basis for the GDPR-compliance-determination claim, and so far as
I can tell there can be no basis for such a thing. I suspect that
they have confused mandatory registration of a data processing
operation with compliance certification of their software.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Were such a compliance basis to exist I
think there would be a most interesting discussion for OSI. I
still think that it would probably be a non-starter, but it would
address many of the problems with the approaches that I critiqued
in my SOTS talk earlier in the year. While much of the debate
quite properly punts "comply with the law" to the law instead of
embedding it in licenses, there's a definite cross-border concern
here. I really don't buy use-discriminatory licensing as
compatible with OSD, but I can see that there's going to be a
concern for some developers in highly-developed regulatory
environments who are comfortable with deferring to law for
licensees in their own jurisdiction as a harm-mitigation approach,
nonetheless being quite uncomfortable about the lack of comparable
protections elsewhere and looking to embedding compliance
obligations in licenses to assuage this (e.g. compliance with data
protection law in the licensor's jurisdiction, not the
licensee's).</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">- Roland</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">
<hr width="100%" size="2"><br>
</div>
<div class="moz-cite-prefix">On 14/12/20 6:59 am, Pamela Chestek
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:7b24a408-5983-a922-aa0b-d7c3aa34ddee@opensource.org">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Moving the conversation to license-discuss, since it's not
about the terms of this license specifically but more generally
about the intersection of GDPR compliance and software
licensing.</p>
<p>Pam</p>
Pamela Chestek<br>
Chair, License Committee<br>
Open Source Initiative<br>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 12/10/20 10:39 PM, Roland Turner
via License-review wrote:<br>
</div>
<blockquote type="cite"
cite="mid:2220a7ff-58a2-52b9-b9f4-2f45c4374943@rolandturner.com">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<div class="moz-cite-prefix">Hi Wayne,</div>
<div class="moz-cite-prefix"><br>
</div>
<blockquote type="cite"
cite="mid:1764a910a39.e14846f8839613.2781088703153336734@viratrace.us">
<div style="font-family: Verdana, Arial, Helvetica,
sans-serif; font-size: 10pt;">
<div>First, regarding rationale: Our company is in the
business of creating frameworks and software products
which facilitate automated contact tracing initiatives
across the globe. These frameworks and products must be
GDPR- and HIPPA-compliant and have been designed to be
such, with strict, ongoing legal review processes
undertaken to ensure this. The frameworks and products
that we create are designed to be utilized by governmental
agencies and private corporations in the creation of
applications and platforms which aid in the fight against
COVID-19 and future pandemic scenarios. In order for this
to be of benefit, the frameworks and software we develop
must be open source, so that the governmental agencies and
private corporations can be free to utilize them.
Unfortunately, due to the legal compliance issues
vis-a-vis GDPR and HIPPA, a level of control regarding
development must be maintained. It is our position that
the GNU and other OSI-approved licenses do not provide
this level of control. <br>
</div>
</div>
</blockquote>
<p>Others are addressing the appearance of a profound
incompatibility between what you're proposing ("free to
utilise" vs. "level of control [by Viratrace]") and the Open
Source Definition.</p>
<p>I'm interested in the concept of software license terms as an
element of GDPR compliance. Can you explain how you see
license terms being a relevant part of this? It is my
understanding that data protection law in most jurisdictions
is about the legal obligations of organisations in control of
personal data both with respect to that data and to people
that it relates to (and often to regulators), and
legal/contractual obligations of other organisations
processing that data on their behalf; software licensors are
not part of the picture. As neither Viratrace nor likely
licensees would be looking to establish a controller/processor
relationship[1] through the license, the relevance is not
immediately clear to me.</p>
<p>(For a sense of where I'm coming from:</p>
<ul>
<li>Although this is my first ever post to license-review,
I've been involved in open-source license advocacy for
rather a long time. It was I who initially proposed late
last century (!) a multi-license approach for Mozilla.</li>
<li>I serve as Chief Privacy Officer for my employer — a
specialist processor of personal data — and in that capacity
have assisted customers with data protection obligations
across a dozen jurisdictions on four continents.</li>
<li>Although the specific concerns of Free Software are
largely out of scope here, I am an advocate of the approach
and have spoken in public about the overlapping objectives
of Software Freedom and of GDPR data subject rights.<br>
</li>
<li>I am tangentially involved in Singapore's TraceTogether
program as an independent expert, both on the technology and
on personal data protection.<br>
</li>
<li>I am working on a design for a system to extend
TraceTogether which coincidentally also uses secure
enclaves, although for a much simpler purpose that the one
that you appear to be pursuing.)</li>
</ul>
<p><br>
</p>
<p>- Roland</p>
<p><br>
</p>
<p>1: nor the analogous relationships in other jurisdictions</p>
<p><br>
</p>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
The opinions expressed in this email are those of the sender and not necessarily those of the Open Source Initiative. Communication from the Open Source Initiative will be sent from an opensource.org email address.
License-review mailing list
<a class="moz-txt-link-abbreviated" href="mailto:License-review@lists.opensource.org" moz-do-not-send="true">License-review@lists.opensource.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" moz-do-not-send="true">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Pamela S. Chestek
Chair, License Committee
Open Source Initiative</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
The opinions expressed in this email are those of the sender and not necessarily those of the Open Source Initiative. Communication from the Open Source Initiative will be sent from an opensource.org email address.
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>
<p><br>
</p>
</body>
</html>