May I publish source code of my project without notifications about use of personal data and cookies and not break laws during it? I have created the demo software project (frontend and backend modules) for manage staff. I want to publish source code of the project on GitHub. I know that according to GPDR page must have notification about using cookies and of personal data. If project is running on server it can collect personal data and use cookies, but source code doesn't do this. Source code have no any notification about cookies and personal data collecting. I am not planning to run publish server with my project. If someone will use my code under opensource license it can create any notifications. May I publish source code of my project without notifications about use of personal data and cookies and not break laws during it?
I don't think you would be responsible for whether your software is used in a GDPR-compliant manner. For GDPR compliance, it is important who the data controller is. The data controller is whoever determines the purposes and means of a personal data processing activity, i.e. the why and how. The data controller alone is responsible for their GDPR compliance. When a data controller wants to run some software, it's the data controller's responsibility to ensure that this software is used in a GDPR-compliant manner (or possibly not at all). Determining purposes and means of processing When someone other than the developer runs a software, the question is who might be a controller: you as the developer, they as the operator, or neither, or both? The operator is clearly a controller: they determine a purpose for data processing (e.g. to manage staff) and have determined means to perform that processing (e.g. to use the software). The developer may or may not be a controller. Clearly, the developer has made choices about how the processing of personal data will be performed, i.e. has determined some means of processing. E.g. the developer has developed a particular architecture, chosen a way to store personal data, and has implemented some security measures. But determining some means is not sufficient to be a data controller, see discussion below. Has the developer participated in determining the purposes of processing? I think this will depend on the specific functionality provided by the software in question. If the software just does what it says and processes the data for the operator's purposes, everything should be fine. If the software also processes data for the developer's purposes, that developer might be a controller. For example, if analytics or crash reports are collected by the developer, that would be a clear indication that the developer would be a (joint) controller. So depending on specific factors, the operator might be the sole controller, or the operator and developer might be joint controllers. Essential vs non-essential means What about the developer determining some means? When does this make the developer a joint controller? The EDPB has created a theory of essential vs non-essential means: 40. As regards the determination of means, a distinction can be made between essential and non-essential means. “Essential means” are traditionally and inherently reserved to the controller. While non-essential means can also be determined by the processor, essential means are to be determined by the controller. “Essential means” are means that are closely linked to the purpose and the scope of the processing, such as the type of personal data which are processed (“which data shall be processed?”), the duration of the processing (“for how long shall they be processed?”), the categories of recipients (“who shall have access to them?”) and the categories of data subjects (“whose personal data are being processed?”). Together with the purpose of processing, the essential means are also closely linked to the question of whether the processing is lawful, necessary and proportionate. “Non-essential means” concern more practical aspects of implementation, such as the choice for a particular type of hard- or software or the detailed security measures which may be left to the processor to decide on. – EDPB guidelines 07/2020 on the concepts of controller and processor in the GDPR, added formatting for legibility Looking through that list of essential means, some might be determined by a software's developer, but I wouldn't expect this to be the case for this kind of open source software. types of personal data: the software certainly sets a framework for processing specific kinds of personal data, e.g. by providing database fields for names, contact details, and schedules. But ultimately, the developer does not control which data is actually collected and filled into those fields – the developer does not cause specific kinds of personal data to be processed with the system. duration of processing: unless the software is programmed with a fixed retention schedule, it should be impossible to argue that the developer has determined the duration of processing. Even then, it would also be the operator who has determined this duration to be appropriate, rather than editing the open-source software to change the duration. But typically, no such retention schedule is enforced, and retention would depend solely on the operator (who can use an admin interface or a database console to erase old records). categories of recipients: typically, the developer does not determine to whom the data in the system will be given. But if the system sends data to third parties by itself, this might change. For example, if the system is pre-configured to store data in an existing cloud database instance, or to a specific analytics server, the developer might be acting as a controller. Here, good software engineering and legal risk minimization coincide. Best practices for web apps state that account credentials and connection strings shouldn't be hardcoded or committed to a repository, and should instead be provided externally (e.g. via environment variables). categories of data subjects: this depends solely on how the software is used. The developer has no way to determine whose data the operator will enter into the system. If the developer isn't a controller, might they be a data processor instead? In a GDPR context, a data processor is whoever processes personal data on behalf of a controller. The developer is clearly not a processor in this scenario because both the “processing” and “on behalf” criteria fail. The developer has no access to the data in the operator's instance, so cannot process the personal data. There is no direct relationship between the developer and the operator. The operator has not delegated authority to the developer so that the developer would be acting “on behalf” of the operator. There is a legal relationship between the two roles (the developer has licensed the software to the operator) but that is entirely irrelevant in a data protection context. The GDPR isn't directly about cookies While the GDPR does cover how personal data can be processed with cookies, the famous “cookie law” is actually separate: those cookie consent requirements stem from EU member state's implementations of the ePrivacy directive. Instead of talking about “controllers”, ePrivacy has concepts such as the “provider of an information society service”. While this role fits perfectly to an operator/provider who runs a web app in a publicly accessible manner, it does not fit a developer who merely makes some source code available. Is the developer even subject to the GDPR? The GDPR can only apply to data controllers and processor who process personal data. As discussed above, the developer is probably not processing personal data at all. Even if the developer were processing personal data, it is questionable if GDPR would apply assuming the developer has no “establishment” in the EU (e.g. an office). Then, the question would be whether those processing activities are either related to offering goods or services to data subjects in Europe, or whether the processing activities involve monitoring the behavior of people who are physically in Europe. Unless the developer is actively targeting European businesses with marketing for this software, the answer is very likely “no”. Could the operator sue the developer for providing software that isn't GDPR-compliant? The operator can sue anyone for any reason, but is probably not going to win. As discussed, the operator is a data controller. They are responsible for ensuring that their purposes and means are GDPR-compliant. That involves selecting suitable software. The data controller would be neglecting their own responsibilities if they just download some random software and start feeding personal data into it. Things might be different if the operator specifically advertises GDPR compliance features but you're not going to do that. It's also worth noting that common open source licenses like the Apache License 2.0 include a warranty and liability disclaimer. To which degree they protect the developer ultimately depends on national laws, but they make it difficult for the operator to make a legal argument that they're entitled to a GDPR-compliant product. See also the related question: Do warranty disclaimers in software licenses carry any legal weight? What can you do? First, don't worry too much. Given how much bad software there is on the internet, surprisingly few developer get into legal trouble for writing source code that's buggy or missing some features. Second, consider choosing a license for your project that includes a reasonable warranty/liability disclaimer. Third, make the state of your project clear in your README file. If someone knows that this is alpha-quality software and that no compliance features were implemented, it's their own fault if they actually use that software.
It is absolutely not the case that Providers are not allowed to keep PII without consent. Article 6 of the GDPR identifies six possible lawful bases for processing personal information. These are: (a) the data subject has given consent ... (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 to entering into a contract; (c) processing is necessary for compliance with a legal obligation to which the controller is subject; (d) processing is necessary in order to protect the vital interests of the data subject or of another natural person; (e) 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; (f) 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. Point (f) of the first subparagraph shall not apply to processing carried out by public authorities in the performance of their tasks. If a person requests services from an online service provider, basis (b) will apply, at least to some information. If there is evidence of criminal activity, basis (c) may well apply, as it also will for much routine record keeping. Any in many such cases, basis (e) or (f) will also apply. In short, article 6 does not create a &quot;haven for online criminals/hackers&quot;. In a comment on another answer the OP writes: The offender has the right to not be identifiable and he can't be denied this right That is simply not correct. Nothing in the GDPR says anything of the sort. It is true that consent may not be forced, but if a user requests a service that service may require the user to identify him- or herself. For example, one cannot order physical goods without giving a name and a shipping address. And the provider may retain PI and even PII when it has a &quot;legitimate interest&quot; in doing so, although if challenged it must justify that legitimate interest.
Does GDPR apply if my web app stores personal data on the user's phone only? No. If you are not processing Personally Identifiable Information (PII) then the GDPR does not apply to you. This is what a web browser does when it asks to remember your username and password for this web site. You are providing a tool, the user is using that tool to process their own data. I do offer to back up the user's personal data At this point you are processing the users PII, and the GDPR does apply to you. Even though you do not have enough information to identify an individual, as it can be used with other information to identify an individual it is PII. From the ICO: Can we identify an individual indirectly from the information we have (together with other available information)? Even if you may need additional information to be able to identify someone, they may still be identifiable. That additional information may be information you already hold, or it may be information that you need to obtain from another source. When considering whether individuals can be identified, you may have to assess the means that could be used by an interested and sufficiently determined person.
I wrote a letter to the Eclipse Foundation. The consultant pointed me to section 5 in their FAQ. My case falls under the term "linking". He warned that he isn't a lawyer, but offered the following short answer: The Eclipse Foundation does not consider linking with EPL content to be a derivative work and so you are not required to disclose your source code.
No, you're not required to sign any contracts. But since you're offering a service, you do have to manage some compliance tasks. You are a data controller under the UK GDPR, regardless of whether you have a company. This brings with it various compliance requirements. For example, you MUST post a privacy notice in accordance with Art 13 GDPR that explains how you process user's information. You must sign data processing agreements with your data processors, such as your server providers. And you should reconsider transfers of data to the US, since such transfers are illegal or at least quite questionable in the wake of the 2020 Schrems II ruling. You now have prospective users that are asking you for an Art 28 data processing agreement (DPA). These are likely other organizations that are data controllers of their own. For them to use your browser extension, they either need to find a legal basis that allows them to share their user's/employee's data with you (controller to controller transfer), or they need you to act as their data processor (controller to processor transfer). The third alternative is not to use your plugin at all. Of these, a C2P arrangement is most convenient for these other orgs, but involves a bit of paperwork to set up first. If you want to act as their processor, this doesn't mean you'd have to create a company (though a corporation might be very desirable as a liability shield). Being a processor means that you're contractually bound to only use the personal data as instructed by the controller, and not for your own purposes. This restricts what you can do, and has some special compliance requirements. For example, you cannot engage new subprocessors without your controller's approval. However, processor status can also be convenient for you because you're not responsible for interacting with the controller's data subjects, e.g. you're not responsible for handling their data subject access requests. Note that it's possible to simultaneously be a controller for some users, and a processor for others. E.g. Google Docs is offered directly to users as a B2C product so that Google is a controller, but also as a B2B product as Google Workspace, where Google acts as a data processor. Personally, I'd rather not sign any contracts unless I'm doing it as a business, and adequately compensated for providing this service. GDPR is only one compliance aspect out of many, making it unwise to offer a SaaS product as a hobby. For example, copying other people's web content has copyright implications… A potential alternative for some of the organizations asking you might be to make it possible for them to self-host your backend, so that they are not required to rely on you as a data processor. If you have no plans to commercialize your software, making it Open Source could be a solution. But you're in no way required to do that if you don't want to.
If you aren't including those libraries, then yes because it's entirely your own work. If you are publishing those libraries, then no because their licenses will limit how you can do that. GPL's and MIT's main features are restricting how you can distribute software that includes the licensed code, and they don't allow the &quot;do whatever you want&quot; of public domain.
There are a number of misconceptions in this question. Firstly, the regulatory environment did not drastically change when the GDPR came into force in 2018. Previously, each EU member state had its own laws implementing the 95/46/EC Data Protection Directive. The GDPR harmonizes these laws, and replaces them with a single EU-wide law. However, the GDPR is largely identical with the DPD. In particular, both laws have the same definition of a controller. Secondly, the data controller is not a position to be designated, like a Data Protection Officer would be. A controller is whoever – alone or jointly with others – determines the purposes and means of processing of personal data. Whether someone can decide the purposes of processing is a matter of fact, not a matter of formalities. There can be more than one controller. Most likely, the institution hosting the research group is the controller. For individual researchers, the important aspect would be to demonstrate that they've fully complied with their institution's procedures at all times – that they acted as agents of the controller, not as controllers of their own. The institution might have a more difficult time mounting the defense if its technical and organizational measures were inadequate. For example, keeping an unattended server running for five years without security updates borders on gross negligence – so there should have been a procedure so that each system has a clear point of contact who is responsible for administrating the system. The controller should also have inventoried its systems and processing activities at the latest in preparation of GDPR, e.g. for an Art 30 record of processing activities. Your question suggests that no one could be at fault because no one did anything, but inaction and failure to fulfil responsibilities can also be a violation of law. If the institution wasn't convinced that this server was GDPR-compliant, the correct approach would have been to shut the server down, not to continue the processing of personal data. Of course, the controller may be able to demonstrate that this breach of GDPR was very minor, for example because the personal data was pseudonymized and because other technical measures (like firewalls) would have prevented unauthorized access.
Simply use a cookie to store consent. First consider the opposite. If a user does not agree to store cookies, a cookie is the only way to remember this, as you want to avoid a new pop-up on every page-load. Because this use of a cookie is functional, you don't need permission to store that cookie. You seem have the impression that you have to prove towards the ICO if someone has provided consent. However I think it would be sufficient if you can demonstrate how your website works technically. In particular whether consent is handled properly. You might need to create screenshots or a screencast to do so. Add new proof after each major update of your website. Storing consent server-side would violate the data minimization principle of the GDPR I think. In particular because you would need to do something to be able to identify users. That would violate Art. 11(1) GDPR: If the purposes for which a controller processes personal data do not or do no longer require the identification of a data subject by the controller, the controller shall not be obliged to maintain, acquire or process additional information in order to identify the data subject for the sole purpose of complying with this Regulation. Notice it is possible to configure google analytics in a way so you don't need any consent. See my answer to this question. Just IP anonymization is not sufficient.