Telemetry Policy - Remaining Questions

[Volker Krause]

On Tuesday, 31 October 2017 11:56:23 CET Sebastian Kügler wrote:
> On Tuesday, October 31, 2017 10:39:38 AM CET Volker Krause wrote:
> > On Monday, 30 October 2017 21:24:59 CET Albert Astals Cid wrote:
> > > El dilluns, 30 d’octubre de 2017, a les 9:56:52 CET, Volker Krause
> > > va
> > > 
> > > > Let's try to finally get this finished
> > > > 
> > > > The only remaining blocker is the unique identification used by
> > > > Kexi. There
> > > > was some discussion about this around QtWS, and it seemed like
> > > > there was consensus on having a strong policy on this topic would
> > > > be a good thing for
> > > > KDE, as opposed to e.g. turning this into just recommendations, or
> > > > opening
> > > > it up to unique identification. The suggested solution for Kexi
> > > > was to add
> > > > a special exception for it to the "These rules apply to all
> > > > products released by KDE." statement of the policy.
> > > 
> > > I'm confused, is that a workaround so that it doesn't apply to Kexi
> > > by implying Kexi isn't released by KDE?
> > 
> > That sounds a bit convoluted to me, I was more thinking about making
> > it a direct exception to the policy, e.g. like this:
> > 
> > "These rules apply to all products released by KDE (with the
> > exception of Kexi, which uses a telemetry system predating this
> > policy)."
> 
> This will make the communication downright awful, as people will
> concentrate on the exception, not the rule.

Quite possible, yes.

> I'm thinking along the lines of require code released by KDE to adopt
> the policy and even add it to the manifesto as requirement to make it
> easier to enforce. 

With respect to T7050 I agree with this, although we'd probably need a broader 
set of privacy-related policies for that, telemetry is just one building block 
there.

> Kexi can always make it opt-in, and could be given
> some time to do so before we officially adopt and require this
> telemetry policy.

It's not about opt-in vs. opt-out, the problem with the current policy draft 
is the unique identification used in Kexi. In my understanding that would turn 
the collected data into "personal data" in the legal sense (similar to e.g. IP 
addresses). The whole thing was designed to avoid that and the consequences it 
has, so relaxing the restriction on unique identification essentially results 
in a considerable change to the spirit of the current draft.

So, I see the following possible ways forward:
(1) We accept the policy in its current spirit, and Kexi complies with it (if 
necessary after some transition period).
(2) We accept the policy in its current spirit, and Kexi is exempt from it.
(3) We make the policy opt-in, ie. using it merely as an extra quality 
criteria for the applications wanting to follow it.
(4) We give up on the idea of regulating telemetry, rolling back on the 
decision from Akademy.

Obviously, I'd prefer one of the first two options. But this is now dragging on 
since Akademy and leads to the bizarre situation that I am only allowed to use 
some of my KDE code (KUserFeedback) in non-KDE applications but not in KDE 
applications I'm working on...

Regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20171111/c6648fbc/attachment.sig>