CRA and Django

Django Internals
1

:waving_hand: there’s been a few of us keeping tabs on the EU’s Cyber Resilience Act (CRA) and what it means for Django. I thought now would be a good time to open a forum thread about this, see who else might be keeping an eye on it, and might be interested to help the DSF navigate this?

Just want to be upfront that this isn’t for everyone. It’s a highly technical topic and there is a lot of confusion about what it means for “open source stewards” and “manufacturers” of open source software. This thread is primarily for people who have spent time investigating this and can make sense of the ramification on their own. And for transparency that this is something we need to do.

What’s the CRA

In short it’s a new regulation that creates new requirements in the realm of cybersecurity from providers of technology. A lot of those requirements are likely things Django / the DSF does already because we’re world-class like that – taking security vulnerability reports, very specific processes about disclosure, etc.

As such, I think it’s fair to say for us the CRA can be an opportunity to further mature our processes and further build trust in Django as secure software, possibly fundraise towards that. Rather than a legal liability.

What it means for Django

High level – we’re still in the process of figuring that out, understanding which new roles in the CRA apply to us, and what we should do. We don’t want to do original research on this. We’re just not as well equipped for that as others. Instead, we’re:

  • Following the work of the Open Regulatory Compliance Working Group, part of the Eclipse Foundation, with other open source stakeholders involved as members (for example the PSF). I don’t think we have capacity to join this ourselves.
  • Following more specific projects like OCCTET
  • Researching applicable standards that we could reuse for our own processes

When I say “we are”, again it’s something that only 2-3 people have awareness of (cc @marco-silva0000), so it’s really from afar.

What it means in practice

Thank you to Vladimir Slavov for supporting us with more specific guidance on what we could likely do to meet CRA requirements!

TL;DR; is SBOM :slight_smile: Here’s what we should consider:

What’s next

  • If you’re working in this space on the tech / legal / compliance side and could help us with this, please let us know here?
  • If you have clear thoughts on what Django / the DSF should do, tell us!
  • If you see clear ways in which we could get sponsorship(s) to do this work, share!
2

Hi @thibaudcolas,

while you say,

We don’t want to do original research on this.

we should so the ground work to check if this regulation even applies to Django or rather the DSF in the first place.

The regulation says in (15), before article 1:

This Regulation applies to economic operators only in relation to products with digital elements made available on the market, hence supplied for distribution or use on the Union market in the course of a commercial activity. Supply in the course of a commercial activity might be characterised not only by charging a price for a product with digital elements, but also by charging a price for technical support services where this does not serve only the recuperation of actual costs, by an intention to monetise, for instance by providing a software platform through which the manufacturer monetises other services, by requiring as a condition for use the processing of personal data for reasons other than exclusively for improving the security, compatibility or interoperability of the software, or by accepting donations exceeding the costs associated with the design, development and provision of a product with digital elements. Accepting donations without the intention of making a profit should not be considered to be
a commercial activity.

Which essentially means, if the DSF makes money from Django, by providing commercial services or through donations with the goal of making a profit, yes, the CRA applies to the DSF. But as long as the only income of the DSF are donations without the intention of making a profit, the regulation does not apply. So, as long as the DSF is a non-profit, which I think it still is (that’s the 501(c)(3) thing, right?) we do not need to worry about the CRA.

That being said, if there are things we can do to help organizations simplify their paperwork, yes, those things can be done and they can be funded by donations, as long as the donations don’t exceed the “design, development and provision of a product with digital elements”.

All changes on this topic should be happening through the regular contribution processes, though. We should not implement something, “because of the CRA”, as that argument doesn’t hold, but because we as a community believe in its benefits and usefulness.

My 2¢.

3

@MarkusH the groundwork is done, Django is definitely in scope of the CRA. I’d like this thread to avoid any original interpretation of the legal text if possible. There are better organizations / forums for that, very few people here are equipped to look at all the articles (73), annexes, recitals (130), and have followed the last 18 months’ worth of industry - EC collab on clarifications.

The CRA is relevant for us for two reasons: 1. the DSF would likely be an “open source steward”. 2. There’d be lots of “manufacturers” amongst our downstream users. If you’d like to do more research yourself, check out the ORCWG FAQ and all the linked issues.

All changes on this topic should be happening through the regular contribution processes, though. We should not implement something, “because of the CRA”, as that argument doesn’t hold, but because we as a community believe in its benefits and usefulness.

Yes the goal is to use the regular contribution process, though the problem (and why I’m opening this thread) is that very few of our contributors have the relevant expertise. I hope our community believes in the benefits and usefulness of the CRA. From my research it’s sometimes onerous but pretty good stuff.

4

Hi @thibaudcolas ,

It was a pleasure chatting with you at EuroPython on this topic.

I’m not sure if SBOMs would be the only focus, this is something you would have to check on your end; however, if we consider Django as being upstream of manufacturers, then SBOMs could be something worthwhile looking into.

In case you need help setting up an ORT instance, please let me know. I also know some of the people behind OCCTET and could help you link up with them, if that would be useful for you.

1 Like