Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [open-regulatory-compliance] CRA discussion topics and activities

I think a key aspect of this topic to discover whether open source software, for use by others, is in scope of the CRA.

 

This requires guidance on the definition of;

 

Products with digital elements (PDEs), which are defined as software or hardware products and their remote data processing solutions

 

We received some legal advice that creation of the software binaries themselves and hosting them for downloads by others is not in full scope as there is no remote data processing.

 

You may have some obligations as an open-source steward but is not clear what they are if the open-source software itself is not by definition a PDE or intended to support creation of a PDE.

 

So a flowchart of questions whereby you could assess the scope of the CRA on your open-source software would be useful.

 

 

--

Steve Millidge
Founder & CEO

 

From: open-regulatory-compliance <open-regulatory-compliance-bounces@xxxxxxxxxxx> On Behalf Of Dirk-Willem van Gulik via open-regulatory-compliance
Sent: Tuesday, June 18, 2024 11:55 AM
To: Olle E. Johansson <oej@xxxxxxxxxx>
Cc: Dirk-Willem van Gulik <dirkx@xxxxxxxxxxxxxx>; Open Regulatory Compliance Working Group <open-regulatory-compliance@xxxxxxxxxxx>
Subject: Re: [open-regulatory-compliance] CRA discussion topics and activities

 

 

On 18 Jun 2024, at 08:06, Olle E. Johansson <oej@xxxxxxxxxx> wrote:

On 17 Jun 2024, at 15:12, Dirk-Willem van Gulik <dirkx@xxxxxxxxxxxxxx> wrote:

On 17 Jun 2024, at 09:16, Olle E. Johansson via open-regulatory-compliance <open-regulatory-compliance@xxxxxxxxxxx> wrote:



I have been working with Open Source for many years, but not with any project that was hosted by a foundation. It is important to keep the scope wide to cover everything from one-person projects to large industry collaboration - without (as you point out) grading projects.

 

Agreed with the sentiment - but I think there is a fairly specific ‘line in the sand’ here — and that is if you go to Article 3 — that you basically are, by default, someone that places things on the market, a manufacturer — and you need to comply with the whole CRA. 

Regardless if you are a one-person project/company or a mega enterprise. 



To be more clear: Kamailio.org is a project without a legal entity.

 

So historically I think we've found of the years that a group of people acting somewhat in concert is a group - and with that becomes enough of a (non natural person) legal entity to be sued (e.g. in civil courts) or get fined. You simply get those 'alone and in concert' sort of phrases on your summons. So while the CRA may well cause loosely knit groups to formalise somewhat to get clarity - I would totally not expect this to be a fundamental requirement. And certainly not in the parts of Europe where Napoleon pitched his tent at some point.



Someone registred the domain and there is a “management group” of people in various companies. How would CRA handle this? Who places the Kamailio “product” on the market?

 

If we assume Kamaillio is ineeded "placed on the market" - then it is placed on the market by that group.

 

There has also been discussions about the difference between providing source code and binaries. If the project only provide source code - is that “placing a product on the market”? If they provide packages or containers with pre-built binaries - does that make a difference?

 

These are things that we need to help the open source community to sort out.

 

Yes - and I think we have a big 'gap' here. I.e. it is easy for, say, Java or C; but gets quite hairy for _javascript_ and python.

 

There is also another boundary I think which we have here -- the CRA does not really try to have any bearing on, say, an academic paper. I.e. where you publish some source code. 

 

However - it is clear that once you start including a make file; a README for the end user; things that make compile&roll out trivial - you start to cross a line where it is clear that you intend this code to be ran by a (potentially less skilled) third party. And this becomes an even more `blind' party when you go that extra mile to include it in, say, PIP or NPM packaging. Or push it to Maven Central.

 

So there is some gray line which we've really not defined well. And even for advanced products - like Kamaillio that is not so clear to me. I.e. even a very knowledgable person fetching it cannot 'do' much with it right out of the box. It is a semi-finished product.



If you place things on the market for others - you need to comply.

 

And then there is a very narrow area for a very well “behaved” and organisationally quite mature open source steward that can (proof how they) provide sustained, systematic support for the development of open source that is intended for commercial activities*. And have the organisational maturity to govern this capability well. I.e. it does not rely on happenstance or good intentions.

 

But that is a fairly tall order - and quite narrow compared to the default.  Most entities will be the default - and not classified as open source stewards. 

 

Right.

 

Good discussion!

/O

Dw.

 

 

 

*) “open-source software steward means a legal person, other than a manufacturer, that has the purpose or objective of systematically providing support on a sustained basis for the development of specific products with digital elements, qualifying as free and open-source software and intended for commercial activities, and that ensures the viability of those products;

  

   Art 3, paragraph 18a

Dw/


Back to the top