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

[Santiago Ruano Rincón]

Dear Debian Fellows,

Following the email sent by Ilu to debian-project (Message-ID:
<4b93ed08-f148-4c7f...@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
decentralized and distributed. The reporting of security issues to
ENISA and the intended propagation to other authorities and national
administrations would collect all software vulnerabilities in one place,
greatly increasing the risk of leaking information about vulnerabilities
to threat actors, representing a threat for all the users around the
world, including European citizens.

d. Activists use Debian (e.g. through derivatives such as Tails),
among other reasons, to protect themselves from authoritarian
governments; handing threat actors exploits they can use for oppression
is against what Debian stands for.

e. Developers and companies will downplay security issues because
a "security" issue now comes with legal implications. Less clarity on
what is truly a security issue will hurt users by leaving them vulnerable.

3. While proprietary software is developed behind closed doors, Free
Software development is done in the open, transparent for everyone. To
keep even with proprietary software the open development process needs
to be entirely exempt from CRA requirements, just as the development of
software in private is. A "making available on the market" can only be
considered after development is finished and the software is released.

4. Even if only "commercial activities" are in the scope of CRA, the
Free Software community - and as a consequence, everybody - will lose a
lot of small projects. CRA will force many small enterprises and most
probably all self employed developers out of business because they
simply cannot fullfill the requirements imposed by CRA. Debian and other
Linux distributions depend on their work. It is not understandable why
the EU aims to cripple not only an established community but also a
thriving market. CRA needs an exemption for small businesses and, at the
very least, solo-entrepreneurs.

==========================================================================


Sources:

(1) CRA proposals and links:
https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-proposal-for-cybersecurity-regulation
PLD proposals and links:
https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-new-product-liability-directive

(2) Background information:
https://blog.documentfoundation.org/blog/2023/01/24/tdf-position-on-eus-proposed-cyber-resilience-act/
https://blogs.eclipse.org/post/mike-milinkovich/european-cyber-resilience-act-potential-impact-eclipse-foundation
https://labs.ripe.net/author/maarten-aertsen/open-source-software-vs-the-proposed-cyber-resilience-act/
https://blog.opensource.org/author/webmink/
Detailed
analysis: https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/13410-Cyber-resilience-act-new-cybersecurity-rules-for-digital-products-and-ancillary-services/F3376542_en

(3) Debian Social Contract No. 2, 3 and 4
https://www.debian.org/social_contract

----- GENERAL RESOLUTION ENDS -----

Cheers,

-- Santiago

[Gunnar Wolf]

We discussed the text quoted below (that is, the full text that
Santiago just sent), and I find its wide discussion and, at least,
understanding of utmost importance to the free software community as a
whole.

I wholeheartedly second the call for votes with this text.

Santiago Ruano Rincón dijo [Sun, Nov 12, 2023 at 12:10:21PM -0300]:

--

[Mattia Rizzolo]

On Sun, Nov 12, 2023 at 12:10:21PM -0300, Santiago Ruano Rincón wrote:
> 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).

I also second this vote, reporter verbatim hereafter.

--
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-

[Nicolas Dandrimont]

Hi,

Thanks for pushing this forward. Seconded.

Cheers,
Nicolas

On Sun, Nov 12, 2023 at 12:10:21PM -0300, Santiago Ruano Rincón wrote:

[Luca Boccassi]

These all seem like good things to me. For too long private
corporations have been allowed to put profit before accountability and
user safety, which often results in long lasting damage for citizens,
monetary or worse. It's about time the wild-west was reined in.

> 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)

Debian does not sell products in the single market. Why would any
requirement be imposed, how, and on whom? SPI? Debian France?

> 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.

We do know whether something is commercial or not though - for
example, we don't have to provide Debian with warranty to our users,
because we know publishing images on debian.org is not a commercial
activity.
The second statement I find hard to follow, what would employment
status have to do with this?

> 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.

Why would projects stop developing? If it's a product sold on the
single market, then it's right that it is subject to these rules. If
it's not a product, then these rules don't affect it, just like rules
on warranties.

> 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.

Same as above. If you are not selling anything, why would you need
legal advice, any more than you already do? The EU Single Market has
many, many rules, this is not the first and won't be the last.

> 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).

Well, actually the CVE system has a lot of critics - see recent LWN
articles for some examples. So a public authority taking over from
Mitre and other private companies doesn't sound so horrible to me, in
principle - devil's in the details of course.

> 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
> decentralized and distributed. The reporting of security issues to
> ENISA and the intended propagation to other authorities and national
> administrations would collect all software vulnerabilities in one place,
> greatly increasing the risk of leaking information about vulnerabilities
> to threat actors, representing a threat for all the users around the
> world, including European citizens.

This already happens with CVEs though? By a private, unaccountable,
for profit corporation.

> d. Activists use Debian (e.g. through derivatives such as Tails),
> among other reasons, to protect themselves from authoritarian
> governments; handing threat actors exploits they can use for oppression
> is against what Debian stands for.

Again, I don't see how this is any different than the status quo.

> e. Developers and companies will downplay security issues because
> a "security" issue now comes with legal implications. Less clarity on
> what is truly a security issue will hurt users by leaving them vulnerable.

Companies already routinely downplay or outright neglect security
issues in their products. It seems the intent of the legislation is to
try and fix precisely that. One might be skeptical on the ability of
the proposed legislation to improve the situation, of course, but
that's a different story.

> 3. While proprietary software is developed behind closed doors, Free
> Software development is done in the open, transparent for everyone. To
> keep even with proprietary software the open development process needs
> to be entirely exempt from CRA requirements, just as the development of
> software in private is. A "making available on the market" can only be
> considered after development is finished and the software is released.
>
> 4. Even if only "commercial activities" are in the scope of CRA, the
> Free Software community - and as a consequence, everybody - will lose a
> lot of small projects. CRA will force many small enterprises and most
> probably all self employed developers out of business because they
> simply cannot fullfill the requirements imposed by CRA. Debian and other
> Linux distributions depend on their work. It is not understandable why
> the EU aims to cripple not only an established community but also a
> thriving market. CRA needs an exemption for small businesses and, at the
> very least, solo-entrepreneurs.

To be brutally honest, if some private corporations' viability depends
on being able to ignore glaring security issues that can harm their
users, then I for one am all for them going out of business. Just like
if a company's existence relies on the ability to breach privacy with
impunity and is hampered by the GDPR, and so on.

To do a reductio ad absurdum to illustrate my point, if a free
software project's existence depended exclusively on an oil&gas
corporation being able to pollute the environment and worsen climate
change with impunity because the author is employed there, would it be
worth it? The answer for me is categorically no. Especially given it's
free software! The whole point of it is that someone else can maintain
it, or the author can find a different source of income, and the
project can continue - it's free, it's by definition not locked in one
corporation.

All in all, given how the situation is explained here, I do not
understand where the issue is, for us as a project or as free software
developers. I do not see any convincing argument at all as to why this
is detrimental to Debian or free software, and the only link that is
made is tenuous at best: maybe some free software developer is also
employed by a company who is negatively affected by this. There are
many, many things that can negatively affect anyone's employer, I do
not see why, by itself, this should warrant a project statement.

[Scott Kitterman]

Then I would encourage you to do a bit of research on the topic. Given the definitions being used in the proposal, Debian and most, if not all, of it's upstreams are squarely within the realm of affected software. If this is passed, I am seriously considering ceasing all free software work, because it's not at all clear it's possible to avoid legal liability for things that I can't reasonably control as a single developer.

This is true even though I don't live in the EU.

Scott K

[Luca Boccassi]

Which definitions does the proposal use? Could you please quote them?
The first two links do not provide any, as far as I can see. The third
link (a blog post, not a piece of legislation) explicitly says: "the
Cyber Resilience Act does not define commercial activity".

[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 context of free and
open-source software, a commercial activity might be characterized not
only by charging a price for a product, but also by charging a price for
technical support services, when this does not serve only the
recuperation of actual costs, by providing a software platform through
which the manufacturer monetises other services, or by the use of
personal data for reasons other than exclusively for improving the
security, compatibility or interoperability of the software. 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."

Am 12.11.23 um 18:17 schrieb Scott Kitterman:

> Then I would encourage you to do a bit of research on the topic.
Given the definitions being used in the proposal, Debian and most, if
not all, of it's upstreams are squarely within the realm of affected
software. If this is passed, I am seriously considering ceasing all
free software work, because it's not at all clear it's possible to avoid
legal liability for things that I can't reasonably control as a single
developer.

Exactly.

Ilu

Am 12.11.23 um 18:09 schrieb Luca Boccassi:

[Ilulu]

Am 12.11.23 um 18:38 schrieb Luca Boccassi:

>
> Which definitions does the proposal use? Could you please quote them?
> The first two links do not provide any, as far as I can see. The third
> link (a blog post, not a piece of legislation) explicitly says: "the
> Cyber Resilience Act does not define commercial activity".

The first two links are aggregated pages from the European Parliament's
website. They link to the relevant legal documents under the sections
"References" and "Further reading". Have fun :-)

[Lisandro Damián Nicanor Pérez Meyer]

Hi,

On Sun, 12 Nov 2023 at 14:35, Ilulu <il...@gmx.net> wrote:
>
[snip]

> (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.

So basically this means Qt will be considered a commercial product
_even_ if it's totally open source (at least in the way we ship it in
Debian). Even more, it can even be argued that if we ship it _and_ I
get to patch it (we do), then I might be responsible for it, which to
me makes no sense at all.

[Luca Boccassi]

That all looks exceedingly clear to me: if you are selling a product
or a service, then just because the software is free software doesn't
exempt you from being liable for its security. That's good! Great,
even. If a for-profit private company, say, sells a phone running
Debian, just because Debian is open source doesn't mean it should get
away with not providing security support to its customers. Just as it
doesn't discount it from the minimum warranty period - if you buy the
phone and it doesn't work, they can't just say "sorry it's the open
source software's fault, no refund/exchange", and so on.
It seems clear to me what the intent of the legislators is here: avoid
loopholes. Another ad-absurdum: if Microsoft were to push all the code
behind Azure to Github, it shouldn't mean that it should be exempt
from providing security support to its customers according to this
legislation, just because it's open source. That sounds like a good
thing to me!

As far as I can see, the key thing here is always that there's a
product put on the single market. Pushing a repository to Github is
not putting a product on the market. Publishing Debian images on
debian.org is not putting a product on the market. Selling a service
that uses a Debian image is - and then the service provider is the
party responsible.

[Luca Boccassi]

Yes - if it's "made available on the market", which is in the first
bit that was snipped. Pushing a repository on Gitlab is not "making
available on the market". Selling QT as a supported toolkit to third
parties that then integrate it in their products or services or use it
internally, is. If you do the former, nothing changes for you. If you
do the latter, then you are affected - and that's a _good_ thing!

[Ilulu]

Am 12.11.23 um 19:01 schrieb Luca Boccassi:

> Yes - if it's "made available on the market", which is in the first
> bit that was snipped. Pushing a repository on Gitlab is not "making
> available on the market".

You are wrong. It is. That's why the proposal has:

"(10d) The sole act of hosting free and open-source software on open
repositories does not in itself constitute making available on the
market of a product with digital elements. As such, most package
managers, code hosting and collaboration platforms should not be
considered as distributors under the meaning of this Regulation."

