Clarification of open-source status of the project

[kbobrowski]

Where to find the issue

README.md

Describe the issue

Strong emphasis on "open-source" and sentences like this:

Like DP-3T and the TCN Protocol, the apps and backend infrastructure will be entirely open source - licensed under the Apache 2.0 license!

led me initially to believe that entire app, including implementation of core contact tracing mechanisms will be open-source (like current implementation of DP-3T). To my best current understanding (please correct me if I'm wrong) core part of Android implementation will be closed-source (deployed through Google Play services) and accessed by open-source part through the API. The split seems to go like this (based on https://static.googleusercontent.com/media/www.google.com/en//covid19/exposurenotifications/pdfs/Android-Exposure-Notification-API-documentation-v1.3.1.pdf):

Closed-source:

• identity key generation
• identity key storage
• broadcasting and scanning for identity keys using Bluetooth Low Energy
• calculating exposure risk

Open-source:

• fetching identity keys uploaded by covid-positive participants from the server and feeding them to closed-source part using API
• getting identity keys from closed-source part using API and uploading them to the server (after permission from covid-positive person)
• fetching exposure configuration provided by RKI and configuring closed-source exposure risk calculator using API
• graphical user interface

Suggested change

Not sure what would be the best way to clarify it. My personal impression after reading README.md was that entire app, including implementation of proximity tracing core mechanisms will be fully open-source. After getting more into details the impression is that the app will be more like a front-end to closed-source proximity tracing engine running inside Google Play services.

Perhaps one approach to clarify it could be using "open-source" term only when referencing open-source components of the app (e.g. communication with a server which provides covid-positive identity keys, or fetching exposure configuration), but avoid it when referencing app as a whole - this would lead to easier understanding of the concept.

[niklas2810]

This is not an issue with the project, but with the Android SDK itself. There is nothing which the SAP developers can do to resolve this issue (except writing an own service which integrates into Android, which would be extremely complicated). The entire app will be open source AFAIK, as this is all the code written by SAP. You also create a standard Android app which is "open source", even though some parts of the SDK are closed source.

There is no reason to add some clarification in the readme, as the DP-3T documents, which are already referenced in the README, refer to that as well.

[kbobrowski]

@niklas2810 the issue I raised was only about use of "open-source" term when clearly implementation responsible for core functionality will be closed-source. I don't try to say that someone should rewrite it in open-source way - this is a topic of another discussion, and I agree that in current situation it would be very complicated, especially considering issues iPhones have with running bluetooth in the background. Personally I won't have any issue with using closed-source proximity tracing engine with open-source country-dependent components, I just wonder whether attaching "open-source" label to the application as a whole is fully transparent.

[SebastianWolf-SAP]

Thanks for that extensive issue description. We are aware of the situation, but as @niklas2810 already explained it perfectly, we can only influence our deliverables and to confirm once again - they will all be open source under Apache 2.0.

If we went down the path of mentioning the status of all dependencies, especially on the devices (you know it's not only the Exposure Notification Libraries but also all things underneath as well) the description would probably only confuse our users. Almost all components of iOS are closed source, also many parts of Android (as it is installed on most devices) is closed source due to the dependencies to Google Play Services.

As we wanted to keep it short, we decided to use the description as it is there in the README and we will also keep it that way. Thank you for your understanding!

[ghost]

@kbobrowski C'mon, this is the most stupid thing I have read in a while.
It seems that, now with the app not collecting and selling data to ad companies, and not being an intransparent blob, you guys just dig out anything you can in order to critizise it, no matter how ridiculous it is.

Following your logic, there is no way to write an open source program for Windows.
Why? Because the implementation for stdin, stdout and the operating system's loader is not open source.
However, in- and output are core functionality for every program out there.
Additionally, it's not even possible to run a program, without a loader.
Thus, any program claiming to be open source is just lying, because they rely on closed source components they couldn't even function without.

[niklas2810]

@hoelzlw Please keep in mind to stay polite 😉 Even though I don't agree with @kbobrowski , it's still a valid question and deserves a precise and fact-based answer. I think that @SebastianWolf-SAP explained why this issue is resolved and why there is no need for further clarification.

I understand that you are frustrated by the massive amount of issues which raise uncommon or unprobable questions (I'm a little mad about this as well and I guess the SAP employees are not happy with the situation either), but let's stay positive and focus on solving issues and not creating discrepancies, okay? 😄 I neither think that this issue is critical, but now it's closed and we should move on.

[SebastianWolf-SAP]

@hoelzlw I can only agree with @niklas2810, please stay polite! Please continue discussions on a factual foundation and avoid words like "stupid thing". I really like to avoid to enforce our Code of Conduct...

[kbobrowski]

@hoelzlw of course it's very difficult to run open-source to the very bottom, including processor code etc., that's why in practice open-source status of the project is always a subject of discussion. My personal distinction is that open-source project should not depend on close-source components which handle core logic of the application, e.g. open-source proximity tracer could depend on proprietary BLE beacon SDK, but code constructing beacon frame, storing contacts, calculating risk score etc should be open-source. I have nothing against close-source applications, I'm just concerned about dissolving open-source meaning and trend to name everything "open-source".

On the other hand it's important to keep the final goal in mind, and if keeping "open-source" label would improve adoption and and at the same time won't confuse end users - I trust @SebastianWolf-SAP on this - it's a good direction.