El viernes, 21 de julio de 2023 23:20:22 (CEST) Adam Steer via Discuss escribió: > It would be great to hear your thoughts on the impact of the proposed > legislation
TL;DR: Not such a big deal. At least, not a big a deal than GitHub (i.e. Microsoft) and ASF seem to be making. A bit of context: I'm a EU citizen, I have fair amounts of experience reading legalese, and I've read through the proposed Act as well as the Github and ASF statements. I also speak as a solo developer/maintainer. It's important to note that as of today (2023-07-26), revision 454 of the proposal seems to cover the concerns about donations and developers employed by corps. It's also important to remember that FOSS licenses rely and build upon intellectual property laws; they *hack* IP laws. In the same vein, it's possible (and, I think, desireable) to hack the EU CRA, by adding a very simple statement such as: «If you will not, or can not, accept liabilities for using this program, then you may not use this program under the terms of this license. In particular, if you will not, or can not, comply with the obligations of the EU Cyber Resilience Act, then you may not use this program under the terms of this license.» There seems to be a fear that there will be undue burdens placed on individual mainainers. I don't think that'll be ever be a problem; but if it would ever be, then I'd like OSGeo to ask the FSF to release an updated GPL v3.1 wih a statement I wrote above. It's a nice hack of the law that, if you think a FLOSS developer should be liable, then that piece of FLOSS is not FLOSS for you anymore, and you should treat it like closed-source software and pay the developer for it (and comply with EU CRA anyway). Magic! --- I do have a concern, and it's about Github's position. It does read as Microsoft FUD: «But think of the POOR DEVELOPERS!». My experience with GitHub for the last few years is that it has become an instrument for Microsoft to shape and control the software supply chain. Bit by bit, the burden of maintenance has shifted from the user to the developer and, from my PoV, they're directly responsible for creating maintainer burnout. Now they're getting told that entities which benefit monetarily from software should be responsible for vulns, and Microsoft doesn't like being told that. --- I disagree with ASF's position about the EU CRA applying to The Commons. After all, my interpretation is that The Commons is very, very different from The Market; and the CRA only applies to The Market. I need to add a "citation needed" bit to this sentence in the ASF text: > [...] the policy makers have made it crystal clear to the ASF that they intend to have the CRA apply to open source foundations. I'd really really like to know who made that clear to the ASF, and with what words. Until then, my position is "The Commons is different from The Market". If the EU CRA would really apply to FLOSS under the umbrella of a foundation (i.e. OSGeo software), then my recommendation is an addendum to the FLOSS license, as above. If (or when?) this becomes an issue, a FLOSS foundation can draft updated licenses and pressure devs to use those updated licenses. It's very much possible to shift the burden away from the developers and away from the foundation(s) via license. --- What's the EU CRA, anyway? A human-readable summary of the obligations is: - Use your brain when designing things like storing user credentials and the like - Try to minimize exploits (SQL injections, XSS, etc) and DDoS - Have some way of logging stuff if it's helpful - Have some way of offering updates - Know your software dependencies - Keep track of vulns (e.g. have a bug tracker) - Have a way of contacting you - Fix vulns ASAP - Keep a changelog - Keep technical documentation (i.e. a README file); write about - what this is for, - what dependencies it has, and - how you've used your brain to try and avoid exploits - Do some kind of audit and/or testing - Report any vulns to ENISA (the EU counterpart to the US NIST) AFAIK, OSGeo projects are doing most of this anyway, so the extra burden is not so big - and remember, the burden applies only if you're making money with the software. --- Jody Garnett said: > The economics of this are where I would like to know more. I hope we get a Paul Ramsey keynote on this topic The economics are going to be intesresting and, yes, please, more Paul Ramsey. I predict that a number of bullshit jobs will be spawned around the EU CRA, the same as happened with the EU cookie law. And instead of empowering users and developers, the bullshitters will somehow create auditing services that ultimately are not necessary and rely on fear and FUD. You know, much like the freaking' obnoxious cookie popups are not needed at all *because you are forcing an antipattern to maximize profits instead of trying to be nice to the user*. There's RHEL, and there will be bullshitter auditors, and there will be (I guess) project forks just for EU CE mark. The later worries me, in terms of actually improving upstream. On other hand, the EU CRA doesn't apply to software in alpha (or beta, or gamma) status, or otherwise "for testing purposes only". I predict that some pieces of software will adopt a "all of our releases are for testing purposes only" policy, as another workaround. Seth G said: > If OSGeo can find a way to capture some of this value by ensuring compliancy and gathering funds from large organisations that use OSGeo projects, then this could be seen as an opportunity rather than an impending disaster. Well, then OSGeo might want to offer auditing services at better terms than the bulshitter auditors, and establish mechanisms to put a CE mark on OSGeo projects. Not that OSGeo can be a target of the EU CRA, though; as ar as I'm concerned it's a non-profit and therefore part of The Commons and not part of The Market. It would just proxy EU CRA responsibilities from commercial users. --- Jody Garnett said: > I am going to stop writing Yeah, me too. -- Iván Sánchez Ortega <i...@sanchezortega.es> https://ivan.sanchezortega.es _______________________________________________ Discuss mailing list Discuss@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/discuss