Re: recent changes to the CRA address FLOSS community concerns?

2023-12-09 Thread Ilu

Am 09.12.23 um 04:07 schrieb Paul Wise:
>
> Does anyone have any more info about the changes?
>
Yes, I've seen the leaked document. I (and not only I) think NL-labs
outlook is too optimistic. It's also necessary to understand that these
kind of statements (the "update, december 2023") are also part of the
political game of give and take.

The leaked rumor says there have been some improvements, mainly to
adress concerns from big platforms and foundations. Only point 3 from
vote A has been addressed. Small projects (point 4) and commercial
endeavours (point 1), like for example Freexian, are still out in the
rain. The reporting obligations for exploited vulnerabilities (point 2)
were doubled and so even became worse. PLD hasn't even been touched yet.
And all this is still only a proposal which needs to be voted on by
parliament (planned for March 2024).
After the parliamentary decision the executive authorities will have to
decide on the provisions for implementation and enforcement. Upcoming
new standards will play a big role. Lobbying will have to go on and
support from Debian will still be needed.

There is also no way and no necessity to adapt the GA text based on
unofficial rumors since ...

> ... the answer from the EU legislative body will not be to read and
> consider each bullet point we make --- ... the European legislative
> bodies will just see "oh, a biggish project opposes CRA".
(Gunnar Wolf am 25.11.23 um 16:59)

And that's all that's necessary.


Am 09.12.23 um 04:07 schrieb Paul Wise:

Hi all,

On IRC it was mentioned that there are updates to the CRA that may
address the concerns of the FLOSS community.

These blogs have updates at the top:

https://blog.nlnetlabs.nl/open-source-software-vs-the-cyber-resilience-act/

拾
update, december 2023: The concerns expressed in this blog have been
heard and are being addressed in the final text. If you read on, do
so because you are interested in historical context, not because
you seek an understanding of how the CRA will apply in practice.

https://berthub.eu/articles/posts/eu-cra-best-open-source-security/

UPDATE: On December 1st the EU agreed on a version of the Cyber
Resilience Act that appears to have substantially addressed the
concerns in the post below. Further analysis awaits, but do know
that the text that follows is now mostly of historical interest!

Does anyone have any more info about the changes?





Re: CRA and PLD vote status

2023-12-08 Thread Ilu

Am 08.12.23 um 21:13 schrieb Russ Allbery:

Ilu  writes:


CRA + PLD proposals include regulations, that will be detrimental
to FOSS


How about:

 CRA and PLD proposals include regulations detrimental to FOSS



This would be real-english-english? ;-) If it has the same meaning, fine
by me. I've pinged Santiago.



Re: CRA and PLD vote status

2023-12-08 Thread Ilu

Am 08.12.23 um 20:55 schrieb Judit Foglszinger:

The CRA and PLD proposals include regulations, that will be detrimental
to free and open source software


We've never had such a long option, and I'm worried this will break for
some people trying to vote when it gets wrapped to the next line. But it
might also just be fine. There is at least some code that only checks
the first few words or something like that.


regulations in CRA and PLD proposals will be detrimental to FLOSS ?



No. It is important that vote A did not say that ALL of CRA and PLD are
detrimental. Just certain parts of it. It says explicitely: "While a lot
of these regulations seem reasonable,..."

CRA + PLD proposals include regulations, that will be detrimental
to FOSS

Without knowing the character limit I cannot produce a solution, but if
this is still too long you could remove the word "proposals".



Re: CRA and PLD vote status

2023-12-08 Thread Ilu

The CRA and PLD proposals include regulations, that will be detrimental
to free and open source software

Am 08.12.23 um 20:40 schrieb Kurt Roeckx:

The CRA and PLD will be detrimental to open source software




CRA is effectively a "law", was Re: This does not have to be a GR

2023-11-22 Thread Ilu

Since this error comes up again and again on this list:

