The EU Cyber Resilience Act (CRA) has an exception for non-commercial/open source software. As an exception to the exception, commercial activity seems to explicitly include "the use of personal data". If one uses the GDPR definition of personal data this would seem to include the usual sort of open source community web presence that all projects have, as any web site or mailing list will need to process the IP or email address of users. This web presence will include improving the security, compatibility or interoperability of the software but is likely to not be exclusively that.

(10) In order not to hamper innovation or research, free and open-source software developed or supplied outside the course of a commercial activity should not be covered by this Regulation. This is in particular the case for software, including its source code and modified versions, that is openly shared and freely accessible, usable, modifiable and redistributable. In the context of software, a commercial activity might be characterized not only by charging a price for a product, but also by charging a price for technical support services, by providing a software platform through which the manufacturer monetises other services, or by the use of personal data for reasons other than exclusively for improving the security, compatibility or interoperability of the software.

Assume an open source developer distributed their software on their web site, would the necessary data processing make them commercial under the CRA?

I have selected a concrete example so as to give something to reference, but I could have selected any one of the huge number of open source developers, many of whom have received no direct monetary reward for their contribution.


ASReview LAB. This is an free open source software developed by and for academics at Utrecht University with no direct way to pay or donate to the authors. Many academics would be in a similar situation to these people, having produced software as part of their employment and distributed it privately.

Data controller/processor

Any web site requires at the minimum to know the users IP address to send the requested data. This requires the hosting entity to become a data controller. The requirements can be minimised by reduction in logging, and being careful about what external reprocesses you include, but there is always some requirement.

This particular case is distributed on a web site that is hosted by a private company, probably controlled by the university and which causes users IP address and browser associated PII to be shared with wp.com, googleapis.com and googletagmanager.com. I am fairly sure that under the GDPR they are data controllers/processors.

  • 1
    PII to be shared with wp.com, googleapis.com and googletagmanager.com. - Where do you base that allegation on? A simple HTML site does not do any of these things, it just provides its contents to the user, and often doesn't even know the moment after who called it.
    – Trish
    Commented Dec 4, 2023 at 10:57
  • 2
    @Trish The linked page requests resources from these domains over https. This necessarily requires transfer of the IP address and I think user agent to, in the latter two cases, google. This is PII in GDPR terms. I do not think they forget it, but it does not matter. I am not sure any of this matters, the fact that the server at asreview.nl has to know the users IP address to send the response would seem to meet the definition of commercial in the law quoted.
    – User65535
    Commented Dec 4, 2023 at 11:22
  • Then state so, because basic HTML does just send data from the own server's architecture.
    – Trish
    Commented Dec 4, 2023 at 11:31
  • @Trish While that is strictly true it is rare and heavily discouraged in the real world. This page for example has https requests to multiple google domains as well as gravatar.com. It could not be served without SE becoming a data controller.
    – User65535
    Commented Dec 4, 2023 at 11:40
  • That's why you need to explain technical details.
    – Trish
    Commented Dec 4, 2023 at 12:25

1 Answer 1


A lot to unpack here, so I'm going to go through it layer by layer including the bits you didn't ask about.

Using the requester's IP address to serve a page:

Yes, the IP address may be personal data - so you would be right to treat all of them as if they are. Using the IP address to send a page might be considered a processing activity if you squint a bit, but like knowing the postal address to send an order to it is absolutely essential in order to serve the request. Unlike sending a package to a postal address this processing activity is so transient and is over in under a second.

If I was absolutely pushed to make this a GDPR issue I would claim it under Art 6.1.b - performance of a contract. You want a page from me so in order to serve that I need to know where to send it.

That being said, this function is so fundamental to how the web needs to work I have never seen it declared as such in any data protection declaration, ever. I doubt a judge would even consider it an issue.

Storing the requester's IP address in server logs:

A lot of people do this, and for good reason. As a server administrator you need to know who is asking what of your application for a variety of reasons - maybe a page is misbehaving and you need to see where the 500s are coming from or you are being attacked by a naughty person.

My own server stores these and I claim this under Art 6.1.f - legitimate interest. Yep, an actual legitimate use of legitimate interest.

The balance test here is that the logs are rotated in a reasonable period of time before being wiped. I've checked my own server and out of the box it stores and wipes at the 2 week mark. The GDPR does not define what a 'reasonable' time is; that is left as an exercise to the site owner. It's basically what you can argue for with a straight face in front of a judge. My employer keeps them for 3 months which I consider reasonable for a web business. If I was in finance or a high security application I might consider 6 years to be reasonable - though in that case I would rotate the logs off the live server into a forensic archive after ... 3 months?

Note that if you are going to claim Art 6.1.f for anything then you do need to do a balance test and have it written down somewhere. You can't just carry on with all the old illegal stuff and claim legitimate interest. Also, saying "the user is unlikely to complain" as part of that test is bullshit. I am likely to complain.

First party cookies:

On my personal site I have a dark/light theme selector. In order to keep the user's selection from page to page and over sessions I store a cookie on the user's machine. It literally consists of the name of the theme they selected last. No personal data. Does not need a cookie declaration.

My employer sets the user's session token in local storage - same as a cookie legally. This is personal data but since it is 100% used for the operation of the site and for no other purpose it does not need a cookie declaration.

Third party cookies:

Anything that contains data that can be resolved to a person and is not absolutely essential to the operation of the site requires both a declaration and a specific consent under Art 6.1.a.

This is all the tracking cookies and identifiers that are stored on your local machine. Any site that does not get specific individual consent or puts up a banner saying "we use cookies, continued use of this site accepts that" is acting illegally.

Plus, there is absolutely no legitimate interest whatsoever that any of these tracking companies have if you do not consent to the main cookie. It's all illegal.

The big-G and WP:

Oh, this is a world of pain. It's a no-no. Yes, these services are useful tools for quick web development but since they do something with the user's data? ... do they? ... they might ... you don't know. They need a separate and clear consent from the user under Art 6.1.a.

And when I say that, they each need a separate and clear consent. The big-G and WP need separate check-boxes, each with a declaration of what data is processed and for what purposes. They must be un-checked by default and the site must work without them being checked.

The biggest offender here is Google fonts. A brilliant service to be sure, but since the big-G wants you to use it at the CSS level this all happens before the first word of the first page is delivered. No chance to view the terms of data collection and opt-out. And yes, if your browser calls those domains directly then they are processing your personal data.

Germany is already wise to this and has put on the stomping-boots. Fine for using G-fonts. This is of course correct and is exactly the sort of thing that the GDPR is meant to protect against.

There are 2 ways to handle this safely.

One is for things like font files - static assets. Simply copy the file you want to your own server and point your CSS to your own domain. Suddenly all of your standard data protection terms apply.

The other way around this is if your site back-end makes the call - so the user's browser calls a path on your domain and server and then the back-end gets the resource from the external so that the external is only processing the IP address of your web infrastructure, not the end user's. This is of course assuming that the payload sent to the external does not contain personal data.

Basically, if the user's browser calls these external domains directly without specific informed consent you are looking at a world of pain.

Data controller/processor:

In the example given the academics at the university are the data controllers and the private hosting company is the data processor. This is a fairly standard setup and as long as the host is in the EU they are probably fine.

The upshot of this is that if you want a subject access request or a data deletion request you write to the data controller. If you write to the processor they will simply refer you to the controller.

Personal nit-pick:

You used the term "PII" in the question. This is a term of law in the US but does not exist in the GDPR. We have a slightly different definition under the term "personal data".

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .