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? Cheers, Albert > > 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