... which means that GITHUB is not responsible for the repo you pushed.

But you are. You are the manufacturer of that software product, you make
it available, and whether this is "on the market" = commercial depends
on a lot of things: how many donations you get and from whom, who your
employer is, or who else is working on that repo ... and so on,
depending on how the wording of CRA-Recital 10 will turn out in the end.
You better ask your lawyer.

[Luca Boccassi]

On Sun, 12 Nov 2023 at 18:11, Ilulu <il...@gmx.net> wrote:
> Am 12.11.23 um 19:01 schrieb Luca Boccassi:
> > Yes - if it's "made available on the market", which is in the first
> > bit that was snipped. Pushing a repository on Gitlab is not "making
> > available on the market".
>
> You are wrong. It is. That's why the proposal has:
>
> "(10d) The sole act of hosting free and open-source software on open
> repositories does not in itself constitute making available on the
> market of a product with digital elements. As such, most package
> managers, code hosting and collaboration platforms should not be
> considered as distributors under the meaning of this Regulation."
>
> ... which means that GITHUB is not responsible for the repo you pushed.

Sure, it would be very strange if it was.

> But you are. You are the manufacturer of that software product, you make
> it available, and whether this is "on the market" = commercial depends
> on a lot of things: how many donations you get and from whom, who your
> employer is, or who else is working on that repo ... and so on,
> depending on how the wording of CRA-Recital 10 will turn out in the end.
> You better ask your lawyer.

But this is a non-sequitur. I don't see how the fact that Github is
not responsible for software hosted on its platform goes to imply that
ever such software is a product. Whether something is or is not a
product on the market is already quite clear, and the sources cited in
the original mail themselves say that the CRA does not change this
aspect. There are many, many, many regulations affecting products put
on the single market - I've already cited one that should be familiar
to everyone, warranties. Are you responsible for the warranty for
software you push to Github if someone git clones it? Of course not.
Because repositories on Github are not products on the single market.

[Ilulu]

"Art. 3
(1) ‘product with digital elements’ means any software or hardware
product ...
(18) ‘manufacturer’ means any natural or legal person who develops or
manufactures products with digital elements ... and markets them under
his or her name or trademark, whether for payment or free of charge;
(23) ‘making available on the market’ means any supply of a product with
digital elements for distribution or use on the Union market in the
course of a commercial activity ..."

Am 12.11.23 um 19:19 schrieb Luca Boccassi:

> I don't see how the fact that Github is
> not responsible for software hosted on its platform goes to imply that
> ever such software is a product. Whether something is or is not a
> product on the market is already quite clear, and the sources cited in
> the original mail themselves say that the CRA does not change this
> aspect.

Because everybody agrees that software is a product. And if you can
download the product on github or elsewhere, it's made available. There
is an explicit exemption only for the platform, not for the uploader.
It's fine if you think your software is not a product, but be aware that
european market authorities will not agree with you.

> Are you responsible for the warranty for
> software you push to Github if someone git clones it? Of course not.

Not yet, but this will change, depending on whether the activity is
considered commercial or not. Of course the details are still unclear.
In your example, pushing to your repo might not count as "making
available" (thanks to a lot of lobbying), but tagging a release probably
does. What about CI artifacts? Nobody knows.

> Because repositories on Github are not products on the single market.

Obviously repositories are not products. Software is.

I'm not spreading fud. I've read the stuff, I'm working on this since
FOSDEM, I have the necessary background and I participate in weekly
meetings with several big FOSS organisations/foundations. This workgroup
had frequent consultations with EU representatives. We are not spending
considerable time on non-issues.

Ilu

[Kurt Roeckx]

On Sun, Nov 12, 2023 at 01:03:38PM -0600, Simon Quigley wrote:
> Just for good measure, seconded.

This is the 5th second.


Kurt

[Simon Richter]

Hi,

On 11/13/23 02:47, Lisandro Damián Nicanor Pérez Meyer wrote:

>> 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.

> So basically this means Qt will be considered a commercial product
> _even_ if it's totally open source (at least in the way we ship it in
> Debian). Even more, it can even be argued that if we ship it _and_ I
> get to patch it (we do), then I might be responsible for it, which to
> me makes no sense at all.

It likely applies to systemd.

Simon

[Pierre-Elliott Bécue]

Seconded.
--
PEB

[Aigars Mahinovs]

Let me pipe in here. I have been exposed quite a bit with EU legislation in the process of our fight against software patents back in 2012. The EU legislators are quite sensible when the underlying issues are clearly explained to them, bu the legal language of the documents can be quite dense and also quite nuanced with one word sometimes completely changing the meaning of the entire document.

Looking at https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52022PC0454

For example the intro clearly states the intent of *not* burdening the open source development process with the requirements of this directive:

(10) In order not to hamper innovation or research, free and open-source software developed or supplied outside the course of a commercial activity should not be covered by this Regulation. This is in particular the case for software, including its source code and modified versions, that is openly shared and freely accessible, usable, modifiable and redistributable. In the context of software, a commercial activity might be characterized not only by charging a price for a product, but also by charging a price for technical support services, by providing a software platform through which the manufacturer monetises other services, or by the use of personal data for reasons other than exclusively for improving the security, compatibility or interoperability of the software.

For this purpose the following point exists:

(23)‘making available on the market’ means any supply of a product with digital elements for distribution or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge;

Here the "in the course of a commercial activity" is the critical bit. All volunteer work no longer meets the "making available on the market" definition and thus all other provisions/definitions no longer apply, because they all use the "making available on the market" definition directly or indirectly (via "manufacturer" definition or "product with digital elements" definitions). Re-read the commercial activity mentioned in the point 10 above - it is quite explicit that the activity can only be commercial if its commercial nature is connected with the software in question. So a commercial company releasing open source software that is *not* part of their commercial activity (for example a router manufacturer releasing an in-house written Git UI) would be "supplied outside the course of a commercial activity" and thus not subject to this regulation. But if they release a WiFi driver that they also ship to their customers on their routers, that *would* be a commercial activity and both the open source and the customer version of that driver would need a safety compliance assessment.

Even regardless of the specific legal wording in the legislation itself, the point 10 of the preamble would be enough to to fix any "bug" in the legislation in post-processing via courts. As in - if any interpretation of the wording of the directive is indeed found to be hampering open source development, then it is clearly in error and contrary to the stated intent of the legislation.

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.

--

Best regards,
    Aigars Mahinovs

[Luca Boccassi]

On Mon, 13 Nov 2023 at 10:55, Aigars Mahinovs <aiga...@gmail.com> wrote:
>
> Let me pipe in here. I have been exposed quite a bit with EU legislation in the process of our fight against software patents back in 2012. The EU legislators are quite sensible when the underlying issues are clearly explained to them, bu the legal language of the documents can be quite dense and also quite nuanced with one word sometimes completely changing the meaning of the entire document.
>
> Looking at https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52022PC0454
>
> For example the intro clearly states the intent of *not* burdening the open source development process with the requirements of this directive:
>>
>> (10) In order not to hamper innovation or research, free and open-source software developed or supplied outside the course of a commercial activity should not be covered by this Regulation. This is in particular the case for software, including its source code and modified versions, that is openly shared and freely accessible, usable, modifiable and redistributable. In the context of software, a commercial activity might be characterized not only by charging a price for a product, but also by charging a price for technical support services, by providing a software platform through which the manufacturer monetises other services, or by the use of personal data for reasons other than exclusively for improving the security, compatibility or interoperability of the software.
>
> For this purpose the following point exists:
>>
>> (23)‘making available on the market’ means any supply of a product with digital elements for distribution or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge;
>
>
> Here the "in the course of a commercial activity" is the critical bit. All volunteer work no longer meets the "making available on the market" definition and thus all other provisions/definitions no longer apply, because they all use the "making available on the market" definition directly or indirectly (via "manufacturer" definition or "product with digital elements" definitions). Re-read the commercial activity mentioned in the point 10 above - it is quite explicit that the activity can only be commercial if its commercial nature is connected with the software in question. So a commercial company releasing open source software that is *not* part of their commercial activity (for example a router manufacturer releasing an in-house written Git UI) would be "supplied outside the course of a commercial activity" and thus not subject to this regulation. But if they release a WiFi driver that they also ship to their customers on their routers, that *would* be a commercial activity and both the open source and the customer version of that driver would need a safety compliance assessment.
>
> Even regardless of the specific legal wording in the legislation itself, the point 10 of the preamble would be enough to to fix any "bug" in the legislation in post-processing via courts. As in - if any interpretation of the wording of the directive is indeed found to be hampering open source development, then it is clearly in error and contrary to the stated intent of the legislation.

This matches precisely my understanding, thank you for stating so
clearly and unambiguously what I've been trying to convey (in a much
less clear way).

> 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.

Personally, I would also find it _very_ disturbing if the official
position of the project contained this sentence: "It is not

understandable why the EU aims to cripple not only an established

community but also a thriving market.". I am sure it was not the
intention, but very frankly, this reads like a line from an
anarcho-capitalist political manifesto that objects to regulating
commercial for-profit corporations as a matter of principle. I would
beg the submitters, if they still intend to go ahead after these
clarifications, to at least consider dropping that sentence.

[Lisandro Damián Nicanor Pérez Meyer]

On Mon, 13 Nov 2023 at 07:55, Aigars Mahinovs <aiga...@gmail.com> wrote:
[snip]

> Even regardless of the specific legal wording in the legislation itself, the point 10
> of the preamble would be enough to to fix any "bug" in the legislation in
> post-processing via courts. As in - if any interpretation of the wording of the
> directive is indeed found to be hampering open source development,
> then it is clearly in error and contrary to the stated intent of the legislation.

According to the current wording if, for some reason, I am held to be
responsible for $whatever, then I should go to court. Me, who lives in
south america (because yes, they are looking for culprits no matter
where they live). They already won.

So, why not try and get the wording correctly from starters?



--

Lisandro Damián Nicanor Pérez Meyer

https://perezmeyer.com.ar/

[Simon Richter]

Hi,

On 13.11.23 19:54, Aigars Mahinovs wrote:

> So a commercial company releasing open source
> software that is *not* part of their commercial activity (for example a
> router manufacturer releasing an in-house written Git UI) would be
> "supplied outside the course of a commercial activity" and thus not
> subject to this regulation.

That's why I mentioned systemd in my other email, perhaps I should
elaborate on that.

The lead developer is employed by Microsoft (who have a certain history
with the EU) and pretty obviously working on it full time.

I can see multiple ways this could go:

1. Microsoft are willing to take responsibility for releases made by one
of their employees on company time. For this to happen, they will need
to formally take control of the release process and the depreciation
schedule.

2. Microsoft will claim that the developer time is a donation to the
Open Source community, and outside their commercial activity. Project
leadership will be transferred. I'm not sure the EU would buy that.

3. Microsoft stop paying for systemd development in order to avoid
liability.

> As in - if any interpretation
> of the wording of the directive is indeed found to be hampering open
> source development, then it is clearly in error and contrary to the
> stated intent of the legislation.

The conflict I see is with the way a lot of Open Source development
actually happens these days -- while I personally would like to see a
return of project complexities and scopes to something that is
sustainably manageable in a community setting (i.e. not dependent on and
steered by full time developers), I know that quite a lot of people on
this mailing list disagree with that view.

