Does GDPR affect individual contributor license agreements for opensource projects? I am wondering, if GDPR affects OSS projects that have an Individual Contributor's Licensing Agreement / (a.k.a. ICLA, or just CLA), such as for example Apache 2.0. The gathered information when signing one of these (name, address, phone, e-mail) as a code contributor is not shared with third-parties, but is required in order to avoid copyright claims.
Short answer: No Long Answer: Presuming the CLA informs the Data Subject of what information is gathered (pretty self explanatory, the Data Subject is putting the information in the CLA) and what it will be used for. Then by them submitting a CLA they are giving consent to what the CLA states. As Shown below a CLA can qualify under all 6 lawful reasons for processing personal data. One of the reasons is a stretch, another a possible stretch, the rest apply. Keep in mind though if the CLA does not or did not specify what the information was to be used for then those documents are in violation of the GDPR. In the case where a CLA was signed prior to May 25th 2018 you have two choices. Destroy the documents or retrieve consent for the information obtained in those documents for the purpose of the license to avoid copyright claims. Consent must be informed per Recital 32 of the GDPR. A CLA is a contract. Thus falls under the following: Article 6: Section 1a: the data subject has given consent to the processing of his or her personal data for one or more specific purposes; Presuming the personal data is only used for what the agreement states it will be used for. Section 1b: 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 to entering into a contract; You entered a contract which should state what the information is needed for. Thus that information is necessary for the performance of that said contract. Section 1c: processing is necessary for compliance with a legal obligation to which the controller is subject; Technically the controller is the natural person or entity responsible for the OS Project. The license attached to the OS Project is their choice. Depending on the chosen license and the CLAs. They may be able to modify that license (re-release under a new license). And thus they aren't technically legally obligated themselves to follow the copyright license themselves. However if the chosen license doesn't give them ownership of the contributed code nor does the CLAs; the license itself requires CLAs, then the information gathered in a CLA is a legal obligation. Though you would be hard pressed to fall into this category. Section 1d: processing is necessary in order to protect the vital interests of the data subject or of another natural person; Only applies if the OS Project is led by a natural person and not an entity. Section 1e: processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller; Possibly, might be stretching it there. Though I personally believe an OS Project is generally in the public interest. Section 1f: processing is necessary for the purposes of the legitimate interests pursued by the controller or by 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. The legitimate interest here would be the copyright license of the OS Project.
Per the comment, the applicable license term seems to be Licensee agrees to maintain in confidence the source code version of the Licensed Software by using at least the same physical and other security measures as Licensee uses for its own confidential technical information and documentation, but in no case less than reasonable measures. So if your own code is on a physically unconnected thumbprint-secured blah blah blah computer deep in a mountain, with files encrypted, so must theirs be. If yours is stored in &quot;the cloud&quot; with decent password protection, theirs must be as well. This seems to describe your Github use (I don't have any knowledge of the degree of hackability of private Github repositories). The legal judgment as to whether this is &quot;reasonably secure&quot; is based on whether a prudent person would know that it is practical to gain unauthorized access. Protecting a file with the password &quot;password&quot; would probably be found to be unreasonably insecure.
Yes, this violates the GDPR if the user is in Europe. Data which is tied to a personal device can be tied to the person who owns it. From "What Is Personal Data" by the UK Information Commissioner's Office (ICO) (emphasis added): Personal data is information that relates to an identified or identifiable individual. What identifies an individual could be as simple as a name or a number or could include other identifiers such as an IP address or a cookie identifier, or other factors. If it is possible to identify an individual directly from the information you are processing, then that information may be personal data. If you cannot directly identify an individual from that information, then you need to consider whether the individual is still identifiable. You should take into account the information you are processing together with all the means reasonably likely to be used by either you or any other person to identify that individual. The bit about "all means reasonably likely" in the last bullet includes the kind of de-anonymisation tactics described in the NYT article. There are 6 lawful bases for data processing in the GDPR, and all processing must fall under at least one of them. (a) Consent: the individual has given clear consent for you to process their personal data for a specific purpose. (b) Contract: the processing is necessary for a contract you have with the individual, or because they have asked you to take specific steps before entering into a contract. (c) Legal obligation: the processing is necessary for you to comply with the law (not including contractual obligations). (d) Vital interests: the processing is necessary to protect someone’s life. (e) Public task: the processing is necessary for you to perform a task in the public interest or for your official functions, and the task or function has a clear basis in law. (f) Legitimate interests: the processing is necessary for your legitimate interests or the legitimate interests of a third party, unless there is a good reason to protect the individual’s personal data which overrides those legitimate interests. (This cannot apply if you are a public authority processing data to perform your official tasks.) Selling data isn't covered by any of the others, so consent must be obtained. Permission must be clear and positive, and you cannot predicate delivery of a service on the processing of data that isn't necessary for that service. So for instance you cannot say "You can use this service as long as we are allowed to collect and sell your data" because selling the data isn't necessary to the provision of the service. From "Consent" by the ICO: Consent requires a positive opt-in. Don’t use pre-ticked boxes or any other method of default consent. Explicit consent requires a very clear and specific statement of consent. Keep your consent requests separate from other terms and conditions. Be specific and ‘granular’ so that you get separate consent for separate things. Vague or blanket consent is not enough. [...] Avoid making consent to processing a precondition of a service. This applies to any processing of data about individuals within the EU, so just being an American company doesn't get you a free pass to ignore the GDPR if your app gets used by Europeans. The "Legitimate interests" basis is more problematic, in that the company collecting the data has to conduct a vague "balancing test" to determine if this basis applies. For direct marketing the ICO has written this, which says that direct marketing may be a legitimate interest, especially if you can show that the user has expressed interest in such adverts. For instance a location service which promises to tell you about nearby special offers would fall into this category. Against this, the impact on the user's privacy has to be considered, and location data is "special category data" because it can reveal medical information (e.g. hospital attendance) or religious affiliation (e.g. which church you go to). So unless the relationship between the recorded location data and the service is very direct its not going to pass the balancing test. The company would also need to distinguish between knowing the current location and keeping a record of historical locations; the two need separate justification. And of course nothing about this covers the sale of the data; this is considering a company which sells advertising space in it's app, not one that sells the data itself.
This issue touches upon two distinct GDPR rights: Art 15 right to access: you have a right to receive a copy of all personal data concerning you that are undergoing processing (including storage). Access may only be denied where this would “adversely affect the rights and freedoms of others.” Art 20 right to data portability: if processing is being carried out by automated means, and processing is based on certain legal bases (consent or contract, but not legitimate interest), then you have a right to receive a copy of your personal data in a machine-readable format, for personal data that you have provided to the data controller. Whereas the right to access is fairly straightforward, the right to data portability applies under much more narrow conditions. Basically, it's a right that you can download any data that you've uploaded so that you can move to a different service. Google Takeout is primarily concerned with your right to data portability, and provides your data in a machine-readable format. Any photos that you've uploaded to Google Photos, you'll be able to download. Thus, it could be technically compliant to exclude information that they've inferred about your personal data, such as image-recognition results. Such results would still be personal data under the GDPR definition of the consent, and would be covered by your right to access. Google might argue that you already have access to this data through the web interface. In my opinion the GDPR clearly requires the data controller to provide a “copy”, i.e. the data in some durable form – not merely access through a web interface. Whereas your question is specifically about Google, the same issue applies to other services as well. E.g. Ruben Verborgh has an interesting blog series on trying to get access to all their data from Facebook, though unsuccessful so far. Similar to your scenario, Facebook offers a download for personal data but does not include all personal data in this download. In one of the documents provided by Facebook in the course of the exchange, they note that they allow access to photo tags through the web interface, but do not include this in downloaded data – without providing further justification.
GDPR is not a blanket ban on the handling of personal data. It is a set of guidelines when and how data may be processed and stored. Documenting the compliance with a deletion request is one of many purposes for which some data may be retained after a deletion request. Others would be past contractual obligations, legal documentation requirements, and even a balance of 'legitimate interests' of the processors and the data subjects. The processor might be able to argue that fraud/abuse prevention is such a legitimate interest. What if I want to create a service that does let users enter their friends' email addresses, and send those friends an email invitation to the service? Get a specialist lawyer on staff who can check your exact business processes. A web site like this cannot possibly give you a full explanation of the pitfalls.
The cookie consent requirement comes from the ePrivacy Directive, not from the GDPR. While the GDPR defines consent, cookie consent is required regardless of whether the cookie actually contains personal data. Instead, it says we can access information stored on an end users device under the following circumstances. Technical access to the information is used for the sole purpose of performing a transmission over a network, e.g. using a browser cache. Accessing the information is strictly necessary for providing a service explicitly requested by the user, e.g. session cookies or a consent-declined cookie. The user has given consent to the access, where consent is defined by the GDPR (freely given, informed, specific, …). The first scenario likely doesn't apply because your cookies aren't likely to be “technical storage or access” in the sense of ePrivacy, and because the tracking cookies wouldn't be used for the sole purpose of carrying out a transmission. The second scenario doesn't apply because tracking cookies are not strictly necessary to interact with the webshop, as evidenced by the possibility to opt out. The service explicitly requested by the user is the webshop or website, not the A/B testing. This only leaves consent as possible grounds for storing or accessing information on the user's device. It is already the storing or access that is covered by ePrivacy, not only later use as a persistent identifier. Your suggestion – to first set the cookie and then delete it if it shouldn't have been set – is more compliant than many set-ups I've seen, but is still technically non-compliant. It is also likely to fail in practice under non-ideal network conditions: if the request to see whether GDPR applies times out, or if the user closes the browser tab before the cookie will be deleted, the tracking cookie will remain without consent. I would instead suggest to consider the following points. It seems that by itself, Optimizely Web cannot be used in a compliant manner since it doesn't provide sufficient control over how cookies are managed. Thus, you should avoid loading such tracking scripts unless consent has been given, or unless this processing falls outside of EU/UK law. Currently, you defer loading of tracking scripts until you know if you have to ask for consent. This can be avoided if you always ask for consent :) This can also be avoided if you load the tracking scripts from a server that can independently determine whether the requests comes from the EU. For non-EU requests and for users with opt-in, the server can return the original tracking scripts. Otherwise, the server returns a dummy script. This server can be independent from your website's hosting. By combining the jurisdiction decision with the loading of the script, one roundtrip is saved and latency is reduced. Finally, no one is forcing you to use Shopify, and ePrivacy/GDPR is not required to accommodate their limitations. You do have different choices: use Shopify, at the cost of slow pages and limited A/B tests use a different A/B test provider that can be used without setting cookies use edge computing to do stuff in between of the browser and the original server use a different webshop platform ignore EU laws Well, one of them is clearly unethical. But you do have choices, and which choice you take is a business decision. Slow pageloads and consent banners are likely costing you conversions, but Shopify might be providing massive value that outweighs all that.
Yes, there would still be an obligation to comply with erasure requests – if the data subject can be identified, and if the GDPR applies. This is a case for Art 11 GDPR: processing which does not require identification. The pastebin site is not required to collect identifying info just in order to facilitate later deletion. If the site is unable to identify the data subjects, then the data subject rights (like access, rectification, erasure, restriction, or data portability) do not apply. Other rights like the right to be informed and the right to object do remain, though. But if the data subject provides sufficient additional information that makes it possible to identify their records, then the data subject rights apply again. In practice, this is likely going to mean that anyone with access to a paste will be able to request deletion, since the site would have no ability to verify the identity of the data subject beyond the information in the paste. None of this absolves the site from implementing appropriate technical and organizational measures to ensure the security of this data. Even though the pastes might not be directly identifying, they are personal data and are far from anonymous. Common practices like numbering pastes with a sequential ID or showing recent pastes on a homepage have to be viewed critically. My go-to recommendation is to assign a cryptographically random UUIDv4 ID to the post, so that it is practically impossible for anyone to find the paste unless they were given a link by the uploader. Your idea to delete pastes after a fairly short retention period is also good. This helps with security, and it is in line with the GDPR's data minimization and storage limitation principles: data may only be kept as long as necessary for its purpose. On the other hand, quick deletion might not be in line with the purpose of these pastes – it all depends on context. You mention that this is an US-based site. If so, there's a question whether GDPR would even apply. GDPR will apply per Art 3(2) if the data controller is offering its services to people who are in Europe. Here, “offering” does not mean mere availability of the website, but that the data controller intends the service to be used by such people, in particular if the service is somehow targeted or marketed to such people.
Since you are from Europe, GDPR applies to all your processing activities per Art 3(1) GDPR, regardless of where the users are located. If you would like to avoid GDPR compliance, you would have to manage your business from abroad so that you no longer have an European establishment, and would have to avoid offering your services to people who are in Europe. So let's assume that you have no European establishment. Then, GDPR can only apply per Art 3(2) to those processing activities that relate to offering goods or services to people who are in Europe. For determining this, IP-based geolocation is indeed common. Very likely, you do not need consent for this. GDPR does not require consent for everything, just a legal basis. There are six potential legal bases in Art 6(1), though the relevant ones are consent, necessity for performing a contract, legal obligations, and necessity for a legitimate interest. For things like security checks, it would be common to claim a legitimate interest. Complying with GDPR can hurt revenue. However, data subjects have a right to data protection, but you do not have a right to a particular business model. Similarly, paying taxes can &quot;hurt revenue&quot;, but it's not really optional. If your business model can't deal with GDPR compliance (or with taxes), it might not be a sound business model. In Europe, many newspapers have since moved from advertising-only to a consent-or-pay model. That is, the user is given a choice: You can read articles without tracking if you buy a subscription. You can access articles for free if you consent to tracking. The legality of this is hotly debated. In principle, such an approach can be compliant, but the details are problematic, for example that you can only buy subscriptions rather than individual articles, and that these subscriptions are often orders of magnitude more expensive than what would be earned through ads. But this might actually be easier to solve for a mobile application than for a website, due to the availability of in-app payment and micropayment infrastructure. In any case, GDPR limits how much you can &quot;encourage&quot; consent – per Art 7(4), you cannot make access to your service conditional on consent. There must be a way to use your app without consenting to anything, unless that consent is actually necessary for the app to work. For example, consenting to camera access is necessary for a QR code reader app to work. It is extremely unlikely that ads would be necessary in this sense. Users also must not suffer detriment for declining or withdrawing consent. From this, the EDPB has developed the concept of &quot;permissible incentive&quot; in their guidelines on consent. In this post, &quot;Europe&quot; means EU/EEA/UK as appropriate.