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 > > escriure: > > 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)." Regards, Volker > > That would still leave us with a strong policy on this subject, while > > solving the conflict with Kexi's current way of collecting telemetry. > > Would > > that work for everyone? > > > > Regards, > > Volker > > > > On Thursday, 14 September 2017 00:20:57 CET Volker Krause wrote: > > > Hi, > > > > > > as not everyone follows long threads, let's start again for the > > > remaining > > > issues. > > > > > > https://community.kde.org/Policies/Telemetry_Policy > > > > > > The following questions were left unanswered in the previous thread (see > > > there for the full arguments if needed): > > > > > > (1) Should we allow opt-in tracking of unique identifiers? > > > > > > This was requested by Jaroslaw, as Kexi has this right now and the > > > policy > > > as written right now would thus conflict with it. > > > > > > (2) Should we require/allow/forbid publication of the raw data? > > > > > > Publication was suggested by Martin F. Practically, this would have to > > > allow for a certain delay, we can't have public access to live data. > > > Suitable licensing options of the data would probably be CC0 or > > > CC-BY-SA. > > > > > > (3) Should we require a revocation feature? > > > > > > That is, allow the user to "delete" the data they submitted from the > > > server. This was also suggested by Martin F, and is technically possible > > > without compromising anonymity. > > > > > > (4) Should we define limits on how long we store the raw data? > > > > > > Brought up by Bhushan. > > > > > > (5) Should we require an "audit log" feature? > > > > > > Thas is, allow the user to see a detailed record of what has been > > > submitted > > > so far? Martin S suggested this (and it has been meanwhile implemented > > > in > > > KUserFeedback). > > > > > > Not from the previous thread, but from a discussion in Randa: > > > (6) What is the "lower bound" of where we consider this policy to apply? > > > > > > That is, does checking for application updates/news (and possibly > > > tracking > > > that on the server) already count as "telemetry" in this context? See > > > e.g. > > > the current practice in Akregator or KDevelop. > > > > > > > > > Allowing (1) might conflict with (2) allowing publication, unique > > > identification brings us in personal data territory. Publication might > > > also > > > conflict with (3) and (4). > > > > > > So, what's your view on those issues? :) > > > > > > Thanks! > > > Volker
signature.asc
Description: This is a digitally signed message part.