I don't believe EU legislation is the correct way to get my wish, so I
think it is important for us to see what the practical outcome of this
legislation would be, and whether it matches the stated intent.

Simon

[Luca Boccassi]

On Mon, 13 Nov 2023 at 12:20, Simon Richter <s...@debian.org> wrote:
>
> Hi,
>
> On 13.11.23 19:54, Aigars Mahinovs wrote:
>
> > So a commercial company releasing open source
> > software that is *not* part of their commercial activity (for example a
> > router manufacturer releasing an in-house written Git UI) would be
> > "supplied outside the course of a commercial activity" and thus not
> > subject to this regulation.
>
> That's why I mentioned systemd in my other email, perhaps I should
> elaborate on that.
>
> The lead developer is employed by Microsoft (who have a certain history
> with the EU) and pretty obviously working on it full time.

Employment statuses are irrelevant, as said development is not done as
part of any commercial product as per relevant legislation as
explained already by Aigars, so these points are moot. Mere employment
of a developer is not enough to make an open source software a
commercial product available on the market.

[Aigars Mahinovs]

True, the employment status is irrelevant. However, in this example Microsoft will actually have the liability of

providing the security assurances and support for systemd and related systems, because they are providing

images of such systems as part of their commercial offering on the Azure cloud platforms. And that will be

true regardless of the employment status of a few developers.

A company that does not provide any Linux system services to EU customers, like some integrator operating

just in Canada, would not have such exposure and thus would not incur any such obligations.

[Aigars Mahinovs]

IANAL, but to me the wording seems correct. As long as you are not explicitly conducting commercial activity in 

direct relation to this product to a customer in the EU, none of this applies to you.

If you *are* engaged in commercial activity with customers in the EU, then the EU wants to protect its people and

also keep up the general hygiene of the computing environment in the EU to a certain level.

 --

Best regards,
    Aigars Mahinovs

[Luca Boccassi]

On Mon, 13 Nov 2023 at 12:57, Aigars Mahinovs <aiga...@gmail.com> wrote:
>
> True, the employment status is irrelevant. However, in this example Microsoft will actually have the liability of
> providing the security assurances and support for systemd and related systems, because they are providing
> images of such systems as part of their commercial offering on the Azure cloud platforms. And that will be
> true regardless of the employment status of a few developers.
>
> A company that does not provide any Linux system services to EU customers, like some integrator operating
> just in Canada, would not have such exposure and thus would not incur any such obligations.

Yes, but they have to do that *as part of that commercial product*,
which is not systemd, it's whatever product uses it, together with the
Linux kernel, glibc, gcc, etc. That's a good thing, and it applies to
any corporation that ships any open source software as part of their
products. The corporation is responsible for security aspects of said
product and its part as shipped in that product, which is great.

It doesn't mean that the upstream open source project is now suddenly
encumbered as a commercial product out of the blue - which is what the
person I was replying to concluded - because it's plainly and
obviously not developed solely and exclusively for that commercial
offering, given it's used everywhere on any Linux image from any
vendor that you can get your hands on by any means.

[Aigars Mahinovs]

Correct. And I agree with that effect:

* a company paying salary of a developer that contributes to an open source project outside of the commercial activity of the company does *not* expose the company to extra requirements

* a company taking *any* software, including open source software, and selling a product based on that or related to that, to EU customers, *will* be required to think more about safety (regardless of who it employs and for what)

The *one* negative impact I can see of this legislation is impact on small integrators that were used to being able to go to a

client company, install a bunch of Ubuntu Desktop workstations, set up a Ubuntu Server for SMB and also to serve the website

of the company, take one-time fee for their work and be gone. Now it would have to be made clear - who will be maintaining those

machines over time, ensuring they are patched with security updates in time, upgraded to new OS releases when old ones are no

longer supported and so on. This, over time, will reduce the number of forgotten and bit-rotting systems on the networks that provide

tons of known security holes for attackers. Who will take the responsibility is still open - would that be the end customer itself, would

that be the system integrator that installed the systems for them, can they maybe have a contract with Canonical for such support or

some other company providing such services specifically for the EU. How much would that cost? How would that cost compare to 

similar agreements on the Windows side?

Lots of interesting questions. But at no point does any responsibility get automatically assigned to, for example, Debian or individual

open source developers.

[Holger Levsen]

On Mon, Nov 13, 2023 at 02:19:38PM +0100, Aigars Mahinovs wrote:
> Correct. And I agree with that effect:

same here.

> The *one* negative impact I can see of this legislation is impact on small
> integrators that were used to being able to go to a
> client company, install a bunch of Ubuntu Desktop workstations, set up a
> Ubuntu Server for SMB and also to serve the website
> of the company, take one-time fee for their work and be gone. Now it would
> have to be made clear - who will be maintaining those
> machines over time, ensuring they are patched with security updates in
> time, upgraded to new OS releases when old ones are no
> longer supported and so on.

I don't see this a negative impact because this will in the long
term hopefully prevent the effect which is similar to a small
freelancer setting up a kitchen machine which will blow up
after some time. And noone wants that, whether it's been a small
or big company responsible for the exploding kitchen. And people
buying kitchen machines have understood they want safe machinery
in kitchens...

computers need maintenance, else they will "explode" or be exploited.

[...]

> Lots of interesting questions. But at no point does any responsibility get
> automatically assigned to, for example, Debian or individual
> open source developers.

yup.


--
cheers,
Holger

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

If we'd ban all cars from cities tomorrow, next week we will wonder why we
waited for so long.

[Aigars Mahinovs]

On Mon, 13 Nov 2023 at 12:31, Luca Boccassi <bl...@debian.org> 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.

[Lisandro Damián Nicanor Pérez Meyer]

That's where I see things differently. With the current wording
someone could say: Debian receives donations and thus is a commercial
entity (look at the text!) Then if Qt comes from a commercial entity
and Debian is a commercial entity then anyone using Qt trough Debian
is doing a commercial activity.

Call me nuts, but that's the way I read it, at least for the moment.

--

Lisandro Damián Nicanor Pérez Meyer

https://perezmeyer.com.ar/

[Lisandro Damián Nicanor Pérez Meyer]

On Mon, 13 Nov 2023 at 10:37, Holger Levsen <hol...@layer-acht.org> wrote:
>
> On Mon, Nov 13, 2023 at 02:19:38PM +0100, Aigars Mahinovs wrote:
> > Correct. And I agree with that effect:
>
> same here.
>
> > The *one* negative impact I can see of this legislation is impact on small
> > integrators that were used to being able to go to a
> > client company, install a bunch of Ubuntu Desktop workstations, set up a
> > Ubuntu Server for SMB and also to serve the website
> > of the company, take one-time fee for their work and be gone. Now it would
> > have to be made clear - who will be maintaining those
> > machines over time, ensuring they are patched with security updates in
> > time, upgraded to new OS releases when old ones are no
> > longer supported and so on.
>
> I don't see this a negative impact because this will in the long
> term hopefully prevent the effect which is similar to a small
> freelancer setting up a kitchen machine which will blow up
> after some time. And noone wants that, whether it's been a small
> or big company responsible for the exploding kitchen. And people
> buying kitchen machines have understood they want safe machinery
> in kitchens...

Just to be clear: I also do agree with the main intention of the
proposal, what I do not like is that the current draft wording might
backfire on us.

--

Lisandro Damián Nicanor Pérez Meyer

https://perezmeyer.com.ar/

[Lisandro Damián Nicanor Pérez Meyer]

On Mon, 13 Nov 2023 at 11:50, Aigars Mahinovs <aiga...@gmail.com> wrote:
>
> You are mixing up completely unrelated things. Commercial entities and software coming from it have nothing to do with commercial activity.
>
> The commercial activity is what *you* are doing with the software. It is completely irrelevant where you got it from or if you wrote it.
>
> If you are doing commercial activity and are getting QT as a commercial product from a commercial entity, then it is *easier* for
> you - you can simply delegate the security responsibilities of that part of your software stack up to the QT commercial entity
> and you just need to take care of the rest of the stack, which you are *selling* to your customers (commercial activity!).
>
> Whether accepting donations *in general* makes your activity in providing software a "commercial activity" in the context of
> this directive proposal is not really a supported notion in the text. There are a few specific examples of what does make
> a "commercial activity" in point 10, but none of those examples directly apply to general donations to a project or person.

I am not mixing, I think the current wording does not _exactly_ says
so, leaving a door open for abuse.

[Aigars Mahinovs]

You are mixing up completely unrelated things. Commercial entities and software coming from it have nothing to do with commercial activity.

The commercial activity is what *you* are doing with the software. It is completely irrelevant where you got it from or if you wrote it.

If you are doing commercial activity and are getting QT as a commercial product from a commercial entity, then it is *easier* for 

you - you can simply delegate the security responsibilities of that part of your software stack up to the QT commercial entity 

and you just need to take care of the rest of the stack, which you are *selling* to your customers (commercial activity!).

Whether accepting donations *in general* makes your activity in providing software a "commercial activity" in the context of

this directive proposal is not really a supported notion in the text. There are a few specific examples of what does make

a "commercial activity" in point 10, but none of those examples directly apply to general donations to a project or person.

[Aigars Mahinovs]

The current working does say what is commercial activity and accepting donations does not fall into any of those examples.

But EFF, among others, does mention that it would be more comforting if accepting donations was explicitly highlighted as an example of

activity that clearly falls outside of the commercial activity definition.

[Emmanuel Arias]

Hi!

I have been part of the Mini Debconf 2023 in Uruguay and I second this.

> software in private is. A "making available on the market" can only be

> considered after development is finished and the software is released.
>
> 4. Even if only "commercial activities" are in the scope of CRA, the
> Free Software community - and as a consequence, everybody - will lose a
> lot of small projects. CRA will force many small enterprises and most
> probably all self employed developers out of business because they
> simply cannot fullfill the requirements imposed by CRA. Debian and other

> Linux distributions depend on their work. It is not understandable why

> the EU aims to cripple not only an established community but also a

> thriving market. CRA needs an exemption for small businesses and, at the
> very least, solo-entrepreneurs.
>
> ==========================================================================
>
>
> Sources:
>
> (1) CRA proposals and links:
> https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-proposal-for-cybersecurity-regulation
> PLD proposals and links:
> https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-new-product-liability-directive
>
> (2) Background information:
> https://blog.documentfoundation.org/blog/2023/01/24/tdf-position-on-eus-proposed-cyber-resilience-act/
> https://blogs.eclipse.org/post/mike-milinkovich/european-cyber-resilience-act-potential-impact-eclipse-foundation
> https://labs.ripe.net/author/maarten-aertsen/open-source-software-vs-the-proposed-cyber-resilience-act/
> https://blog.opensource.org/author/webmink/
> Detailed
> analysis: https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/13410-Cyber-resilience-act-new-cybersecurity-rules-for-digital-products-and-ancillary-services/F3376542_en
>
> (3) Debian Social Contract No. 2, 3 and 4
> https://www.debian.org/social_contract
>
> ----- GENERAL RESOLUTION ENDS -----
>

> Cheers,
>
> -- Santiago

Cheers,
Emmanuel

[Gunnar Wolf]

Aigars Mahinovs dijo [Mon, Nov 13, 2023 at 02:46:06PM +0100]:

