Cyber Resilience Act

[Gregor Mückl]

On Wednesday, 16 September 2026 at 12:32:30 UTC, Adam Wilson 
wrote:
> On Wednesday, 16 September 2026 at 09:15:42 UTC, Gregor Mückl 
> wrote:
>> [Snip]
>
> I'm going to be pretty blunt on this but we just went through 
> something similar with LLM usage and the EU.
>
> The DLF is wholly located in the US and thus is subject solely 
> to the jurisdiction of the US. The EU can do exactly nothing to 
> the DLF from a legal standpoint without severing their internet 
> connections with the US (and anywhere else outside EU borders).
>
> If EU persons download and use D, then they are entirely 
> responsible for managing their compliance with EU law. 
> Furthermore, there is nothing the DLF can do legally to help 
> them as DLF has no legal presence in the EU and thus no access 
> to lawyers who could help ensure compliance. This was also 
> requested during the LLM debate and then, as now, the DLF 
> concluded that it had no ability to make such a legal 
> proclamation.
>
> There are no plans to adjust anything. Nor would we be able to 
> enforce any such rules on package maintainers.
>
> All D users in the EU are strongly recommended to seek local 
> counsel in this and other matters. The DLF cannot provide any 
> legal guidance.

Adam, I think that this is not comparable to the LLM situation.

As I understand it, the DLF seems to fall into the category of an 
Open Source Stewards and thus has requirements to fulfill under 
the CRA. This status exempts the DLF from financial penalties and 
any formal certification requirements, but makes it 
(theoretically) subject to other enforcements, including barring 
the software under its stewardship from commercial use in the EU.

If it were to come to that, companies like Auburn Sound, Funkwerk 
or Weka.io would no longer be able to sell products containing D 
code in the EU. Granted, this would be an extreme measure and the 
DLF would have to ignore some sternly worded official letters 
before it comes to that.

The DLF can meet the CRA requirements without formally declaring 
that the measures are for compliance. For strictly open source 
projects, the CRA is about what happens in practice. That seems 
to be a safe route and as I understand it, that part means 
ensuring development best practices:

- Have development processes in place that reduce the risk that 
code changes lead to exploitable software vulnerabilities.
- Have a vulnerability reporting and handling process that deals 
with actual vulnerabilities in a reasonable time

As I see it, the action items for the DLF are, derived from CRA 
Article 24 and Article 14(1), 14(3) and 14(8):

- Lightly document the the exisiting day to day development 
routine (essentially say that code reviews and automated tests 
etc. are quality bars that need to be passed, the tests need to 
stay up to date, etc.)
- Write out a (loose) policy for handling security 
vulnerabilities in DMD and Phobos (GDC should fall under the 
FSF's stewardship, not sure where LDC2 sits). This should 
probably include publishing a list of (known) security 
vulnerabilities/fixes so that developers using D can address 
those in their products.
- Establish a policy to report to ENISA any exploited 
vulnerabilities in DLF run infrastructure. To me, it seems as if 
this is just like the upcoming CISA reporting requirements.
- Actually try to follow these processes in the future.

Most of this is a good thing anyway, CRA compliance or not.

Gregor