Legal writer at TermsFeed.
On this page
Ever since the General Data Protection Regulation (GDPR) was announced in 2016, the open-source community has been busy. From forum discussions to new compliance code, developers have been doing everything they can to decipher the implications of the GDPR.
Over 90% of online software implements some components of open-source code. This fact in and of itself presents some risks to website security at every level. However, it does not mean that developers and business owners cannot do everything possible to improve open-source security and GDPR compliance within the open-source community.
Start generating the necessary legal agreements for your website or app in minutes with TermsFeed.
We also offer different solutions and tools for your website or app:
- Privacy Consent (Cookie Consent). A cookie consent solution to comply with CCPA/CPRA, GDPR, ePrivacy Directive.
- CCPA/CPRA Opt-Out. A free CCPA/CPRA opt-out solution to allow visitors to opt-out from personalized ads and comply with CCPA/CPRA.
- "I Agree" Checkbox. A free solution to enforce your legal agreements.
The GDPR and Open-Source Projects
The GDPR will affect open-source projects as much as any other online entity. European programmers and users are contributing to and implementing open-source software, making compliance a must.
Here are the most basic GDPR requirements that will apply to almost any business, forum, or developer:
- Transparency: Privacy Policies must be written in clear, plain language and made easily accessible to data subjects (users and customers). Changes to Privacy Policies and any events that affect the personal data of users, such as a data breach, must be reported to data subjects in a timely manner. Data breaches must also be reported to an EU supervisory authority within 72 hours of discovery.
- Accessibility and Consumer Rights: Users must be granted easy access to review, edit or delete their personal information. Upon request, the online entity must provide EU data subjects with a complete copy of their personal information or erase all of the data they have on record for the user in question. Other consumer rights such as the rights to restriction of processing, data portability, withdrawing consent, objection to processing, and objection to automated decision-making must also be honored for EU users.
- Privacy by Design (PbD): Privacy and data security are to be integrated into the design and structure of any software, program, or platform that is used to process consumer data. Privacy by Design is a requirement - not a suggestion.
The above stipulations will apply to any entity that processes EU user data anywhere in the world. Business owners and developers must keep the GDPR in mind when implementing or designing software that may be used to process the personal information of EU residents.
These regulations also apply to open-source projects that European developers contribute to, since most forums and communities must collect some personal data from contributors.
This is the point that has the open-source community feeling nervous. What if a European programmer demands that his contributions to an open-source project be deleted under the right to erasure clause?
We'll address that and other potential issues within this article.
Open-Source Projects and Security Risks
The GDPR is very clear about new expectectations for data security. As described above, PbD is a requirement. The privacy and security of personal information is expected to be a part of an online platform from the design stage. In other words, there's no excuse for negligent or lax security measures when it comes to protecting personal information.
What does this imply for open-source projects? Many security experts express concern about using open-source software because of the security risks it presents. Since the code is public knowledge, hackers may be more likely to find security vulnerabilities in open-source than in other, more confidential types of software. Once a security flaw is found in a piece of open-source code, that flaw may be exploited in any program that contains the same code.
On the other hand, it is almost impossible not to use open-source code to some extent, since this kind of common-knowledge code is used in almost any application or program designed within the last 10 years.
The solution is not to avoid the use of open-source software so much as to practice rigorous risk-prevention practices when it comes to any software, program, or application that collects, processes, or stores user data:
- Pseudonymize and encrypt personal data wherever possible.
- Review and analyze all data processing and security systems or services before implementing them. If you have any current systems in place that have not been reviewed and analyzed for confidentiality, integrity and security, do so as soon as possible.
- Regularly test, assess and evaluate the effectiveness of technical and organizational measures for ensuring security.
- Create a system or process to regularly check all data processing software, applications and services for new updates, patches or necessary maintenance.
Types of OS and GDPR Implications
Open-source software has become an essential component of online software in general. Almost every type of software designed for security, web functionality and advertising utilizes some kind of open-source coding.
This presents several different implications regarding the GDPR:
- Since a security flaw in a common type of open-source code could affect any number of programs and software applications, both programmers and online business owners must remain vigilant and aware of potential security flaws, updating, patching, or replacing software regularly and as needed.
- Open-source designers and programmers will now have no choice but to become educated and mindful of GDPR regulations and how they affect software and security. Consent features, data encryption programs, as well as website functionality in general must be designed with security, transparency, PbD and compliant consent practices in mind.
- It may be necessary for business owners that utilize open-source software to perform a full review of their software, programs, and platforms for online business. Make sure that the existing software is GDPR-compliant or replace it as necessary to ensure proper security and decrease liability.
Open-source website building services like WordPress and Magento are commonplace solutions for businesses all over the world. These services incorporate open-source code that anyone can learn to design and manipulate. While this system presents the same general risks that are associated with all open-source projects, some open-source website providers are leading the way into GDPR Compliance.
WordPress & GDPR Compliance
Although other open-source website providers are following suit, WordPress is leading the way in bolstering a community approach to GDPR compliance within an open-source platform.
Here are a few of the ways that WordPress is addressing the GDPR and its requirements:
- To address the risks of using open-source code, WordPress maintains a security team and set of protocols to constantly monitor and sustain security measures across all WordPress websites. If any vulnerability is identified in their code or software, it is quickly addressed before widespread damage can occur.
- Whether you're a WordPress developer or the owner of a WordPress site, the company is offering a wide range of tools to help the community learn about the GDPR and become compliant. From compliance plugins and educational tools to message boards, the WordPress community is making GDPR compliance a priority.
- For developers in particular, several message boards exist for open-source code questions, ideation and collaborations regarding GDPR compliance.
Open-source projects are a community effort. The open-source community and the forums in which developers and designers collaborate are key to the projects created within them.
For this reason, many developers immediately became alarmed by the GDPR's right to erasure policy.
After all, what will happen to a collaborative coding thread if a European user suddenly decides to erase his account and all of his comments?
There are several ways this could go.
Under the GDPR, forum developers will have no choice but to uphold the GDPR's right to erasure policy.
Technically, comments made by a European user should be erased if that user requests that his personal information and intellectual property be deleted from the forum. Many may ask, but won't this leave holes in the threads?
This leaves forum administrators with two options:
- Delete the user's comments but leave a default message in the gaps left behind stating that this comment has been deleted by the user.
- Leave the user's comments under an anonymous username so as not to lose the integrity of the thread itself, while deleting all other information associated with the user account.
The problem with option number 2 above is that the user could potentially claim the comments are intellectual property whether or not they have been anonymized. This is one point that is not completely clear in the GDPR. It is not possible to determine how supervisory authorities will judge cases such as these. For now, you may prefer to go with option 1 to avoid any potential infringement violations.
Here's an example of how option 1 would look in a forum:
Perhaps a larger concern for open-source projects and their developers is the potential effect of the right of erasure when it comes to existing open-source code.
What happens if a European contributor to an open-source project asks to have his data erased after the project is already well into the development phase? Will his contributions to the project have to be erased as well?
Most experts agree that in the case of open-source code or software that is being developed by a community of contributors, erasure of one user's contributions would seriously compromise the legitimate interest of the project and all those who contributed.
According to GDPR Article 17, the right to erasure will not apply if there are overriding legitimate grounds to retain the information.
The Information Commissioner's Office says that "The legitimate interests can be your own interests or the interests of third parties. They can include commercial interests, individual interests, or broader societal benefits."
In other words, if retaining the data (or in this case, an open-source contribution) can be classified as a legitimate interest that benefits a commercial interest or society in general, than it may be retained despite the user's right to erasure.
When it comes to code or software that has already been contributed to an open-source project and the contribution would significantly alter or damage the project if removed, most experts agree that this qualifies as a legitimate interest.
Once again, it is impossible to predict how GDPR supervisory authorities will judge cases like these in the future and whether open-source projects will be considered a legitimate interest for retaining data. The open-source community will simply have to wait and see.
Open-Source as a Compliance Instrument
One beautiful thing about open-source projects is the supportive environment of the community itself. Since the moment the GDPR became official in 2016, open-source coders, designers and programmers began developing compliance solutions. Now there are already hundreds of open-source solutions, such as:
- Security programs to identify privacy vulnerabilities
- GDPR risk assessment tools
- Programs that grant users easy access to their consumer rights
- Personal data erasure tools
- Consent and consent recording software
Along with the software mentioned above, new open-source solutions for GDPR compliance are being produced every day.