This is one of the reasons I really thank Ilu for bringing this to our
attention and thoroughly explaining some of the dangers. And for
explaining logic as seen from the "lawyer point of view": Even though
the legislation can be read as well thought-out and correctly
addressing our worris, some spikes and prongs come out of it from
which a hostile larty could abuse it and _with a very low bar_ could
force Debian, or any individual developer working with Debian, or any
other free software project, or even a lonely free software developer
doing things for fun "the old-fashioned way" to face a legal process.

Legal processes are not met with easy, clear-cut, engineer-like logic,
as we are used to. Legal processes must include legal interpretation,
argumentations about intent and reach, harmonization with local and
supranational laws, and whatnot.

Ilu _is_ a lawyer, and very well aligned with Debian and with free
software in general. And I don't think I'm overstepping in Ilu's
closely guarded privacy (which is also a great thing), but I'm sure we
would all have a sure ally in here if we were to need a lawyer in
fighting such a demand. And you mention *great* organizations such as
the EFF. But were we to face a hostile threat, be it from individuals
or from companies... I fear it could mean a very considerable resource
drain and –as Scott K. made clear yesterday– can lead to an important
reduction in volunteer engagement, both in our project and in the free
software ecosystem.

[Scott Kitterman]

This is precisely my concern. Even if I win (because of some words about legislative intent or whatever), the moment I have to hire a lawyer to deal with it, I've already lost. This may not be a problem for Debian, but it's definitely a potential issue for small upstream projects.

I do free software development because I enjoy it and it makes the world a better place. There's a real limit to how far I am willing to carry legal/financial risks to do so.

Scott K

[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 context of free and
> open-source software, a commercial activity might be characterized not

> only by charging a price for a product, but also by charging a price for

> technical support services, when this does not serve only the
> recuperation of actual costs, by providing a software platform through

> which the manufacturer monetises other services, or by the use of
> personal data for reasons other than exclusively for improving the

> security, compatibility or interoperability of the software. 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."
>
> Am 12.11.23 um 18:17 schrieb Scott Kitterman:
> > Then I would encourage you to do a bit of research on the topic.
> Given the definitions being used in the proposal, Debian and most, if
> not all, of it's upstreams are squarely within the realm of affected
> software.  If this is passed, I am seriously considering ceasing all
> free software work, because it's not at all clear it's possible to avoid
> legal liability for things that I can't reasonably control as a single
> developer.
>
> Exactly.
>
> Ilu
>
> Am 12.11.23 um 18:09 schrieb Luca Boccassi:

>> These all seem like good things to me. For too long private
>> corporations have been allowed to put profit before accountability and
>> user safety, which often results in long lasting damage for citizens,
>> monetary or worse. It's about time the wild-west was reined in.

>>
>>>      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)
>>

>> Debian does not sell products in the single market. Why would any
>> requirement be imposed, how, and on whom? SPI? Debian France?

>>
>>>          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.
>>

>> We do know whether something is commercial or not though - for
>> example, we don't have to provide Debian with warranty to our users,
>> because we know publishing images on debian.org is not a commercial
>> activity.
>> The second statement I find hard to follow, what would employment
>> status have to do with this?

>>
>>>          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.
>>

>> Why would projects stop developing? If it's a product sold on the
>> single market, then it's right that it is subject to these rules. If
>> it's not a product, then these rules don't affect it, just like rules
>> on warranties.

>>
>>>          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.
>>

>> Same as above. If you are not selling anything, why would you need
>> legal advice, any more than you already do? The EU Single Market has
>> many, many rules, this is not the first and won't be the last.

>>
>>>      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).
>>

>> Well, actually the CVE system has a lot of critics - see recent LWN
>> articles for some examples. So a public authority taking over from
>> Mitre and other private companies doesn't sound so horrible to me, in
>> principle - devil's in the details of course.

>>
>>>          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
>>>      decentralized and distributed. The reporting of security issues to
>>>      ENISA and the intended propagation to other authorities and
>>> national
>>>      administrations would collect all software vulnerabilities in
>>> one place,
>>>      greatly increasing the risk of leaking information about
>>> vulnerabilities
>>>      to threat actors, representing a threat for all the users around
>>> the
>>>      world, including European citizens.
>>

>> This already happens with CVEs though? By a private, unaccountable,
>> for profit corporation.

>>
>>>          d.  Activists use Debian (e.g. through derivatives such as
>>> Tails),
>>>      among other reasons, to protect themselves from authoritarian
>>>      governments; handing threat actors exploits they can use for
>>> oppression
>>>      is against what Debian stands for.
>>

>> Again, I don't see how this is any different than the status quo.

>>
>>>          e.  Developers and companies will downplay security issues
>>> because
>>>      a "security" issue now comes with legal implications. Less
>>> clarity on
>>>      what is truly a security issue will hurt users by leaving them
>>> vulnerable.
>>

>> Companies already routinely downplay or outright neglect security
>> issues in their products. It seems the intent of the legislation is to
>> try and fix precisely that. One might be skeptical on the ability of
>> the proposed legislation to improve the situation, of course, but
>> that's a different story.

>> To be brutally honest, if some private corporations' viability depends
>> on being able to ignore glaring security issues that can harm their
>> users, then I for one am all for them going out of business. Just like
>> if a company's existence relies on the ability to breach privacy with
>> impunity and is hampered by the GDPR, and so on.
>>
>> To do a reductio ad absurdum to illustrate my point, if a free
>> software project's existence depended exclusively on an oil&gas
>> corporation being able to pollute the environment and worsen climate
>> change with impunity because the author is employed there, would it be
>> worth it? The answer for me is categorically no. Especially given it's
>> free software! The whole point of it is that someone else can maintain
>> it, or the author can find a different source of income, and the
>> project can continue - it's free, it's by definition not locked in one
>> corporation.
>>
>> All in all, given how the situation is explained here, I do not
>> understand where the issue is, for us as a project or as free software
>> developers. I do not see any convincing argument at all as to why this
>> is detrimental to Debian or free software, and the only link that is
>> made is tenuous at best: maybe some free software developer is also
>> employed by a company who is negatively affected by this. There are
>> many, many things that can negatively affect anyone's employer, I do
>> not see why, by itself, this should warrant a project statement.
>>
>

