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:
>> On Sun, 12 Nov 2023 at 15:10, Santiago Ruano Rincón
>> <santiagorr@riseup.net> wrote:
>>>
>>> Dear Debian Fellows,
>>>
>>> Following the email sent by Ilu to debian-project (Message-ID:
>>> <4b93ed08-f148-4c7f-b172-f967f7de7e4d@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).
>>
>> 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.
>>
>