OSMF Licence Working GroupWhite Paper on the Introduction of the General
Data Protection Regulation
DRAFT May 2018

Introduction
On May 25th 2018 the new EU-wide data protection regulation, the General Data Protection
Regulation, short GDPR, will enter in to force. Contrary to the previous data protection
directive, the GDPR does not require national legislation and is directly binding. Lots ofaspects of the GDPR are not new and have been present in national laws in one form or theother, however this is the first time there will be largely identical data protection regulation
throughout the EU and other territories that will need to have comparable regulation (CH, UKetc).
The LWG has been tasked with investigating the impact of the GPDR on the OSMF and thewider OpenStreetMap project and proposing any necessary changes. This however has nottaken part in a vacuum, we have received professional counsel on a number of the aspects
and data protection in OSM has been a hotly debated subject in the context of the national
data protection regulation.
Naturally estimating the impact of the GDPR introduction and consequences before it isactually in force are fraught with the problem that we have to guess how the legislation will
be applied in practice and there is a danger of both over- and underreacting.
This document does not aspire to cover every possible aspect of the GDPR, but just themost relevant points with the largest impact on OpenStreetMap.
Notes:● The handling of OSMF membership data is naturally subject to the GDPR too,however as this is unlikely to have any major operational impact it is not a topic that
we will discuss in this paper.
● This is not an implementation plan, while we will recommend certain changes andactions, we expect the OSMF board to actually decide on following and implementing
them. The LWG will naturally work on the items that are within its scope.