[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:

[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)

[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:

[Helmut Grohne]

Please Cc me in replies.

On Sun, Nov 12, 2023 at 12:10:21PM -0300, Santiago Ruano Rincón wrote:

> Following the email sent by Ilu to debian-project (Message-ID:
> <4b93ed08-f148-4c7f...@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.

In the process of reading background material, I understand why you see
this matter as important. The proposed resolution has aspects that I
find questionable though.

> 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.

As far as I understand it, it never is a question whether a particular
software is commercial or not. It can be both at the same time. What is
a question is how someone interacts with said software. If a
contribution is compensated, then that activity fairly obviously is
commercial and the regulation is rather explicit about such activity
coming with responsibility about the aspect that has been changed. A
redistribution may also be a commercial activity.

This can be read from e.g.

(10) ... a commercial activity might be characterized not only by

charging a price for a product, but also by charging a price for

technical support services, ...

So much of the time, the product made available in commercial capacity
is not a complete software, but a change made to the software. It is
very unclear how the regulation can be applied to patches. A possible
interpretation is that when sending a patch, the relevant entity assumes
responsibility for the entire software, which also is unrealistic.

Does this interpretation make sense to you? If not, why?

An interesting side aspect here is that SaaS is explicitly exempted from
the regulation.

(9) ... It does not regulate services, such as Software-as-a-Service
(SaaS), ... Directive ... (NIS2) applies to cloud computing services
and cloud service models, such as SaaS. ...

Therefore a possible effect of CRA is pushing software out of the market
by never making it available and only providing services using the
software to avoid being covered.

> 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.

Given the above, I do not think that focusing on upstream projects is a
good idea. How about changing that to:

c. Paid developers and companies may stop contributing to upstream
projects for fear of being in the scope of CRA and ...

> 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.

Given the above, this makes less sense to me. To me, there is a clear
intention of not covering non-commercial contributions. However, many of
us get paid for contributions, so telling apart which contribution is a
commercial activity and which is not is a difficult affair resulting in
said discouragement.

> 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).

I think this misses an important detail. The relevant article requires a
vulnerability to be actively exploited. Therefore, most of the
vulnerabilities that we deal with are not covered. On the flip side,
this turns the obligation useless as any non-conforming vendor will
simply claim that their vulnerability was not actively exploited.

> c. Security issue tracking and remediation is intentionally
> decentralized and distributed. The reporting of security issues to
> ENISA and the intended propagation to other authorities and national
> administrations would collect all software vulnerabilities in one place,
> greatly increasing the risk of leaking information about vulnerabilities
> to threat actors, representing a threat for all the users around the
> world, including European citizens.

Given the "actively exploited" requirement, there isn't much to leak,
right?

> d. Activists use Debian (e.g. through derivatives such as Tails),
> among other reasons, to protect themselves from authoritarian
> governments; handing threat actors exploits they can use for oppression
> is against what Debian stands for.

When a vulnerability is actively exploited, chances are that
authoritarian governments are involved. This becomes a weak argument to
me and I suggest skipping it for brevity.

> 3. While proprietary software is developed behind closed doors, Free
> Software development is done in the open, transparent for everyone. To
> keep even with proprietary software the open development process needs
> to be entirely exempt from CRA requirements, just as the development of
> software in private is. A "making available on the market" can only be
> considered after development is finished and the software is released.

I think this is partially covered by Article 4.

3. Member States shall not prevent the making available of
unfinished software which does not comply with this Regulation
provided that the software is only made available for a limited
period required for testing purposes and that a visible sign clearly
indicates that it does not comply with this Regulation and will not
be available on the market for purposes other than testing.

So in principle, we could attach that warning sign to all software and
argue that 100 years still is limited at which point there no longer is
any commercial activity about it. I suspect it doesn't work like this,
but we need to be more precise about why this is item insufficient.

So while I see value in such a statement in general, the current wording
makes me believe that proponents of CRA may easily dismiss many of the
arguments brought forward.

Helmut

[Philip Hands]

Lisandro Damián Nicanor Pérez Meyer <perez...@gmail.com> writes:
...
> Just to be clear: I also do agree with the main intention of the
> proposal, what I do not like is that the current draft wording might
> backfire on us.

I'd expect the multinationals, who have large legal teams, and are used
to interacting with the EU, to find various ways of ensuring that they
can continue to avoid responsibility for their (often-shoddy) wares.
They seem to treat legal fees and fines as costs of doing business, so
won't be significantly inconvenienced.

Meanwhile, one could imagine something like the BSA going around looking
to see if vendors of Free Software based systems have sold anything into
the EU, and encouraging the EU authorities to audit them, just to crap
on the competition.

I remember MS signing-up UK schools to per-processor site licenses where
if one offered to give a school 100 refurbished laptops running Debian,
they'd often end up saying no because they couldn't afford the extra
Windows/Word licenses that they'd have to pay for if they allowed those
CPUs on site.

I'm sure there are still people being paid by incumbents to come up with
ways of maintaining market share by whatever means, who are perfectly
capable of weaponising this legislation against new entrants -- and that
seems very likely to include people associated with Free Software.

Do we really want the likes of Purism to refuse to ship into the EU in
future? I think that seems quite likely to be a rational response on the
part of small enterprises where the bulk of their market lies elsewhere.

I'd love for the vendors of crappy software to be held accountable
for the endless plague of viruses, and the Internet of Shit, they're
inflicting on the world, but I suspect that it won't work out that way.

Instead, I worry that it will only touch people that are trying much
harder to do a good job, but cannot afford a full-time lobbying team in
Brussels.

Cheers, Phil.
--
Philip Hands -- https://hands.com/~phil

[Luca Boccassi]

On Sun, 2023-11-12 at 12:10 -0300, Santiago Ruano Rincón wrote:
> Dear Debian Fellows,

>
> Following the email sent by Ilu to debian-project (Message-ID:
> <4b93ed08-f148-4c7f...@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.

Hi Santiago,

It seems clear that there is a lot of interest in the project to
express a position on this matter. But as mentioned in the thread by
myself and others, I find some of the specifics of the text a bit
problematic - and some of the responses it elicited even more so.

So, I'd like to propose an alternative text, that uses a very similar
preamble and still expresses a strong request to the legislators to
protect the interests of FOSS and its contributors and clarify any
issue, grey area or confusion that might be present in the current
texts, and put it beyond any reasonable doubt that FOSS projects can
continue working as they have, while at the same time supporting the
spirit of the law and its goal to improve the abysmal landscape of
software security in commercial products.

What do you think? Here's what I came up with:

----- 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. Security issues under
active exploitation will have to be reported to European authorities
within 24 hours (1). The CRA will be followed up by an update to the
existing Product Liability Directive (PLD) which, among other things,
will introduce the requirement for products on the market using software
to be able to receive updates to address security vulnerabilities.

Given the current state of the electronics and computing devices market,
constellated with too many irresponsible vendors (largely employing
proprietary software) not taking taking enough precautions to ensure and
maintain the security of their products, resulting in grave issues such
as the plague of ransomware (that, among other things, has often caused
public services to be severely hampered or shut down entirely, across
the European Union and beyond, to the detriment of its citizens), the
Debian project welcomes this initiative and supports its spirit and
intent.

The Debian project believes Free and Open Source Software Projects to be
very well positioned to respond to modern challenges around security and
accountability that these regulations aim to improve for products
commercialized on the Single Market. Debian is well known for its

security track record through practices of responsible disclosure and

coordination with upstream developers and other Free and Open Source
Software projects. The project aims to live up to the commitment made in
the Debian Social Contract: "We will not hide problems." (2)

The Debian project welcomes the attempt of the legislators to ensure
that the development of Free and Open Source Software is not negatively
affected by these regulations, as clearly expressed by the European
Commission in response to stakeholders' requests (1) and as stated in
Recital 10 of the preamble to the CRA:

'In order not to hamper innovation or research, free and open-source
software developed or supplied outside the course of a commercial
activity should not be covered by this Regulation.'

The Debian project however notes that not enough emphasis has been
employed in all parts of these regulations to clearly exonerate Free
and Open Source Software Projects from being subject to the same
liabilities as commercial products, which has caused uncertainty and
worry among Free and Open Source Software developers and stakeholders.

Therefore, the Debian project requests the legislators to enhance the
text of these regulations to clarify beyond any reasonable doubt that
Free and Open Source Software developers and contributors are not going
to be treated as commercial vendors, with special emphasis on
clarifying grey areas such as donations and contributions from
commercial companies. It is fundamental for the interests of the
European Union itself that Free and Open Source Software development
can continue to thrive and produce high quality software components,
applications and operating systems, and this can only happen if Free
and Open Source Software developers and contributors can continue to
work on these projects as they have been doing before these new
regulations, without being encumbered by legal requirements that are
only appropriate for commercial companies and enterprises.

==========================================================================

Sources:

(1) CRA proposals and links:
https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-proposal-for-cybersecurity-regulation
PLD proposals and links:
https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-new-product-liability-directive

Response from the European Commission to a question from the European Parliament on FOSS awareness:
https://www.europarl.europa.eu/doceo/document/E-9-2023-002473-ASW_EN.html

(2) Debian Social Contract No. 2, 3 and 4

https://www.debian.org/social_contract

----- GENERAL RESOLUTION ENDS -----

--
Kind regards,
Luca Boccassi

[Lucas Nussbaum]

On 15/11/23 at 00:49 +0000, Luca Boccassi wrote:
> What do you think? Here's what I came up with:

Hi,

FWIW, I would likely second something along those lines. Some comments:

> The Debian project however notes that not enough emphasis has been
> employed in all parts of these regulations to clearly exonerate Free
> and Open Source Software Projects from being subject to the same
> liabilities as commercial products

I find this part a bit ambiguous. When GitLab or Proxmox or RedHat sells
services around a free software product, I think it's OK if they are
covered by this regulation. Maybe it would be better with
s/Projects/Organizations/?

Maybe we should underline specific borderline situations where the
impact of the regulation would be unclear?

> , which has caused uncertainty and
> worry among Free and Open Source Software developers and stakeholders.
>
> Therefore, the Debian project requests the legislators to enhance the

(minor) s/requests/asks/? (can we request the legislators?)

Lucas

[Simon Richter]

Hi,

On 11/15/23 15:22, Lucas Nussbaum wrote:

>> The Debian project however notes that not enough emphasis has been
>> employed in all parts of these regulations to clearly exonerate Free
>> and Open Source Software Projects from being subject to the same
>> liabilities as commercial products

> I find this part a bit ambiguous. When GitLab or Proxmox or RedHat sells
> services around a free software product, I think it's OK if they are
> covered by this regulation. Maybe it would be better with
> s/Projects/Organizations/?

That is exactly why I think this is dangerous: I want GitLab and Proxmox
to be responsible for what they release, but it is very difficult to
draw a line between their offering and what Microsoft is doing by paying
for systemd development while they are also selling Azure cloud.

> Maybe we should underline specific borderline situations where the
> impact of the regulation would be unclear?

There is no defined borderline, that is part of the problem. Development
happens on a continuum between "commercial enterprise releases part of
their product as open source, but contributions are not actively
solicited" to "a project some random person in Nebraska has been
thanklessly maintaining since 2003."

What Microsoft are doing, with developers being paid by them and then
given a lot of freedom, is somewhere in the middle, but the proposed
legislation does not have a provision for that. So it either falls into
the same category as GitLab, or it doesn't.

So:

- do we believe GitLab should be classed as a commercial enterprise?
- do we believe systemd development should not be classed as a
commercial enterprise?
- can we identify a distinguishing criterion that can be applied by a
regulatory body that will give the results we believe are correct, and
that is also difficult to subvert?

Luca's proposal is only "please take our position into account" without
actually spelling our position out: we are asking for a carve-out for
certain commercially supported projects, but not others. This problem
applies to more than just systemd, but they are a good test case.

We should at least identify

- which projects these are
- why we believe they should be exempted (is it internal governance?
is it because we rely on them? is it because we trust the people involved?)
- how new commercially supported projects could make the list
(sustainability)

and then derive rules from that, see if they sound sensible, and then
ask the EU to implement them.

Simon

[Aigars Mahinovs]

On Wed, 15 Nov 2023 at 12:14, Simon Richter <s...@debian.org> wrote:

Hi,

On 11/15/23 15:22, Lucas Nussbaum wrote:

>>      The Debian project however notes that not enough emphasis has been
>>      employed in all parts of these regulations to clearly exonerate Free
>>      and Open Source Software Projects from being subject to the same
>>      liabilities as commercial products

> I find this part a bit ambiguous. When GitLab or Proxmox or RedHat sells
> services around a free software product, I think it's OK if they are
> covered by this regulation. Maybe it would be better with
> s/Projects/Organizations/?

That is exactly why I think this is dangerous: I want GitLab and Proxmox
to be responsible for what they release, but it is very difficult to
draw a line between their offering and what Microsoft is doing by paying
for systemd development while they are also selling Azure cloud.

Why should there be a borderline between that? Microsoft has to be responsible 

for what they are selling in the Azure cloud (pre-defined images), regardless of

the systemd developer work.

[Luca Boccassi]

On Wed, 15 Nov 2023 at 06:23, Lucas Nussbaum <lu...@debian.org> wrote:
>
> On 15/11/23 at 00:49 +0000, Luca Boccassi wrote:
> > What do you think? Here's what I came up with:
>
> Hi,
>
> FWIW, I would likely second something along those lines. Some comments:
>
> > The Debian project however notes that not enough emphasis has been
> > employed in all parts of these regulations to clearly exonerate Free
> > and Open Source Software Projects from being subject to the same
> > liabilities as commercial products
>
> I find this part a bit ambiguous. When GitLab or Proxmox or RedHat sells
> services around a free software product, I think it's OK if they are
> covered by this regulation. Maybe it would be better with
> s/Projects/Organizations/?
>
> Maybe we should underline specific borderline situations where the
> impact of the regulation would be unclear?

I think the two paragraphs are clearer than that already when taken
together, especially the last bit which essentially boils down to "let
us continue to do what we are doing and go after vendors instead
kkthxbye", but what about this rewording:

The Debian project however notes that not enough emphasis has been
employed in all parts of these regulations to clearly exonerate Free

and Open Source Software developers and maintainers from being subject
to the same liabilities as commercial vendors, which has caused
uncertainty and worry among such stakeholders.

Therefore, the Debian project asks the legislators to enhance the

text of these regulations to clarify beyond any reasonable doubt that
Free and Open Source Software developers and contributors are not going

to be treated as commercial vendors in the exercise of their duties when
merely developing and publishing Free and Open Source Software, with
special emphasis on clarifying grey areas, such as donations,
contributions from commercial companies and developing Free and Open
Source Software that may be later commercialised by a
commercial vendor. It is fundamental for the interests of the

European Union itself that Free and Open Source Software development
can continue to thrive and produce high quality software components,
applications and operating systems, and this can only happen if Free
and Open Source Software developers and contributors can continue to
work on these projects as they have been doing before these new
regulations, without being encumbered by legal requirements that are
only appropriate for commercial companies and enterprises.

> > , which has caused uncertainty and
> > worry among Free and Open Source Software developers and stakeholders.
> >
> > Therefore, the Debian project requests the legislators to enhance the
>
> (minor) s/requests/asks/? (can we request the legislators?)

Sure, I went back-and-forth a few times myself on that phrasing, switched back.

[Santiago Ruano Rincón]

El 15/11/23 a las 00:49, Luca Boccassi escribió:

> On Sun, 2023-11-12 at 12:10 -0300, Santiago Ruano Rincón wrote:
> > Dear Debian Fellows,
> >
> > Following the email sent by Ilu to debian-project (Message-ID:
> > <4b93ed08-f148-4c7f...@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.
>
> Hi Santiago,

Hello Luca

I don't feel comfortable with most of the above paragraph. Where is the
value in kind-of-finger-pointing proprietary software?

Just a quick comment:

IMHO, this proposal doesn't take into account issues with article 11. I
don't think the proposed article helps to increase the security of the
users, whether the vulnerabilities to be reported are known to be
actively exploited or not. And this is for developers/manufacturers
under commercial or non-commercial activities.

Spreading the information about unpatched vulnerabilities among the
agencies of the members of the Union increases the risk of leaks to
malicious actors.
Other than that, given recent history, I would prefer if government
agencies don't get even more data about vulnerabilities that they could
exploit.

I find the reporting time limit too short and hard to fulfill for
small-size companies or single developers, and it would also impact the
research on security issues as it is currently done.

Moreover, this regulation will likely inspire other countries to apply
similar disclosure requirements to their own agencies, increasing even
more the above mentioned risk.

In any case, you are, of course, free to propose an alternative text :-)

Cheers,

-- Santiago

[Lucas Nussbaum]

This looks better, thanks!

I wonder if we should have something like "Free software development by
nonprofit organizations" somewhere. I agree that are many situations
where development happens outside of the context of an NPO, and where
this regulation should not apply. But it might be easier for Debian to
focus on its own context.

Lucas

[Luca Boccassi]

The intent was to reflect these parts of the original proposal:

While proprietary software is developed behind closed doors, Free
Software development is done in the open, transparent for everyone.

and highlight the difference between FOSS and proprietary software in
that regard. I can drop the explicit mention to proprietary software
between brackets, though, that's not a problem.

Article 11 applies to actively exploited security vulnerabilities, and
keeping them hidden - as irresponsible vendors routinely do - is bad
for users and for the ecosystem as a whole. It is also directly
against our social contract, as the original text already pointed out.
It is an overwhelmingly positive step forward, and one that will have
little to no effect on FOSS given, as the original proposal already
highlighted, FOSS already follows best practices around responsible
disclosure and security maintenance, even if some implementation
details (e.g.: time windows) could be improved in the law. It will on
the other hand likely be very detrimental for many irresponsible
commercial actors that routinely hide or refuse to fix security issues
affecting products, but I don't see why the Debian project should take
the defence of such bad practices around commercial products, even if
individual members think they should be allowed to do so - it has
nothing to do with our work or our project, as far as I can tell.

> Spreading the information about unpatched vulnerabilities among the
> agencies of the members of the Union increases the risk of leaks to
> malicious actors.
> Other than that, given recent history, I would prefer if government
> agencies don't get even more data about vulnerabilities that they could
> exploit.

On the contrary, status quo is that FOSS projects already disclose
unpatched vulnerabilities, but to for-profit enterprises like MITRE,
which are not exactly doing a stellar job in maintaining vulnerability
databases. Also commercial vendors routinely disclose vulnerabilities
to privileged (== well paying) business partners, ignoring small
customers or users, and making them answer to public bodies,
themselves accountable to the public rather than shareholders
interested only in maximizing their own profits, is a good step
forward.

> I find the reporting time limit too short and hard to fulfill for
> small-size companies or single developers, and it would also impact the
> research on security issues as it is currently done.

I believe it was mentioned that the time window is still subject to
discussions, and surely it can be improved, while noting that this all
applies to _actively_ exploited problems, so the window needs to be
short out of practical necessities of damage control. I am happy to
add a paragraph to mention this detail, how about something like the
following as the last paragraph:

Finally, the Debian project recognizes the importance of responsible and
timely disclosure of actively exploited security vulnerabilities, and notes
that Free and Open Source Projects are already leading by example in this
regard, but notes that the current proposed 24 hours window is very short
and could be problematic for small projects and vendors to comply with,
and thus encourages the legislators to consider relaxing this requirement
to ensure that all involved parties are able to comply with it.

> Moreover, this regulation will likely inspire other countries to apply
> similar disclosure requirements to their own agencies, increasing even
> more the above mentioned risk.

It's already happening in various forms for large markets anyway (see
for example the US govt EO on bills of materials), which again is a
good thing.

> In any case, you are, of course, free to propose an alternative text :-)

I would very much prefer presenting a single proposal, if at all
possible - hence all these modifications that I am happy to do, and
keep the alternative proposal as a last resort. Is there anything else
you'd like me to change or mention that could make it more amenable?

[Luca Boccassi]

How about:

...if Free and Open Source Software developers and contributors can continue to

work on these projects as they have been doing before these new

regulations, especially but not exclusively in the context of
nonprofit organizations,

[Lucas Nussbaum]

Great thanks!

Lucas

[Simon Richter]

Hi,

On 11/15/23 20:27, Aigars Mahinovs wrote:

> That is exactly why I think this is dangerous: I want GitLab and
> Proxmox
> to be responsible for what they release, but it is very difficult to
> draw a line between their offering and what Microsoft is doing by
> paying
> for systemd development while they are also selling Azure cloud.

> Why should there be a borderline between that? Microsoft has to be
> responsible
> for what they are selling in the Azure cloud (pre-defined images),
> regardless of
> the systemd developer work.

Yes, but in the other direction we don't want them to be responsible for
systemd, because that is still meant to remain a community project even
though the lead developers are employees.

I am not convinced the "mere employment does not immediately cause
responsibility" is enough of a shield here. It would be, if there wasn't
another division of Microsoft that bundled this software and sold
services for it, and was therefore required to provide warranties under
this regulation to their customers.

Transferring that situation back onto GitLab (because we need one set of
regulations that fits all), that would mean that the company was only
required to provide security fixes to their paying customers and could
leave the "community edition" unpatched.

That would also be a consistent position: "as long as the source code is
public under a DFSG-compliant license, the open source exemption should
apply even to works produced for commercial gain."

However, I do not think the EU wants an exemption this broad, which is
why I see a risk that this threatens the model that systemd is currently
developed under.

From my personal perspective on systemd, I don't care much, but with my
Debian hat on I think that would be pretty disruptive.

Simon

[Lisandro Damián Nicanor Pérez Meyer]

On Thu, 16 Nov 2023 at 02:54, Simon Richter <s...@debian.org> wrote:
[snip]

> That would also be a consistent position: "as long as the source code is
> public under a DFSG-compliant license, the open source exemption should
> apply even to works produced for commercial gain."
>
> However, I do not think the EU wants an exemption this broad, which is
> why I see a risk that this threatens the model that systemd is currently
> developed under.

Yeah... maybe something like:

"as long as the source code is public under a DFSG-compliant license,
the open source exemption should apply even to works produced for

commercial gain, except the final user is in a direct contract with
the company developing it"

So: if you are using it for free, it still plain old open source. If
you are paying for it, it's another story. And yes, forgive my lack of
proper words for this.

> From my personal perspective on systemd, I don't care much, but with my
> Debian hat on I think that would be pretty disruptive.

Same here.

[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...@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
> decentralized and distributed. The reporting of security issues to
> ENISA and the intended propagation to other authorities and national
> administrations would collect all software vulnerabilities in one place,
> greatly increasing the risk of leaking information about vulnerabilities
> to threat actors, representing a threat for all the users around the
> world, including European citizens.
>

> d. Activists use Debian (e.g. through derivatives such as Tails),
> among other reasons, to protect themselves from authoritarian
> governments; handing threat actors exploits they can use for oppression
> is against what Debian stands for.
>

> e. Developers and companies will downplay security issues because
> a "security" issue now comes with legal implications. Less clarity on
> what is truly a security issue will hurt users by leaving them vulnerable.
>

> 3. While proprietary software is developed behind closed doors, Free
> Software development is done in the open, transparent for everyone. To
> keep even with proprietary software the open development process needs
> to be entirely exempt from CRA requirements, just as the development of
> software in private is. A "making available on the market" can only be
> considered after development is finished and the software is released.
>

> 4. Even if only "commercial activities" are in the scope of CRA, the
> Free Software community - and as a consequence, everybody - will lose a
> lot of small projects. CRA will force many small enterprises and most
> probably all self employed developers out of business because they
> simply cannot fullfill the requirements imposed by CRA. Debian and other
> Linux distributions depend on their work. It is not understandable why
> the EU aims to cripple not only an established community but also a
> thriving market. CRA needs an exemption for small businesses and, at the
> very least, solo-entrepreneurs.
>

> ==========================================================================
>
>
> Sources:
>
> (1) CRA proposals and links:
> https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-proposal-for-cybersecurity-regulation
> PLD proposals and links:
> https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-new-product-liability-directive
>

> (2) Background information:
> https://blog.documentfoundation.org/blog/2023/01/24/tdf-position-on-eus-proposed-cyber-resilience-act/
> https://blogs.eclipse.org/post/mike-milinkovich/european-cyber-resilience-act-potential-impact-eclipse-foundation
> https://labs.ripe.net/author/maarten-aertsen/open-source-software-vs-the-proposed-cyber-resilience-act/
> https://blog.opensource.org/author/webmink/
> Detailed
> analysis: https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/13410-Cyber-resilience-act-new-cybersecurity-rules-for-digital-products-and-ancillary-services/F3376542_en
>

> (3) Debian Social Contract No. 2, 3 and 4

> https://www.debian.org/social_contract
>
> ----- GENERAL RESOLUTION ENDS -----
>

> Cheers,
>
> -- Santiago

[Bart Martens]

On Wed, Nov 15, 2023 at 02:52:31PM +0100, Lucas Nussbaum wrote:
> I wonder if we should have something like "Free software development by
> nonprofit organizations" somewhere.

Are we now drawing a line between profit and nonprofit? In my view, with Free
Software it should not matter who produces, publishes or uses the software, in
commercial or nonprofit context. That is, in my view, an essential element of
the continuous growth and success of Free Software. This should be the main
message if Debian would make a public statement in this context. Debian should
not try to fix the EU text by defining which categories of contributors are to
be protected. On the contrary, we should aim at keeping the existing freedoms
for anyone alike, including commercial companies. That is also publishing open
source software under licenses with the usual disclaimers of liabilities.

Cheers,
Bart

[Bart Martens]

On Mon, Nov 13, 2023 at 03:57:44PM +0100, Aigars Mahinovs wrote:
> On Mon, 13 Nov 2023 at 15:51, Lisandro Damián Nicanor Pérez Meyer <
> perez...@gmail.com> wrote:
>
> > On Mon, 13 Nov 2023 at 11:50, Aigars Mahinovs <aiga...@gmail.com> wrote:
> > > Whether accepting donations *in general* makes your activity in
> > providing software a "commercial activity" in the context of
> > > this directive proposal is not really a supported notion in the text.
> > There are a few specific examples of what does make
> > > a "commercial activity" in point 10, but none of those examples directly
> > apply to general donations to a project or person.
> >
> > I am not mixing, I think the current wording does not _exactly_ says
> > so, leaving a door open for abuse.
> >
>
> The current working does say what is commercial activity and accepting
> donations does not fall into any of those examples.

It does. Quoted by Ilu: "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."

>

> But EFF, among others, does mention that it would be more comforting if
> accepting donations was explicitly highlighted as an example of
> activity that clearly falls outside of the commercial activity definition.
>
> --
> Best regards,
> Aigars Mahinovs

--

[Sam Hartman]

>>>>> "Bart" == Bart Martens <ba...@debian.org> writes:

Bart> On Wed, Nov 15, 2023 at 02:52:31PM +0100, Lucas Nussbaum wrote:
>> I wonder if we should have something like "Free software
>> development by nonprofit organizations" somewhere.

Bart> Are we now drawing a line between profit and nonprofit? In my
Bart> view, with Free Software it should not matter who produces,
Bart> publishes or uses the software, in commercial or nonprofit
Bart> context. That is, in my view, an essential element of the
Bart> continuous growth and success of Free Software. This should be
Bart> the main message if Debian would make a public statement in
Bart> this context. Debian should not try to fix the EU text by
Bart> defining which categories of contributors are to be
Bart> protected. On the contrary, we should aim at keeping the
Bart> existing freedoms for anyone alike, including commercial
Bart> companies. That is also publishing open source software under
Bart> licenses with the usual disclaimers of liabilities.

I think that when your practices can be best described as monatizing
your customers, or monatizing the users of your open-source software,
then you have extended beyond the free-software ethos, and I think
commercial liability makes sense.

So let's consider some situations.

* A commercial company writes free software. Should they have liability
to someone who grabs that software uses it unrelated to that company's
business and they never make money from that person? Example: A large
company makes a useful library that they and others use; the library
is ancillary to their business; they do not provide support for the
library.
I'd generally say that the commercial company is writing free software
and I agree that Debian should support the idea they should have all
the protections of anyone writing free software.

* A commercial company writes free-software that for all practical
purposes can be used only for access to their proprietary web
service. I'd rather not allow arguments about whether a flaw is on
the web service side or the client API side to be used to help the
company get out of liability to their customers/users.

*A company writes software. They sell support for that software. They
have a track record of being bad about providing security updates to
people who do not pay for support; it is hinted that this helps them
drive support revenue.
I think they should be in the same boat as any company giving software
away for free and also selling support. I.E. the fact that the source
is available should not in this instance help them escape liability.
Whether not giving away security updates for free should be considered
good business or a social evil seems like a debate for another forum,
but I don't think open source should be a factor here.

So, there are some cases where I agree with you that the commercial
nature of the company should not matter to free software protection and
other cases where it is a lot less clear to me.

I do think we want to avoid cases where releasing something as free
software or open source increases liability over giving the same
software away for gratis as closed-source.

--Sam

[Emmanuel Arias]

Hi,

Sorry I did not note that I did not sign this message. I second this:

[Bart Martens]

On Sat, Nov 18, 2023 at 11:43:27AM -0700, Sam Hartman wrote:
> >>>>> "Bart" == Bart Martens <ba...@debian.org> writes:
>
> Bart> On Wed, Nov 15, 2023 at 02:52:31PM +0100, Lucas Nussbaum wrote:
> >> I wonder if we should have something like "Free software
> >> development by nonprofit organizations" somewhere.
>
> Bart> Are we now drawing a line between profit and nonprofit? In my
> Bart> view, with Free Software it should not matter who produces,
> Bart> publishes or uses the software, in commercial or nonprofit
> Bart> context. That is, in my view, an essential element of the
> Bart> continuous growth and success of Free Software. This should be
> Bart> the main message if Debian would make a public statement in
> Bart> this context. Debian should not try to fix the EU text by
> Bart> defining which categories of contributors are to be
> Bart> protected. On the contrary, we should aim at keeping the
> Bart> existing freedoms for anyone alike, including commercial
> Bart> companies. That is also publishing open source software under
> Bart> licenses with the usual disclaimers of liabilities.
>
> I think that when your practices can be best described as monatizing
> your customers, or monatizing the users of your open-source software,
> then you have extended beyond the free-software ethos, and I think
> commercial liability makes sense.

My point was that Debian's role in this context is promoting the DFSG, and not
helping the EU with overruling DFSG 6.

>
> So let's consider some situations.
>
> * A commercial company writes free software. Should they have liability
> to someone who grabs that software uses it unrelated to that company's
> business and they never make money from that person? Example: A large
> company makes a useful library that they and others use; the library
> is ancillary to their business; they do not provide support for the
> library.
> I'd generally say that the commercial company is writing free software
> and I agree that Debian should support the idea they should have all
> the protections of anyone writing free software.

I follow that.

>
> * A commercial company writes free-software that for all practical
> purposes can be used only for access to their proprietary web
> service. I'd rather not allow arguments about whether a flaw is on
> the web service side or the client API side to be used to help the
> company get out of liability to their customers/users.

I guess "awscli" is an example of this situation.
https://packages.debian.org/sid/awscli
https://metadata.ftp-master.debian.org/changelogs//main/a/awscli/awscli_2.12.0-1_copyright
So the EU would hold Amazon liable for damages caused by using "awscli",
overruling the "without warranties" clause in the license. Well, then next time
Amazon might choose to only provide documentation of the API, without
publishing an open source example implementation like "awscli". That's a loss
for foss. It illustrates the value of DFSG 6.

>
> *A company writes software. They sell support for that software. They
> have a track record of being bad about providing security updates to
> people who do not pay for support; it is hinted that this helps them
> drive support revenue.

Example of such software in Debian?

> I think they should be in the same boat as any company giving software
> away for free and also selling support. I.E. the fact that the source
> is available should not in this instance help them escape liability.
> Whether not giving away security updates for free should be considered
> good business or a social evil seems like a debate for another forum,
> but I don't think open source should be a factor here.

We have a different opinion on that.

>
> So, there are some cases where I agree with you that the commercial
> nature of the company should not matter to free software protection and
> other cases where it is a lot less clear to me.
>
> I do think we want to avoid cases where releasing something as free
> software or open source increases liability over giving the same
> software away for gratis as closed-source.

I follow those two points.

Cheers,
Bart

>
> --Sam

[Sam Hartman]

>>>>> "Bart" == Bart Martens <ba...@debian.org> writes:
>>
>> * A commercial company writes free-software that for all
>> practical purposes can be used only for access to their
>> proprietary web service. I'd rather not allow arguments about
>> whether a flaw is on the web service side or the client API side
>> to be used to help the company get out of liability to their
>> customers/users.

Bart> I guess "awscli" is an example of this situation.

Sure, let's say it is.
One could quibble about whether there are alternate implementations of
AWS's API, but for most uses, I'd agree with awscli being an example of
what I'm talking about.

Bart> https://packages.debian.org/sid/awscli
Bart> https://metadata.ftp-master.debian.org/changelogs//main/a/awscli/awscli_2.12.0-1_copyright
Bart> So the EU would hold Amazon liable for damages caused by using
Bart> "awscli", overruling the "without warranties" clause in the
Bart> license. Well, then next time Amazon might choose to only
Bart> provide documentation of the API, without publishing an open
Bart> source example implementation like "awscli". That's a loss for
Bart> foss. It illustrates the value of DFSG 6.

Ah, because the regulations specifically exclude SAAS and so Amazon
doesn't have liability for the API unless they publish software to use
the API?

If that's your point, I certainly understand you better.

If in practice we end up with less open-source software because of
things like that, I agree it would be a negative.

Now that I think I understand you better, I'm going to step aside and
let the Europeans debate this.
Thanks for helping me understand your point.

[Luca Boccassi]

The software license makes no difference, if there's a commercial
activity involved then the vendor is responsible to its customers.
Amazon didn't build awscli because it's a hobby activity or as a favor
to the open source ecosystem, they built it because their cloud
customers demand it and use it (same for Microsoft for azcli, and for
Google for the gcloud cli). So it would not make any difference one
way or the other, these softwares will still exist, and will still be
open source because there's nothing to gain from doing otherwise. It's
a good thing that cloud vendors are held accountable for the security
of the software they ship on users' machines, even if their services
fall under different regulatory regimes. A certain vendor that I won't
name regularly bundles an outdated set of python interpreter, standard
library, ancillary modules _and_ OpenSSL as cherry on top with their
CLI tool - maybe once these regulations are in place, they'll finally
get their act together and start doing proper security maintenance of
said product.

[Luca Boccassi]

Second version, taking into account feedback. Looking for seconds at
this point:

----- 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. Security issues under
active exploitation will have to be reported to European authorities
within 24 hours (1). The CRA will be followed up by an update to the
existing Product Liability Directive (PLD) which, among other things,
will introduce the requirement for products on the market using software
to be able to receive updates to address security vulnerabilities.

Given the current state of the electronics and computing devices market,

constellated with too many irresponsible vendors not taking taking

enough precautions to ensure and maintain the security of their products,
resulting in grave issues such as the plague of ransomware (that, among
other things, has often caused public services to be severely hampered or
shut down entirely, across the European Union and beyond, to the
detriment of its citizens), the Debian project welcomes this initiative
and supports its spirit and intent.

The Debian project believes Free and Open Source Software Projects to be
very well positioned to respond to modern challenges around security and
accountability that these regulations aim to improve for products
commercialized on the Single Market. Debian is well known for its
security track record through practices of responsible disclosure and
coordination with upstream developers and other Free and Open Source
Software projects. The project aims to live up to the commitment made in
the Debian Social Contract: "We will not hide problems." (2)

The Debian project welcomes the attempt of the legislators to ensure
that the development of Free and Open Source Software is not negatively
affected by these regulations, as clearly expressed by the European
Commission in response to stakeholders' requests (1) and as stated in
Recital 10 of the preamble to the CRA:

'In order not to hamper innovation or research, free and open-source
software developed or supplied outside the course of a commercial
activity should not be covered by this Regulation.'

The Debian project however notes that not enough emphasis has been
employed in all parts of these regulations to clearly exonerate Free

and Open Source Software developers and maintainers from being subject
to the same liabilities as commercial vendors, which has caused
uncertainty and worry among such stakeholders.

Therefore, the Debian project asks the legislators to enhance the

text of these regulations to clarify beyond any reasonable doubt that
Free and Open Source Software developers and contributors are not going

to be treated as commercial vendors in the exercise of their duties when
merely developing and publishing Free and Open Source Software, with
special emphasis on clarifying grey areas, such as donations,
contributions from commercial companies and developing Free and Open
Source Software that may be later commercialised by a commercial vendor.

It is fundamental for the interests of the European Union itself that
Free and Open Source Software development can continue to thrive and
produce high quality software components, applications and operating
systems, and this can only happen if Free and Open Source Software
developers and contributors can continue to work on these projects as

they have been doing before these new regulations, especially but not

exclusively in the context of nonprofit organizations, without being

[Aigars Mahinovs]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I second adding this version to the vote

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEFmwrqIlWRDzdY39G+mQ7ph0ievsFAmVanPAACgkQ+mQ7ph0i
evuStBAAtXUNvhfZyTkUxOxB5i5o0P+bbkx5Abs8UU+LICRARCBIJ4aGdlQWMeTp
Ye09hD3cBbbTtgid1idmpEOEbSJW1N0vhPLke1W1cJzv3lhSBLwgcb3fyB1KN1Ye
PFG7/1cpAssQwfvobcaXG7CFWukWKApU9K84G8dv6DMiSvpMnxkBhzSwfLUnb5Y+
H4yZfEn3XdyOociXInxDB+AIVkfXXSwFTFWugYPV+SF371pgOhAZtkRhNOzEUjbJ
DfPkQ1ljMg69Jrs11b2E9Bhe+zvqjSFUbjBv5y+lCusCtMaI5pKQvQjsuVKPpAY5
XtQ3E9Pt8EZQFTohyKe4jsfnUqCGxKXNE7taytTz5Cyf8AeyNsoS4qfXmbVFVTMy
hkU5nBHPVYsB9OtjiK+pv1zM29w9o78ChzuFNinE0KQHzX11p39Udfw9VqZGw/zv
VVgHZxNIRohXgprqw/98nloCQj3akCd7dKFoUNfsl+TBStTrWys6lmvAGvyg/Q00
GC7uxn454LhsGAEDdDf2155fSQsiiK7j+O/ZibwXEP/thfcJJwNmOyjVtiRvtdMg
CnpXWR4RTe+OS73T7LbaS79pDEa5ZLPuLcbGCbB3O/yi2ZUALIbFK02uwex+19Kw
///xr/s+0MXBmiUIZYs+cXZG2u33Vy+GwalbKGhvNN6nRFvvFBY=
=av62
-----END PGP SIGNATURE-----

[Kurt Roeckx]

On Mon, Nov 20, 2023 at 12:40:58AM +0100, Aigars Mahinovs wrote:
> I second adding this version to the vote

I'm getting a bad signature on this.

> On Mon, 20 Nov 2023 at 00:22, Luca Boccassi <bl...@debian.org> wrote:
> Second version, taking into account feedback. Looking for seconds at
> this point:

Maybe Santiago wants to adopt this text, rather than having 2 options?


Kurt

[Luca Boccassi]

> > Second version, taking into account feedback. Looking for seconds
> at
> > this point:
>
> Maybe Santiago wants to adopt this text, rather than having 2
> options?

Already attempted that last week:

https://lists.debian.org/debian-vote/2023/11/msg00051.html

Unfortunately time available is limited by the GR process.

[Simon Richter]

Hi,

On 11/20/23 08:21, Luca Boccassi wrote:

> Therefore, the Debian project asks the legislators to enhance the
> text of these regulations to clarify beyond any reasonable doubt that
> Free and Open Source Software developers and contributors are not going
> to be treated as commercial vendors in the exercise of their duties when
> merely developing and publishing Free and Open Source Software, with
> special emphasis on clarifying grey areas, such as donations,
> contributions from commercial companies and developing Free and Open
> Source Software that may be later commercialised by a commercial vendor.

> It is fundamental for the interests of the European Union itself that
> Free and Open Source Software development can continue to thrive and
> produce high quality software components, applications and operating
> systems, and this can only happen if Free and Open Source Software
> developers and contributors can continue to work on these projects as
> they have been doing before these new regulations, especially but not
> exclusively in the context of nonprofit organizations, without being
> encumbered by legal requirements that are only appropriate for
> commercial companies and enterprises.

*How* do we want the grey areas to be clarified?

With the definitions above, systemd is a commercial product by Microsoft
Corporation, and fully subject to the provisions of the CRA. Microsoft
is not a nonprofit organization, and it is not inappropriate to subject
them to "legal requirements that are only appropriate for commercial
companies and enterprises."

If we want the "Free and Open Source Software developers and
contributors" associated with the systemd project to be able to

"continue to work on these projects as they have been doing before these

new regulations", then there needs to be a reason why they should be
included in the FOSS exception, and we need to spell this out *to the
people involved in the legislative process*, not just insinuate that
there might be additional criteria they may have missed and leave them
guessing what they might be.

I have gathered that we *do* want Amazon's aws-cli and Microsoft's
azure-cli to be covered by CRA, because these are obviously products
that are part of a commercial cloud computing product, even if their
source code is publicly hosted on GitHub (owned by Microsoft) and they
accept contributions from outside their organization. The same applies
to systemd, unless we provide a reason for it not to different:

- Should this be based on the license used?

We've established in this thread that the answer is "no".

- Should this be based on the employment status of the person making
releases?

We've established in this thread that the answer is "no".

- Should this be based on whether the release tag's author information
uses a private or organizational email address?

I'm running out of ideas here.

I think the Debian project itself is not in danger, but some of our
upstreams are, especially faster-paced ones that require full-time
developers to keep up, or ones that have "consulting" constructs
attached to them where you can pay one of the lead developers for
implementing a particular feature, but that is not lucrative enough for
a full-time position yet?

Simon

[Chris Hofstaedtler]

I second adding this version.

* Luca Boccassi <bl...@debian.org> [231119 23:22]:

[Lucas Nussbaum]

Seconded.

[Luca Boccassi]

On Tue, 21 Nov 2023 at 08:14, Thomas Goirand <zi...@debian.org> wrote:

> Hi,
>
> Thanks a lot for taking the time to word out things this way.
>
> However, I really think this text is being too nice with the EU. The
> feeling in short is reading:
> - what you did was good
> - what you did was good
> - what you did was good
> - oh, btw, there's room for improvement... it'd be nice if...
>
> That's not at all my feeling about the CRA. I'm once more really unhappy
> about EU, I feel like we're getting trapped by big corp and their
> lobbying power, and we need to use stronger words.

Directives such as GDPR, DMA and CRA itself, along with many others
and a bunch of very fat fines levied in recent years, shows that it's
not really the case. Despite the marketing spin, Apple was not fine
with having to swap their proprietary charging connector with USB-C.
Intel was not happy with being slapped with a half a billion fine.
Microsoft was not happy with having to unbundle Bing and Edge from
Windows. Literally no company ever was happy about having to comply
with the GDPR.

Do these go far enough? Of course not, it's always possible to do
better, and compromises will water down some parts, but it's a good
start, and about damn time a regulatory entity stepped up and tried to
put some order to the absolute chaos that is the electronics consumer
market, and the non-existent security support that plagues a very
large chunk of it. It is simply jaw-dropping that there are companies
allowed to put on the market smartphones (which are for a large part
of the population the only devices they use, and to which they entrust
all their personal data) that stop receiving security support after
just a few months of being sold. Will the CRA and PLD definitely fix
100% of the problems for all times? Probably not, but if they start
dispensing some well-deserved kicks up the backsides to some of those
irresponsible vendors, then that sounds good to me.

[Santiago Ruano Rincón]

El 20/11/23 a las 08:53, Kurt Roeckx escribió:

The initial proposal was made collectively, and now I realise I should
have signed with a "On behalf of the Debian fellows in Montevideo". So
it is not only me to decide.

Anyway, IMHO, it is good to have more than one option.

Cheers,

-- Santiago

[Gunnar Wolf]

Santiago Ruano Rincón dijo [Tue, Nov 21, 2023 at 01:15:40PM -0300]:

> > > I second adding this version to the vote
> >
> > I'm getting a bad signature on this.
> >
> > > On Mon, 20 Nov 2023 at 00:22, Luca Boccassi <bl...@debian.org> wrote:
> > > Second version, taking into account feedback. Looking for seconds at
> > > this point:
> >
> > Maybe Santiago wants to adopt this text, rather than having 2 options?
>
> The initial proposal was made collectively, and now I realise I should
> have signed with a "On behalf of the Debian fellows in Montevideo". So
> it is not only me to decide.
>
> Anyway, IMHO, it is good to have more than one option.

As one of the seconders --- I know it's up to Santiago to formally
adopt or reject the modification to the text he submitted, but yes,
this text was the result of –at least– a couple of hours of us working
collectively over a text drafted by Ilu. It will surely have some
English non-native weirdnesses, as highlighted by Wookey; I'm willing
to adopt Wookey's suggestions, as they don't change tone or meaning.

As for Luca's proposed version, it _is_ a worthy proposal, and I'll
surely vote it above "Further Discussion". But it strongly changes the
tone used. I'm happier with the original version. I believe this
highlights the strength of Condorcet-based voting systems. If Santiago
were to adopt the new text, we might get a situation –as happened in
vote 2016-002 leading to 2016-004– where the "softer" version does not
get the traction, where the original, "raw" version does.

Thanks!

- Gunnar.

[Salvo Tomaselli]

In data martedì 21 novembre 2023 16:13:32 CET, Luca Boccassi ha scritto:

> Microsoft was not happy with having to unbundle Bing and Edge from
> Windows.

It is still impossible to uninstall edge...


--
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei

https://ltworf.codeberg.page/

[Luca Boccassi]

On Tue, 21 Nov 2023 at 16:46, Salvo Tomaselli <tipo...@tiscali.it> wrote:
>
> In data martedì 21 novembre 2023 16:13:32 CET, Luca Boccassi ha scritto:
>
> > Microsoft was not happy with having to unbundle Bing and Edge from
> > Windows.
>
> It is still impossible to uninstall edge...

https://arstechnica.com/gadgets/2023/11/europeans-can-soon-strip-bing-edge-other-microsoft-cruft-from-windows-11/

[Bart Martens]

On Tue, Nov 21, 2023 at 09:14:05AM +0100, Thomas Goirand wrote:
> On 11/20/23 00:21, Luca Boccassi wrote:

> > Second version, taking into account feedback. Looking for seconds at
> > this point:

[...]

>
> Thanks a lot for taking the time to word out things this way.
>
> However, I really think this text is being too nice with the EU. The feeling
> in short is reading:
> - what you did was good
> - what you did was good
> - what you did was good
> - oh, btw, there's room for improvement... it'd be nice if...
>
> That's not at all my feeling about the CRA. I'm once more really unhappy
> about EU,

Same here. But...

> I feel like we're getting trapped by big corp and their lobbying
> power, and we need to use stronger words.

Probably in a different way. I'd rather prefer Debian to defend the DFSG,
including DFSG 6. If the EU were to draw a line for compulsory liability, then
it should not be between commercial and nonprofit, but rather between FOSS and
non-FOSS. For example, in my opinion "awscli" is FOSS, and the usual liability
disclaimer in FOSS licenses should also be valid for "awscli". This is, in my
understanding, a different opinion than discussed so far, right?

>
> In the absence of something better, I'll still vote for the above...
>
> Cheers,
>
> Thomas Goirand (zigo)
>

[Luca Boccassi]

On Sun, 2023-11-19 at 23:21 +0000, Luca Boccassi wrote:
> Second version, taking into account feedback. Looking for seconds at
> this point:

Elbrus spotted a typo, fixed below - that's the only change, "taking
taking" -> "taking" in the second paragraph

----- 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. Security issues under
active exploitation will have to be reported to European authorities
within 24 hours (1). The CRA will be followed up by an update to the
existing Product Liability Directive (PLD) which, among other things,
will introduce the requirement for products on the market using software
to be able to receive updates to address security vulnerabilities.

Given the current state of the electronics and computing devices market,

constellated with too many irresponsible vendors not taking enough

[Luca Boccassi]

That would not be a good outcome. Just because a smartphone ships open
source software, it doesn't mean its vendor should get away with not
providing security updates after a few months, causing the phone
owners to lose their data or worse.

[Bart Martens]

That is a different case. The user of a smartphone depends on the vendor for
keeping the smarthpone safe for use during a reasonable time after purchase.
I follow you on that.

[Luca Boccassi]

It's not really different, if you can get out of security maintenance
of some software just because of its license, then it affects any
product using software. That would be quite an obvious loophole to
take advantage of, and that's probably why the distinction in these
regulations is never on the license, but on whether it's a commercial
activity or not.

[Bart Martens]

Well, I think that the CRA & PLD are meant to cover such loopholes. The CRA &
PLD are useful when they introduce compulsory liability for closed products
entirely, also when those products contain pieces of FOSS. The criterion is
that the FOSS is embedded in a closed product, so the user of the product
relies on the product manufacturer for updating that FOSS.

[Kurt Roeckx]

On Sun, Nov 19, 2023 at 11:21:47PM +0000, Luca Boccassi wrote:
> Second version, taking into account feedback. Looking for seconds at
> this point:

So I'm still only counting 4 seconds at this point.


Kurt

[Russ Allbery]

Seconded.

--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>

[Holger Levsen]

On Sun, Nov 19, 2023 at 11:21:47PM +0000, Luca Boccassi wrote:

seconded, thank you.


--
cheers,
Holger

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

Segregation was legal. Slavery was legal. Don't use legality as a guide to
morality. Outlaw profits from fossil fuel.