• Call for vote: public statement about the EU Legislation "Cyber Resilie

    From Santiago Ruano =?iso-8859-1?Q?Rinc=@21:1/5 to All on Sun Nov 12 16:20:01 2023
    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).

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

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

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

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

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

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

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

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

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

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

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

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

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


    Sources:

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

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

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

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

    Cheers,

    -- Santiago

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

    iHUEABYIAB0WIQRZVjztY8b+Ty43oH1itBCJKh26HQUCZVDq3QAKCRBitBCJKh26 HdnCAP92NtfZ4H9BqbFsJomtMurPG1Rho6/5GZNf1F8fa4oVtAEA+fizX+iDdiC1 2ej15sz2zYR6L26NNompOBWqjEIbEQg=
    =zjaP
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gunnar Wolf@21:1/5 to All on Sun Nov 12 16:20:01 2023
    We discussed the text quoted below (that is, the full text that
    Santiago just sent), and I find its wide discussion and, at least, understanding of utmost importance to the free software community as a
    whole.

    I wholeheartedly second the call for votes with this text.

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

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

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

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

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

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

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

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

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

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

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

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

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

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


    Sources:

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

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

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

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

    Cheers,

    -- Santiago



    --


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

    iHUEABYIAB0WIQRNFAUGU6QC1zaHBJ0kBMlUbhRTYAUCZVDrfgAKCRAkBMlUbhRT YN0zAP9rIB7mda9EBwRRhodiMb9RmTY+YKQu1Exs/LA8ex3HkQD/XeP9mMvD0WSq gE/HbpvjdZ9oj59pG0+9IUjpc058KwU=
    =BCaG
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mattia Rizzolo@21:1/5 to All on Sun Nov 12 16:30:01 2023
    On Sun, Nov 12, 2023 at 12:10:21PM -0300, Santiago Ruano Rincón wrote:
    I
    would like to call for a vote about issuing a Debian public statement regarding
    the EU Cyber Resilience Act (CRA) and the Product Liability Directive
    (PLD).

    I also second this vote, reporter verbatim hereafter.

    ----- GENERAL RESOLUTION STARTS -----

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


    Sources:

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

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

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

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

    Cheers,

    -- Santiago



    --
    regards,
    Mattia Rizzolo

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

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

    iQIzBAEBCgAdFiEEi3hoeGwz5cZMTQpICBa54Yx2K60FAmVQ7i8ACgkQCBa54Yx2 K62D8Q/+Kip8rGcWtz1Ux89XK3Y8cjBDvBH5nMu497Y43OBxoCKKvFReoZk5dScc V2MdjU6C7mkBinh+vX+hmoqTnp9YnWO+unZQWFFM7t5Ej38GZAkmrK840Fz33ni8 OCY0lbLSn0nTPxH1+klQPqOy6ga17nW/aAAI84/RzweuLllGOrnZ6/JEYfNLSs4e dZIkXSRTt6dSmAGAAI6w/J1Sd2P1IO/EWuTykJvPrQgpnCyr0tqksXXHPg5aPpFN tgLO7BG2RbMABnHRl09EjzTMA11ypqBoa+KShaXKLFWbRmYqvq6cGwfcouln0cwu OWKkSAOoib26oqIGf5DLLtUYHe/DiQtLit2FqNxx1J3nADG0ocKcIUIi73zE1jjo 2YJNDC0E4gcs7kNSOeEVERyFIt+LPSuqOjP0BOchP00ONdn7y5vvtVRSU/5M/8nC sH1Eyd7JCl0IvtYkOMh7gvW5eqWIzITCNSGA62shdkDwhuy5Wy/PheIeVUHTZlXF 4sXDhKbrku75503Tpc4vgK9UJ6xiWE7pxmS0Jn6AEHLHd+17qAH
  • From Nicolas Dandrimont@21:1/5 to All on Sun Nov 12 16:50:01 2023
    Hi,

    Thanks for pushing this forward. Seconded.

    Cheers,
    Nicolas

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

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

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

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

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

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

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

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

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

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

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

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

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

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


    Sources:

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

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

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

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

    Cheers,

    -- Santiago



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

    iHUEABYIAB0WIQTB729fH18IcEx4DLn8XLJnUYbabwUCZVDybgAKCRD8XLJnUYba by8BAP9L1FW0krzT/EzKADwFP8SDiy+iIixKP6oXn0P5ZR4dOQD/aMCkzPxKLGSU O3GIFP22yxEvEXndD7wyWcrI/aigWwk=
    =V7Hv
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Luca Boccassi@21:1/5 to santiagorr@riseup.net on Sun Nov 12 18:20:02 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Scott Kitterman@21:1/5 to Luca Boccassi on Sun Nov 12 18:30:01 2023
    On November 12, 2023 5:09:26 PM UTC, Luca Boccassi <bluca@debian.org> wrote: >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.

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

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

    Scott K

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Luca Boccassi@21:1/5 to Scott Kitterman on Sun Nov 12 18:40:01 2023
    On Sun, 12 Nov 2023 at 17:29, Scott Kitterman <debian@kitterman.com> wrote:
    On November 12, 2023 5:09:26 PM UTC, Luca Boccassi <bluca@debian.org> wrote: >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.

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

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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ilulu@21:1/5 to All on Sun Nov 12 18:40:01 2023
    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.


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ilulu@21:1/5 to All on Sun Nov 12 18:50:02 2023
    Am 12.11.23 um 18:38 schrieb Luca Boccassi:

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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Lisandro_Dami=C3=A1n_Nica@21:1/5 to Ilulu on Sun Nov 12 18:50:02 2023
    Hi,

    On Sun, 12 Nov 2023 at 14:35, Ilulu <ilulu@gmx.net> wrote:

    [snip]
    (10a) For example, a fully decentralised development model, where no
    single commercial entity exercises control over what is accepted into
    the project’s code base, should be taken as an indication that the
    product has been developed in a non-commercial setting. On the other
    hand, where free and open source software is developed by a single organisation or an asymmetric community, where a single organisation is generating revenues from related use in business relationships, this
    should be considered to be a commercial activity. Similarly, where the
    main contributors to free and open-source projects are developers
    employed by commercial entities and when such developers or the employer
    can exercise control as to which modifications are accepted in the code
    base, the project should generally be considered to be of a commercial nature.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Luca Boccassi@21:1/5 to perezmeyer@gmail.com on Sun Nov 12 19:10:01 2023
    On Sun, 12 Nov 2023 at 17:47, Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com> wrote:

    Hi,

    On Sun, 12 Nov 2023 at 14:35, Ilulu <ilulu@gmx.net> wrote:

    [snip]
    (10a) For example, a fully decentralised development model, where no
    single commercial entity exercises control over what is accepted into
    the project’s code base, should be taken as an indication that the product has been developed in a non-commercial setting. On the other
    hand, where free and open source software is developed by a single organisation or an asymmetric community, where a single organisation is generating revenues from related use in business relationships, this
    should be considered to be a commercial activity. Similarly, where the
    main contributors to free and open-source projects are developers
    employed by commercial entities and when such developers or the employer can exercise control as to which modifications are accepted in the code base, the project should generally be considered to be of a commercial nature.

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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Luca Boccassi@21:1/5 to Ilulu on Sun Nov 12 19:00:02 2023
    On Sun, 12 Nov 2023 at 17:35, Ilulu <ilulu@gmx.net> wrote:

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

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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Luca Boccassi@21:1/5 to Ilulu on Sun Nov 12 19:30:01 2023
    On Sun, 12 Nov 2023 at 18:11, Ilulu <ilulu@gmx.net> wrote:
    Am 12.11.23 um 19:01 schrieb Luca Boccassi:
    Yes - if it's "made available on the market", which is in the first
    bit that was snipped. Pushing a repository on Gitlab is not "making available on the market".

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

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

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

    Sure, it would be very strange if it was.

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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ilulu@21:1/5 to All on Sun Nov 12 19:20:01 2023
    Am 12.11.23 um 19:01 schrieb Luca Boccassi:
    Yes - if it's "made available on the market", which is in the first
    bit that was snipped. Pushing a repository on Gitlab is not "making
    available on the market".

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

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

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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ilulu@21:1/5 to All on Mon Nov 13 02:30:01 2023
    "Art. 3
    (1) ‘product with digital elements’ means any software or hardware
    product ...
    (18) ‘manufacturer’ means any natural or legal person who develops or manufactures products with digital elements ... and markets them under
    his or her name or trademark, whether for payment or free of charge;
    (23) ‘making available on the market’ means any supply of a product with digital elements for distribution or use on the Union market in the
    course of a commercial activity ..."

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

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

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

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

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

    Obviously repositories are not products. Software is.

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

    Ilu

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kurt Roeckx@21:1/5 to Simon Quigley on Mon Nov 13 07:20:01 2023
    On Sun, Nov 12, 2023 at 01:03:38PM -0600, Simon Quigley wrote:
    Just for good measure, seconded.

    This is the 5th second.


    Kurt

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Richter@21:1/5 to All on Mon Nov 13 08:50:01 2023
    Hi,

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

    Similarly, where the
    main contributors to free and open-source projects are developers
    employed by commercial entities and when such developers or the employer
    can exercise control as to which modifications are accepted in the code
    base, the project should generally be considered to be of a commercial
    nature.

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

    It likely applies to systemd.

    Simon

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Pierre-Elliott =?utf-8?Q?B=C3=A9cue@21:1/5 to santiagorr@riseup.net on Mon Nov 13 11:00:01 2023
    Santiago Ruano Rincón <santiagorr@riseup.net> 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-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).

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

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

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

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

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

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

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

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

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

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

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

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

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


    Sources:

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

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

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

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

    Seconded.
    --
    PEB

    --=-=-Content-Type: application/pgp-signature; name="signature.asc"

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

    iQJDBAEBCgAtFiEE5CQeth7uIW7ehIz87iFbn7jEWwsFAmVR818PHHBlYkBkZWJp YW4ub3JnAAoJEO4hW5+4xFsLoi4P/RnpHhxHFju1aTg0sLS+eDH96ypVWO91ut2w avTlwraNX38DnzPmRHVoVPb0FmRV8Cy05HD92f6LzqafsfeQw7aNTXiGm8ACpcgk F62PLlGi5ni18eCmJF4g4hPOYdMHI9D6XqTCGFCBQQ0vmQZUqC5Q+6uGz0Djvg3u Nvy0nTRn/bPavKNkPXSqCZXBoWdyHA7pkR89h0KnurccwTDdxro0Bt1HaYk1nWHg cVxTGR5/mdzCMgRdzzwZ6b3CXbDGgI5Y3IiiLywvSPhl388GM4Otn2iCqHqhf0kS 0Wir3qZFTvyoshhE/aPyZ7wQb3I/oxHYphYkdgEm918rFF0DSiqecx6PuC+FVft3 SEteWLjTAZ7KvdSwtfRz0KRp2aEHg3Uoa01ak0wlZmXqDJmLYMMGNBgLddHCqMTG 3LNhtHq2JdB1nP1/oVT2CDW9fvs7kGq4Ie1RPA9jbw008hZ/SjW6+v+NvhCuYrt4 89cNirJAcXRFpdxQRG1Rtut6oe5aESWjRgz5C3AGU6czzCfpVxulvbT1aDAhXNG1 DbFtSbUXQz+S9kaKjWqoYORHGH7y4ZCezsgmuH+GEn6aB/oKOaTNb0vPE+cLgBS9 P5lSAGtswZohwQUiOARtEQfcxE61i+GCyuTtLRm7ik7K1NthfcBvv0Z322dpSbhN
    Gy/3EpCB
    ùQ3
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Aigars Mahinovs@21:1/5 to Ilulu on Mon Nov 13 12:00:01 2023
    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 <ilulu@gmx.net> 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 market is already quite clear, and the sources cited in
    the original mail themselves say that the CRA does not change this
    aspect.

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

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

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

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

    Obviously repositories are not products. Software is.

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

    Ilu



    --
    Best regards,
    Aigars Mahinovs

    <div dir="ltr"><div>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.</div><div><br></div><div>Looking at <a href="https://eur-lex.europa.eu/legal-content/EN/TXT/
    HTML/?uri=CELEX:52022PC0454">https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52022PC0454</a></div><div><br></div><div>For example the intro clearly states the intent of *not* burdening the open source development process with the
    requirements of this directive:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p class="gmail-li gmail-ManualConsidrant"><span class
  • From Luca Boccassi@21:1/5 to Aigars Mahinovs on Mon Nov 13 12:40:01 2023
    On Mon, 13 Nov 2023 at 10:55, Aigars Mahinovs <aigarius@gmail.com> wrote:

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

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

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

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

    For this purpose the following point exists:

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


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

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

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

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

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

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

    Personally, I would also find it _very_ disturbing if the official
    position of the project contained this sentence: "It is not
    understandable why the EU aims to cripple not only an established
    community but also a thriving market.". I am sure it was not the
    intention, but very frankly, this reads like a line from an
    anarcho-capitalist political manifesto that objects to regulating
    commercial for-profit corporations as a matter of principle. I would
    beg the submitters, if they still intend to go ahead after these clarifications, to at least consider dropping that sentence.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Luca Boccassi@21:1/5 to Simon Richter on Mon Nov 13 13:30:02 2023
    On Mon, 13 Nov 2023 at 12:20, Simon Richter <sjr@debian.org> wrote:

    Hi,

    On 13.11.23 19:54, Aigars Mahinovs wrote:

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

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

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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Lisandro_Dami=C3=A1n_Nica@21:1/5 to Aigars Mahinovs on Mon Nov 13 13:30:01 2023
    On Mon, 13 Nov 2023 at 07:55, Aigars Mahinovs <aigarius@gmail.com> wrote: [snip]
    Even regardless of the specific legal wording in the legislation itself, the point 10
    of the preamble would be enough to to fix any "bug" in the legislation in post-processing via courts. As in - if any interpretation of the wording of the
    directive is indeed found to be hampering open source development,
    then it is clearly in error and contrary to the stated intent of the legislation.

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

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



    --
    Lisandro Damián Nicanor Pérez Meyer
    https://perezmeyer.com.ar/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Richter@21:1/5 to All on Mon Nov 13 13:30:02 2023
    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------5MN0sdMEP1a1aVHugqPTpPXg
    Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

    SGksDQoNCk9uIDEzLjExLjIzIDE5OjU0LCBBaWdhcnMgTWFoaW5vdnMgd3JvdGU6DQoNCj4g U28gYSBjb21tZXJjaWFsIGNvbXBhbnkgcmVsZWFzaW5nIG9wZW4gc291cmNlIA0KPiBzb2Z0 d2FyZSB0aGF0IGlzICpub3QqIHBhcnQgb2YgdGhlaXIgY29tbWVyY2lhbCBhY3Rpdml0eSAo Zm9yIGV4YW1wbGUgYSANCj4gcm91dGVyIG1hbnVmYWN0dXJlciByZWxlYXNpbmcgYW4gaW4t aG91c2Ugd3JpdHRlbiBHaXQgVUkpIHdvdWxkIGJlIA0KPiAic3VwcGxpZWQgb3V0c2lkZSB0 aGUgY291cnNlIG9mIGEgY29tbWVyY2lhbCBhY3Rpdml0eSIgYW5kIHRodXMgbm90IA0KPiBz dWJqZWN0IHRvIHRoaXMgcmVndWxhdGlvbi4NCg0KVGhhdCdzIHdoeSBJIG1lbnRpb25lZCBz eXN0ZW1kIGluIG15IG90aGVyIGVtYWlsLCBwZXJoYXBzIEkgc2hvdWxkIA0KZWxhYm9yYXRl IG9uIHRoYXQuDQoNClRoZSBsZWFkIGRldmVsb3BlciBpcyBlbXBsb3llZCBieSBNaWNyb3Nv ZnQgKHdobyBoYXZlIGEgY2VydGFpbiBoaXN0b3J5IA0Kd2l0aCB0aGUgRVUpIGFuZCBwcmV0 dHkgb2J2aW91c2x5IHdvcmtpbmcgb24gaXQgZnVsbCB0aW1lLg0KDQpJIGNhbiBzZWUgbXVs dGlwbGUgd2F5cyB0aGlzIGNvdWxkIGdvOg0KDQoxLiBNaWNyb3NvZnQgYXJlIHdpbGxpbmcg dG8gdGFrZSByZXNwb25zaWJpbGl0eSBmb3IgcmVsZWFzZXMgbWFkZSBieSBvbmUgDQpvZiB0 aGVpciBlbXBsb3llZXMgb24gY29tcGFueSB0aW1lLiBGb3IgdGhpcyB0byBoYXBwZW4sIHRo ZXkgd2lsbCBuZWVkIA0KdG8gZm9ybWFsbHkgdGFrZSBjb250cm9sIG9mIHRoZSByZWxlYXNl IHByb2Nlc3MgYW5kIHRoZSBkZXByZWNpYXRpb24gDQpzY2hlZHVsZS4NCg0KMi4gTWljcm9z b2Z0IHdpbGwgY2xhaW0gdGhhdCB0aGUgZGV2ZWxvcGVyIHRpbWUgaXMgYSBkb25hdGlvbiB0 byB0aGUgDQpPcGVuIFNvdXJjZSBjb21tdW5pdHksIGFuZCBvdXRzaWRlIHRoZWlyIGNvbW1l cmNpYWwgYWN0aXZpdHkuIFByb2plY3QgDQpsZWFkZXJzaGlwIHdpbGwgYmUgdHJhbnNmZXJy ZWQuIEknbSBub3Qgc3VyZSB0aGUgRVUgd291bGQgYnV5IHRoYXQuDQoNCjMuIE1pY3Jvc29m dCBzdG9wIHBheWluZyBmb3Igc3lzdGVtZCBkZXZlbG9wbWVudCBpbiBvcmRlciB0byBhdm9p ZCANCmxpYWJpbGl0eS4NCg0KPiBBcyBpbiAtIGlmIGFueSBpbnRlcnByZXRhdGlvbiANCj4g b2YgdGhlIHdvcmRpbmcgb2YgdGhlIGRpcmVjdGl2ZSBpcyBpbmRlZWQgZm91bmQgdG8gYmUg aGFtcGVyaW5nIG9wZW4gDQo+IHNvdXJjZSBkZXZlbG9wbWVudCwgdGhlbiBpdCBpcyBjbGVh cmx5IGluIGVycm9yIGFuZCBjb250cmFyeSB0byB0aGUgDQo+IHN0YXRlZCBpbnRlbnQgb2Yg dGhlIGxlZ2lzbGF0aW9uLg0KDQpUaGUgY29uZmxpY3QgSSBzZWUgaXMgd2l0aCB0aGUgd2F5 IGEgbG90IG9mIE9wZW4gU291cmNlIGRldmVsb3BtZW50IA0KYWN0dWFsbHkgaGFwcGVucyB0 aGVzZSBkYXlzIC0tIHdoaWxlIEkgcGVyc29uYWxseSB3b3VsZCBsaWtlIHRvIHNlZSBhIA0K cmV0dXJuIG9mIHByb2plY3QgY29tcGxleGl0aWVzIGFuZCBzY29wZXMgdG8gc29tZXRoaW5n IHRoYXQgaXMgDQpzdXN0YWluYWJseSBtYW5hZ2VhYmxlIGluIGEgY29tbXVuaXR5IHNldHRp bmcgKGkuZS4gbm90IGRlcGVuZGVudCBvbiBhbmQgDQpzdGVlcmVkIGJ5IGZ1bGwgdGltZSBk ZXZlbG9wZXJzKSwgSSBrbm93IHRoYXQgcXVpdGUgYSBsb3Qgb2YgcGVvcGxlIG9uIA0KdGhp cyBtYWlsaW5nIGxpc3QgZGlzYWdyZWUgd2l0aCB0aGF0IHZpZXcuDQoNCkkgZG9uJ3QgYmVs aWV2ZSBFVSBsZWdpc2xhdGlvbiBpcyB0aGUgY29ycmVjdCB3YXkgdG8gZ2V0IG15IHdpc2gs IHNvIEkgDQp0aGluayBpdCBpcyBpbXBvcnRhbnQgZm9yIHVzIHRvIHNlZSB3aGF0IHRoZSBw cmFjdGljYWwgb3V0Y29tZSBvZiB0aGlzIA0KbGVnaXNsYXRpb24gd291bGQgYmUsIGFuZCB3 aGV0aGVyIGl0IG1hdGNoZXMgdGhlIHN0YXRlZCBpbnRlbnQuDQoNCiAgICBTaW1vbg0K

    --------------5MN0sdMEP1a1aVHugqPTpPXg--

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

    iQEzBAEBCgAdFiEEtjuqOJSXmNjSiX3Tfr04e7CZCBEFAmVSFFoACgkQfr04e7CZ CBHOsQgAnHM5LHbCc7FbL2a9QyliOlvBDfsRLIf8/hErjWPz+vcb6iCmcie8rp7z bJNtLQ8YwlVTU+rS48kNwpYgJyFV0hRJnsUDKO4U5zzbajyGzohu6jh49vO3/64F QDXGZFhYn4EGdw6KdXcBeYFEmZ4xKi07F3greMTLcPvjpjLwtB3SQJduM84iyOe5 dnCzETnwLoHGTbzoGb/K7i41ZVMZNCx2VMVSHvOFvcxspubn5Yai5NL/2nd1WXuS 8haGLpYMPcC6lxVl/ZJM0jlyMC8AHnGQz/WbnYoS8215cZTOH9o2T9teqUlaXUsz 6/V6yn32Vc/ua47LChifeRAvVBBM5w==
    =wBmB
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Aigars Mahinovs@21:1/5 to perezmeyer@gmail.com on Mon Nov 13 14:00:01 2023
    On Mon, 13 Nov 2023 at 13:29, Lisandro Damián Nicanor Pérez Meyer < perezmeyer@gmail.com> wrote:

    On Mon, 13 Nov 2023 at 07:55, Aigars Mahinovs <aigarius@gmail.com> wrote: [snip]
    Even regardless of the specific legal wording in the legislation itself,
    the point 10
    of the preamble would be enough to to fix any "bug" in the legislation in post-processing via courts. As in - if any interpretation of the wording
    of the
    directive is indeed found to be hampering open source development,
    then it is clearly in error and contrary to the stated intent of the
    legislation.

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

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


    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

    <div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 13 Nov 2023 at 13:29, Lisandro Damián Nicanor Pérez Meyer &lt;<a href="mailto:perezmeyer@gmail.com">perezmeyer@gmail.com</a>&gt; wrote:<br></
    <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 13 Nov 2023 at 07:55, Aigars Mahinovs &lt;<a href="mailto:aigarius@gmail.com" target="_blank">aigarius@gmail.com</a>&gt;
    wrote:<br>
    [snip]<br>
    &gt; Even regardless of the specific legal wording in the legislation itself, the point 10<br>
    &gt; of the preamble would be enough to to fix any &quot;bug&quot; in the legislation in<br>
    &gt; post-processing via courts. As in - if any interpretation of the wording of the<br>
    &gt; directive is indeed found to be hampering open source development,<br> &gt; then it is clearly in error and contrary to the stated intent of the legislation.<br>

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

    So, why not try and get the wording correctly from starters?<span class="gmail_signature_prefix"></span></blockquote><div><br></div><div>IANAL, but to me the wording seems correct. As long as you are not explicitly conducting commercial activity in </
    <div>direct relation to this product to a customer in the EU, none of this applies to you.</div><div><br></div><div>If you *are* engaged in commercial activity with customers in the EU, then the EU wants to protect its people and</div><div>also keep
    up the general hygiene of the computing environment in the EU to a certain level.<br></div><div><br></div><div> -<span class="gmail_signature_prefix">- </span><br></div><div></div></div><div dir="ltr" class="gmail_signature"><div dir="ltr">Best regards,<
        Aigars Mahinovs</div></div></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Aigars Mahinovs@21:1/5 to Luca Boccassi on Mon Nov 13 14:00:01 2023
    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 <bluca@debian.org> wrote:

    On Mon, 13 Nov 2023 at 12:20, Simon Richter <sjr@debian.org> wrote:

    Hi,

    On 13.11.23 19:54, Aigars Mahinovs wrote:

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

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

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

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



    --
    Best regards,
    Aigars Mahinovs

    <div dir="ltr"><div>True, the employment status is irrelevant. However, in this example Microsoft will actually have the liability of</div><div>providing the security assurances and support for systemd and related systems, because they are providing</div>
    <div>images of such systems as part of their commercial offering on the Azure cloud platforms. And that will be</div><div>true regardless of the employment status of a few developers.</div><div><br></div><div>A company that does not provide any Linux
    system services to EU customers, like some integrator operating</div><div>just in Canada, would not have such exposure and thus would not incur any such obligations.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 13 Nov
    2023 at 13:28, Luca Boccassi &lt;<a href="mailto:bluca@debian.org">bluca@debian.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 13 Nov 2023 at 12:
    20, Simon Richter &lt;<a href="mailto:sjr@debian.org" target="_blank">sjr@debian.org</a>&gt; wrote:<br>
    &gt;<br>
    &gt; Hi,<br>
    &gt;<br>
    &gt; On 13.11.23 19:54, Aigars Mahinovs wrote:<br>
    &gt;<br>
    &gt; &gt; So a commercial company releasing open source<br>
    &gt; &gt; software that is *not* part of their commercial activity (for example a<br>
    &gt; &gt; router manufacturer releasing an in-house written Git UI) would be<br>
    &gt; &gt; &quot;supplied outside the course of a commercial activity&quot; and thus not<br>
    &gt; &gt; subject to this regulation.<br>
    &gt;<br>
    &gt; That&#39;s why I mentioned systemd in my other email, perhaps I should<br> &gt; elaborate on that.<br>
    &gt;<br>
    &gt; The lead developer is employed by Microsoft (who have a certain history<br>
    &gt; with the EU) and pretty obviously working on it full time.<br>

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

    </blockquote></div><br clear="all"><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Best regards,<br>    Aigars Mahinovs</div></div></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Luca Boccassi@21:1/5 to Aigars Mahinovs on Mon Nov 13 14:10:01 2023
    On Mon, 13 Nov 2023 at 12:57, Aigars Mahinovs <aigarius@gmail.com> wrote:

    True, the employment status is irrelevant. However, in this example Microsoft will actually have the liability of
    providing the security assurances and support for systemd and related systems, because they are providing
    images of such systems as part of their commercial offering on the Azure cloud platforms. And that will be
    true regardless of the employment status of a few developers.

    A company that does not provide any Linux system services to EU customers, like some integrator operating
    just in Canada, would not have such exposure and thus would not incur any such obligations.

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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Holger Levsen@21:1/5 to Aigars Mahinovs on Mon Nov 13 14:40:01 2023
    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.

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

    iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmVSJoQACgkQCRq4Vgaa qhwn0hAAmjS1ydAHKiJYlrbT8tCIOheV1AbkF40EQqc3yi+Rb76TIE6tEjePpmKS USUrudaFGYw6QVCdvjdrjHqeY/FAAZfNGH8ZvXQNfaE8iwLbAkLKmXmOAVg46mJG kes41lOZ205vylvW9Waa7BmVl2Ex89NZqw1A1bL0ephKcC2J16grtLA8T9nTfkqB FQ2361j/YIHF7XYVnWgEYQi+xvWV0U2n9a1bJO5WiDmj2y/MVwgMe8lneOtGIGFb vLeef8AzcjqDoC6aMcSJMb8ViXPT+nZiTtzrqTg6ojGQZLG3McBYW8YHn88s2eKR gTegP7AC/8XJSDPXJTwbFVB7sUBTOlUkC6hAJzWDmMBW7ft5Kv2hfplDKqoAQJau HDValmT9/4QF5FfWOJeYCV7NEZ2tW+AAz3az2g3af5qYqOxFXWOEzHl3J27w1Xod eUGtokWiCLV0VfIJjmOdwMX9/X33z5+BVOsiZ97R8udNLCdpudWOe3/kfcSb4dxo 68S2gRptIvl6bEka9ynxdnu48p3k5HCMgDQRPkF+tzR7u7OKbCFvSg8y9DvujNEi 1mcSxF2Xwr9Lc9U96
  • From Aigars Mahinovs@21:1/5 to Luca Boccassi on Mon Nov 13 14:30:02 2023
    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 <bluca@debian.org> wrote:

    On Mon, 13 Nov 2023 at 12:57, Aigars Mahinovs <aigarius@gmail.com> wrote:

    True, the employment status is irrelevant. However, in this example
    Microsoft will actually have the liability of
    providing the security assurances and support for systemd and related
    systems, because they are providing
    images of such systems as part of their commercial offering on the Azure
    cloud platforms. And that will be
    true regardless of the employment status of a few developers.

    A company that does not provide any Linux system services to EU
    customers, like some integrator operating
    just in Canada, would not have such exposure and thus would not incur
    any such obligations.

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

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



    --
    Best regards,
    Aigars Mahinovs

    <div dir="ltr"><div>Correct. And I agree with that effect:</div><div><br></div><div>* 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</div><div></div><div>* 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)</div><div><br></div><div>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</div><div>client company, install a bunch of Ubuntu Desktop workstations, set up
    a Ubuntu Server for SMB and also to serve the website</div><div>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</div><div>machines over time, ensuring they are patched with
    security updates in time, upgraded to new OS releases when old ones are no</div><div>longer supported and so on. This, over time, will reduce the number of forgotten and bit-rotting systems on the networks that provide</div><div>tons of known security
    holes for attackers. Who will take the responsibility is still open - would that be the end customer itself, would</div><div>that be the system integrator that installed the systems for them, can they maybe have a contract with Canonical for such support
    or</div><div>some other company providing such services specifically for the EU. How much would that cost? How would that cost compare to </div><div>similar agreements on the Windows side?</div><div><br></div><div>Lots of interesting questions. But at
    no point does any responsibility get automatically assigned to, for example, Debian or individual</div><div>open source developers.<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 13 Nov 2023 at 14:03,
    Luca Boccassi &lt;<a href="mailto:bluca@debian.org">bluca@debian.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 13 Nov 2023 at 12:57, Aigars
    Mahinovs &lt;<a href="mailto:aigarius@gmail.com" target="_blank">aigarius@gmail.com</a>&gt; wrote:<br>
    &gt;<br>
    &gt; True, the employment status is irrelevant. However, in this example Microsoft will actually have the liability of<br>
    &gt; providing the security assurances and support for systemd and related systems, because they are providing<br>
    &gt; images of such systems as part of their commercial offering on the Azure cloud platforms. And that will be<br>
    &gt; true regardless of the employment status of a few developers.<br>
    &gt;<br>
    &gt; A company that does not provide any Linux system services to EU customers, like some integrator operating<br>
    &gt; just in Canada, would not have such exposure and thus would not incur any such obligations.<br>

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

    It doesn&#39;t mean that the upstream open source project is now suddenly<br> encumbered as a commercial product out of the blue - which is what the<br> person I was replying to concluded - because it&#39;s plainly and<br>
    obviously not developed solely and exclusively for that commercial<br> offering, given it&#39;s used everywhere on any Linux image from any<br>
    vendor that you can get your hands on by any means.<br>
    </blockquote></div><br clear="all"><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Best regards,<br>    Aigars Mahinovs</div></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Aigars Mahinovs@21:1/5 to Luca Boccassi on Mon Nov 13 14:50:01 2023
    On Mon, 13 Nov 2023 at 12:31, Luca Boccassi <bluca@debian.org> wrote:


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

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

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


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

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

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

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

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

    --
    Best regards,
    Aigars Mahinovs

    <div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 13 Nov 2023 at 12:31, Luca Boccassi &lt;<a href="mailto:bluca@debian.org">bluca@debian.org</a>&gt; wrote:<br></div><blockquote class="gmail_
    quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
    &gt; 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.<br>
    &gt;<br>
    &gt; 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 &quot;pollute&quot; the digital environment with insecure or unmaintained
    software just because they are small businesses makes no sense from a European perspective.<br>

    Indeed. This is good legislation, and the parts you quoted make it<br> exceedingly obvious that the legislators in fact do care about not<br> hampering open source development. It would be very, very strange and<br> self-defeating for the project to come out against this, as the next<br>
    time around (because if this doesn&#39;t pass, something else will -<br> software security in commercial products is too important to leave the<br> current far-west as-is) we might not be so lucky.<br></blockquote><div><br></div><div>By now the EU is actually quite used to dealing with volunteer projects and open source projects in general. So they would not <br></div><div>be surprised in the
    slightest. And I do not believe it would tarnish the image of Debian.<br></div><div><br></div><div>A lot of the same comments *were* communicated to EU Commission and EU Parliament by <br></div><div>IT industry associations, which employ lawyers that
    track such things and analyse possible impacts, including towards open</div><div>source software, because that is a solid backbone of the modern digital economy (their words, not mine). And there were </div><div>indeed many bugs in earlier revisions of
    these texts that would have made a bad impact if implemented as written.<br></div><div> <br clear="all"></div></div><div>The EU listens *very* well to national IT associations of the member states for feedback on such matters and open source experts</
    <div>are very well represented in those. Opinions of IT people from outside of the EU are usually not considered to be relevant. As in </div><div>not adding anything new that the EU experts have not already considered.</div><div><br></div><div>
    Volunteer open source projects are seen as ... not being able to invest sufficient legal understanding into the topics to be able</div><div>to contribute to the discussion meaningfully *and* keep up with the nuanced changes in the proposals over time. </
    <div><br></div><div>But umbrella organisations, like EFF are better positioned for this.</div><div></div><div>See: <a href="https://www.eff.org/deeplinks/2023/10/eff-and-other-experts-join-pointing-out-pitfalls-proposed-eu-cyber-resilience-act">https:
    //www.eff.org/deeplinks/2023/10/eff-and-other-experts-join-pointing-out-pitfalls-proposed-eu-cyber-resilience-act</a></div><div>Note how the open source language has become very much softened and nuanced after changes in the</div><div>proposal removed
    most of the bugs that would have affected open source previously. <br></div><div><br></div><div><div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Best regards,<br>    Aigars Mahinovs</div></
    </div></div></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Lisandro_Dami=C3=A1n_Nica@21:1/5 to Aigars Mahinovs on Mon Nov 13 15:30:01 2023
    On Mon, 13 Nov 2023 at 09:54, Aigars Mahinovs <aigarius@gmail.com> wrote:

    On Mon, 13 Nov 2023 at 13:29, Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com> wrote:

    On Mon, 13 Nov 2023 at 07:55, Aigars Mahinovs <aigarius@gmail.com> wrote:
    [snip]
    Even regardless of the specific legal wording in the legislation itself, the point 10
    of the preamble would be enough to to fix any "bug" in the legislation in >> > post-processing via courts. As in - if any interpretation of the wording of the
    directive is indeed found to be hampering open source development,
    then it is clearly in error and contrary to the stated intent of the legislation.

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

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


    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/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Aigars Mahinovs@21:1/5 to perezmeyer@gmail.com on Mon Nov 13 16:00:01 2023
    On Mon, 13 Nov 2023 at 15:51, Lisandro Damián Nicanor Pérez Meyer < perezmeyer@gmail.com> wrote:

    On Mon, 13 Nov 2023 at 11:50, Aigars Mahinovs <aigarius@gmail.com> wrote:
    Whether accepting donations *in general* makes your activity in
    providing software a "commercial activity" in the context of
    this directive proposal is not really a supported notion in the text.
    There are a few specific examples of what does make
    a "commercial activity" in point 10, but none of those examples directly
    apply to general donations to a project or person.

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


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

    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

    <div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 13 Nov 2023 at 15:51, Lisandro Damián Nicanor Pérez Meyer &lt;<a href="mailto:perezmeyer@gmail.com">perezmeyer@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_
    quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 13 Nov 2023 at 11:50, Aigars Mahinovs &lt;<a href="mailto:aigarius@gmail.com" target="_blank">aigarius@gmail.com</a>&gt; wrote:<br>&gt; Whether
    accepting donations *in general* makes your activity in providing software a &quot;commercial activity&quot; in the context of<br>
    &gt; this directive proposal is not really a supported notion in the text. There are a few specific examples of what does make<br>
    &gt; a &quot;commercial activity&quot; in point 10, but none of those examples directly apply to general donations to a project or person.<br>

    I am not mixing, I think the current wording does not _exactl
  • From =?UTF-8?Q?Lisandro_Dami=C3=A1n_Nica@21:1/5 to Holger Levsen on Mon Nov 13 16:00:01 2023
    On Mon, 13 Nov 2023 at 10:37, Holger Levsen <holger@layer-acht.org> wrote:

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

    same here.

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

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

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

    --
    Lisandro Damián Nicanor Pérez Meyer
    https://perezmeyer.com.ar/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Lisandro_Dami=C3=A1n_Nica@21:1/5 to Aigars Mahinovs on Mon Nov 13 16:00:01 2023
    On Mon, 13 Nov 2023 at 11:50, Aigars Mahinovs <aigarius@gmail.com> wrote:

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

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

    If you are doing commercial activity and are getting QT as a commercial product from a commercial entity, then it is *easier* for
    you - you can simply delegate the security responsibilities of that part of your software stack up to the QT commercial entity
    and you just need to take care of the rest of the stack, which you are *selling* to your customers (commercial activity!).

    Whether accepting donations *in general* makes your activity in providing software a "commercial activity" in the context of
    this directive proposal is not really a supported notion in the text. There are a few specific examples of what does make
    a "commercial activity" in point 10, but none of those examples directly apply to general donations to a project or person.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Emmanuel Arias@21:1/5 to All on Mon Nov 13 16:40:01 2023
    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-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).

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

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

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

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

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

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

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

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

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

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

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

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

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


    Sources:

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

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

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

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

    Cheers,

    -- Santiago

    Cheers,
    Emmanuel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gunnar Wolf@21:1/5 to All on Mon Nov 13 16:40:02 2023
    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.

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

    iHUEABYIAB0WIQRNFAUGU6QC1zaHBJ0kBMlUbhRTYAUCZVJBgAAKCRAkBMlUbhRT YMOQAQCy//5xH4tJ2tImiO2QkNZ09E8Foupc0A8PpRL+JAPX6gD/ZDjwER9pTT2L 9y1AFS3LPS4QtCxuhzenQrpYuViFjQ8=
    =17EV
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Scott Kitterman@21:1/5 to perezmeyer@gmail.com on Mon Nov 13 17:30:01 2023
    On November 13, 2023 12:29:20 PM UTC, "Lisandro Damián Nicanor Pérez Meyer" <perezmeyer@gmail.com> wrote:
    On Mon, 13 Nov 2023 at 07:55, Aigars Mahinovs <aigarius@gmail.com> wrote: >[snip]
    Even regardless of the specific legal wording in the legislation itself, the point 10
    of the preamble would be enough to to fix any "bug" in the legislation in
    post-processing via courts. As in - if any interpretation of the wording of the
    directive is indeed found to be hampering open source development,
    then it is clearly in error and contrary to the stated intent of the legislation.

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

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

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ilu@21:1/5 to All on Mon Nov 13 18:00:01 2023
    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 <bluca@debian.org> wrote:


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

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

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


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

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

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

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

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


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ilu@21:1/5 to All on Mon Nov 13 17:40:01 2023
    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.



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Aigars Mahinovs@21:1/5 to ilulu@gmx.net on Mon Nov 13 18:00:01 2023
    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, <ilulu@gmx.net> 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 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.





    <div dir="auto">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.<div dir="auto"><div dir="auto"><br></div><div dir="auto">But that position should not be a blanket opposition to the legislation or containing
    overbroad statements.</div><div dir="auto"><br></div><div dir="auto">Specific highlights on what activities should not fall into the scope of the directive would be helpful.</div><div dir="auto"><br></div><div dir="auto">But beyond that, I have not
    researched this specific issue enough to recommend specifics.</div><div dir="auto"><br></div><div dir="auto">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)</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_
    attr">On Mon, 13 Nov 2023, 17:32 Ilu, &lt;<a href="mailto:ilulu@gmx.net">ilulu@gmx.net</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">At the moment - as the official proposals
    are worded now - everything<br>
    depends on the meaning of the word &quot;commercial&quot;. Please note that the<br>
    proposals have some examples on this as I mentioned before - but each<br> proposal is worded differently.<br>

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

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

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

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

    What Aigar writes is what we would like to have (and what we are<br>
    lobbying for) but not what the EU presently wants and not what&#39;s written<br>
    in all proposals.<br>

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

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

    Please also note that cloud services like Azure are not effected by CRA,<br> that&#39;s NIS2. If you are familiar with European legislation you will know<br>
    that.<br>

    Ilu<br>

    Am 12.11.23 um 18:35 schrieb Ilulu:<br>
    &gt; Am 12.11.23 um 18:09 schrieb Luca Boccassi:<br>
    &gt;  &gt; We do know whether something is commercial or not though ...<br> &gt;<br>
    &gt; I sincerely doubt that. Just to illustrate this I&#39;m citing a part (only<br>
    &gt; a part) of one of the regulation drafts which are presently considered<br> &gt; in trilogue.<br>
    &gt;<br>
    &gt; &quot;(10) Only free and open-source made available on the market in the<br>
    &gt; course of a commercial activity should be covered by this Regulation.<br> &gt; Whether a free and open-source product has been made available as part<br> &gt; of a commercial activity should be assessed on a product-by-product<br> &gt; basis, looking at both the development model and the supply phase of the<br>
    &gt; free and open-source product with digital elements.<br>
    &gt; (10a) For example, a fully decentralised development model, where no<br> &gt; single commercial entity exercises control over what is accepted into<br> &gt; the project’s code base, should be taken as an indication that the<br> &gt; product has been developed in a non-commercial setting. On the other<br> &gt; hand, where free and open source software is developed by a single<br> &gt; organisation or an asymmetric community, where a single organisation is<br>
    &gt; generating revenues from related use in business relationships, this<br> &gt; should be considered to be a commercial activity. Similarly, where the<br> &gt; main contributors to free and open-source projects are developers<br>
    &gt; employed by commercial entities and when such developers or the employer<br>
    &gt; can exercise control as to which modifications are accepted in the code<br>
    &gt; base, the project should generally be considered to be of a commercial<br> &gt; nature.<br>
    &gt; (10b) With regards to the supply phase, in the context of free and<br> &gt; open-source software, a commercial activity might be characterized not<br> &gt; only by charging a price for a product, but also by charging a price for<br>
    &gt; technical support services, when this does not serve only the<br>
    &gt; recuperation of actual costs, by providing a software platform through<br> &gt; which the manufacturer monetises other services, or by the use of<br>
    &gt; personal data for reasons other than exclusively for improving the<br> &gt; security, compatibility or interoperability of the software. Accepting<br> &gt; donations without the intention of making a profit should not<br>
    &gt; count as a commercial activity, unless such donations are made by<br>
    &gt; commercial entities and are recurring in nature.&quot;<br>
    &gt;<br>
    &gt; Am 12.11.23 um 18:17 schrieb Scott Kitterman:<br>
    &gt;  &gt; Then I would encourage you to do a bit of research on the topic.<br>
    &gt; Given the definitions being used in the proposal, Debian and most, if<br> &gt; not all, of it&#39;s upstreams are squarely within the realm of affected<br>
    &gt; software.  If this is passed, I am seriously considering ceasing all<br> &gt; free software work, because it&#39;s not at all clear it&#39;s possible to avoid<br>
    &gt; legal liability for things that I can&#39;t reasonably control as a single<br>
    &gt; developer.<br>
    &gt;<br>
    &gt; Exactly.<br>
    &gt;<br>
    &gt; Ilu<br>
    &gt;<br>
    &gt; Am 12.11.23 um 18:09 schrieb Luca Boccassi:<br>
    &gt;&gt; On Sun, 12 Nov 2023 at 15:10, Santiago Ruano Rincón<br>
    &gt;&gt; &lt;<a href="mailto:santiagorr@riseup.net" target="_blank" rel="noreferrer">santiagorr@riseup.net</a>&gt; wrote:<br>
    &gt;&gt;&gt;<br>
    &gt;&gt;&gt; Dear Debian Fellows,<br>
    &gt;&gt;&gt;<br>
    &gt;&gt;&gt; Following the email sent by Ilu to debian-project (Message-ID:<br> &gt;&gt;&gt; &lt;<a href="mailto:4b93ed08-f148-4c7f-b172-f967f7de7e4d@gmx.net" target="_blank" rel="noreferrer">4b93ed08-f148-4c7f-b172-f967f7de7e4d@gmx.net</a>&gt;), and as we have<br>
    &gt;&gt;&gt; discussed during the MiniDebConf UY 2023 with other Debian Members, I<br>
    &gt;&gt;&gt; would like to call for a vote about issuing a Debian public statement<br>
    &gt;&gt;&gt; regarding<br>
    &gt;&gt;&gt; the EU Cyber Resilience Act (CRA) and the Product Liability Directive<br>
    &gt;&gt;&gt; (PLD). The CRA is in the final stage in the legislative process in the<br>
    &gt;&gt;&gt; EU Parliament, and we think it will impact negatively the Debian<br>
    &gt;&gt;&gt; Project, users, developers, companies that rely on Debian, and the FLOSS<br>
    &gt;&gt;&gt; community as a whole. Even if the CRA will be probably adopted before<br>
    &gt;&gt;&gt; the time the vote ends (if it takes place), we think it is important to<br>
    &gt;&gt;&gt; take a public stand about it.<br>
    &gt;&gt;&gt;<br>
    &gt;&gt;&gt;      ----- GENERAL RESOLUTION STARTS -----<br> &gt;&gt;&gt;<br>
    &gt;&gt;&gt;      Debian Public Statement about the EU Cyber Resilience Act and the<br>
    &gt;&gt;&gt;      Product Liability Directive<br>
    &gt;&gt;&gt;<br>
    &gt;&gt;&gt;      The European Union is currently preparing a regulation &quot;on<br>
    &gt;&gt;&gt; horizontal<br>
    &gt;&gt;&gt;      cybersecurity requirements for products with digital elements&quot;<br>
    &gt;&gt;&gt; known as<br>
    &gt;&gt;&gt;      the Cyber Resilience Act (CRA). It&#39;s currently in the final<br>
    &gt;&gt;&gt; &quot;trilogue&quot;<br>
    &gt;&gt;&gt;      phase of the legislative process. The act includes a set of<br>
    &gt;&gt;&gt; essential<br>
    &gt;&gt;&gt;      cybersecurity and vulnerability handling requirements for<br>
    &gt;&gt;&gt; manufacturers.<br>
    &gt;&gt;&gt;      It will require products to be accompanied by information and<br>
    &gt;&gt;&gt;      instructions to the user. Manufacturers will need to perform risk<br>
    &gt;&gt;&gt;      assessments and produce technical documentation and for critical<br>
    &gt;&gt;&gt;      components, have third-party audits conducted. Discoverded security<br>
    &gt;&gt;&gt;      issues will have to be reported to European authorities within<br>
    &gt;&gt;&gt; 24 hours<br>
    &gt;&gt;&gt;      (1). The CRA will be followed up by the Product Liability Directive<br>
    &gt;&gt;&gt;      (PLD) which will introduce compulsory liability for software. More<br>
    &gt;&gt;&gt;      information about the proposed legislation and its consequences<br>
    &gt;&gt;&gt; in (2).<br>
    &gt;&gt;<br>
    &gt;&gt; These all seem like good things to me. For too long private<br> &gt;&gt; corporations have been allowed to put profit before accountability and<br>
    &gt;&gt; user safety, which often results in long lasting damage for citizens,<br>
    &gt;&gt; monetary or worse. It&#39;s about time the wild-west was reined in.<br>
    &gt;&gt;<br>
    &gt;&gt;&gt;      While a lot of these regulations seem reasonable, the Debian<br>
    &gt;&gt;&gt; project<br>
    &gt;&gt;&gt;      believes that there are grave problems for Free Software projects<br>
    &gt;&gt;&gt;      attached to them. Therefore, the Debian project issues the<br>
    &gt;&gt;&gt; following<br>
    &gt;&gt;&gt;      statement:<br>
    &gt;&gt;&gt;<br>
    &gt;&gt;&gt;      1.  Free Software has always been a gift, freely given to<br>
    &gt;&gt;&gt; society, to<br>
    &gt;&gt;&gt;      take and to use as seen fit, for whatever purpose. Free Software<br>
    &gt;&gt;&gt; has<br>
    &gt;&gt;&gt;      proven to be an asset in our digital age and the proposed EU Cyber<br>
    &gt;&gt;&gt;      Resilience Act is going to be detrimental to it.<br> &gt;&gt;&gt;          a.  It is Debian&#39;s goal to &quot;make the best system we can, so<br>
    &gt;&gt;&gt; that<br>
    &gt;&gt;&gt;      free works will be widely distributed and used.&quot; Imposing<br>
    &gt;&gt;&gt; requirements<br>
    &gt;&gt;&gt;      such as those proposed in the act makes it legally perilous for<br>
    &gt;&gt;&gt; others<br>
    &gt;&gt;&gt;      to redistribute our works and endangers our commitment to<br>
    &gt;&gt;&gt; &quot;provide an<br>
    &gt;&gt;&gt;      integrated system of high-quality materials _with no legal<br>
    &gt;&gt;&gt; restrictions_<br>
    &gt;&gt;&gt;      that would prevent such uses of the system&quot;. (3)<br> &gt;&gt;<br>
    &gt;&gt; Debian does not sell products in the single market. Why would any<br>

    [continued in next message]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ilu@21:1/5 to All on Mon Nov 13 19:40:01 2023
    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, <ilulu@gmx.net> 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 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.






    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Helmut Grohne@21:1/5 to All on Mon Nov 13 20:50:01 2023
    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-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.

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

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

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

    This can be read from e.g.

    (10) ... a commercial activity might be characterized not only by
    charging a price for a product, but also by charging a price for
    technical support services, ...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    I think this is partially covered by Article 4.

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

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

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

    Helmut

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Philip Hands@21:1/5 to perezmeyer@gmail.com on Tue Nov 14 02:30:01 2023
    Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com> writes:
    ...
    Just to be clear: I also do agree with the main intention of the
    proposal, what I do not like is that the current draft wording might
    backfire on us.

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

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

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

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

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

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

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

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

    --=-=-Content-Type: application/pgp-signature; name="signature.asc"

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

    iQIzBAEBCgAdFiEE3/FBWs4yJ/zyBwfW0EujoAEl1cAFAmVSyrsACgkQ0EujoAEl 1cCYFhAAg0PisVli0S2AVLc09J11eHJNvfnnKPUBZ9srxBXxZeRL8y3UE2Abl6J7 6iHf813QEuiWqa9Acboy2GFcB3XHVIargJhBW6DwjviyEuO44hrIBoThD5zFKpJ/ EjdLSRkjwgPCExBBNmfi22AXsEHXpU6HyMyABX0hE7mBInTZnJnYaPzfPwoIuHiC Oa3xgB+vgzWiTVYGOqP5ITku0dRAbIs0nsjnHGyDDIR4Hlgv0laalBJzr38JjMWo UXFVyNooWp8iA1kvLLKc6i3j6iqHaCyys8SJ9QUsGLcgNOPsMTZ8IIiKax7H3OZe a8+z6zy/OrSGvm2HD6xUeebBDAOvmC3HuK5SgRKb+rb6fLO13roD1F7J2JrEAnnk q9TELGirHtO826ZgNfIB3DcGdIq94HKh9Graad5ln1/mYk0IfzLGzgvv5AVaUX9x cj3QY4EfqkaVIs86ac6lkZKTMa61uA1Fv0d/P78l0jF+xCIZEiM5gb/77b20CcGA 8OX+I08digpn8UQmomvTVG9P7CQfq27YWtFsr0sN95zkiGiBo0NLEVBXrMVAB9l/ qvBRXKa48hcmawwwhlU+B77DyLZGVlaaYaVRF14NcCTErqM3VvSOqrTQXIvwIubw YmFUvq+fXQ24N9jEdg/5NlPTtKSiy82aJHs3ixxyiwHagDMg8xs=9tQK
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gatewa
  • From Luca Boccassi@21:1/5 to All on Wed Nov 15 01:50:01 2023
    On Sun, 2023-11-12 at 12:10 -0300, Santiago Ruano Rincón wrote:
    Dear Debian Fellows,

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

    Hi Santiago,

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

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

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

    ----- GENERAL RESOLUTION STARTS -----

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

    The European Union is currently preparing a regulation "on horizontal
    cybersecurity requirements for products with digital elements" known as
    the Cyber Resilience Act (CRA). It's currently in the final "trilogue"
    phase of the legislative process. The act includes a set of essential
    cybersecurity and vulnerability handling requirements for manufacturers.
    It will require products to be accompanied by information and
    instructions to the user. Manufacturers will need to perform risk
    assessments and produce technical documentation and for critical
    components, have third-party audits conducted. Security issues under
    active exploitation will have to be reported to European authorities
    within 24 hours (1). The CRA will be followed up by an update to the
    existing Product Liability Directive (PLD) which, among other things,
    will introduce the requirement for products on the market using software
    to be able to receive updates to address security vulnerabilities.

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

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

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

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

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

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

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

    Sources:

    (1) CRA proposals and links:
    https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-proposal-for-cybersecurity-regulation
    PLD proposals and links:
    https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-new-product-liability-directive
    Response from the European Commission to a question from the European Parliament on FOSS awareness:
    https://www.europarl.europa.eu/doceo/document/E-9-2023-002473-ASW_EN.html

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

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

    --
    Kind regards,
    Luca Boccassi

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

    iQIzBAABCgAdFiEErCSqx93EIPGOymuRKGv37813JB4FAmVUFZAACgkQKGv37813 JB6jUA//fVQ9ohPk7DhKvxjTorhywfn9l6TGiJ2bC8fKencM+TV8Y1cfVwujX1zE dcLvoihrEDgOnNcopS6pj5gl7O/5C7wQNA8XkFYJAKJowtxbluyP7cTDJyMRh/vl K2ljSUcBg62+G5eoJjwCtF3UqMI0mM/Ecj7CcpL1XRuvAjS7kv6fbTJFuE5tnGh8 184YYj8RjazM8io/czCs84xzPBLG1fTgg6xajgXL2aK+NPgvoT6HIdBQ6rV6nE76 tyOY82/AJqmlk6kkJ9lI2ZiYGjYjLEhCbuMlfu7trOUlt70wNvjGMuGBhwidh6aZ wD4OOv4bpBKBc9Cg1W5Ja0TF0+hQxIN2ZljttwEGenHyQVvivFKgJbjdwRBSoFtu UWpAZrfVvOp1WXfWGOTthT9G+E8O8IFP/qNvagaKEMTWX9jVLYghzOhhvbtgX0tu QyRnV+hy3lAoqWyGbOC96RcI9iTr9RSS/nPpExLZZEVxdSnoUG7qbVLdYGhm/GSZ 6aU430LiNCfHymSNMpAUT17wQSDSq1ohcXwK4QQKmzSNaY/tHYiz23dWEZbBVyHg xk6qTYCrNP4J0EZokNREG+4fCq+tzM80mlAuw8mjwj8JhIQTj7okp4ueLNqZPgQL Qpn2nCSBkrnN11I0P4As3WGTC5y7J/rGYkGFdKtVn4lCUS5QfAs=
    =ADOh
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lucas Nussbaum@21:1/5 to Luca Boccassi on Wed Nov 15 07:30:01 2023
    On 15/11/23 at 00:49 +0000, Luca Boccassi wrote:
    What do you think? Here's what I came up with:

    Hi,

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

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

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

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

    , which has caused uncertainty and
    worry among Free and Open Source Software developers and stakeholders.

    Therefore, the Debian project requests the legislators to enhance the

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

    Lucas

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

    iQIzBAABCgAdFiEE/t7ByzN7z1CfQ8IkORS1MvTfvpkFAmVUY8MACgkQORS1MvTf vpnuGhAAoAh6DyTg7OTMuWd8HizPkgtSWtGwUTnM3qvyRgrjiRNxPqE+7tdbOelt 50P0dmwJKbTgWQEh27xJv5ZMVze5Gm3js1N60viGzN995j65+goSeo5zeuFYuWtg KIgcbCFdJCnV4l32I6kQTLaXOXB319TvwT4J7c/hMcdI4q0eZeHJonkzLSrONI3F i32pZsGMuMKi/5lXbDzY0MNyDjbSjGDiUZ5JRyuaH8C+S94utvSWZn/jJd4IsVMm lebBdxqk5EAbWOzBOasNtzy3ZIqt1CdDPDo1r4uJcUNMsyj33iE9PPqfxtupkKFQ X9iLxY/sPItTqhzVJ44YVqEpXKCztJPDhxj9pJ5IKzaqNIlK1moMgvr4AjqrxLp5 jK54TdIIfmsFEckP0JNuRyh3RSoFrBGGpXfgY/cT9TJ2BxRbMrH3D45ZiLO1D0Hh 8dPgkYKr/Hb508ZUrX0E89AwS9wZzWK2kRZSQD0Y1bIWMtRPdYF/4jQ5EAmZObKs DmRoUfsep5B8f2T9qa03GZ1at08cEPnP9XQYTe2ZX/zgRtF8nZUH8Taw6kXqj7PR IAQBfq3rf3UW1U6AQ+PxzSfvMM/kAuqMCWBtdq+8uFO9OWSIS96XwlrlhvMqQHtk K1EdPAGrSI/SXrY4JuXTnfSfmpjrF665D1QRx8RPRWxOfbKAwzs=
    =w5ce
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Aigars Mahinovs@21:1/5 to Simon Richter on Wed Nov 15 12:30:02 2023
    On Wed, 15 Nov 2023 at 12:14, Simon Richter <sjr@debian.org> wrote:

    Hi,

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

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

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

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


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

    --
    Best regards,
    Aigars Mahinovs

    <div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 15 Nov 2023 at 12:14, Simon Richter &lt;<a href="mailto:sjr@debian.org">sjr@debian.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote"
    style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>

    On 11/15/23 15:22, Lucas Nussbaum wrote:<br>

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

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

    That is exactly why I think this is dangerous: I want GitLab and Proxmox <br> to be responsible for what they release, but it is very difficult to <br>
    draw a line between their offering and what Microsoft is doing by paying <br> for systemd development while they are also selling Azure cloud.<br clear="all"></blockquote><div><br></div><div>Why should there be a borderline between that? Microsoft has to be responsible </div><div>for what they are selling in the Azure cloud (pre-
    defined images), regardless of</div><div>the systemd developer work. <br></div></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Best regards,<br>    Aigars Mahinovs</div></div></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Luca Boccassi@21:1/5 to Lucas Nussbaum on Wed Nov 15 12:40:01 2023
    On Wed, 15 Nov 2023 at 06:23, Lucas Nussbaum <lucas@debian.org> wrote:

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

    Hi,

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

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

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

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

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

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

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

    , which has caused uncertainty and
    worry among Free and Open Source Software developers and stakeholders.

    Therefore, the Debian project requests the legislators to enhance the

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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Richter@21:1/5 to Lucas Nussbaum on Wed Nov 15 12:20:01 2023
    Hi,

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

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

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

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

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

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

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

    So:

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

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

    We should at least identify

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

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

    Simon

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Santiago Ruano =?iso-8859-1?Q?Rinc=@21:1/5 to All on Wed Nov 15 14:10:02 2023
    El 15/11/23 a las 00:49, Luca Boccassi escribió:
    On Sun, 2023-11-12 at 12:10 -0300, Santiago Ruano Rincón wrote:
    Dear Debian Fellows,

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

    Hi Santiago,

    Hello Luca


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

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

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

    ----- GENERAL RESOLUTION STARTS -----

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

    The European Union is currently preparing a regulation "on horizontal
    cybersecurity requirements for products with digital elements" known as
    the Cyber Resilience Act (CRA). It's currently in the final "trilogue"
    phase of the legislative process. The act includes a set of essential
    cybersecurity and vulnerability handling requirements for manufacturers.
    It will require products to be accompanied by information and
    instructions to the user. Manufacturers will need to perform risk
    assessments and produce technical documentation and for critical
    components, have third-party audits conducted. Security issues under
    active exploitation will have to be reported to European authorities
    within 24 hours (1). The CRA will be followed up by an update to the
    existing Product Liability Directive (PLD) which, among other things,
    will introduce the requirement for products on the market using software
    to be able to receive updates to address security vulnerabilities.

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

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

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

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

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

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

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

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

    Sources:

    (1) CRA proposals and links:
    https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-proposal-for-cybersecurity-regulation
    PLD proposals and links:
    https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-new-product-liability-directive
    Response from the European Commission to a question from the European Parliament on FOSS awareness:
    https://www.europarl.europa.eu/doceo/document/E-9-2023-002473-ASW_EN.html

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

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

    Just a quick comment:

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

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

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

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

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

    Cheers,

    -- Santiago

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

    iHUEABYIAB0WIQRZVjztY8b+Ty43oH1itBCJKh26HQUCZVTAwgAKCRBitBCJKh26 Ha9TAQCoTT+7J3cnyxVdtW9sQg2SFdj8a8CnY+V9mqRZf+mMWgEA3fSgNmzKRnzS 6hJE+1yz0YnZWAOR9p4eGGF5IR4t0AU=
    =9eBY
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lucas Nussbaum@21:1/5 to Luca Boccassi on Wed Nov 15 15:00:02 2023
    On 15/11/23 at 11:38 +0000, Luca Boccassi wrote:
    On Wed, 15 Nov 2023 at 06:23, Lucas Nussbaum <lucas@debian.org> wrote:

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

    Hi,

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

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

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

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

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

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

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

    This looks better, thanks!

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

    Lucas

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Luca Boccassi@21:1/5 to santiagorr@riseup.net on Wed Nov 15 15:00:01 2023
    On Wed, 15 Nov 2023 at 12:59, Santiago Ruano Rincón
    <santiagorr@riseup.net> wrote:

    El 15/11/23 a las 00:49, Luca Boccassi escribió:
    On Sun, 2023-11-12 at 12:10 -0300, Santiago Ruano Rincón wrote:
    Dear Debian Fellows,

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

    Hi Santiago,

    Hello Luca


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

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

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

    ----- GENERAL RESOLUTION STARTS -----

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

    The European Union is currently preparing a regulation "on horizontal
    cybersecurity requirements for products with digital elements" known as
    the Cyber Resilience Act (CRA). It's currently in the final "trilogue"
    phase of the legislative process. The act includes a set of essential
    cybersecurity and vulnerability handling requirements for manufacturers.
    It will require products to be accompanied by information and
    instructions to the user. Manufacturers will need to perform risk
    assessments and produce technical documentation and for critical
    components, have third-party audits conducted. Security issues under
    active exploitation will have to be reported to European authorities
    within 24 hours (1). The CRA will be followed up by an update to the
    existing Product Liability Directive (PLD) which, among other things,
    will introduce the requirement for products on the market using software
    to be able to receive updates to address security vulnerabilities.

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

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

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

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

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

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

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

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

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

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

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

    Sources:

    (1) CRA proposals and links:
    https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-proposal-for-cybersecurity-regulation
    PLD proposals and links:
    https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-new-product-liability-directive
    Response from the European Commission to a question from the European Parliament on FOSS awareness:
    https://www.europarl.europa.eu/doceo/document/E-9-2023-002473-ASW_EN.html

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

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

    Just a quick comment:

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

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

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

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

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

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

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

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

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

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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lucas Nussbaum@21:1/5 to Luca Boccassi on Wed Nov 15 15:20:01 2023
    On 15/11/23 at 14:13 +0000, Luca Boccassi wrote:
    On Wed, 15 Nov 2023 at 13:53, Lucas Nussbaum <lucas@debian.org> wrote:

    On 15/11/23 at 11:38 +0000, Luca Boccassi wrote:
    On Wed, 15 Nov 2023 at 06:23, Lucas Nussbaum <lucas@debian.org> wrote:

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

    Hi,

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

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

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

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

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

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

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

    This looks better, thanks!

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

    How about:

    ...if Free and Open Source Software developers and contributors can continue to
    work on these projects as they have been doing before these new
    regulations, especially but not exclusively in the context of
    nonprofit organizations,
    without being encumbered by legal requirements that are only appropriate for commercial companies and enterprises.

    Great thanks!

    Lucas

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Richter@21:1/5 to Aigars Mahinovs on Thu Nov 16 07:00:01 2023
    Hi,

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

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

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

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

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

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

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

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

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

    Simon

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Lisandro_Dami=C3=A1n_Nica@21:1/5 to Simon Richter on Thu Nov 16 14:10:01 2023
    On Thu, 16 Nov 2023 at 02:54, Simon Richter <sjr@debian.org> wrote:
    [snip]
    That would also be a consistent position: "as long as the source code is public under a DFSG-compliant license, the open source exemption should
    apply even to works produced for commercial gain."

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

    Yeah... maybe something like:

    "as long as the source code is public under a DFSG-compliant license,
    the open source exemption should apply even to works produced for
    commercial gain, except the final user is in a direct contract with
    the company developing it"

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

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

    Same here.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ilu@21:1/5 to All on Fri Nov 17 05:50:02 2023
    I mixed up one of the links: The first link under (1) should be https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-european-cyber-resilience-act
    All that talk about cybersecurity at the EU these days got me confused. :-)

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

    Am 12.11.23 um 16:10 schrieb Santiago Ruano Rincón:
    Dear Debian Fellows,

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

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

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

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

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

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

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

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

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

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

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

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

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

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


    Sources:

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

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

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

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

    Cheers,

    -- Santiago

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bart Martens@21:1/5 to Lucas Nussbaum on Sat Nov 18 18:20:01 2023
    On Wed, Nov 15, 2023 at 02:52:31PM +0100, Lucas Nussbaum wrote:
    I wonder if we should have something like "Free software development by nonprofit organizations" somewhere.

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

    Cheers,
    Bart

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sam Hartman@21:1/5 to All on Sat Nov 18 20:10:02 2023
    "Bart" == Bart Martens <bartm@debian.org> writes:

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

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

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

    So let's consider some situations.

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

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

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

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

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

    --Sam

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bart Martens@21:1/5 to Aigars Mahinovs on Sat Nov 18 20:00:01 2023
    On Mon, Nov 13, 2023 at 03:57:44PM +0100, Aigars Mahinovs wrote:
    On Mon, 13 Nov 2023 at 15:51, Lisandro Damián Nicanor Pérez Meyer < perezmeyer@gmail.com> wrote:

    On Mon, 13 Nov 2023 at 11:50, Aigars Mahinovs <aigarius@gmail.com> wrote:
    Whether accepting donations *in general* makes your activity in
    providing software a "commercial activity" in the context of
    this directive proposal is not really a supported notion in the text.
    There are a few specific examples of what does make
    a "commercial activity" in point 10, but none of those examples directly
    apply to general donations to a project or person.

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


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

    It does. Quoted by Ilu: "Accepting donations without the intention of making a profit should not count as a commercial activity, unless such donations are made by commercial entities and are recurring in nature."


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

    --
    Best regards,
    Aigars Mahinovs

    --

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Emmanuel Arias@21:1/5 to All on Sat Nov 18 20:40:01 2023
    Hi,

    Sorry I did not note that I did not sign this message. 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-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).

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

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

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

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

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

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

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

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

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

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

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

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

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


    Sources:

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

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

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

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

    Cheers,

    -- Santiago

    Cheers,
    Emmanuel

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

    iQIzBAABCgAdFiEEE3lnVbvHK7ir4q61+p3sXeEcY/EFAmVZEpEACgkQ+p3sXeEc Y/H4XxAAvHK/uMPGbx6oNJDkC7v8wwUz71JFrRzD2ZN0czHw5hwfIV0M0DyVC/IW TZ9MxoYigpyIKVOslIf951GGVEaZ23CWKKAKknfTf5WMjX+Eow5jPV7JAgadgAA7 lkqxeuGjA4IG3hvZALOOI8/F2jQ+4aaA48HlYcSqP9PUIr9PD3UnrSoq2v7r+Sd6 SoD8sfLGpCpwizS2dcc2bSYmoe7Jjuu8Y7dFGWe/1Q5WzYuqGSa800D4Su6TKLMS btHHX9NfmiN7sXqPje9B6jqLx6jGwUmJGSnWDRXzZylsRLDSiORFFNbtmOkUscwS o4aZV15Yk7VUnQgFFkSsefw3RVxBvS0tQHx11si4RnBH3RI+b3CGFF0Gbe7EBufb alNP+vCfWuypCpbL39bc/nvGqwNRIwxKHgiIQpXeUYgXHCeYTOBaZYoy+3mwNTi+ kiV+F7NYF92/hY4h2ZhXqJsCkNQW6cxdCqQ85vhskXgPCE1AwkYjsGCE1G8xYloz qAux1k8HT/lYjW3AvUbhkzmiGXst3+W736iL4QH7livCQBDlLv4R2MAOvm/iMaaA MPRpgAbMkJMTs0vl8vrCpMjVCrzd8Hw/w/XFbF2flWWzJzabKVkY+XPV3GVb0fg6 ZP0Pq6gRgcXlWDtkuJ04wWU4k7TYjYk7ofAUyx5P7rVAv8bdh7A=
    =4Qeh
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bart Martens@21:1/5 to Sam Hartman on Sat Nov 18 23:20:01 2023
    On Sat, Nov 18, 2023 at 11:43:27AM -0700, Sam Hartman wrote:
    "Bart" == Bart Martens <bartm@debian.org> writes:

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

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

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

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


    So let's consider some situations.

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

    I follow that.


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

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


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

    Example of such software in Debian?

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

    We have a different opinion on that.


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

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

    I follow those two points.

    Cheers,
    Bart


    --Sam

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sam Hartman@21:1/5 to All on Sun Nov 19 01:30:01 2023
    "Bart" == Bart Martens <bartm@debian.org> writes:
    >>
    >> * A commercial company writes free-software that for all
    >> practical purposes can be used only for access to their
    >> proprietary web service. I'd rather not allow arguments about
    >> whether a flaw is on the web service side or the client API side
    >> to be used to help the company get out of liability to their
    >> customers/users.

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

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

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

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

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

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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Luca Boccassi@21:1/5 to Sam Hartman on Mon Nov 20 00:30:01 2023
    On Sun, 19 Nov 2023 at 00:21, Sam Hartman <hartmans@suchdamage.org> wrote:

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

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

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

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

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

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

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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Luca Boccassi@21:1/5 to All on Mon Nov 20 00:30:01 2023
    Second version, taking into account feedback. Looking for seconds at
    this point:

    ----- GENERAL RESOLUTION STARTS -----

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

    The European Union is currently preparing a regulation "on horizontal
    cybersecurity requirements for products with digital elements" known as
    the Cyber Resilience Act (CRA). It's currently in the final "trilogue"
    phase of the legislative process. The act includes a set of essential
    cybersecurity and vulnerability handling requirements for manufacturers.
    It will require products to be accompanied by information and
    instructions to the user. Manufacturers will need to perform risk
    assessments and produce technical documentation and for critical
    components, have third-party audits conducted. Security issues under
    active exploitation will have to be reported to European authorities
    within 24 hours (1). The CRA will be followed up by an update to the
    existing Product Liability Directive (PLD) which, among other things,
    will introduce the requirement for products on the market using software
    to be able to receive updates to address security vulnerabilities.

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

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

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

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

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

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

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

    Sources:

    (1) CRA proposals and links:
    https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-proposal-for-cybersecurity-regulation
    PLD proposals and links:
    https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-new-product-liability-directive
    Response from the European Commission to a question from the European Parliament on FOSS awareness:
    https://www.europarl.europa.eu/doceo/document/E-9-2023-002473-ASW_EN.html

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

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

    --
    Kind regards,
    Luca Boccassi

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

    iQIzBAABCgAdFiEErCSqx93EIPGOymuRKGv37813JB4FAmVamIsACgkQKGv37813 JB5UvQ/7BohXrjs6Y2hMcgFyOVQ3FsIZuJ7n6eZqYGwtPS8QyZHdUJNLnKPn2O4z fH9jcZyMLePV+V+bMwGqWuHb9NF7yru0HJ06vXB2mscjuuPTdclNt8khczl5HIai toqneT/SOov7XMeW4jN6jcF1pJ53hrZuitjffId8S8quTa1dgDRX+VVhvR6vPGuJ gm7rNjzEIIL3Ys53nn19aqAV7MXSh15ZTUTrhDb9H2qVQS+hXjZwQLPXDGLoWESz yo2cNqrIOBdHZwa7ulpOdw9Dl5H5v17P1kNeB0FLVxfErAdA+NjIbo7T5q42xCdy DvL2nfXSMpID0AmVSplFyzSllUJENtbGbQklQ/2XQbGnSpsgkX5dTtIoCWLfFVWm ehI/KflAnoMD1u0aHuRn9Hd57zTOyB7+K0YAAbnO2zYD7HBCzI5Bk5l7SoJG6XtD 8oERWJaExzvDyjp1rm+JGobVxB2Q4bz1JiFR4uOyHxpbZtRbwBoFW6Qo5PaLcTja IXXsgNJ8Bpk+Y1+nJaPLEYm5Kof0W+mXdMgLp9qtHM+yvIHj7aSjcVrp96vWtbqO QSMYhltun9LDPJn8/Rwpzh7Wwj5w8XwOe88c/sA/R2a/AJtL2aQhXNwfLLkHQ4xn WvPxTp+nduOGVo9w54guxZHSsq+kxISuSfZ9GEefgUl/r3DDthw=
    =ZKF9
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Aigars Mahinovs@21:1/5 to All on Mon Nov 20 00:50:02 2023
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA256

    I second adding this version to the vote

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

    ----- GENERAL RESOLUTION STARTS -----

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

    The European Union is currently preparing a regulation "on horizontal
    cybersecurity requirements for products with digital elements" known as
    the Cyber Resilience Act (CRA). It's currently in the final "trilogue"
    phase of the legislative process. The act includes a set of essential
    cybersecurity and vulnerability handling requirements for manufacturers.
    It will require products to be accompanied by information and
    instructions to the user. Manufacturers will need to perform risk
    assessments and produce technical documentation and for critical
    components, have third-party audits conducted. Security issues under
    active exploitation will have to be reported to European authorities
    within 24 hours (1). The CRA will be followed up by an update to the
    existing Product Liability Directive (PLD) which, among other things,
    will introduce the requirement for products on the market using software
    to be able to receive updates to address security vulnerabilities.

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

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

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

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

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

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


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

    Sources:

    (1) CRA proposals and links:

    https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-proposal-for-cybersecurity-regulation
    PLD proposals and links:

    https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-new-product-liability-directive
    Response from the European Commission to a question from the European Parliament on FOSS awareness:

    https://www.europarl.europa.eu/doceo/document/E-9-2023-002473-ASW_EN.html

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

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

    - --
    Kind regards,
    Luca Boccassi

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

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

    <div dir="ltr"><div>-----BEGIN PGP SIGNED MESSAGE-----<br>Hash: SHA256<br><br>I second adding this version to the vote<br><br>On Mon, 20 Nov 2023 at 00:22, Luca Boccassi &lt;<a href="mailto:bluca@debian.org">bluca@debian.org</a>&gt; wrote:<br>Second
    version, taking into account feedback. Looking for seconds at<br>this point:<br><br>    ----- GENERAL RESOLUTION STARTS -----<br><br>    Debian Public Statement about the EU Cyber Resilience Act and the<br>    Product Liability Directive<br><br>  Â
      The European Union is currently preparing a regulation &quot;on horizontal<br>    cybersecurity requirements for products with digital elements&quot; known as<br>    the Cyber Resilience Act (CRA). It&#39;s currently in the final &quot;trilogue&
    quot;<br>    phase of the legislative process. The act includes a set of essential<br>    cybersecurity and vulnerability handling requirements for manufacturers.<br>    It will require products to be accompanied by information and<br>   
    instructions to the user. Manufacturers will need to perform risk<br>    assessments and produce technical documentation and for critical<br>    components, have third-party audits conducted. Security issues under<br>    active exploitation will
    have to be reported to European authorities<br>    within 24 hours (1). The CRA will be followed up by an update to the<br>    existing Product Liability Directive (PLD) which, among other things,<br>    will introduce the requirement for products
    on the market using software<br>    to be able to receive updates to address security vulnerabilities.<br><br>    Given the current state of the electronics and computing devices market,<br>    constellated with too many irresponsible vendors not
    taking taking<br>    enough precautions to ensure and maintain the security of their products,<br>    resulting in grave issues such as the plague of ransomware (that, among<br>    other things, has often caused public services to be severely
    hampered or<br>    shut down entirely, across the European Union and beyond, to the<br>    detriment of its citizens), the Debian project welcomes this initiative<br>    and supports its spirit and intent.<br><br>    The Debian project believes
    Free and Open Source Software Projects to be<br>    very well positioned to respond to modern challenges around security and<br>    accountability that these regulations aim to improve for products<br>    commercialized on the Single Market. Debian
    is well known for its<br>    security track record through practices of responsible disclosure and<br>    coordination with upstream developers and other Free and Open Source<br>    Software projects. The project aims to live up to the commitment
    made in<br>    the Debian Social Contract: &quot;We will not hide problems.&quot; (2)<br><br>    The Debian project welcomes the attempt of the legislators to ensure<br>    that the development of Free and Open Source Software is not negatively<br>Â
        affected by these regulations, as clearly expressed by the European<br>    Commission in response to stakeholders&#39; requests (1) and as stated in<br>    Recital 10 of the preamble to the CRA:<br><br>     &#39;In order not to hamper
    innovation or research, free and open-source<br>      software developed or supplied outside the course of a commercial<br>      activity should not be covered by this Regulation.&#39;<br><br>    The Debian project however notes that not enough
    emphasis has been<br>    employed in all parts of these regulations to clearly exonerate Free<br>    and Open Source Software developers and maintainers from being subject<br>    to the same liabilities as commercial vendors, which has caused<br> 
      uncertainty and worry among such stakeholders.<br><br>    Therefore, the Debian project asks the legislators to enhance the<br>    text of these regulations to clarify beyond any reasonable doubt that<br>    Free and Open Source Software
    developers and contributors are not going<br>    to be treated as commercial vendors in the exercise of their duties when<br>    merely developing and publishing Free and Open Source Software, with<br>    special emphasis on clarifying grey areas,
    such as donations,<br>    contributions from commercial companies and developing Free and Open<br>    Source Software that may be later commercialised by a commercial vendor.<br>    It is fundamental for the interests of the European Union itself
    that<br>    Free and Open Source Software development can continue to thrive and<br>    produce high quality software components, applications and operating<br>    systems, and this can only happen if Free and Open Source Software<br>   
    developers and contributors can continue to work on these projects as<br>    they have been doing before these new regulations, especially but not<br>    exclusively in the context of nonprofit organizations, without being<br>    encumbered by
    legal requirements that are only appropriate for<br>    commercial companies and enterprises.<br><br>    ==========================================================================<br><br>    Sources:<br><br>    (1) CRA proposals and links:<br>  Â
      <a href="https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-proposal-for-cybersecurity-regulation">https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-proposal-for-
    cybersecurity-regulation</a><br>    PLD proposals and links:<br>    <a href="https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-new-product-liability-directive">https://www.europarl.europa.eu/legislative-
    train/theme-a-europe-fit-for-the-digital-age/file-new-product-liability-directive</a><br>    Response from the European Commission to a question from the European Parliament on FOSS awareness:<br>    <a href="https://www.europarl.europa.eu/doceo/
    document/E-9-2023-002473-ASW_EN.html">https://www.europarl.europa.eu/doceo/document/E-9-2023-002473-ASW_EN.html</a><br><br>    (2) Debian Social Contract No. 2, 3 and 4<br>    <a href="https://www.debian.org/social_contract">https://www.debian.org/
    social_contract</a><br><br>    ----- GENERAL RESOLUTION ENDS -----<br><br>- --<br>Kind regards,<br>Luca Boccassi<br><br>-----BEGIN PGP SIGNATURE-----<br><br>iQIzBAEBCAAdFiEEFmwrqIlWRDzdY39G+mQ7ph0ievsFAmVanPAACgkQ+mQ7ph0i<br>
    evuStBAAtXUNvhfZyTkUxOxB5i5o0P+bbkx5Abs8UU+LICRARCBIJ4aGdlQWMeTp<br>Ye09hD3cBbbTtgid1idmpEOEbSJW1N0vhPLke1W1cJzv3lhSBLwgcb3fyB1KN1Ye<br>PFG7/1cpAssQwfvobcaXG7CFWukWKApU9K84G8dv6DMiSvpMnxkBhzSwfLUnb5Y+<br>H4yZfEn3XdyOociXInxDB+AIVkfXXSwFTFWugYPV+
    SF371pgOhAZtkRhNOzEUjbJ<br>DfPkQ1ljMg69Jrs11b2E9Bhe+zvqjSFUbjBv5y+lCusCtMaI5pKQvQjsuVKPpAY5<br>XtQ3E9Pt8EZQFTohyKe4jsfnUqCGxKXNE7taytTz5Cyf8AeyNsoS4qfXmbVFVTMy<br>hkU5nBHPVYsB9OtjiK+pv1zM29w9o78ChzuFNinE0KQHzX11p39Udfw9VqZGw/zv<br>VVgHZxNIRohXgprqw/
    98nloCQj3akCd7dKFoUNfsl+TBStTrWys6lmvAGvyg/Q00<br>GC7uxn454LhsGAEDdDf2155fSQsiiK7j+O/ZibwXEP/thfcJJwNmOyjVtiRvtdMg<br>CnpXWR4RTe+OS73T7LbaS79pDEa5ZLPuLcbGCbB3O/yi2ZUALIbFK02uwex+19Kw<br>///xr/s+0MXBmiUIZYs+cXZG2u33Vy+GwalbKGhvNN6nRFvvFBY=<br>=av62<br>----
    -END PGP SIGNATURE-----<br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Best regards,<br>    Aigars Mahinovs</div></div></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kurt Roeckx@21:1/5 to Aigars Mahinovs on Mon Nov 20 09:00:01 2023
    On Mon, Nov 20, 2023 at 12:40:58AM +0100, Aigars Mahinovs wrote:
    I second adding this version to the vote

    I'm getting a bad signature on this.

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

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


    Kurt

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Luca Boccassi@21:1/5 to All on Mon Nov 20 11:30:01 2023
    Second version, taking into account feedback. Looking for seconds
    at
    this point:

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

    Already attempted that last week:

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

    Unfortunately time available is limited by the GR process.

    --
    Kind regards,
    Luca Boccassi

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

    iQIzBAABCgAdFiEErCSqx93EIPGOymuRKGv37813JB4FAmVbMx4ACgkQKGv37813 JB6eTxAAtxSehZxPdsOqIUBEQpM9F40DEI8yjZvof1BunajGL5gF8hYZRYug0Gva ilTovnwQ0dm3PDTPkPOZ9mseg0GL9wrHEydFHB/T2qNgxvvU1mApBoCFeeBH97GZ EhZTK1G1xqmsguWK3dK9UELX+7WcGf8sSYDk8yOhpM/lvXk2FL3BCzG51XVES3A3 GqAKnrNEbz6DDG6o3EzfDkEjv3pL6H0n2VBxW7L8YxXTdSsuvyZMQaZqCHlUjhL6 WQxOeoXUFtMXyRN1CXFzJgzSVE9kqe5lxGu85MJolSXB+yQRG1exsK8RsQU78Jpx S8tSBTstc73gyVmbSubZxjKnZJH8p4trBZsozdMTZG8MNLJU07U1bJMVCIHFVzv6 w/dJkkRwLWN2IayuWIE12JIPYUwNBDLSIYw+46wIqHoCLW6/4Atmw2/GOMZiJEbh 87UNUivAIl6SZpGAgdicAbO8mTZ6s0vi34Ut++NFnK5Bp+MZjIvILvImt1Xfm/37 PEzqj6Ui3OG/VQFcvG5Zo1xZsI0/Gc9mQnI4HNrrUGgfKYOnAJFz/vcNu6EQaM28 rXtUGIlM7/3cOYYTjIDGLieip64AATMQH5dcT6H22hqwluqdOxos3y3KEIi0n/yw AJjx6bRNREc5+0Rokr/GA17FzmavphlBiW9dsdLH7gMJXkKphWk=
    =bIvU
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Richter@21:1/5 to Luca Boccassi on Mon Nov 20 15:50:01 2023
    Hi,

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

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

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

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

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

    If we want the "Free and Open Source Software developers and
    contributors" associated with the systemd project to be able to
    "continue to work on these projects as they have been doing before these
    new regulations", then there needs to be a reason why they should be
    included in the FOSS exception, and we need to spell this out *to the
    people involved in the legislative process*, not just insinuate that
    there might be additional criteria they may have missed and leave them
    guessing what they might be.

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

    - Should this be based on the license used?

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

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

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

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

    I'm running out of ideas here.

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

    Simon

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris Hofstaedtler@21:1/5 to All on Mon Nov 20 18:00:01 2023
    I second adding this version.

    * Luca Boccassi <bluca@debian.org> [231119 23:22]:
    Second version, taking into account feedback. Looking for seconds at
    this point:

    ----- GENERAL RESOLUTION STARTS -----

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

    The European Union is currently preparing a regulation "on horizontal
    cybersecurity requirements for products with digital elements" known as
    the Cyber Resilience Act (CRA). It's currently in the final "trilogue"
    phase of the legislative process. The act includes a set of essential
    cybersecurity and vulnerability handling requirements for manufacturers.
    It will require products to be accompanied by information and
    instructions to the user. Manufacturers will need to perform risk
    assessments and produce technical documentation and for critical
    components, have third-party audits conducted. Security issues under
    active exploitation will have to be reported to European authorities
    within 24 hours (1). The CRA will be followed up by an update to the
    existing Product Liability Directive (PLD) which, among other things,
    will introduce the requirement for products on the market using software
    to be able to receive updates to address security vulnerabilities.

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

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

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

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

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

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

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

    Sources:

    (1) CRA proposals and links:
    https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-proposal-for-cybersecurity-regulation
    PLD proposals and links:
    https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-new-product-liability-directive
    Response from the European Commission to a question from the European Parliament on FOSS awareness:
    https://www.europarl.europa.eu/doceo/document/E-9-2023-002473-ASW_EN.html

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

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

    --
    Kind regards,
    Luca Boccassi



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

    iQIzBAABCAAdFiEEfRrP+tnggGycTNOSXBPW25MFLgMFAmVbjxYACgkQXBPW25MF LgPBhhAAkYNo1UByPhnG+hPBS5JsRTVa5EmuGFReWawrVFZQYseEJo2eFmWdLSB0 slPEIgrIQtLiJnqFTtZbcQ2NK2KzWwgk5IWLQe9QgR/81asIm8P8v+K5wmccS8y2 dDxg5hDWWSx1tGvgzZw4DQSSUE5OsP+6Gl088JmBnRHqUChWhMVM2VHmpOWxjwec JktK065u/kndV5wGmJhmTdRSQymauYWKmscwpPBXGorKOzFUX/nBYlNAqRL8WerS zcj+CP4rLM1an5ru5QjZT1l3FWu5nxyTzEt03/RahZZFhxco3MHig1mEEZSVt6wv Z7hxjddgqWyB9Ou06CFIxKI1HVk0SVYYPe92cwDf51ZswVDk7QSDgcTXiYyHZ8/K Tjeu9+sbY1pKggYSnP2rUUjRsFkHvDeIvEZo23rQ20uikpXjdDCGVRVq8XUOLFcW vHR4lAmuy0585CXET+WJSX6ea/OYdouUnkRTh1M7dDjZ4xqIkCtzOd7Incb7BBPS pk0pWKHpMX+TNyYAer5/gIg26rcyiVPc7tQC9AhbspaNhK7jsPW33IG8mwNt6lTE fjLOLOcjdv2V2EuCM0KFTr9qLIsumd3AVq0bQTGjxdCTjvcujwF6pbrraiNlWew5 CrAQp+p794BZBQn0gAuPs50tLt0ECDdD+0N2qLh4wFJ7pnlFM/Q=
    =Rcq0
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lucas Nussbaum@21:1/5 to Chris Hofstaedtler on Mon Nov 20 19:50:01 2023
    Seconded.

    On 20/11/23 at 17:54 +0100, Chris Hofstaedtler wrote:
    I second adding this version.

    * Luca Boccassi <bluca@debian.org> [231119 23:22]:
    Second version, taking into account feedback. Looking for seconds at
    this point:

    ----- GENERAL RESOLUTION STARTS -----

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

    The European Union is currently preparing a regulation "on horizontal
    cybersecurity requirements for products with digital elements" known as
    the Cyber Resilience Act (CRA). It's currently in the final "trilogue"
    phase of the legislative process. The act includes a set of essential
    cybersecurity and vulnerability handling requirements for manufacturers.
    It will require products to be accompanied by information and
    instructions to the user. Manufacturers will need to perform risk
    assessments and produce technical documentation and for critical
    components, have third-party audits conducted. Security issues under
    active exploitation will have to be reported to European authorities
    within 24 hours (1). The CRA will be followed up by an update to the
    existing Product Liability Directive (PLD) which, among other things,
    will introduce the requirement for products on the market using software
    to be able to receive updates to address security vulnerabilities.

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

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

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

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

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

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

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

    Sources:

    (1) CRA proposals and links:
    https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-proposal-for-cybersecurity-regulation
    PLD proposals and links:
    https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-new-product-liability-directive
    Response from the European Commission to a question from the European Parliament on FOSS awareness:
    https://www.europarl.europa.eu/doceo/document/E-9-2023-002473-ASW_EN.html

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

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

    --
    Kind regards,
    Luca Boccassi





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

    iQIzBAABCgAdFiEE/t7ByzN7z1CfQ8IkORS1MvTfvpkFAmVbqM8ACgkQORS1MvTf vpl3LQ/+MHutFzi75eheVoEJfCOCwCS51220VrnnKWvlN5rk25IwgknH34gH3elh qEpS4MDyetOGrSUaS5vGDKW2aDToDyV8BFXGJTl7OPJSgaad3N/d0m73Hf2HPQNz J54Dlvvk8RP3psHiEglWMP7UAAm/7LmSZjld5CR1h3EL0pbxopjwZk5R8b4dAVFW QeebzmVtn9EpWnbbnf8I86thxSXDirQaPHg7BeBJ5k24V9dRxg3I8LFf6S7/DRRu JHliE6DKifmwSkUiVFzpP+txR5aa2zqBcL9ehd7F0gkxkxjcjSLswVAmh8A93oNO DdulWRXrtndxdzsFk2E42XKjlQlx9JXfppV4Sue5c9MfDNQqMQXtjVmP2pf7S+h1 PHjavJIuccBa29AgGRBJpKVLQIpsa1A3zDIBrT5QD/vROEjMpz6ldJlh9VZoonmC l7s/+AhDWytvexfTBjJEkTHasv4bDpT0T1E8sNw4dJ4PHeKUDL9TcCCef1zgycwE SifXl/MJK1TM5K8dJsgqapHlupsxz+U+IkbD7dXESa0nUMAVsr3iRTcR/GpeoJWK 6QaXeNdV+shxUEFfJiD0EYQPFezX15CovghE5HD4G9z6D0zs3IzRxlZobC6T1xSM m93pC37Vs0IWN8DRSkAo+DUTMJUlp9gmzKT3+akS/nCpshhOLzw=
    =JWnw
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Luca Boccassi@21:1/5 to Thomas Goirand on Tue Nov 21 16:20:01 2023
    On Tue, 21 Nov 2023 at 08:14, Thomas Goirand <zigo@debian.org> wrote:

    On 11/20/23 00:21, Luca Boccassi wrote:
    Second version, taking into account feedback. Looking for seconds at
    this point:

    ----- GENERAL RESOLUTION STARTS -----

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

    The European Union is currently preparing a regulation "on horizontal
    cybersecurity requirements for products with digital elements" known as
    the Cyber Resilience Act (CRA). It's currently in the final "trilogue"
    phase of the legislative process. The act includes a set of essential
    cybersecurity and vulnerability handling requirements for manufacturers.
    It will require products to be accompanied by information and
    instructions to the user. Manufacturers will need to perform risk
    assessments and produce technical documentation and for critical
    components, have third-party audits conducted. Security issues under
    active exploitation will have to be reported to European authorities
    within 24 hours (1). The CRA will be followed up by an update to the
    existing Product Liability Directive (PLD) which, among other things,
    will introduce the requirement for products on the market using software
    to be able to receive updates to address security vulnerabilities.

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

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

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

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

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

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

    Hi,

    Thanks a lot for taking the time to word out things this way.

    However, I really think this text is being too nice with the EU. The
    feeling in short is reading:
    - what you did was good
    - what you did was good
    - what you did was good
    - oh, btw, there's room for improvement... it'd be nice if...

    That's not at all my feeling about the CRA. I'm once more really unhappy about EU, I feel like we're getting trapped by big corp and their
    lobbying power, and we need to use stronger words.

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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Santiago Ruano =?iso-8859-1?Q?Rinc=@21:1/5 to All on Tue Nov 21 17:20:01 2023
    El 20/11/23 a las 08:53, Kurt Roeckx escribió:
    On Mon, Nov 20, 2023 at 12:40:58AM +0100, Aigars Mahinovs wrote:
    I second adding this version to the vote

    I'm getting a bad signature on this.

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

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

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

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

    Cheers,

    -- Santiago

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

    iHUEABYIAB0WIQRZVjztY8b+Ty43oH1itBCJKh26HQUCZVzXrAAKCRBitBCJKh26 Hei6AP9WAJwCeOYbYQz6+RPeV0RKYLn7CwIRlZXrO8/If15HWwD+J2sDMMmCsEzr IWx8LCqhqHNXBcemLIU1Kzb9CBADEQE=
    =HTbg
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gunnar Wolf@21:1/5 to All on Tue Nov 21 17:40:01 2023
    Santiago Ruano Rincón dijo [Tue, Nov 21, 2023 at 01:15:40PM -0300]:
    I second adding this version to the vote

    I'm getting a bad signature on this.

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

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

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

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

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

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

    Thanks!

    - Gunnar.

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

    iHUEABYIAB0WIQRNFAUGU6QC1zaHBJ0kBMlUbhRTYAUCZVzbXAAKCRAkBMlUbhRT YBdXAP4uZF6eU0bpPkL5q2KUS1WVsqCwIX0FoTeTwq52zc2FjAEA8fRpw1e4Zbyd xwEdENyTPEACYtLZ73ceEKzeiS4Ezg4=
    =L+XI
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Salvo Tomaselli@21:1/5 to All on Tue Nov 21 17:46:39 2023
    Copy: bluca@debian.org (Luca Boccassi)

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

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

    It is still impossible to uninstall edge...


    --
    Salvo Tomaselli

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

    https://ltworf.codeberg.page/
    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCAAdFiEEQnSLnnbYmXmeH74Us6fPDIAYhs8FAmVc3u8ACgkQs6fPDIAY hs9g1A//Q7Ou/3fnFHzwMWEmtsYCh11UY8LmG6r/NbkHUV1tEJfzN3RooaEJUM8H BtI4G9R5hGlllLFMnkz89me8qVVPtQFjE4jbAu2WEEosNySNaGGrQ0oQUtCS1hBy YjxC/vhVYuRk5ubqUiqEnY/4txgTOBO+N9agx4JGqi80r/FJ2Yo5I2FZ/U8KHoWZ g4bkvi0VMxIDXn4nd9uB9wXZBnvExHGcU+6zp6e2/6pAP6D7y9UBrYWUZxFlzMLp SwYRh8gnNkfr8QO+t+S/F8Ho3dUiW+JeAY9FMgYupuy3pNYDADwhaPbQML1a1oWX 6GkF0JK+nNlWoGj86zSd3vVFbfoIWQ3E98utJ1sGXzr/ILMtJ4jUyuMA2KocO9dL v+VDdBKDaou32SlLee73Nk305g6RgEE6gd5uO95E2wlVzHIC1SzPBNRmzJBf23nr ENRC/U9+6qIAC6CdaUOoTEdQIm/U7ivDa0SEEkbJPee2u/wv8g/3jJQO5nIbTFi3 tZ8ioJwCkIDXEUpoVNam68Q4HfVdxtrnyhc2uOnAvZ+sRAqbo03L2N4NkGQyhZ0b FNWw6es0jk+357dC0Iinc30qdJYDJ6LM4MLaZhZQDAKl+Q5PVMwFx+8HucCsIF7Y u+tw3ZHZREDrRX0f0nXAhNw08
  • From Luca Boccassi@21:1/5 to Salvo Tomaselli on Tue Nov 21 18:00:01 2023
    On Tue, 21 Nov 2023 at 16:46, Salvo Tomaselli <tiposchi@tiscali.it> wrote:

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

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

    It is still impossible to uninstall edge...

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bart Martens@21:1/5 to Thomas Goirand on Wed Nov 22 10:30:01 2023
    On Tue, Nov 21, 2023 at 09:14:05AM +0100, Thomas Goirand wrote:
    On 11/20/23 00:21, Luca Boccassi wrote:
    Second version, taking into account feedback. Looking for seconds at
    this point:
    [...]

    Thanks a lot for taking the time to word out things this way.

    However, I really think this text is being too nice with the EU. The feeling in short is reading:
    - what you did was good
    - what you did was good
    - what you did was good
    - oh, btw, there's room for improvement... it'd be nice if...

    That's not at all my feeling about the CRA. I'm once more really unhappy about EU,

    Same here. But...

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

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


    In the absence of something better, I'll still vote for the above...

    Cheers,

    Thomas Goirand (zigo)


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Luca Boccassi@21:1/5 to Luca Boccassi on Wed Nov 22 11:50:01 2023
    On Sun, 2023-11-19 at 23:21 +0000, Luca Boccassi wrote:
    Second version, taking into account feedback. Looking for seconds at
    this point:

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


    ----- GENERAL RESOLUTION STARTS -----

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

    The European Union is currently preparing a regulation "on horizontal
    cybersecurity requirements for products with digital elements" known as
    the Cyber Resilience Act (CRA). It's currently in the final "trilogue"
    phase of the legislative process. The act includes a set of essential
    cybersecurity and vulnerability handling requirements for manufacturers.
    It will require products to be accompanied by information and
    instructions to the user. Manufacturers will need to perform risk
    assessments and produce technical documentation and for critical
    components, have third-party audits conducted. Security issues under
    active exploitation will have to be reported to European authorities
    within 24 hours (1). The CRA will be followed up by an update to the
    existing Product Liability Directive (PLD) which, among other things,
    will introduce the requirement for products on the market using software
    to be able to receive updates to address security vulnerabilities.

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

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

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

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

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

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

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

    Sources:

    (1) CRA proposals and links:
    https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-proposal-for-cybersecurity-regulation
    PLD proposals and links:
    https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-new-product-liability-directive
    Response from the European Commission to a question from the European Parliament on FOSS awareness:
    https://www.europarl.europa.eu/doceo/document/E-9-2023-002473-ASW_EN.html

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

    ----- GENERAL RESOLUTION ENDS -----
    --
    Kind regards,
    Luca Boccassi

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

    iQIzBAABCgAdFiEErCSqx93EIPGOymuRKGv37813JB4FAmVd2zEACgkQKGv37813 JB5jCxAAlXC3Q7gr9b7jL6bp8e6EDUKh8vTlzFGPWD7ENvGeO1mYyWz0iWwRqBft 0gAJF6aRK3aBuJEpwed0Gw5lI6fdghsT+LDRlHemmIJiHQbKv8Jw4lC+5HkSmqBk je9ga3Jv3bFCYshSz0V+PrHI/GleJaXO+9mZUjhLH6WJLjQaizHqZ6njkAXa32F/ omIlM0l0ZpjB5m+lb3XSGyPStcLDuz7MtY3x/TpYZBTIs8UUfw5Q0vRZOgW0gZeZ EzyT7NN7scH9tKnE8tDF31oi5++GIV31zv1WcSKXGBj8KY3Pkmil3vvu1Naf83De Fh2r7D/ecwC/a/2ffb+z17y9PTeZGfBk4PL3vDJ2U5Y9mRNCacWJeQqpcNjISROs vkezEOvSL9/CfPPojWyb9W5tnODfZV6ga8JQGFFbpD617OWhMPmYMYtUrEJhHpLj K92criP9k0preoQbMMlvA28MJ76h+8zPIqsMa2U0QV0YiNv/Kb36WyXooay1fHY2 P02t7WuEdsqsKR6Lfrofs3swQoHoh8oRho//kVSUqp022xxeQZmtAxKSsBH2otzq lwhSBlvuIqUs0ZQyfgVg73XHfwS/zRiGtbIxiVeHib3May4zr9sof0ri6seVawgz HpZjk3Dyi5MY35lRsZYoEQxOSX+H4xDVt4gMtX1TOxQCrzYd0sE=
    =0/ti
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Luca Boccassi@21:1/5 to Bart Martens on Wed Nov 22 19:50:02 2023
    On Wed, 22 Nov 2023 at 09:28, Bart Martens <bartm@debian.org> wrote:

    On Tue, Nov 21, 2023 at 09:14:05AM +0100, Thomas Goirand wrote:
    I feel like we're getting trapped by big corp and their lobbying
    power, and we need to use stronger words.

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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bart Martens@21:1/5 to Luca Boccassi on Wed Nov 22 21:40:01 2023
    On Wed, Nov 22, 2023 at 06:46:06PM +0000, Luca Boccassi wrote:
    On Wed, 22 Nov 2023 at 09:28, Bart Martens <bartm@debian.org> wrote:

    On Tue, Nov 21, 2023 at 09:14:05AM +0100, Thomas Goirand wrote:
    I feel like we're getting trapped by big corp and their lobbying
    power, and we need to use stronger words.

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

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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Luca Boccassi@21:1/5 to Bart Martens on Thu Nov 23 11:40:02 2023
    On Wed, 22 Nov 2023 at 20:35, Bart Martens <bartm@debian.org> wrote:

    On Wed, Nov 22, 2023 at 06:46:06PM +0000, Luca Boccassi wrote:
    On Wed, 22 Nov 2023 at 09:28, Bart Martens <bartm@debian.org> wrote:

    On Tue, Nov 21, 2023 at 09:14:05AM +0100, Thomas Goirand wrote:
    I feel like we're getting trapped by big corp and their lobbying
    power, and we need to use stronger words.

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

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

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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bart Martens@21:1/5 to Luca Boccassi on Thu Nov 23 13:10:01 2023
    On Thu, Nov 23, 2023 at 10:30:01AM +0000, Luca Boccassi wrote:
    On Wed, 22 Nov 2023 at 20:35, Bart Martens <bartm@debian.org> wrote:

    On Wed, Nov 22, 2023 at 06:46:06PM +0000, Luca Boccassi wrote:
    On Wed, 22 Nov 2023 at 09:28, Bart Martens <bartm@debian.org> wrote:

    On Tue, Nov 21, 2023 at 09:14:05AM +0100, Thomas Goirand wrote:
    I feel like we're getting trapped by big corp and their lobbying power, and we need to use stronger words.

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

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

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

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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kurt Roeckx@21:1/5 to Luca Boccassi on Fri Nov 24 14:30:02 2023
    On Sun, Nov 19, 2023 at 11:21:47PM +0000, Luca Boccassi wrote:
    Second version, taking into account feedback. Looking for seconds at
    this point:

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


    Kurt

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Russ Allbery@21:1/5 to Luca Boccassi on Sat Nov 25 00:30:01 2023
    Seconded.

    Luca Boccassi <bluca@debian.org> writes:

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

    ----- GENERAL RESOLUTION STARTS -----

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

    The European Union is currently preparing a regulation "on horizontal
    cybersecurity requirements for products with digital elements" known as
    the Cyber Resilience Act (CRA). It's currently in the final "trilogue"
    phase of the legislative process. The act includes a set of essential
    cybersecurity and vulnerability handling requirements for manufacturers.
    It will require products to be accompanied by information and
    instructions to the user. Manufacturers will need to perform risk
    assessments and produce technical documentation and for critical
    components, have third-party audits conducted. Security issues under
    active exploitation will have to be reported to European authorities
    within 24 hours (1). The CRA will be followed up by an update to the
    existing Product Liability Directive (PLD) which, among other things,
    will introduce the requirement for products on the market using software
    to be able to receive updates to address security vulnerabilities.

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

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

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

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

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

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

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

    Sources:

    (1) CRA proposals and links:
    https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-proposal-for-cybersecurity-regulation
    PLD proposals and links:
    https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-new-product-liability-directive
    Response from the European Commission to a question from the European Parliament on FOSS awareness:
    https://www.europarl.europa.eu/doceo/document/E-9-2023-002473-ASW_EN.html

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

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

    --
    Kind regards,
    Luca Boccassi


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

    --=-=-Content-Type: application/pgp-signature; name="signature.asc"

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

    iQEzBAEBCgAdFiEE1zk0tJZ0z1zNmsJ4fYAxXFc23nUFAmVhMQIACgkQfYAxXFc2 3nU6mgf/eFe48ocgRHGMgc4WjodfJ0AkaGHj7fYiCaecyNrMFZrjRnl64FzEEQMt Mu3HOOBb9iYUtrGv5SrCpBZk2VU9pmjSjzQ4e6dv9KzyOwaA12lOdCzQiGOWPOcc OZteIjwfcI3gmRKcjYTzDDPip7g32Ck5p0kZu3x00LkHLA5Tws2X3nMVv5+pEV6V B1TqglMB72YRwRPIKjFBpABw4XymmwI79bt5a6YVfRNfuzY9aBwV2AQU6oa/4usL Eo0yrBG/aqU6t9rZnd+x2FWwPTxviMZy45KcilbKDnUFXd9hCPkjstWNsIMhvJmH zuAgJRWOATgX2MDGi9oX0KWc/FYesw==G+Gq
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Holger Levsen@21:1/5 to Luca Boccassi on Tue Nov 28 13:40:01 2023
    On Sun, Nov 19, 2023 at 11:21:47PM +0000, Luca Boccassi wrote:
    Second version, taking into account feedback. Looking for seconds at
    this point:

    ----- GENERAL RESOLUTION STARTS -----

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

    The European Union is currently preparing a regulation "on horizontal
    cybersecurity requirements for products with digital elements" known as
    the Cyber Resilience Act (CRA). It's currently in the final "trilogue"
    phase of the legislative process. The act includes a set of essential
    cybersecurity and vulnerability handling requirements for manufacturers.
    It will require products to be accompanied by information and
    instructions to the user. Manufacturers will need to perform risk
    assessments and produce technical documentation and for critical
    components, have third-party audits conducted. Security issues under
    active exploitation will have to be reported to European authorities
    within 24 hours (1). The CRA will be followed up by an update to the
    existing Product Liability Directive (PLD) which, among other things,
    will introduce the requirement for products on the market using software
    to be able to receive updates to address security vulnerabilities.

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

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

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

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

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

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

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

    Sources:

    (1) CRA proposals and links:
    https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-proposal-for-cybersecurity-regulation
    PLD proposals and links:
    https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-new-product-liability-directive
    Response from the European Commission to a question from the European Parliament on FOSS awareness:
    https://www.europarl.europa.eu/doceo/document/E-9-2023-002473-ASW_EN.html

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

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

    seconded, thank you.


    --
    cheers,
    Holger

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

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

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

    iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmVl3WIACgkQCRq4Vgaa qhzybxAAhNvU3mOThUh3DbA77BTqK/2KvS4r7zt9PG1G+UMPmiSRBl4dtNrtowgX WvmEdPJoeIlP9lR/Av4pqIZjnhYDef5yQKU/5DPPTnla6Fi9DJJ+wqA/Wa+ch50j wx1WruPeXs7DuoKqJSdiTUS7Ei+IIjo55b1Y7C+ORYybAoPjrdph83ZyMokvWdJ+ zQjtFs//+JmioYUV2Z21/gyDlLL3N6KjY5f7ldTPj7BehT5Y4WQgkurXxYDlLgBi 0h19/LOwVGeZ+U3KJSlEw6jOFgdNKQazQrKWZcc18V3U8lpFKyTSTrG1RlgZOSk7 RvlORUHJMexCe/B/n/C3bWnmWGT3022Ok4MUiDd5FdRmhP62dzT8WY9Xbq8NWo+v 5MyEujwEOs6r7fhQLa1HaDK/tEkPoZmDodjfr8BRkMWLt3ho1rKhnmFCZXz1Sv1G Zx2V4V/83LYACE/WJ6WnrcwgLTOSYzeFuGlbvjhOYx41jL9YVAO379nFusPWQHDc OkI64x4syinIqav291SZGhnGfdFjF8NJDjhUS3d4Hm/lqvHSHl6HwZL2EMki