Is the OSMF and OpenStreetMap subject to the GDPR?
Article 3 (​https://gdpr-info.eu/art-3-gdpr/​) states that the GDPR applies to the processing of
personal data by a “controller or a processor” in the EU and to the processing of personal

GDPR Position Paper, Page 1

data of data subjects “who are in the Union” that are offered goods or services “irrespectiveof whether a payment of the data subject is required.”
Assuming that we do process personal data in one form or the other, the conclusion can only
be that the OSMF is subject to the GDPR.
At this point in time, prior to any court decisions, we must further assume that the exceptions
listed in article 2 (2) (​https://gdpr-info.eu/art-2-gdpr/​) do not apply to typical services provided
by community members (for example http://hdyc.neis-one.org/)

Does the OSMF process ‘personal data’?
In article 4 (​https://gdpr-info.eu/art-4-gdpr/​) the GDPR defines personal data as:‘personal data’ means any information relating to an identified or identifiable natural person(‘data subject’); an identifiable natural person is one who can be identified, directly or
indirectly, in particular by reference to an identifier such as a name, an identification number,
location data, an online identifier or to one or more factors specific to the physical,
physiological, genetic, mental, economic, cultural or social identity of that natural person;
The OSMF collects and distributes a vast amount of data, see Appendix A for an overview. It
is clear that the email addresses stored for each account are personal data, but does that
apply to our geodata too?
While our geodata in itself should simply reflect what is on the ground, the metadata
associated with the contributions, for example the time stamps, change set tags (for example
locale, device and editor application information), can be associated with an “​identifiable
natural person”​ via at least the user id and the display name. For example it is possible togenerate contribution profiles (when in the day somebody contributed to OSM) from theinformation.
Further it is clearly possible, with the metadata itself, to develop a fingerprint that would allow
one to associate individual contributions with a specific person for many of our contributors
even if user id and display name are not the person’s real name. For example, a user might
use the same display name on OSM as on social media, and the social media account might
identify the user’s real name, allowing a searcher to link the mapper’s real identity to theircontributions.
An additional point to consider is that in low contributor density areas just the geographic
location of the contributions may be enough to associate them with one individual andhistorically it has been shown (during the licence change) that the first edit of a contributor isvery often an indication of their place of residence.
The GDPR does not require that we can do any of the above directly or a complete
association of all contributions to their creators, as a result we believe it is clear that ourgeodata as currently distributed can be considered to contain personal data.
GDPR Position Paper, Page 2

Do we process the personal data? The GDPR defines (​https://gdpr-info.eu/art-4-gdpr/​)‘processing’ means any operation or set of operations which is performed on personal dataor on sets of personal data, whether or not by automated means, such as collection,
recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation,use, disclosure by transmission, dissemination or otherwise making available, alignment or
combination, restriction, erasure or destruction;
It is clear that we do multiple of the above and therefore clearly are processing personal
data.

Does the OSMF process personal data “lawfully”?
In article 5 (​https://gdpr-info.eu/art-5-gdpr/​) the GDPR defines the principles for processing
personal data, (1) a) states in respect to personal data that it should beprocessed lawfully, fairly and in a transparent manner in relation to the data subject(‘lawfulness, fairness and transparency’);And in article 6 (​https://gdpr-info.eu/art-6-gdpr/​) goes on to define “Lawfulness ofprocessing”, relevant clauses for OSM are(1) a) the data subject has given consent to the processing of his or her personal datafor one or more specific purposes;(1) b) processing is necessary for the performance of a contract to which the data
subject is party or in order to take steps at the request of the data subject prior toentering into a contract;(1) c) adequate, relevant and limited to what is necessary in relation to the purposes forwhich they are processed (‘data minimisation’);and(1) f) processing is necessary for purposes of legitimate interests pursued by thecontroller or a third party, except where such interests are overridden by the interests
or fundamental rights and freedoms of the data subject which require protection of
personal data, in particular where the data subject is a child.
To process personal data lawfully we need to decide on what legal basis we are undertaking
it, and inform the data subjects accordingly as required by Art 12, 13 and 14(​https://gdpr-info.eu/art-12-gdpr/​ ff).

Does the OSMF have “consent” to process personal data?
In article 4 (​https://gdpr-info.eu/art-4-gdpr/​) the GDPR defines consent as:‘consent’ of the data subject means any freely given, specific, informed and unambiguous
indication of the data subject’s wishes by which he or she, by a statement or by a clear
GDPR Position Paper, Page 3

affirmative action, signifies agreement to the processing of personal data relating to him orher;
The contractual arrangements between OpenStreetMap contributors and the OSMF are the“Contributor Terms” (​https://wiki.osmfoundation.org/wiki/Licence/Contributor_Terms​). The
terms defines in the first paragraph its scope as...contributing data and/or any other content (collectively, “Contents”) to the geo-database of
the OpenStreetMap project (the “Project”).This contributor agreement (the “Agreement”) is
made between you (“You”) and The OpenStreetMap Foundation (“OSMF”) and clarifies theintellectual property rights in any Contents that You choose to submit to the Project in thisuser account.
It specifically limits its applicability to contributions to the geo-database and its scope tointellectual property rights.
In article 2 “Rights Granted” it further says
You hereby grant to OSMF a worldwide, royalty-free, non-exclusive, perpetual, irrevocable
licence to do any act that is restricted by copyright, database right or any related right overanything within the Contents, whether in the original medium or any other.
Again clarifying that it only concerns itself with intellectual property rights.
During the sign up process (a new user creating an account on openstreetmap.org) we
display a link to the OSMF privacy policy (see ​the privacy policy​ and Appendix A) , the newuser is however not required to explicitly indicate agreement to any of the sections nor to theterms overall. The policy currently does not elaborate on our data distribution via the
database dumps and only mentions what is available via the website, it further does notmake clear that most information on the website and API is available to the general public,
not just only to logged in users. We cannot derive consent and from that lawfulness of theprocessing from agreement to the terms of the privacy policy as it stands.

Is it necessary to process personal data to fulfill the obligations from theContributor Terms?
Certain types of processing personal data could be required, but not all of the types ofprocessing that OSMF currently engages in. For example, the Contributor Terms state that
the OSMF will, if it distributes the data, only do so on specific (open) terms and a procedurethat must be followed to change those terms. Thus, distribution of any personal data thatmight be in geodata (e.g., an account’s first edit is often near their home address), but not
metadata (when the edit was made, with which editor and similar) would be necessary.
Now, even if not explicitly stated, we believe that it is fair to assume that it is implicit insigning up for an OSM account and agreeing to the Contributing Terms that an account iscreated and the means are provided to actually contribute to the project, and that consent is
GDPR Position Paper, Page 4

given to store display name and e-mail address that are provided during that process.
However, nothing explicitly states that personal data in metadata is distributed with our
geo-data, and a person who does not fully investigate OSMF’s APIs and data dumps would
not necessarily understand this.
In summary we currently lack both the explicit consent and contractual obligations to process
the personal data lawfully in all of the current ways we do so. The Contributor Terms andPrivacy Policy could be updated to explicitly describe and require affirmative consent to alldata processing.

Data minimisation
The requirements in (1) c) further requires for lawfulness that the processing is ​“limited towhat is necessary in relation to the purposes for which they are processed” ​ (dataminimization principle). Distribution of metadata is clearly not necessary for the purpose ofcreating and distributing free geo-data and it is fair to assume that the overwhelming majority
of consumers of OSM data simply discard any such information during processing.

Does the OSMF have other lawful grounds for processing personal
data?
Processing geodata that contains personal data might be considered necessary for thecreation and maintenance of a public world map. Further, metadata such as userids,changesets, and timestamps are necessary to detect, prevent, and undo vandalism or otherdamaging or disruptive edits. Even emails, stored privately, are necessary in order to contact
mappers about any issues in support of this overall goal. User names and diaries, which areprovided voluntarily, also aid in communications on these issues.
The recitals appear to support such an interpretation (​https://gdpr-info.eu/recitals/no-47/​).
For example, ​“The processing of personal data strictly necessary for the purposes of
preventing fraud also constitutes a legitimate interest of the data controller concerned.”(Even directed marketing is considered a legitimate interest.)
The recital does caution that: “At any rate the existence of a legitimate interest would needcareful assessment including whether a data subject can reasonably expect at the time andin the context of the collection of the personal data that processing for that purpose may takeplace.” It should be expected that contributions containing personal data would beprocessed, as well as user names, diary entries, and emails would be processed, evenabsent an explicit consent form addressing GDPR rights from IP rights.
Further, Recital 50 (​https://gdpr-info.eu/recitals/no-50/​) states that ​“processing of personal
data for purposes other than those for which the personal data were initially collected shouldbe allowed only where the processing is compatible with the purposes for which the personal
data were initially collected.” ​Specifically, “[f]urther processing for archiving purposes in the
public interest, scientific or historical research purposes or statistical purposes should beconsidered to be compatible lawful processing operations.”
GDPR Position Paper, Page 5

These additional lawful processing grounds appear available as OSMF is very unlikely toprocess any “sensitive personal data” (defined as “personal data revealing racial or ethnic
origin, political opinions, religious or philosophical beliefs, or trade union membership, andthe processing of genetic data, biometric data for the purpose of uniquely identifying anatural person, data concerning health or data concerning a natural person’s sex life orsexual orientation”).
This could likely support our internal data retention and potentially the forwarding tocommunity services for vandalism detection, for example OSMCha.

Does the OSMF operate ‘information society services’?
In conjunction with article 8 (​https://gdpr-info.eu/art-8-gdpr/​) we need to determine if the
OSMF operates ‘information society services’. The term is not defined in the GDPR but is inother EU regulation, however not in one document, from the summary here
https://www.mpo.cz/en/e-communications-and-postal-services/postal-services/information-so
ciety-services/the-term-information-society-service--102673/
we can follow yes that we provide ‘information society services’ and that the requirements inarticle 8 apply on top of the general lawfulness requirements.

Do the restrictions on services to children apply to OSM?
Article 8 (​https://gdpr-info.eu/art-8-gdpr/​) adds additional restrictions to when explicit consent
can be given for lawful processing of personal data. In particular it requires that the data
subject must be over a minimum age (16 in the GDPR but can be lowered to 13 by member
states) or ​that consent is given or authorised by the holder of parental responsibility over thechild.
As the OSMF clearly operates ‘information society services’ and article 8 does not have any
exceptions based on the nature or kind of such services, it is obvious that the additional
restrictions in article 8 would apply to the OSMF if we base the lawfulness of processing
personal data on consent. It has been suggested to us that in such a scenario we would
need to remove data (that is delete the account and associated metadata) from under 16
year olds if we in one way or another gain knowledge of the fact..

How does the ‘Right to erasure (right to be forgotten)’ apply?
The GDPR defines multiple rights of the data subject, the most well known is the ‘right to beforgotten’, laid out in article (​https://gdpr-info.eu/art-17-gdpr/​). In the context of OSM themost likely reason for this to be invoked is documented in(1) b) the data subject withdraws consent on which the processing is based according topoint (a) of​ ​Article 6​(1), or point (a) of​ ​Article 9(​ 2), and where there is no other legal
ground for the processing;

GDPR Position Paper, Page 6

Our current practice is on account deletion to remove the display name, diary entries, diary
comments and access to the users profile page, but to retain the e-mail address (which isnever public) internally. Contributed geodata continues to be distributed.
It should be noted that there are no conditions for revoking consent and personal data has tobe removed unless there is an ​other legal ground for processing. ​For geodata and metadata
related to data integrity, legitimate interests lawful grounds may apply, as discussed above.
For other personal data, essentially this is the account specific data that we do not distribute(the e-mail address for example), we could argue again the the OSMF has a legitimate
interest to retain such data for vandalism and similar protection.
We believe that this will continue to be defendable under the GDPR, however while this isreflected in new data dumps and the API, it is not in dumps prior to the account removal.
According to advice received, we should apply this retroactively to the existing dumps andwe should also remove any metadata linking contributions to a specific account (at least uid
and display name).
The GDPR extends these obligations to third parties in(2) ​Where the controller has made the personal data public and is obliged pursuant
to paragraph 1 to erase the personal data, the controller, taking account of available
technology and the cost of implementation, shall take reasonable steps, including
technical measures, to inform controllers which are processing the personal data thatthe data subject has requested the erasure by such controllers of any links to, or
copy or replication of, those personal data​.
Which impacts any community service or other service that has consumed OSM data
dumps.
There is no obligation that account deletion be automatized or/and immediate. However froma practical point of view we should be interested in keeping the workload generated bydeletions (currently roughly 1 per day) to a minimum.

How does the ‘Right to data portability’ apply?
An often overlooked aspect of the GDPR and consequences for OSM is the Right to data
portability in article 20 (​https://gdpr-info.eu/art-20-gdpr/​).
Diary entries, GPX traces and similar content would seem to be largely unproblematic andwe could simply provide a mechanism to download the content in a suitable format. However
the actual geo-data contributions are more difficult, as there may be residual contributions
and associated rights when existing data has been edited. It may be enough to provide a
download option in osmChange format of all changesets and stipulate that any existing datain the download is subject to the ODbL.
GDPR Position Paper, Page 7

This right is only relevant is the processing of personal data is based on consent, if ourprocessing is based on “legitimate interests” the right does not apply.

What are the obligations on OSMF operations?
The GDPR defines in article 4 (​https://gdpr-info.eu/art-4-gdpr/​) 7. to 10. roles that are
relevant to the processing of personal data
7.​ ‘controller’ means the natural or legal person, public authority, agency or otherbody which, alone or jointly with others, determines the purposes and means of theprocessing of personal data;...
8.​ ‘processor’ means a natural or legal person, public authority, agency or other bodywhich processes personal data on behalf of the controller;
9.​ ‘recipient’ means a natural or legal person, public authority, agency or another
body, to which the personal data are disclosed, whether a third party or not….
10.​ third party’ means a natural or legal person, public authority, agency or bodyother than the data subject, controller, processor and persons who, under the direct
authority of the controller or processor, are authorised to process personal data;
The OSMF is clearly in the role of a controller, our volunteer operations staff might beconsidered part of the OSMF for purposes of the GDPR, Third party projects, community andcommercial, could be handled as contractually bound processors, or independent
controllers. As requiring a data processing agreement (DPA) would seem to be a quite
onerous requirement, particularly for community projects, the later model seems to bepreferable.
Controllers are required (see below) to notify data subjects of their processing, as this would
again be a rather high hurdle for small projects, the OSMF could facilitate this by providing
the required information from the controllers to the data subjects on sign up (and later
updates)..
Chapter 4 of the GPDR (​https://gdpr-info.eu/chapter-4/​) lays out in detail the obligations ofcontrollers and processors.
Points of note:● The controller needs to be able to demonstrate that the processing of personal data
is in accordance with the GDPR. This implies at least documenting which data weprocess and how (​https://gdpr-info.eu/art-30-gdpr/​)● The controller is only allowed to use a processor that provides suitable guarantees
that the processing meets the requirements of the GDPR and requires a contractual
arrangement between controller and processor.

GDPR Position Paper, Page 8●●Processors and controllers not based in the EU need to designate a representative in
the EU.
The controller and the processors have obligations to notify the authorities and thedata subject in the case of a personal data breach (in the case of OSM this would forexample be access to the e-mail addresses).

Restrictions on transfer of personal data to third countries
Chapter 5 (​https://gdpr-info.eu/chapter-5/​) restricts the transfer of personal data to non-EU
countries, there is no reason to believe that these do not apply to personal data processedby the OSMF.. Article 49 (1) a) however allows such transfer in the absence of adequacy
determinations by the EU, if
the data subject has explicitly consented to the proposed transfer, after having been
informed of the possible risks of such transfers for the data subject due to theabsence of an adequacy decision and appropriate safeguards;
It is unlikely that a blanket consent for any transfer destinations can be obtained based on
the above clause and it would seem best to restrict any transfers to countries where anadequacy determination has been made. The GDPR allows data transfers to countries withexisting arrangements between the EU, most notably the USA to continue till a based GDPR
adequacy determination has been made.

Recommendations
In making these recommendations we have tried to balance impact on the OSM communityand operations against both the legal and ethical privacy requirements that we believe exist.
In particular we try to avoid complexity by making what data is available to the general public
as privacy issue free as possible, but allowing bona fide community members andresearchers complete access with a minimum of additional hassle. We have further tried not
to tie the hands of operations and developers to exactly how these recommendations shouldbe implemented.
While not a panacea we believe restricting access to the more problematic aspects of ourdata to logged in users that have agreed to a ToU document at least partially fulfills therequirement that we control what processing happens.
We suggest that our rationale why our processing of personal data is lawful should be based
on “legitimate interests” (Art 5.(1) f) ​https://gdpr-info.eu/art-5-gdpr/​). While this allows us tocircumvent some of the more problematic impacts of the GDPR on OSM, it does require us
to make determinations “​where such interests are overridden by the interests or
fundamental rights and freedoms of the data subject which require protection of personaldata, in particular where the data subject is a child”.

GDPR Position Paper, Page 9

We recommend to the OSMF board that the following actions and tasks are considered andimplemented:

1. Complete privacy policy
The privacy policy will need to outline our rationale why our processing is lawful andcover the required information as set out in Art 13 (​https://gdpr-info.eu/art-13-gdpr/​).
We will need to review all systems operated under the OSMF umbrella forcompliance with the policy (for example that they are not running google analytics,
gravatar or similar).

2. Reduce data availability as proposed in Appendix B
Most consumers of OSM data do not need the metadata and discard it anyway. By
removing essentially all metadata from general public distribution we greatly simplify
the situation.
●●●●

The geo-data “dumps” and “diffs” without the metadata can be continued tobe distributed to anonymous consumers as is.
Applications that don’t require the metadata can still use read-only API
endpoints.
Account deletion only has to concern itself with our database and API and asmall number of data consumers that will be known.
We apply the data-minimisation principle..

3. Add Terms of Use for the API and website for logged in users thatcovers the privacy aspects
We need to lay down the rules as to what can be done with the data and what not:● Editing the data will continue as is● Scraping the website and the API for local storage should be explicitly
disallowed● Using the data for user and contribution profiling will either require a dataprocessing agreement (and a similar agreement for research) or the the OSM
data consumer needs to operate as an independent data controller (seebelow)..

4. Confirm consent to privacy terms and new ToU for existing users,
Reasoning: we need to have the same legal framework in place for all users.

5. Create framework for supporting third party controllers
Entities receiving full data (that is including metadata) are expected to operate as
independent controllers. Such controllers are expected to inform the data subjects of
their processing as outlined in Art.14 (​https://gdpr-info.eu/art-14-gdpr/​) . The OSMF
can provide such controller supplied information to the users on sign up making the
GDPR Position Paper, Page 10

logistics of doing so far simpler for the controllers. This might be accompanied by aconfidentiality agreement between the controller and the OSMF.

6. Provide deleted users service (list of uids) to controllers
Part of the above mentioned agreements will be an obligation to remove relevant
data for deleted users, the simplest approach to enable this is to provide suchprocessors with a regularly updated list of uids or a corresponding API endpoint.

7. Create confidentiality agreements for all persons that have access torestricted data
This mainly concerns operations volunteers and DWG members that have access to
non-public data (e-mail addresses etc), and to user data post deletion.

Impact Assessment
After the changes due to the licence change in 2012, adapting to the GDPR will be thebiggest change in policies and procedures since “modern” (post 2007) OpenStreetMap hasexisted. It is important to gauge what impact the suggested changes will have both on
OpenStreetMap data consumers and contributors.
In the end we need to balance the risk of not following the GDPR to the letter with both theeffort needed to do so and the impact of the changes on the stakeholders in
OpenStreetMap.

The general Public
People not further involved with the OpenStreetMap project will typically consume OSM datain the form of maps, search results, POI information and routing instructions. None of thiswould be impacted by the proposed changes (and no user metadata is required to generated
such products), except that it can be argued that at least low precision “last modified” dates
should be available for both historic data processing and quality assurance. .

OpenStreetMap Contributors
The main impact is that to access metadata (which user added/edited data, when the edit
was made and so on) the contributors will need to be logged on and have agreed to a set of
ToU.

Service Providers
Entities providing services based on OSM data will not need to change (with the exception ofpotential updates to their toolchains) anything as long as they are not doing metadata based
quality assurance or validation.

GDPR Position Paper, Page 11

QA and Data Validation Projects
Projects that actually use the metadata will be most impacted, however they would be,
regardless of whatever model we suggest, subject to the GDPR and will need to adapt
accordingly. They will need to provide the information as outlined in Art. 14(​https://gdpr-info.eu/art-14-gdpr/​) to all OSM contributors and implement their own privacy
policies and mechanisms.

GDPR Position Paper, Page 12

Appendix A -The OSMF and Personal Data
20170914 Simon Poole
The document is intended for use in briefing of third parties, providing a tally of personal dataor potentially personal data the OSMF utilizes and distributes and any known open questions
with respect to the introduction of the GDPR in 2018.

OpenStreetMap
OpenStreetMap, short OSM, is a global volunteer project to collect and survey geo-data anddistribute the results as open data. Starting in 2004 it has grown to be the go-to alternative
data-provider in a market dominated by small number of commercial providers (TomTom,
Here and as a service provider google) Coverage is particularly good in German speaking
Europe and in many developing nations OSM is the only player with any notable data at all.
As of fall 2017, nearly 1’000’000 contributors have added to the OSM dataset and maps andapplications based on OSM are widely used by small and large organisations of any kind,from purely commercial to humanitarian, worldwide. Notable large users of OSM data
include Apple, the American Red Cross, Médecins sans
Frontières, Facebook and many more.
It is important to note, that despite the name OpenStreetMap, we consider the data ourprimary product and we do not engage in providing apps and services to the general public
in more than an incidental fashion. For example the US based company Mapbox is acommercial service provider re-using OSM data to provide services to companies worldwide.
This is a different operating philosophy compared to Wikipedia which is the best known
project OSM is similar to.
The main OSM website is at http://openstreetmap.org/

The OpenStreetMap Foundation
The OpenStreetMap Foundation, short OSMF, is a small non-profit organisation based in the
UK that formally operates the infrastructure behind the OpenStreetMap projectand distributes and licenses OpenStreetMap data to third parties.
The OSMF has roughly 500 members and a annual budget of £100’000. Membership dues,
donations and profits from the annual global conference “State of the Map” are the main
sources of income.

GDPR Position Paper, Page 13

While the OSMF has an important formal role, it does not govern the project in any
conventional sense of the word. Essentially all work is carried out by volunteers either bydirectly working on the data, taking part in OSMF working groups, or developing software..
More information on the OSMF can be found at http://osmfoundation.org/

The OpenStreetMap Licence
Between 2004 and 2012 the data collected by OSM was distributed on CC BY-SA 2.0 terms,
in 2012 the licence was changed to the Open Database Licence (ODbL) see
https://opendatacommons.org/licenses/odbl/
The change included a switch from a model in which every contributor licensed their data
individually to a model in which the OSMF licenses that data to third parties. To facilitate that
contributors have to agree to a set of contributor terms
https://wiki.osmfoundation.org/wiki/Licence/Contributor_Terms​ which not only includes the
grant of the necessary rights to the OSMF it binds the OSMF to only distribute thecontributions on the terms laid out in the agreement.

OSM User Accounts
To contribute to OSM an user account on openstreetmap.org is required. Contributors needto supply a display name (can be changed at any time), a working e-mail address (can bechanged at any time) and agree to the contributor terms mentioned above.
We do not require any further user information. The e-mail address is used internally by oursystems to send notifications and is only accessible to system administrators.
Users have access to a simple publicly accessible “user page” on which they can add some
information about themselves, can create diary entries, can add a home location to theiraccount, can add a picture or enable gravatar support and have access to the OSM
messaging system. However none of this is required. It should be noted that users can, andsometimes do, choose their personal name as a display name.
There are currently roughly 4.2 million user accounts of which 1 million have contributed tothe project. Users can have multiple accounts which is typically the case if they are engaging
in special projects for which they want to keep the contributions separate from their regularwork.
Simply consuming services and data provided by OSM does not, in general, require an
account.

Data distributed to the public by the OSMF

GDPR Position Paper, Page 14

The data distributed by the OSMF contains, besides geometry and properties of thegeographic objects and so called Notes (short geo-referenced texts that point out an issue
or similar at a specific location), metadata including● A “changeset” id that links together all contributions that were made in one editing“session”● A timestamp● The computer-generated numeric ID of the user account● The display name of the user account● Metadata associated with the editing session, editing program used, comments by
the user, sources used, imagery used and other fields. None of this is mandatory andsome is added automatically by the editing programs, sometimes undetectable by theusers. The OSMF does not have control over the editing programs.
● Comments made by the user on other users changesets and notes.
Separately from the above:● GPS generated traces that the users have uploaded and allowed to be publicly
provided (metadata availability can be set by user uploading the traces)● A map rendering of the above traces, currently this is immutable in the sense that
traces cannot be removed from the rendering.
All of the data is provided in the form of “dumps” chronologically created and named files
containing all of the respective data at the time of creation. These files are normally final andare not changed after they have been stored. Many of these dumps are regularly
downloaded and utilized by third parties.
The sum of data contributions, user name, GPX traces and other provided information
currently makes it easy to fingerprint individuals and associate at least editing patterns if not
more with such an individual.
We currently do not have explicit terms of use covering how user metadata can be utilizedthat is retrieved from the data dumps. Our data distribution licence does not limit use in anyway.
The distribution location is ​http://planet.openstreetmap.org/​.

Data available publicly via the API
The OSMF provides access to the data via an API. While this is primarily intended for use forediting and adding data for our contributors, the data retrieval functions of the API can beaccessed by anybody.
The data publicly accessible by the API includes the information in the dumps plus
● Account created data
● Flag indicating if the contributor terms were agreed to● Number of changesets/edit sessions, which is also derivable from dumps
GDPR Position Paper, Page 15

●
●
●
●
●
●
●

Number of uploaded GPS traces
Number of blocks received total (a block stops the user from logging in)
Number of active blocks
Number of blocks issued, only in the case of user information for “moderator” users
Gravatar (if the user has turned on gravatar support, which is highly problematic froma privacy point of view) or picture linkRole (empty except for administrators/moderators)
Any user provided description

The non-editing functions of the API are available for programmatic access by all comers.
We currently do not have explicit terms of use covering how user metadata can be utilizedthat is retrieved via the API.

Data available publicly via the openstreetmap.org website
A small amount of information is only available via the OSM website.
All of the already mentioned data plus
● User home location marker (if set), only visible to logged-in users● Diary entries (available via RSS feed too) and comments● Block messages
We currently do not have terms of use for the website including use of user metadata
obtained from it.

Non-public data
The systems operated by the OSMF generate log files in various formats that are retained
for an unspecified amount of time and are only available to system administrators. The data
includes Internet protocol addresses and website navigation data.
Further e-mail addresses supplied during the sign up process are only visible to the systemadministrators.
Other notable internal user related data stored in the database● List of “friends”● Flag indicating if user considers their contributions public domain● Received and sent personal messages
All the above data is only used for internal and security purposes and is not distributed tothird parties.

GDPR Position Paper, Page 16

Privacy policy
The OSMF privacy policy can be found at ​http://wiki.osmfoundation.org/wiki/Privacy_Policy​ alink to the document is provided during the sign-up process (see below) however the newuser does not have to explicitly acknowledge acceptance of it.

GDPR Position Paper, Page 17

OSMF Member Data
The OSMF holds information on its members, roughly 420 members according to the UK
Companies Act, 240 associate members and 20 corporate members.
The membership data for normal users (​https://join.osmfoundation.org/normal-membership/​)
is entered in the the membership register, is not removed from that if membership isterminated and can, in principle, be inspected by anybody (this is all a legal requirement of
the companies act).
Associate member submit far less data and access to this data is set out in the articles ofassociation, not in the companies act.
Details on the membership classes are presented before signup here
https://join.osmfoundation.org/
Membership data, including some payment-related information, can be accessed by themembers of the OSMF “Membership Working Group” that have signed a confidentiality
agreement with the foundation.

ExamplesHDYC
HDYC (http://hdyc.neis-one.org/) is a privately operated website (“How Did You Contribute”)
displaying information on individual OSM contributors. All information displayed is obtained
from publicly available OSM data. Since 2017 the site requires an OSM login to access,previously it was completely public. Earlier versions included more detail, for example
information on which time of day contributions were being made.

GDPR Position Paper, Page 18

GDPR Position Paper, Page 19

OSMCha
OSMCha ​https://osmcha.mapbox.com/​ is a privately operated, public (logins are only
required to set filters and to review changesets), quality control site that displays edits in realtime and allows access to user metadata.

Specific Questions“Right to be forgotten”/Account deletion
Is retention ofa) Contributed datab) E-mail address (only available to administrators) possible going forward?
Deleting an account does not affect the above mentioned data dumps, is that problematic?
Changing the display name does not affect already generated and archived data dumps, isthat problematic?
Currently “deleting” an account is a manual process that requires sending e-mail to a systemadministrator, does that have to be possible directly by the user? Note currently we delete a
couple of 100 accounts each year.

GDPR Position Paper, Page 20

Children
As mentioned above we currently completely ignore the issue of if contributors are children
or not, is there a requirement that we actually ask for age information (which naturally in turnwould lead to other complications) so that we can apply the age limits in Art. 8? While we
don't specifically target children as a contributor group we do now and then have schoolclasses participating and other organised groups (scouts etc), so we probably do actually
have younger than 16 kids with accounts.

Sign-up process
Do we need to get explicit agreement to the privacy policy?

Privacy policy
Are there important point missing?
Are all of the provisions legally sound with the new regime?

Operational questions
All the operational “staff” are currently volunteers and are not employed by the OSMF,
should we be taking any specific steps wrt data protection legislation to formalize some
aspects of the relationship? Current requirements for joinig the the sysadmin grouphttps://operations.osmfoundation.org/policies/sysadmin-membership/

GDPR Position Paper, Page 21

Appendix B - Detailed proposed data availability and accessRed ​= access removed
WebsitepublicWebsitelogged inAPIpublicAPIlogged inDumps
and diffs
publicDumps
and diffs
with ToU

Geo data(without
metadata)

X

X

X

X

X

X

Display name

X

X

X

X

X

X

UID

X

X

X

X

X

X

TIme stamps

X (1)

X

X (1)

X

X (1)

X

Changeset id

X

X

X

X

X

X

Changeset tags

X

X

X

X

X

X

Changeset
comments

X

X

X

X

X

X

Notes (text anddiscussion
without
metadata)

X (4)

X

X (4)

X

X

X

GPX traces(without
metadata andaccording to theprivacy setting)

X (4)

X

X (4)

X

X

X

Account
creation date

X

X

X

X

Item

Ops only

Deletedonaccount
removal

X(3)

X(3)

GDPR Position Paper, Page 22

Contributor
terms flag

X

X

X

X

X

X(3)

Number ofchangesets

X

X

X

X

Uploaded GPS
traces count

X

X

X

X

X

X

X

X(3)

X

X

X

X(3)

X

X

X

X(3)

Number ofblocks received

Number ofactive blocks

X

Number ofblocks issued

Blockmessages

X

X

Gravatar /
Image

X

X

Role

User provided
description

X

Home location

X(3)

X

X

X

X

X

X

X

X

X(3)

X

X(3)

Diary entries

X

X

X

Diary comments

X

X

X

GDPR Position Paper, Page 23

e-mailX(1) It can be argued that completely removing timestamps causes a significant loss offunctionality and information, for example when an object was last updated. This
could be partially rectified by simply reducing the granularity of the timestamps inpublicly available data, for example by only displaying dates.
(2) User edits only in osmChange format(3) This data is potentially useful for combating vandalism and should only be removed
from the public API and website.
(4) In the website UI access to this data is via the users profile page which naturally
de-anonymizes the data.

GDPR Position Paper, Page 24