Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Policies/Uploading and Downloading from Eclipse Software Policy"

(Auditing and Approval)
(Common Mechanism)
Line 54: Line 54:
 
=Common Mechanism=
 
=Common Mechanism=
  
Reasonable effort must be undertaken to leverage existing "call home" mechanisms rather than create new ones.
+
Reasonable effort must be undertaken to leverage existing mechanisms rather than create new ones.

Revision as of 16:32, 22 October 2013

Warning2.png
This is a work-in-progress; this policy is not in effect.


Overview

This policy is concerned with Eclipse Foundation project code "calling home" or otherwise connecting from software distributed by the Eclipse Foundation to remote services.

This policy applies for software that:

  • checks for updates;
  • pulls information from websites;
  • provides a heartbeat;
  • gathers usage statistics;
  • gathers data from a user's workstation; or
  • otherwise collects information from user installations.

Opt-in

Any service that uploads data must be "opt-in". That is, a user must agree to participate (agreement may be implicit due to the nature of the service).

If the nature of the data being collected changes, the user must be informed of the changes and be given the opportunity to explicitly agree to continue participation.

The user must be able to review any data before it is uploaded.

Services that get/pull data only do not require "opt-in". The server components for these services must not attempt to persist any information related to a get/pull data service (server logs, with access restricted to administration staff only, are exempted from this requirement).

Private Information

All uploaded information is subject to the terms of the Eclipse Privacy Policy.

Raw data, which may include non-obvious potentially private information, must be transferred securely.

Raw data must be stored securely and access to the data needs to be strictly controlled. To access the raw data stored on an Eclipse Foundation Server, an individual must be a committer. Access to raw data that may include personally-identifiable information must sign a non-disclosure agreement (NDA) with The Eclipse Foundation.

Obvious means of identifying a specific individual or organization (e.g. IP address) must not be persisted. Server logs that are accessible only by Eclipse Foundation Webmasters are exempt.

Reasonable effort must be taken to avoid persisting or disseminating information that can inadvertently be used to identify an individual or organization.

Storage

The target for data collected by content distributed from an Eclipse Foundation-managed server must also be an Eclipse Foundation-managed server (e.g. the Eclipse packages must be configured to send data to an eclipse.org server). This can be configurable by adopters to send to an alternate server.

Dissemination

Information that may be used to identify individuals or organizations must not be made publicly available.

The retention policy for publicly accessible data must be documented.

Auditing and Approval

Documentation, including a full description of the nature of all information captured by a call-home service, must be publicly accessible.

The implementation of a service that uploads data must be reviewed and approved by the implementing project's Project Management Committee (PMC).

The implementation of a service that uploads potentially private data must be reviewed and approved by the EMO(ED).

Common Mechanism

Reasonable effort must be undertaken to leverage existing mechanisms rather than create new ones.

Back to the top