The CRA is a "Regulation" (look at the long title: "REGULATION OF THE
EUROPEAN PARLIAMENT AND OF THE COUNCIL on horizontal cybersecurity
requirements for products with digital elements and amending Regulation
(EU) 2019/1020"), in effect a law which will be directly in force in all
EU member states.

The PLD is going to be a "Directive" which needs to be adapted by the
member states. Member states can change things within certain limits.
Those limits are not very wide. They cannot change the main content of
the directive.

Am 22.11.23 um 09:35 schrieb Sébastien Villemot:

Le mercredi 22 novembre 2023 à 09:05 +0100, Thomas Goirand a écrit :

Excuse me to insist with vocabulary, but since you've use the word "law"
6 times above: the EU isn't a state or a nation, and doesn't make laws.


Just a minor note: the EU actually issues laws, they’re called
“regulation” in the EU jargon¹. But indeed a “directive” (as in the CRA
case) is something different, and as you say opens up the possibility
of a fight at the national level.


We're talking about "directives", that eventually will be implemented as
laws in each member state. This is a huge difference that make it
possible to fight the CRA at multiple levels. This also mean that the
CRA wording isn't as important as the wording of its implementation as a
law in each member state.

Also, once the directive is passed, it's still theoretically possible to
fight its wording in each state. Seen the other way around: it's
possible that the implementation as a law in each country is worse than
then directive itself, we must pay attention to it (it's probably even
more difficult for us this way, as there will be 27 implementations to
take care of).


¹ https://en.wikipedia.org/wiki/Regulation_(European_Union)





Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"

2023-11-16 Thread Ilu

I mixed up one of the links: The first link under (1) should be
https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-european-cyber-resilience-act
All that talk about cybersecurity at the EU these days got me confused. :-)

I think somebody already noticed and you all probably figured this out
... anyway, sorry about that.

Am 12.11.23 um 16:10 schrieb Santiago Ruano Rincón:

Dear Debian Fellows,

Following the email sent by Ilu to debian-project (Message-ID:
<4b93ed08-f148-4c7f-b172-f967f7de7...@gmx.net>), and as we have
discussed during the MiniDebConf UY 2023 with other Debian Members, I
would like to call for a vote about issuing a Debian public statement regarding
the EU Cyber Resilience Act (CRA) and the Product Liability Directive
(PLD). The CRA is in the final stage in the legislative process in the
EU Parliament, and we think it will impact negatively the Debian
Project, users, developers, companies that rely on Debian, and the FLOSS
community as a whole. Even if the CRA will be probably adopted before
the time the vote ends (if it takes place), we think it is important to
take a public stand about it.

 - GENERAL RESOLUTION STARTS -

 Debian Public Statement about the EU Cyber Resilience Act and the
 Product Liability Directive

 The European Union is currently preparing a regulation "on horizontal
 cybersecurity requirements for products with digital elements" known as
 the Cyber Resilience Act (CRA). It's currently in the final "trilogue"
 phase of the legislative process. The act includes a set of essential
 cybersecurity and vulnerability handling requirements for manufacturers.
 It will require products to be accompanied by information and
 instructions to the user. Manufacturers will need to perform risk
 assessments and produce technical documentation and for critical
 components, have third-party audits conducted. Discoverded security
 issues will have to be reported to European authorities within 24 hours
 (1). The CRA will be followed up by the Product Liability Directive
 (PLD) which will introduce compulsory liability for software. More
 information about the proposed legislation and its consequences in (2).

 While a lot of these regulations seem reasonable, the Debian project
 believes that there are grave problems for Free Software projects
 attached to them. Therefore, the Debian project issues the following
 statement:

 1.  Free Software has always been a gift, freely given to society, to
 take and to use as seen fit, for whatever purpose. Free Software has
 proven to be an asset in our digital age and the proposed EU Cyber
 Resilience Act is going to be detrimental to it.
 a.  It is Debian's goal to "make the best system we can, so that
 free works will be widely distributed and used." Imposing requirements
 such as those proposed in the act makes it legally perilous for others
 to redistribute our works and endangers our commitment to "provide an
 integrated system of high-quality materials _with no legal restrictions_
 that would prevent such uses of the system". (3)

 b.  Knowing whether software is commercial or not isn't feasible,
 neither in Debian nor in most free software projects - we don't track
 people's employment status or history, nor do we check who finances
 upstream projects.

 c.  If upstream projects stop developing for fear of being in the
 scope of CRA and its financial consequences, system security will
 actually get worse instead of better.

 d.  Having to get legal advice before giving a present to society
 will discourage many developers, especially those without a company or
 other organisation supporting them.

 2.  Debian is well known for its security track record through practices
 of responsible disclosure and coordination with upstream developers and
 other Free Software projects. We aim to live up to the commitment made
 in the Social Contract: "We will not hide problems." (3)
 a.  The Free Software community has developed a fine-tuned, well
 working system of responsible disclosure in case of security issues
 which will be overturned by the mandatory reporting to European
 authorities within 24 hours (Art. 11 CRA).

 b.  Debian spends a lot of volunteering time on security issues,
 provides quick security updates and works closely together with upstream
 projects, in coordination with other vendors. To protect its users,
 Debian regularly participates in limited embargos to coordinate fixes to
 security issues so that all other major Linux distributions can also
 have a complete fix when the vulnerability is disclosed.

 c.  Security issue tracking and remediation is intentionally
 decentr

Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"

