Cyber Resilience Act

[Adam Wilson]

On Thursday, 17 September 2026 at 09:15:59 UTC, Gregor Mückl 
wrote:
> 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.

All of this is a very complex way of saying that DLF will have to 
hire EU counsel to write these policies and provide ongoing 
oversight of code changes and responses to security incidents to 
ensure continuing compliance.

DLF nor it's individual contributors have the financial or legal 
capability to do this on their own. The only way this will happen 
is that such counsel and compliance will have to be funded by 
commercial/monied users of D within the EU.

This is why the only realistic path is for individual EU based 
corps to self-certify their usage of D.

The reason that I said that this is similar to LLM situation is 
that in both cases, people are/were asking the DLF and it's 
contributors to shoulder the burden of compliance so that they 
didn't have to.

If you are located in the EU you already need local counsel to 
ensure compliance.