[License-review] GDPR compliance through software license terms? (Re: Approval Request - ViraTrace Public Source License 1.0)

Roland Turner roland at rolandturner.com
Sat Dec 12 08:10:43 UTC 2020

Hi Wayne,

Thanks for your reply.

In fact I only asked one question and — although you referred to it in 
your reply — you don't appear to have addressed it. In particular, GDPR 
creates non-delegable obligations for several classes of actors 
(controllers, processors, authorities, DPOs, EDPB, ...), none of which 
you appear to have addressed. So far as I've been able to determine 
you've also not published elsewhere an analysis of the compliance basis 
that you're claiming. You have asserted without evidence a compliance 
determination of your software by the "Information Commissioner’s Office 
for the EU" (which doesn't exist; presumably you mean the UK?). I can 
find no evidence of such a determination, nor of any legal basis for the 
ICO to make such a determination outside of a formal investigation into 
a suspected infringement, and even then only into compliance by a 
controller or processor, not by a piece of software. Have you been the 
subject of a formal investigation? Is documentary evidence of the 
determination public? Is it possible that you are instead referring to 
simply registering a data processing operation with the ICO, an 
operation which does not imply any GDPR compliance finding on the ICO's 
part, whether of the registering organisation or a piece of software?

You are quite properly concerned about the protection of individuals in 
the face of poorly-designed tracing support systems (or straight-out 
tracking systems), even in places where health authorities really should 
know better[1], let alone places lacking technical, ethical, and legal 
expertise in personal data protection. Unfortunately your approach 
amounts to an unaccountable private sector actor seeking to insert 
itself into a position of control — over national health authorities no 
less — while not taking on the obligations of a data controller, an 
approach that is not at all compatible with GDPR. Even the FSF refers to 
variants of the arrangement that you have in mind as instruments of 
unjust power. Quite what government would be willing to operate under 
these conditions is not clear. More likely they'll (a) write their own, 
(b) approach you for a more appropriate license, or in some cases (c) 
ignore your license.

