Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Thu, 16 Nov 2023 at 02:54, Simon Richter 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.
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Mon, 13 Nov 2023 at 11:50, Aigars Mahinovs wrote: > > You are mixing up completely unrelated things. Commercial entities and > software coming from it have nothing to do with commercial activity. > > The commercial activity is what *you* are doing with the software. It is > completely irrelevant where you got it from or if you wrote it. > > If you are doing commercial activity and are getting QT as a commercial > product from a commercial entity, then it is *easier* for > you - you can simply delegate the security responsibilities of that part of > your software stack up to the QT commercial entity > and you just need to take care of the rest of the stack, which you are > *selling* to your customers (commercial activity!). > > Whether accepting donations *in general* makes your activity in providing > software a "commercial activity" in the context of > this directive proposal is not really a supported notion in the text. There > are a few specific examples of what does make > a "commercial activity" in point 10, but none of those examples directly > apply to general donations to a project or person. I am not mixing, I think the current wording does not _exactly_ says so, leaving a door open for abuse.
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Mon, 13 Nov 2023 at 10:37, Holger Levsen wrote: > > On Mon, Nov 13, 2023 at 02:19:38PM +0100, Aigars Mahinovs wrote: > > Correct. And I agree with that effect: > > same here. > > > The *one* negative impact I can see of this legislation is impact on small > > integrators that were used to being able to go to a > > client company, install a bunch of Ubuntu Desktop workstations, set up a > > Ubuntu Server for SMB and also to serve the website > > of the company, take one-time fee for their work and be gone. Now it would > > have to be made clear - who will be maintaining those > > machines over time, ensuring they are patched with security updates in > > time, upgraded to new OS releases when old ones are no > > longer supported and so on. > > I don't see this a negative impact because this will in the long > term hopefully prevent the effect which is similar to a small > freelancer setting up a kitchen machine which will blow up > after some time. And noone wants that, whether it's been a small > or big company responsible for the exploding kitchen. And people > buying kitchen machines have understood they want safe machinery > in kitchens... Just to be clear: I also do agree with the main intention of the proposal, what I do not like is that the current draft wording might backfire on us. -- Lisandro Damián Nicanor Pérez Meyer https://perezmeyer.com.ar/
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Mon, 13 Nov 2023 at 09:54, Aigars Mahinovs wrote: > > On Mon, 13 Nov 2023 at 13:29, Lisandro Damián Nicanor Pérez Meyer > wrote: >> >> On Mon, 13 Nov 2023 at 07:55, Aigars Mahinovs wrote: >> [snip] >> > Even regardless of the specific legal wording in the legislation itself, >> > the point 10 >> > of the preamble would be enough to to fix any "bug" in the legislation in >> > post-processing via courts. As in - if any interpretation of the wording >> > of the >> > directive is indeed found to be hampering open source development, >> > then it is clearly in error and contrary to the stated intent of the >> > legislation. >> >> According to the current wording if, for some reason, I am held to be >> responsible for $whatever, then I should go to court. Me, who lives in >> south america (because yes, they are looking for culprits no matter >> where they live). They already won. >> >> So, why not try and get the wording correctly from starters? > > > IANAL, but to me the wording seems correct. As long as you are not explicitly > conducting commercial activity in > direct relation to this product to a customer in the EU, none of this applies > to you. > > If you *are* engaged in commercial activity with customers in the EU, then > the EU wants to protect its people and > also keep up the general hygiene of the computing environment in the EU to a > certain level. That's where I see things differently. With the current wording someone could say: Debian receives donations and thus is a commercial entity (look at the text!) Then if Qt comes from a commercial entity and Debian is a commercial entity then anyone using Qt trough Debian is doing a commercial activity. Call me nuts, but that's the way I read it, at least for the moment. -- Lisandro Damián Nicanor Pérez Meyer https://perezmeyer.com.ar/
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
On Mon, 13 Nov 2023 at 07:55, Aigars Mahinovs wrote: [snip] > Even regardless of the specific legal wording in the legislation itself, the > point 10 > of the preamble would be enough to to fix any "bug" in the legislation in > post-processing via courts. As in - if any interpretation of the wording of > the > directive is indeed found to be hampering open source development, > then it is clearly in error and contrary to the stated intent of the > legislation. According to the current wording if, for some reason, I am held to be responsible for $whatever, then I should go to court. Me, who lives in south america (because yes, they are looking for culprits no matter where they live). They already won. So, why not try and get the wording correctly from starters? -- Lisandro Damián Nicanor Pérez Meyer https://perezmeyer.com.ar/
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
Hi, On Sun, 12 Nov 2023 at 14:35, Ilulu 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.
Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"
I have also been part of the discussion on the Mini DebConf and I second this. On 12/11/23 12:10, Santiago Ruano Rincón wrote: Dear Debian Fellows, Following the email sent by Ilu to debian-project (Message-ID: <4b93ed08-f148-4c7f-b172-f967f7de7...@gmx.net>), and as we have discussed during the MiniDebConf UY 2023 with other Debian Members, I would like to call for a vote about issuing a Debian public statement regarding the EU Cyber Resilience Act (CRA) and the Product Liability Directive (PLD). The CRA is in the final stage in the legislative process in the EU Parliament, and we think it will impact negatively the Debian Project, users, developers, companies that rely on Debian, and the FLOSS community as a whole. Even if the CRA will be probably adopted before the time the vote ends (if it takes place), we think it is important to take a public stand about it. - GENERAL RESOLUTION STARTS - Debian Public Statement about the EU Cyber Resilience Act and the Product Liability Directive The European Union is currently preparing a regulation "on horizontal cybersecurity requirements for products with digital elements" known as the Cyber Resilience Act (CRA). It's currently in the final "trilogue" phase of the legislative process. The act includes a set of essential cybersecurity and vulnerability handling requirements for manufacturers. It will require products to be accompanied by information and instructions to the user. Manufacturers will need to perform risk assessments and produce technical documentation and for critical components, have third-party audits conducted. Discoverded security issues will have to be reported to European authorities within 24 hours (1). The CRA will be followed up by the Product Liability Directive (PLD) which will introduce compulsory liability for software. More information about the proposed legislation and its consequences in (2). While a lot of these regulations seem reasonable, the Debian project believes that there are grave problems for Free Software projects attached to them. Therefore, the Debian project issues the following statement: 1. Free Software has always been a gift, freely given to society, to take and to use as seen fit, for whatever purpose. Free Software has proven to be an asset in our digital age and the proposed EU Cyber Resilience Act is going to be detrimental to it. a. It is Debian's goal to "make the best system we can, so that free works will be widely distributed and used." Imposing requirements such as those proposed in the act makes it legally perilous for others to redistribute our works and endangers our commitment to "provide an integrated system of high-quality materials _with no legal restrictions_ that would prevent such uses of the system". (3) b. Knowing whether software is commercial or not isn't feasible, neither in Debian nor in most free software projects - we don't track people's employment status or history, nor do we check who finances upstream projects. c. If upstream projects stop developing for fear of being in the scope of CRA and its financial consequences, system security will actually get worse instead of better. d. Having to get legal advice before giving a present to society will discourage many developers, especially those without a company or other organisation supporting them. 2. Debian is well known for its security track record through practices of responsible disclosure and coordination with upstream developers and other Free Software projects. We aim to live up to the commitment made in the Social Contract: "We will not hide problems." (3) a. The Free Software community has developed a fine-tuned, well working system of responsible disclosure in case of security issues which will be overturned by the mandatory reporting to European authorities within 24 hours (Art. 11 CRA). b. Debian spends a lot of volunteering time on security issues, provides quick security updates and works closely together with upstream projects, in coordination with other vendors. To protect its users, Debian regularly participates in limited embargos to coordinate fixes to security issues so that all other major Linux distributions can also have a complete fix when the vulnerability is disclosed. c. Security issue tracking and remediation is intentionally decentralized and distributed. The reporting of security issues to ENISA and the intended propagation to other authorities and national administrations would collect all software vulnerabilities in one place, greatly increasing the risk of leaking information about vulnerabilities to threat actors, representing a threat for all the use
Re: GR: Constitutional Amendment to fix an off-by-one error and duplicate section numbering
On Wednesday 26 August 2015 15:18:36 Russ Allbery wrote: > I second the below text, for both changes. FWIW, at least on my mail client I'm failing to verify this signature. Not that is *that* important considering the number of seconds already available, but I thought it was better to make it clear. Kinds regards, Lisandro. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: GR proposal, Call for Seconds - term limit for the tech-ctte
On Monday 01 December 2014 12:20:25 Stefano Zacchiroli wrote: [snip] > +6. If the Technical Committee and the Project Leader agree they may > remove or replace an existing member of the Technical Committee. In the special case that a member is replaced, the new member "resets" it's status or does him inherits the status of the one being replaced? Yes, maybe I'm too picky here, but who knows... -- 9: Que es el "Explorador" de Windows * El tipo que le roba las ideas a MacOs Damian Nadales http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Alternative proposal: support for alternative init systems is desirable but not mandatory
On Friday 17 October 2014 23:03:37 Wouter Verhelst wrote: [snip] > I would like to see the above clause modified like this: > > "There may be some loss of functionality under sysvinit if the package > is still basically functional." > > Rationale: I don't think that "the maintainer believes the loss of > functionality is acceptable" is a good test for whether the cost is > worth the benefit. Rather, that test should be about "how hard is it for > a maintainer to support the alternative init system". If a maintainer > thinks that, say, a power manager written to read /sys/power directly > but control things through systemd is useless without the ability to > suspend the system, they might well remove all support for non-systemd > systems; if someone else believes otherwise and sends in a patch, under > the proposed language the maintainer would be able to reject such > patches. > > As such, in the spirit of §2.1.1 of the consitution, I would therefore > like to see something along the lines of "in the absense of patches, > it's okay for a maintainer to remove support for non-default init > systems if they have no desire to maintain that support themselves, but > maintainers should not reject patches implementing such support without > a sound technical reason". I do partly agree with you in here. The part that I do not agree with is: supposing Mike the maintainer receives a patch from Peter the patcher to support $foo then Mike would be forced to ship the patch most possibly as a delta from upstream. Now a new version of the software arrives and the patch does not applies anymore, needing a big refactoring. Peter doesn't shows up and Mike is forced to either drop the support (would that become RC bugs?) or do the refactoring himself. All I can see is problems for Mike, added to what he already has. We could also add broken API/ABIs if the package in question is a lib, big deltas from upstream, etc. I think we should still leave that to the maintainer unless overridden by the TC. -- I am two fools, I know, for loving, and for saying so. John Donne Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: All DPL candidates: Debian assets
On Friday 21 March 2014 17:48:02 Lucas Nussbaum wrote: [snip] > Generally, my impression is that many Debian contributors do not fancy > travelling that much, or are just too busy, and thus don't really like > to attend too many such events. While I recognize that - I don't know many DDs in person except for those I met in DC8 and thus my view might be slanted, - I live **far** away from the nearest DD and even more **far** away from any normal meeting place, I think this is not true. If I had the chance to meet people from my teams and/or something else which could be useful to the project I wouldn't mind the travel. What I do mind are the expenses, which are truly prohibitive. But then again, my POV might be the result of an exceptional case, but I wanted to put in on the table non the less. Note: no, I'm not asking money for traveling, just wanted to present my POV. -- 17: Cual es la funcion inicial de un antivirus * Desarrollar virus para vender el producto Damian Nadales http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Debian for third party (read: propietary) apps/vendors
There are third party vendors (read: propietary) that support the installation of their software in Debian, but mostly because selfish reasons: they need to be present everywhere for their business model to work. A clear example of this is Skype. Now there is a second class of apps/vendors which do not need to be ubiquitous for their business model to work. Most of the examples that come to my mind are CAD-related: Synopsys [0], Cadence [1] and Mentor [2] are examples of propietary vendors that give support for Linux but just on Red Hat and sometimes, Suse. And they are a PITA to make them work on Debian. This makes IT workers need to have RH/Suse/CentOS boxes even if the rest of them run Debian. Sometimes the Debian support is a *.deb made from the RPM packages with alien, but this is just a small rant :-) [0] <http://www.synopsys.com/home.aspx> [1] <http://www.cadence.com/us/pages/default.aspx> [2] <http://www.mentor.com/> Now my question is: without going against the Social Contract, is there anything Debian can/should do wrt this situation? Kinds regards, Lisandro. -- ~/ sweet ~/ Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: mentoring programs in Debian
On Tue 12 Mar 2013 17:56:10 Ana Guerrero escribió: [snip] > Yeah, and also the GSoC have a huge disadvantage, it is available only to a > tiny small percentage of the population who have the privilege of getting > a higher education, then only if their school load and life > responsibilities allow them to participate in the program. Without taking into account that summer is happening just in the northern hemisphere. In the remaining of the globe, we are not on holidays. -- Esperando confirmación de ingredientes necesarios que serán expuestos a la radiación... Manera geek de expresar que se espera la compra de carne para un típico asado argentino. Silvio Rikemberg. Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
