This seems sort of reasonable. If you charge for tech support, you have a business. I’m all for not making it harder for people who are actually just sharing their hobby projects, but a project that makes money isn’t a hobby anymore.
I mean we wouldn’t want to leave a gap large enough to send Android through, right?
With the current writing it might be that a distributor different from the commercial entity might be liable for vulnerabilities and reporting.
https://blog.sonatype.com/eu-cyber-resilience-act-good-for-s...
To me it sounds like the "software is delivered as is" clause would nullify that.
What I see emerging is a dual license system where you can buy a supported version that's compliant with whatever European law or get the one hosted on an American mirror (where thankfully European law doesn't apply).
True. I should have said "distribute". But the point holds.
It all depends. There are plenty of people who have hobbies and engage in some sort of low-level commerce in order to fund them. They aren't intending to profit by them (and don't), but are looking to reduce their loss.
Could be an unintended side benefit given that as it stands FOSS is basically free labor for SaaS with the latter delivering a user experience that is significantly less open and free than the old closed source paradigm FOSS intended to replace.
FOSS + SaaS = less freedom than old closed source.
If you directly or indirectly (support contracts) sell some software sure it should apply, but the regulation isn't well defined (in it's draft state) and includes much more.
A lot of FOSS is based around the idea:
- provide software components as FOSS on a as is-basis, components you do not sell directly or indirectly but plan to use, or used, or planed to use until things changed etc.
- the consumer of the software (other programmers/companies) are expected to do _their own_ risk assessment, reviews etc. IF they decide to use the software (but only if, i.e. not needed for prototyping)
- if they use the software (hopefully) you get feedback from their review and assessment leading to bug fixes and improvements
- in some cases projects are evaluated by enough other parties that not everyone needs to do their risk assessment
- you don't make profit from the release, but you do get feedback which could safe cost and do get publicity and trust, so it has a commercial benefit so it's commercial in a certain way
Now you probably can already spot the problem, in many cases companies do _not_ do their do due diligence in reviewing software and blindly assume "someone" did it.
So an regulating which requires you to have made sure that someone did due diligence for all software you include in a product, including SaaS(!) is reasonable IMHO.
But because the regulation is based on the concepts/ideas of a physical supply chain it is instead requiring anyone which is publishing software components (instead of using them) to do the due diligence if it's commercial. But due to OSS leading to feedback, publicity and trust _ANY_ OSS done by a company can be classified as "commercial", even if it's a tech demo explicitly not meant to be used in production or a early pre-pre-pre release version.
Another problem is the definition of what I called due diligence but to comment on that I had to read the draft again.
So IMHO the problem is not the regulation by itself, it might even make OSS better, but the exact formulation which either show a deep missing understanding of software development or bribed politicians, probably a bit of both. Ah I mean lobby influence politicians, it's practically the same, but not legally so better clarify that.
EDIT: I.e. a lot of OSS software is more like sharing (potential prototype) technical blue prints in an informal shared development/research agreements then it is selling "parts" in a supply chain.
The example applications included in them are usually vague enough that implementing them isn't trivial. It'd be very hard to view them as anything more than pseudocode, with similar expectations of functionality.
Another thing I’m wondering about is academic code. Hypothetically the code I wrote for my thesis is available online and I was paid to write it, I guess, or at least it is part of the research I was given a stipend to do. (Happily, it has nothing to do with security!).
Nobody is making any money off it. Hypothetically it could be seen as something that is there to add (very marginal!) value to my resume or to the university by showing off research chops… I dunno. If we had a law like this in the US, I wonder if it could stay up. I guess universities would end up with an additional CYA administrative step before posting code, and a big disclaimer in all their licenses.
It's specifically an important feature of libre software that others are free to resell or to make money from support of your own software : this is seen as a good thing because distribution (and support) are not free for the distributor (though I guess much less relevant in a world with widespread high speed Internet and peer to peer distribution software ?) (and supporter).
The distinction is really much more about philosophical objectives and marketing than it is about anything material.
Because there isn't a difference.
I may generally prefer permissive licenses but I certainly don't see how the GPL, for example, doesn't enable access to source code--though it may sometimes discourage participation in development.
But nobody taught me this definition. Not sure where I got it. So I could very well be wrong.
Nope. That's free as in free beer.
free/libre software / open source software is free as in free speech (and often as in free beer but not always)
some people use the French/Spanish word libre in English to avoid this exact confusion caused by the world free having both meanings.
free software and open source software are defined by the FSF and the OSI, respectively, but the definition are equivalent and designate the same set of software, essentially.
The Register appears to have bought into the FUD being spewed by a bunch of people being paid a lot of money to run “non-profits”.
Businesses like Litesspeed can sell their product as a certified one and sell that as a feature.
If I am distributing a product based on Linux, it is my job to ensure that I use Linux in a secure way, to the extent required by contracts between me and my customers, and by local regulations. I can either take on this work myself, or pay IBM RedHat or SUSE or whoever else to take on some of the responsibility.
How else would this work?
Using a "standard" kernel, keeping it up to date, etc. is due diligence but WAY cheaper and easier to do then any form of certification.
Software certification especially wrt. to security is and always has been a mostly a scam.
It also is a _major_ driving factor(1) for insecure software not getting fixed. Because it's "certified" but the security fix is not. (1: in certain industries)
we can't even do that reliably for very well understood mass production processes of "simple" physical goods ( Which is why you make systems which in presence of defects still yield acceptable results.). The goal you are listing is not something which can be reached through laws like this _at all_!!!.
Outside of clear negligence and potentially hurting FOSS it will not lead to a major increase in security in it's current form and can easily have the opposite effect too due to companies "hiding there code" to avoid problems when people find issues and potentially use all kinds of questionable means to try to prevent people from doing independent security research on their products.
If past experiences around e.g. government projects with similar requirements are anything to go by certification is not in any way a reliable form of security, especially for mass products.
In my experience the overlap between competent security researchers and people doing the certification for most (not all) for-hire security review companies is rather small.
For example the amount of peace makers which can be hacked even through such medical devices have extreme strict certification requirements far beyond what can be applied to most software is still pretty high.
I have seen cases of really big (and supposedly competent) software consulting companies certifying something as secure which most 3 semester or so bachelor students could have told you is clearly not secure.
Don't get me wrong, there is a problem with negligence and having a law/regulation which reduces that is by itself a good thing.
But the issues the software industries has are much more deep rooted then such negligence (else we wouldn't also see such issues en-mass in cases where no such negligence was done). You could even say they are fundamentally rooted in human nature and society ;-)
Worse if such a regulation is not done well it might more lead to a game of shifting blame then people actually trying to fix things.