I'd suggest therefore that, even if borderline ODS-compatibility were 
established, there isn't some enormous potential benefit to individual 
or developer freedoms to weigh against a general unwillingness to 
stretch the definition. Per the rest of the discussion, however, the 
incompatibility with OSD appears extensive and likely insurmountable 
anyway. I'd hazard a guess that part of the problem is that no matter 
how well-intentioned your approach, it stems from basic 
misunderstandings about what OSI is about; in particular your repeated 
reference to a "spirit of open source", rather than to OSD and the 
freedoms that it seeks to sustain, etc. I'd guess that what you're after 
is closer to various non-open-source "source-available" schemes (e.g. 
Microsoft's Shared Source Initiative) in which source is made available 
publicly with an automatic (non-negotiated, non-registered) license 
grant, but under a license which keeps control very much in its 
developer's hands. These are perfectly reasonable schemes of course, but 
are not at all compatible with OSI's objectives and the associated 
licenses are not candidates for OSI approval.

Although I don't agree with it, your approach is an interesting one and 
far less objectionable than the approaches that I critiqued in my OSI 
SOTS talk[2] earlier this year. Thank you again for your reply.

- Roland

1: Norway 
springs to mind.

2: The critical importance of use-neutrality in F/OSS licensing 


On 12/12/20 1:04 am, Wayne Thornton wrote:
> Hello Roland,
> You raise an interesting set of questions and I will admit that when 
> it comes to the “ins-and-outs” of GDPR and HIPPA compliance, I am 
> probably not as well versed as yourself or our attorneys. That being 
> said, we at ViraTrace have from the very beginning sought to ensure 
> that the products we develop for automated contact tracing are the 
> most secure and privacy-protective on the market.
> As you may be aware from your work with TraceTogether, there is a 
> large percentage of the populations across the globe who object to the 
> concept of automated contact tracing. These objections are generally 
> centered around privacy. Here in the United States, everyone is 
> concerned with government eavesdropping and monitoring – they think 
> that by using an automated contact tracing application they are 
> providing the government with a means to track their day-to-day 
> activities and to glean nefarious insights into that data. This is of 
> course an oversimplification of the issues, but I believe it is 
> nonetheless a powerful one.
> My co-founders are citizens of former Eastern Bloc countries and these 
> concerns are just as real for them as they are for everyone else, if 
> not more so. Their countries are seeking to release automated contact 
> tracing applications which have little to no privacy protections for 
> users and then to make these applications mandatory, and this has led 
> to backlash from the population. Although some of this is a result of 
> rampant political corruption, a large portion of it is the result of a 
> lack of knowledge on how to release something that is more secure and 
> privacy-centric. This provided an opening for ViraTrace to engage in 
> ongoing negotiations with these governments to develop and maintain an 
> automated contact tracing solution.
> The solutions and frameworks we have developed are designed from the 
> ground-up to ensure end-users that their data is safe and that 
> automated contact tracing is confidential, private and secure from 
> governmental intrusion.
> Thus far, we have developed:
> 1)A cross-platform mobile application.
> 2)A cross-platform BLE/GPS/WiFi-baseddevice-to-device communications 
> protocol for use in third-party automated contact tracing applications.
> 3)A secure, delay tolerant communications protocol for 
> device-to-secure enclave communications.
> 4)A second-generation mutli-node propogation infection model which 
> utilizes distributed simulations to determine infection risk for 
> users. This model has been peer reviewed by professors at Oxford and 
> University of Torino and proven to be 85% more effective than other 
> models and has already been deployed to over 150+ million users via 
> the Aarogya Setu app.
> 5)A secure enclave processing environment which is designed to strip 
> confidential data obtained from the infection model and our 
> communications protocol and output a cleansed and sanitized data set 
> for analysis.
> 6)A web dashboard which allows government health workers to utilize 
> the cleansed and sanitized data set and communicate anonymously with 
> end users.
> We have released (or are planning to release) each and every one of 
> these technologies as open source for implementation by anyone 
> developing contact tracing platforms. Because of the nature of each 
> component being separate and designed to operate independently, there 
> are a number of potential data privacy violations that could be 
> introduced by downstream developers.
> As the maintainer and inventor of the underlying technologies, 
> ViraTrace believe we are responsible for ensuring that data privacy 
> violations are not introduced and that end users of automated contact 
> tracing applications enjoy aconsistent level of data security and privacy.
> This brings me to your specific question regarding software license 
> terms as an element of compliance.
> Our software is used as a means of processing data that is protected 
> by GDPR and HIPPA.
> It is the position of ViraTrace that as a maintainer and inventor of 
> these underlying technologies, the only way we can ensure a consistent 
> level of data security and privacy for end users is to include 
> provisions within our license that provide for oversight consistent 
> with our goals.
> The software we have, are and will release under the proposed license 
> has undergone stringent legal review for both HIPPA and GDPR 
> compliance in terms of automated contact tracing applications. It has 
> been determined to be fully compliant with both regulations by the 
> Information Commissioner’s Office for the EU and the Attorney 
> General’s Office of the United States.
> By including the provisions at issue within our license, we ensure 
> that we remain responsible for legal compliance with data privacy 
> regulations and that end users have a central point of contact for 
> questions or concerns regardless of where or how, or by whom the 
> technology is deployed.
> Our review process as specified for in the proposed license is used to 
> review the modifications and implementation of our software source 
> code and to determine if it meets compliance standards at every point 
> in a developer’s implementation. If it does not, the license provides 
> a process by which the developer must rectify the deficiencies or 
> withdraw the software from the market upon license termination.
> Although one could argue that it is the responsibility of the party 
> deploying the automated contact tracing solution to comply with data 
> privacy regulations in the means you describe, we fully believe that 
> it is our responsibility to the end users, as the maintainer and 
> inventor of the underlying technologies used for data processing, to 
> ensure that the software we provide and that is deployed basedon our 
> technologies remains fully compliant with GDPR and HIPPA.
> We would acknowledge that this is not normal practice within the 
> industry, but neither is it precluded.
> Hopefully that helps answer questions. If not, you can of course 
> respond within this thread or if you have other questions or comments, 
> you may contact me directly at the number/email within my signature below.
> Best to you and yours.
> Regards,
> Wayne M. Thornton, B.S., CPDT
> Co-Founder & Project Manager
> 720-766-0254 – Direct
> https://www.viratrace.o <https://www.viratrace.org/>rg
>> Be sure to join our Microsoft Teams 
> <https://teams.microsoft.com/join/lw83179ktnqf> channel for updates 
> and to contribute!
> This message is intended only for the individual or entity to which it 
> is addressed. It may contain privileged, confidential information 
> which is exempt from disclosure under applicable laws. If you are not 
> the intended recipient, please note that you are strictly 
> prohibited from disseminating or distributing this information (other 
> than to the intended recipient) or copying this information. If you 
> have received this communication in error, please notify us 
> immediately by e-mail. Thank you.
> ---- On Thu, 10 Dec 2020 20:39:10 -0700 *Roland Turner 
> <roland at rolandturner.com>* wrote ----
>     Hi Wayne,
>         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.
>     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.
>     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.
>     (For a sense of where I'm coming from:
>       * 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.
>       * 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.
>       * 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.
>       * I am tangentially involved in Singapore's TraceTogether
>         program as an independent expert, both on the technology and
>         on personal data protection.
>       * 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.)
>     - Roland
>     1: nor the analogous relationships in other jurisdictions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20201212/6d02272c/attachment-0001.html>

More information about the License-review mailing list