Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
Lisandro Damián Nicanor Pérez Meyer 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 signature.asc Description: PGP signature
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
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-b172-f967f7de7...@gmx.net>), and as we have > discussed during the MiniDebConf UY 2023 with other Debian Members, I > would like to call for a vote about issuing a Debian public statement > regarding > the EU Cyber Resilience Act (CRA) and the Product Liability Directive > (PLD). The CRA is in the final stage in the legislative process in the > EU Parliament, and we think it will impact negatively the Debian > Project, users, developers, companies that rely on Debian, and the FLOSS > community as a whole. Even if the CRA will be probably adopted before > the time the vote ends (if it takes place), we think it is important to > take a public stand about it. 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
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
Marten from NLlabs made a comprehensive flowchart (https://github.com/maertsen/cra-foss-diagram) that shows the state of CRA as we presently (a bit of hope included) understand it. It includes the 4th proposal. Check it out to see where your project possibly might stand if we are able to hold this position. Regarding commerciality: The "employment clause" is not in the flowchart because we are fairly confident that it is not going to be in the final text. But it does not stay away on its own. A lot of people / organisations invested a lot of time to get it removed and are continuosly working to (hopefully) keep it removed. The "donation clause" is in the flowchart and there's still uncertainty about how it will be worded in the final text. There is quite some leeway in between "donations exceeding costs" and no "intention to make a profit". Same goes, more or less, for the "support clause". The drafted Debian statement is meant to lent support to those people / organisations that continue to work on this. The CRA wording can change anytime either way so we have to keep up engagement until the last minute. Agreed, the statement does not have to be perfect. It can very well be more radical or even too radical. That does not hurt, ramping up your demands and then offering a compromise is the way politics work. Ilu Am 13.11.23 um 17:57 schrieb Aigars Mahinovs: Thanks for the detailed explanation! It had quite a few details that I was not aware about. Expressing the desired position of Debian and of the community *is* useful, especially when there are multiple variants of the legislation that need reconciliation. I was looking at the specific version that I linked to and the language in that version. But that position should not be a blanket opposition to the legislation or containing overbroad statements. Specific highlights on what activities should not fall into the scope of the directive would be helpful. But beyond that, I have not researched this specific issue enough to recommend specifics. Peculiarly I am also not against Debian passing the resolution as it stands because the negotiatiators in the loop of reconciliation *are* able to use Debians position to argue for better open source conditions, even if the actual text in the Debian vote *were* far from perfect or accurate. (Which I am not saying it is) On Mon, 13 Nov 2023, 17:32 Ilu, wrote: At the moment - as the official proposals are worded now - everything depends on the meaning of the word "commercial". Please note that the proposals have some examples on this as I mentioned before - but each proposal is worded differently. The software is deemed commercial if - the developer is selling services for it - developers are employed by a company and can exercise control (= can merge) - the project receives donations (depending on how much, how often and from whom) - developed by a single organisation or an asymmetric community (whatever that is, ask your lawyer) - a single organisation is generating revenues from related use in business relationships (notice the vague word "related") - ... The 3 proposals differ on these examples but they show what lawmakers have in mind. Their intent is to include every project where a company is involved in any way. And we all know that without company sponsorship a lot of projects could not exist. Luca might state that "Mere employment of a developer is not enough to make an open source software a commercial product available on the market" but the parliaments proposal explicitely says the opposite (if the developer has control, i.e. merge permission). It doesn't help making blanket statements without reading *all* proposals first. There is even an inofficial 4th proposal circulating behind closed doors, that tries to ditch the commercial/non-commercial differentiation and goes off in a completely different direction (that will target every project that has a backing organisation - Debian has one). It is all still in flow. I cited the Parliaments proposal that says: "Accepting donations without the intention of making a profit should not count as a commercial activity, unless such donations are made by commercial entities and are recurring in nature." which clearly states that recurrent donations by companies make a software commercial. But Aigar still claims that "accepting donations does not fall into any of those examples." What Aigar writes is what we would like to have (and what we are lobbying for) but not what the EU presently wants and not what's written in all proposals. It is not helpful to read legal texts with your own interpretation and your own wishes in mind. Aigar and Luca are writing what they think is reasonable (and I mostly agree) and what they gather from one of the texts (and my hope is that that will be the outcome) but at the moment that is not the consensus among EU legislators. This is why I want Debian to make a statement. We need to argue against the dangerous
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
Thanks for the detailed explanation! It had quite a few details that I was not aware about. Expressing the desired position of Debian and of the community *is* useful, especially when there are multiple variants of the legislation that need reconciliation. I was looking at the specific version that I linked to and the language in that version. But that position should not be a blanket opposition to the legislation or containing overbroad statements. Specific highlights on what activities should not fall into the scope of the directive would be helpful. But beyond that, I have not researched this specific issue enough to recommend specifics. Peculiarly I am also not against Debian passing the resolution as it stands because the negotiatiators in the loop of reconciliation *are* able to use Debians position to argue for better open source conditions, even if the actual text in the Debian vote *were* far from perfect or accurate. (Which I am not saying it is) On Mon, 13 Nov 2023, 17:32 Ilu, wrote: > At the moment - as the official proposals are worded now - everything > depends on the meaning of the word "commercial". Please note that the > proposals have some examples on this as I mentioned before - but each > proposal is worded differently. > > The software is deemed commercial if > - the developer is selling services for it > - developers are employed by a company and can exercise control (= can > merge) > - the project receives donations (depending on how much, how often and > from whom) > - developed by a single organisation or an asymmetric community > (whatever that is, ask your lawyer) > - a single organisation is generating revenues from related use in > business relationships (notice the vague word "related") > - ... > > The 3 proposals differ on these examples but they show what lawmakers > have in mind. Their intent is to include every project where a company > is involved in any way. And we all know that without company sponsorship > a lot of projects could not exist. Luca might state that "Mere > employment of a developer is not enough to make an open source software > a commercial product available on the market" but the parliaments > proposal explicitely says the opposite (if the developer has control, > i.e. merge permission). It doesn't help making blanket statements > without reading *all* proposals first. > > There is even an inofficial 4th proposal circulating behind closed > doors, that tries to ditch the commercial/non-commercial differentiation > and goes off in a completely different direction (that will target every > project that has a backing organisation - Debian has one). It is all > still in flow. > > I cited the Parliaments proposal that says: "Accepting donations without > the intention of making a profit should not count as a commercial > activity, unless such donations are made by commercial entities and are > recurring in nature." which clearly states that recurrent donations by > companies make a software commercial. But Aigar still claims that > "accepting donations does not fall into any of those examples." > > What Aigar writes is what we would like to have (and what we are > lobbying for) but not what the EU presently wants and not what's written > in all proposals. > > It is not helpful to read legal texts with your own interpretation and > your own wishes in mind. Aigar and Luca are writing what they think is > reasonable (and I mostly agree) and what they gather from one of the > texts (and my hope is that that will be the outcome) but at the moment > that is not the consensus among 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
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
The discussion on this list hasn't even touched the subject of Art. 11 CRA which is the most worrysome. Am 13.11.23 um 14:46 schrieb Aigars Mahinovs: "See: https://www.eff.org/deeplinks/2023/10/eff-and-other-experts-join-pointing-out-pitfalls-proposed-eu-cyber-resilience-act Note how the open source language has become very much softened and nuanced after changes in the proposal removed most of the bugs that would have affected open source previously." Nothing mentioned there has been fixed in any of the proposals. And there's little chance that Art. 11 will get changed in a substantial way. Law enforcement is pressuring for it. All the more reason to voice dissent. Ilu Am 13.11.23 um 14:46 schrieb Aigars Mahinovs: On Mon, 13 Nov 2023 at 12:31, Luca Boccassi wrote: I am *not* objecting to Debian taking such a vote and expressing the stance intended. However, I expect that it will be seen by the EU legislators with mifled amusement, because in their context and understanding the legislative proposal already contains all the necessary protections for open source and free software development processes. However, if a company (say Amazon or MySQL) takes an open source product and provides a commercial service based on that product, then they are expected to also provide security updates, vulnerability notifications and other relevant services to their customers. Which is also an intended consequence of the legislation. The EU puts the interests of the consumers and of the community above commercial interests. Even commercial interests of small businesses. Allowing small businesses to "pollute" the digital environment with insecure or unmaintained software just because they are small businesses makes no sense from a European perspective. Indeed. This is good legislation, and the parts you quoted make it exceedingly obvious that the legislators in fact do care about not hampering open source development. It would be very, very strange and self-defeating for the project to come out against this, as the next time around (because if this doesn't pass, something else will - software security in commercial products is too important to leave the current far-west as-is) we might not be so lucky. By now the EU is actually quite used to dealing with volunteer projects and open source projects in general. So they would not be surprised in the slightest. And I do not believe it would tarnish the image of Debian. A lot of the same comments *were* communicated to EU Commission and EU Parliament by IT industry associations, which employ lawyers that track such things and analyse possible impacts, including towards open source software, because that is a solid backbone of the modern digital economy (their words, not mine). And there were indeed many bugs in earlier revisions of these texts that would have made a bad impact if implemented as written. The EU listens *very* well to national IT associations of the member states for feedback on such matters and open source experts are very well represented in those. Opinions of IT people from outside of the EU are usually not considered to be relevant. As in not adding anything new that the EU experts have not already considered. Volunteer open source projects are seen as ... not being able to invest sufficient legal understanding into the topics to be able to contribute to the discussion meaningfully *and* keep up with the nuanced changes in the proposals over time. But umbrella organisations, like EFF are better positioned for this. See: https://www.eff.org/deeplinks/2023/10/eff-and-other-experts-join-pointing-out-pitfalls-proposed-eu-cyber-resilience-act Note how the open source language has become very much softened and nuanced after changes in the proposal removed most of the bugs that would have affected open source previously.
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
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
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On November 13, 2023 12:29:20 PM UTC, "Lisandro Damián Nicanor Pérez Meyer" wrote: >On Mon, 13 Nov 2023 at 07:55, Aigars Mahinovs 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? > 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
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
Hi! I have been part of the Mini Debconf 2023 in Uruguay and I second this. On Sun, Nov 12, 2023 at 12:10:21PM -0300, Santiago Ruano Rincón wrote: > Dear Debian Fellows, > > Following the email sent by Ilu to debian-project (Message-ID: > <4b93ed08-f148-4c7f-b172-f967f7de7...@gmx.net>), and as we have > discussed during the MiniDebConf UY 2023 with other Debian Members, I > would like to call for a vote about issuing a Debian public statement > regarding > the EU Cyber Resilience Act (CRA) and the Product Liability Directive > (PLD). The CRA is in the final stage in the legislative process in the > EU Parliament, and we think it will impact negatively the Debian > Project, users, developers, companies that rely on Debian, and the FLOSS > community as a whole. Even if the CRA will be probably adopted before > the time the vote ends (if it takes place), we think it is important to > take a public stand about it. > > - GENERAL RESOLUTION STARTS - > > Debian Public Statement about the EU Cyber Resilience Act and the > Product Liability Directive > > The European Union is currently preparing a regulation "on horizontal > cybersecurity requirements for products with digital elements" known as > the Cyber Resilience Act (CRA). It's currently in the final "trilogue" > phase of the legislative process. The act includes a set of essential > cybersecurity and vulnerability handling requirements for manufacturers. > It will require products to be accompanied by information and > instructions to the user. Manufacturers will need to perform risk > assessments and produce technical documentation and for critical > components, have third-party audits conducted. Discoverded security > issues will have to be reported to European authorities within 24 hours > (1). The CRA will be followed up by the Product Liability Directive > (PLD) which will introduce compulsory liability for software. More > information about the proposed legislation and its consequences in (2). > > While a lot of these regulations seem reasonable, the Debian project > believes that there are grave problems for Free Software projects > attached to them. Therefore, the Debian project issues the following > statement: > > 1. Free Software has always been a gift, freely given to society, to > take and to use as seen fit, for whatever purpose. Free Software has > proven to be an asset in our digital age and the proposed EU Cyber > Resilience Act is going to be detrimental to it. > a. It is Debian's goal to "make the best system we can, so that > free works will be widely distributed and used." Imposing requirements > such as those proposed in the act makes it legally perilous for others > to redistribute our works and endangers our commitment to "provide an > integrated system of high-quality materials _with no legal restrictions_ > that would prevent such uses of the system". (3) > > b. Knowing whether software is commercial or not isn't feasible, > neither in Debian nor in most free software projects - we don't track > people's employment status or history, nor do we check who finances > upstream projects. > > c. If upstream projects stop developing for fear of being in the > scope of CRA and its financial consequences, system security will > actually get worse instead of better. > > d. Having to get legal advice before giving a present to society > will discourage many developers, especially those without a company or > other organisation supporting them. > > 2. Debian is well known for its security track record through practices > of responsible disclosure and coordination with upstream developers and > other Free Software projects. We aim to live up to the commitment made > in the Social Contract: "We will not hide problems." (3) > a. The Free Software community has developed a fine-tuned, well > working system of responsible disclosure in case of security issues > which will be overturned by the mandatory reporting to European > authorities within 24 hours (Art. 11 CRA). > > b. Debian spends a lot of volunteering time on security issues, > provides quick security updates and works closely together with upstream > projects, in coordination with other vendors. To protect its users, > Debian regularly participates in limited embargos to coordinate fixes to > security issues so that all other major Linux distributions can also > have a complete fix when the vulnerability is disclosed. > > c. Security issue tracking and remediation is intentionally > 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
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
Aigars Mahinovs dijo [Mon, Nov 13, 2023 at 02:46:06PM +0100]: > 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. 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. signature.asc Description: PGP signature
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Mon, 13 Nov 2023 at 15:51, Lisandro Damián Nicanor Pérez Meyer < perezme...@gmail.com> wrote: > On Mon, 13 Nov 2023 at 11:50, Aigars Mahinovs 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. 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
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Mon, 13 Nov 2023 at 11:50, Aigars Mahinovs 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.
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Mon, 13 Nov 2023 at 10:37, Holger Levsen 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/
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
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. On Mon, 13 Nov 2023 at 15:20, Lisandro Damián Nicanor Pérez Meyer < perezme...@gmail.com> wrote: > On Mon, 13 Nov 2023 at 09:54, Aigars Mahinovs wrote: > > > > On Mon, 13 Nov 2023 at 13:29, Lisandro Damián Nicanor Pérez Meyer < > perezme...@gmail.com> wrote: > >> > >> On Mon, 13 Nov 2023 at 07:55, Aigars Mahinovs > 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? > > > > > > 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. > > 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/ > -- Best regards, Aigars Mahinovs
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Mon, 13 Nov 2023 at 09:54, Aigars Mahinovs wrote: > > On Mon, 13 Nov 2023 at 13:29, Lisandro Damián Nicanor Pérez Meyer > wrote: >> >> On Mon, 13 Nov 2023 at 07:55, Aigars Mahinovs 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? > > > 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. 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/
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Mon, 13 Nov 2023 at 12:31, Luca Boccassi wrote: > > > I am *not* objecting to Debian taking such a vote and expressing the > stance intended. However, I expect that it will be seen by the EU > legislators with mifled amusement, because in their context and > understanding the legislative proposal already contains all the necessary > protections for open source and free software development processes. > However, if a company (say Amazon or MySQL) takes an open source product > and provides a commercial service based on that product, then they are > expected to also provide security updates, vulnerability notifications and > other relevant services to their customers. Which is also an intended > consequence of the legislation. > > > > The EU puts the interests of the consumers and of the community above > commercial interests. Even commercial interests of small businesses. > Allowing small businesses to "pollute" the digital environment with > insecure or unmaintained software just because they are small businesses > makes no sense from a European perspective. > > Indeed. This is good legislation, and the parts you quoted make it > exceedingly obvious that the legislators in fact do care about not > hampering open source development. It would be very, very strange and > self-defeating for the project to come out against this, as the next > time around (because if this doesn't pass, something else will - > software security in commercial products is too important to leave the > current far-west as-is) we might not be so lucky. > By now the EU is actually quite used to dealing with volunteer projects and open source projects in general. So they would not be surprised in the slightest. And I do not believe it would tarnish the image of Debian. A lot of the same comments *were* communicated to EU Commission and EU Parliament by IT industry associations, which employ lawyers that track such things and analyse possible impacts, including towards open source software, because that is a solid backbone of the modern digital economy (their words, not mine). And there were indeed many bugs in earlier revisions of these texts that would have made a bad impact if implemented as written. The EU listens *very* well to national IT associations of the member states for feedback on such matters and open source experts are very well represented in those. Opinions of IT people from outside of the EU are usually not considered to be relevant. As in not adding anything new that the EU experts have not already considered. Volunteer open source projects are seen as ... not being able to invest sufficient legal understanding into the topics to be able to contribute to the discussion meaningfully *and* keep up with the nuanced changes in the proposals over time. But umbrella organisations, like EFF are better positioned for this. See: https://www.eff.org/deeplinks/2023/10/eff-and-other-experts-join-pointing-out-pitfalls-proposed-eu-cyber-resilience-act Note how the open source language has become very much softened and nuanced after changes in the proposal removed most of the bugs that would have affected open source previously. -- Best regards, Aigars Mahinovs
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
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. signature.asc Description: PGP signature
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
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. On Mon, 13 Nov 2023 at 14:03, Luca Boccassi wrote: > On Mon, 13 Nov 2023 at 12:57, Aigars Mahinovs 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. > -- Best regards, Aigars Mahinovs
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Mon, 13 Nov 2023 at 12:57, Aigars Mahinovs 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.
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
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. On Mon, 13 Nov 2023 at 13:28, Luca Boccassi wrote: > On Mon, 13 Nov 2023 at 12:20, Simon Richter 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. > > -- Best regards, Aigars Mahinovs
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Mon, 13 Nov 2023 at 13:29, Lisandro Damián Nicanor Pérez Meyer < perezme...@gmail.com> wrote: > On Mon, 13 Nov 2023 at 07:55, Aigars Mahinovs 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? 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
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Mon, 13 Nov 2023 at 07:55, Aigars Mahinovs 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/
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Mon, 13 Nov 2023 at 12:20, Simon Richter 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.
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
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 OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Mon, 13 Nov 2023 at 10:55, Aigars Mahinovs 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
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
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. On Mon, 13 Nov 2023 at 02:22, Ilulu wrote: > "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
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
Santiago Ruano Rincón wrote on 12/11/2023 at 16:10:21+0100: > Dear Debian Fellows, > > Following the email sent by Ilu to debian-project (Message-ID: > <4b93ed08-f148-4c7f-b172-f967f7de7...@gmx.net>), and as we have > discussed during the MiniDebConf UY 2023 with other Debian Members, I > would like to call for a vote about issuing a Debian public statement > regarding > the EU Cyber Resilience Act (CRA) and the Product Liability Directive > (PLD). The CRA is in the final stage in the legislative process in the > EU Parliament, and we think it will impact negatively the Debian > Project, users, developers, companies that rely on Debian, and the FLOSS > community as a whole. Even if the CRA will be probably adopted before > the time the vote ends (if it takes place), we think it is important to > take a public stand about it. > > - GENERAL RESOLUTION STARTS - > > Debian Public Statement about the EU Cyber Resilience Act and the > Product Liability Directive > > The European Union is currently preparing a regulation "on horizontal > cybersecurity requirements for products with digital elements" known as > the Cyber Resilience Act (CRA). It's currently in the final "trilogue" > phase of the legislative process. The act includes a set of essential > cybersecurity and vulnerability handling requirements for manufacturers. > It will require products to be accompanied by information and > instructions to the user. Manufacturers will need to perform risk > assessments and produce technical documentation and for critical > components, have third-party audits conducted. Discoverded security > issues will have to be reported to European authorities within 24 hours > (1). The CRA will be followed up by the Product Liability Directive > (PLD) which will introduce compulsory liability for software. More > information about the proposed legislation and its consequences in (2). > > While a lot of these regulations seem reasonable, the Debian project > believes that there are grave problems for Free Software projects > attached to them. Therefore, the Debian project issues the following > statement: > > 1. Free Software has always been a gift, freely given to society, to > take and to use as seen fit, for whatever purpose. Free Software has > proven to be an asset in our digital age and the proposed EU Cyber > Resilience Act is going to be detrimental to it. > a. It is Debian's goal to "make the best system we can, so that > free works will be widely distributed and used." Imposing requirements > such as those proposed in the act makes it legally perilous for others > to redistribute our works and endangers our commitment to "provide an > integrated system of high-quality materials _with no legal restrictions_ > that would prevent such uses of the system". (3) > > b. Knowing whether software is commercial or not isn't feasible, > neither in Debian nor in most free software projects - we don't track > people's employment status or history, nor do we check who finances > upstream projects. > > c. If upstream projects stop developing for fear of being in the > scope of CRA and its financial consequences, system security will > actually get worse instead of better. > > d. Having to get legal advice before giving a present to society > will discourage many developers, especially those without a company or > other organisation supporting them. > > 2. Debian is well known for its security track record through practices > of responsible disclosure and coordination with upstream developers and > other Free Software projects. We aim to live up to the commitment made > in the Social Contract: "We will not hide problems." (3) > a. The Free Software community has developed a fine-tuned, well > working system of responsible disclosure in case of security issues > which will be overturned by the mandatory reporting to European > authorities within 24 hours (Art. 11 CRA). > > b. Debian spends a lot of volunteering time on security issues, > provides quick security updates and works closely together with upstream > projects, in coordination with other vendors. To protect its users, > Debian regularly participates in limited embargos to coordinate fixes to > security issues so that all other major Linux distributions can also > have a complete fix when the vulnerability is disclosed. > > c. Security issue tracking and remediation is intentionally > 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,