2023-11-13 Thread Ilu

Marten from NLlabs made a comprehensive flowchart
(https://github.com/maertsen/cra-foss-diagram) that shows the state of
CRA as we presently (a bit of hope included) understand it. It includes
the 4th proposal. Check it out to see where your project possibly might
stand if we are able to hold this position.

Regarding commerciality: The "employment clause" is not in the flowchart
because we are fairly confident that it is not going to be in the final
text. But it does not stay away on its own. A lot of people /
organisations invested a lot of time to get it removed and are
continuosly working to (hopefully) keep it removed. The "donation
clause" is in the flowchart and there's still uncertainty about how it
will be worded in the final text. There is quite some leeway in between
"donations exceeding costs" and no "intention to make a profit". Same
goes, more or less, for the "support clause".

The drafted Debian statement is meant to lent support to those people /
organisations that continue to work on this. The CRA wording can change
anytime either way so we have to keep up engagement until the last minute.

Agreed, the statement does not have to be perfect. It can very well be
more radical or even too radical. That does not hurt, ramping up your
demands and then offering a compromise is the way politics work.

Ilu

Am 13.11.23 um 17:57 schrieb Aigars Mahinovs:

Thanks for the detailed explanation! It had quite a few details that I was
not aware about. Expressing the desired position of Debian and of the
community *is* useful, especially when there are multiple variants of the
legislation that need reconciliation. I was looking at the specific version
that I linked to and the language in that version.

But that position should not be a blanket opposition to the legislation or
containing overbroad statements.

Specific highlights on what activities should not fall into the scope of
the directive would be helpful.

But beyond that, I have not researched this specific issue enough to
recommend specifics.

Peculiarly I am also not against Debian passing the resolution as it stands
because the negotiatiators in the loop of reconciliation *are* able to use
Debians position to argue for better open source conditions, even if the
actual text in the Debian vote *were* far from perfect or accurate. (Which
I am not saying it is)

On Mon, 13 Nov 2023, 17:32 Ilu,  wrote:


At the moment - as the official proposals are worded now - everything
depends on the meaning of the word "commercial". Please note that the
proposals have some examples on this as I mentioned before - but each
proposal is worded differently.

The software is deemed commercial if
- the developer is selling services for it
- developers are employed by a company and can exercise control (= can
merge)
- the project receives donations (depending on how much, how often and
from whom)
- developed by a single organisation or an asymmetric community
(whatever that is, ask your lawyer)
- a single organisation is generating revenues from related use in
business relationships (notice the vague word "related")
- ...

The 3 proposals differ on these examples but they show what lawmakers
have in mind. Their intent is to include every project where a company
is involved in any way. And we all know that without company sponsorship
a lot of projects could not exist. Luca might state that "Mere
employment of a developer is not enough to make an open source software
a commercial product available on the market" but the parliaments
proposal explicitely says the opposite (if the developer has control,
i.e. merge permission). It doesn't help making blanket statements
without reading *all* proposals first.

There is even an inofficial 4th proposal circulating behind closed
doors, that tries to ditch the commercial/non-commercial differentiation
and goes off in a completely different direction (that will target every
project that has a backing organisation - Debian has one). It is all
still in flow.

I cited the Parliaments proposal that says: "Accepting donations without
the intention of making a profit should not count as a commercial
activity, unless such donations are made by commercial entities and are
recurring in nature." which clearly states that recurrent donations by
companies make a software commercial. But Aigar still claims that
"accepting donations does not fall into any of those examples."

What Aigar writes is what we would like to have (and what we are
lobbying for) but not what the EU presently wants and not what's written
in all proposals.

It is not helpful to read legal texts with your own interpretation and
your own wishes in mind. Aigar and Luca are writing what they think is
reasonable (and I mostly agree) and what they gather from one of the
texts (and my hope is that that will be the outcome) but at the moment
that is not the consensus among E

Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"

2023-11-13 Thread Ilu

The discussion on this list hasn't even touched the subject of Art. 11
CRA which is the most worrysome.

Am 13.11.23 um 14:46 schrieb Aigars Mahinovs:
"See:
https://www.eff.org/deeplinks/2023/10/eff-and-other-experts-join-pointing-out-pitfalls-proposed-eu-cyber-resilience-act
Note how the open source language has become very much softened and
nuanced after changes in the proposal removed most of the bugs that
would have affected open source previously."

Nothing mentioned there has been fixed in any of the proposals. And
there's little chance that Art. 11 will get changed in a substantial
way. Law enforcement is pressuring for it. All the more reason to voice
dissent.

Ilu

Am 13.11.23 um 14:46 schrieb Aigars Mahinovs:

On Mon, 13 Nov 2023 at 12:31, Luca Boccassi  wrote:




I am *not* objecting to Debian taking such a vote and expressing the

stance intended. However, I expect that it will be seen by the EU
legislators with mifled amusement, because in their context and
understanding the legislative proposal already contains all the necessary
protections for open source and free software development processes.
However, if a company (say Amazon or MySQL) takes an open source product
and provides a commercial service based on that product, then they are
expected to also provide security updates, vulnerability notifications and
other relevant services to their customers. Which is also an intended
consequence of the legislation.


The EU puts the interests of the consumers and of the community above

commercial interests. Even commercial interests of small businesses.
Allowing small businesses to "pollute" the digital environment with
insecure or unmaintained software just because they are small businesses
makes no sense from a European perspective.

Indeed. This is good legislation, and the parts you quoted make it
exceedingly obvious that the legislators in fact do care about not
hampering open source development. It would be very, very strange and
self-defeating for the project to come out against this, as the next
time around (because if this doesn't pass, something else will -
software security in commercial products is too important to leave the
current far-west as-is) we might not be so lucky.



By now the EU is actually quite used to dealing with volunteer projects and
open source projects in general. So they would not
be surprised in the slightest. And I do not believe it would tarnish the
image of Debian.

A lot of the same comments *were* communicated to EU Commission and EU
Parliament by
IT industry associations, which employ lawyers that track such things and
analyse possible impacts, including towards open
source software, because that is a solid backbone of the modern digital
economy (their words, not mine). And there were
indeed many bugs in earlier revisions of these texts that would have made a
bad impact if implemented as written.

The EU listens *very* well to national IT associations of the member states
for feedback on such matters and open source experts
are very well represented in those. Opinions of IT people from outside of
the EU are usually not considered to be relevant. As in
not adding anything new that the EU experts have not already considered.

Volunteer open source projects are seen as ... not being able to invest
sufficient legal understanding into the topics to be able
to contribute to the discussion meaningfully *and* keep up with the nuanced
changes in the proposals over time.

But umbrella organisations, like EFF are better positioned for this.
See:
https://www.eff.org/deeplinks/2023/10/eff-and-other-experts-join-pointing-out-pitfalls-proposed-eu-cyber-resilience-act
Note how the open source language has become very much softened and nuanced
after changes in the
proposal removed most of the bugs that would have affected open source
previously.





Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"

2023-11-13 Thread Ilu

At the moment - as the official proposals are worded now - everything
depends on the meaning of the word "commercial". Please note that the
proposals have some examples on this as I mentioned before - but each
proposal is worded differently.

The software is deemed commercial if
- the developer is selling services for it
- developers are employed by a company and can exercise control (= can
merge)
- the project receives donations (depending on how much, how often and
from whom)
- developed by a single organisation or an asymmetric community
(whatever that is, ask your lawyer)
- a single organisation is generating revenues from related use in
business relationships (notice the vague word "related")
- ...

The 3 proposals differ on these examples but they show what lawmakers
have in mind. Their intent is to include every project where a company
is involved in any way. And we all know that without company sponsorship
a lot of projects could not exist. Luca might state that "Mere
employment of a developer is not enough to make an open source software
a commercial product available on the market" but the parliaments
proposal explicitely says the opposite (if the developer has control,
i.e. merge permission). It doesn't help making blanket statements
without reading *all* proposals first.

There is even an inofficial 4th proposal circulating behind closed
doors, that tries to ditch the commercial/non-commercial differentiation
and goes off in a completely different direction (that will target every
project that has a backing organisation - Debian has one). It is all
still in flow.

I cited the Parliaments proposal that says: "Accepting donations without
the intention of making a profit should not count as a commercial
activity, unless such donations are made by commercial entities and are
recurring in nature." which clearly states that recurrent donations by
companies make a software commercial. But Aigar still claims that
"accepting donations does not fall into any of those examples."

What Aigar writes is what we would like to have (and what we are
lobbying for) but not what the EU presently wants and not what's written
in all proposals.

It is not helpful to read legal texts with your own interpretation and
your own wishes in mind. Aigar and Luca are writing what they think is
reasonable (and I mostly agree) and what they gather from one of the
texts (and my hope is that that will be the outcome) but at the moment
that is not the consensus among EU legislators. This is why I want
Debian to make a statement. We need to argue against the dangerous
proposals - which are there and I cited some of them. Ignoring the bad
proposals by only reading the stuff that suits you does not help.

My intention with this resolution is not to damn CRA. A lot of things
required by CRA are correct and are done anyway by almost all free
software projects (certainly by Debian). My intention is to give support
to those organisations that are trying to push CRA in the right
direction, notably EDRI and OFE (these are the ones I know of).
"Lobbying" is an integral part of EU law making and we should use it
like everybody else does.

Please also note that cloud services like Azure are not effected by CRA,
that's NIS2. If you are familiar with European legislation you will know
that.

Ilu

Am 12.11.23 um 18:35 schrieb Ilulu:

Am 12.11.23 um 18:09 schrieb Luca Boccassi:
 > We do know whether something is commercial or not though ...

I sincerely doubt that. Just to illustrate this I'm citing a part (only
a part) of one of the regulation drafts which are presently considered
in trilogue.

"(10) Only free and open-source made available on the market in the
course of a commercial activity should be covered by this Regulation.
Whether a free and open-source product has been made available as part
of a commercial activity should be assessed on a product-by-product
basis, looking at both the development model and the supply phase of the
free and open-source product with digital elements.
(10a) For example, a fully decentralised development model, where no
single commercial entity exercises control over what is accepted into
the project’s code base, should be taken as an indication that the
product has been developed in a non-commercial setting. On the other
hand, where free and open source software is developed by a single
organisation or an asymmetric community, where a single organisation is
generating revenues from related use in business relationships, this
should be considered to be a commercial activity. Similarly, where the
main contributors to free and open-source projects are developers
employed by commercial entities and when such developers or the employer
can exercise control as to which modifications are accepted in the code
base, the project should generally be considered to be of a commercial
nature.
(10b) With regards to the supply phase, in the c