The way the remote job market is being flooded by American companies proves your point. EU companies do not even try to compete with them, with a few exceptions.
Probably shouldn't oversimplify it. Ex: I'm in the USA and every company I've worked for in the past 20 years was remote work and based in Europe. They opened American offices to make some things easier here, but They Came From Europe (ooohhh spoooooky).
TFA this thread is based on is low quality. It’s breathless in its criticism of the legislation but uses hyperbole instead of calmly laying out the issues.
The Maven Central guy puts it plainly - the proposed legislation doesn’t penalise OSS developers, unless they distribute software they also get a commercial benefit from. But that describes the operator of Maven Central, who publishes software and has some commercial interests tied to it. However they cannot possibly take on liability for every published package. In that case they would be left with no choice but to block EU users.
Having to profit from the software isn't neccessarily that big of a caveat either depending on what precise wording that ends up in the law. Do donations count? What if you accept a bug bounty? How about a one time contract to implement a minor feature? Monetizing OSS is already hard enough that having to deal with compliance even for (money wise) tiny projects will make it impossible for many more.
Remember when the CDU politicians celebrated when they successfully lobbied for upload filters for their publisher friends in the EU? Why should not assume that its intended？Plenty of McKinsey consultants around to make sure governments don't use too much FOSS to keep paying those nice license fees to MS.
>Plenty of McKinsey consultants around to make sure governments don't use too much FOSS to keep paying those nice license fees to MS.
Maybe, but remember that Ursula von der Leyen herself has been advocating for a while for EU's "digital sovereignty" (not having to depend on products and services form non-EU countries) and the easiest way to achieve that would be to heavily rely on FOSS.
Ursula just like Macron has been involved in McKinsey scandals, the outcome of which was shoveling money to McKinsey and decimating the German military. Iirc her son was a partner or something. Ursula says all sorts of crazy stuff. The last year of Ursula policies have made sure that the EU is everything BUT sovereign. They are now fully dependent on the US MIC and fully dependent on US resource and energy imports at any price or terms the US wishes.
Looks like everyone here has forgotten that the EU copyright stance is basically to shovel money to the US.
I really wish people here would judge politicians by the outcome of their actions and not by what they say.
EU regulators are not shy of ignoring side-effects, so intention is not likely but negligence is widespread. EU loves to regulate even for the sake or regulating; it was even listed as one of the reasons listed behind Brexit, even if that is a completely different story.
> EU loves to regulate even for the sake or regulating; it was even listed as one of the reasons listed behind Brexit, even if that is a completely different story.
Some proof of that would be nice. The phrase "it was even listed as one of the reasons for Brexit" sends my personal prior in the direction of it being a lie, though I am quite willing to adjust if there is some evidence.
I'm also skeptical. Most EU laws take a very long time to be negotiated, because different countries bring forward different needs/desires. But I do think it is hard for the average citizen to notice that there is a new law being drafted that could have bad consequences for one's personal life circumstances.
the EU regulates the speed at which you are allowed to vacuum clean your house. until 2009 there was regulation about how curved cucumbers are allowed to be(amongst other vegetables). Its blindingly obvious that the system has run so amok that it ought to be criminal
A lot of the "reasons for Brexit" turned out to be well spread misinformation if you looked closer into them or where cause by UK government instead of the EU so that a pretty stupid argument to bring up.
Yep. I remember back in 2003 when I wrote a personal letter to all EU MPs to ask them to reject software patents.
Software patents enforcement would have been terrible for EU software and a boon for the rich US software company who constantly lobby the EU parliament...
Well, I'm pretty sure that these same US software companies are still there lobbying in their own interest, in a complete absence of transparency.
> The CRA draft even exempts FOSS from compliance – but only if no commercial use is made of it, including things like technical support and as part of monetized services.
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?
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.
There is a difference between due diligence and required certification.
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)
Due diligence is relative to the industry. I agree that having a reasonably up to date and boring kernel, and keeping updated, is the best we can do now. But there’s something defective in the industry, if there wasn’t, then we could apply industry standards to produce a fully understood and certified device that is actually known to be free of defects.
> certified device that is actually known to be free of defects
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.
> 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.
With the current writing it might be that a distributor different from the commercial entity might be liable for vulnerabilities and reporting.
Furthermore, as the author of the Sonatype piece told me last fall, it also goes beyond the upstream project and any distributor. In the case of a lot of vulnerabilities, the fixes have existed in the upstream for maybe a year or more. But they're still in downstream code that has never been updated.
I'm always impressed at how little European regulators seem to understand tech (and at how little they want a healthy tech sector to grow in Europe, preferring American and Chinese alternatives).
To me it sounds like the "software is delivered as is" clause would nullify that.
But there are huge problems with "as is" clauses, and in the US anyway, they aren't always enforceable. If I sell a doohicky that I know is likely to kill people, slapping an "as-is" clause on it probably won't keep me out of jail.
In the case of OSS libraries and open-source distributors, there's no sale happening.
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).
Thanks to current US politics, whatever gets developed over there might not be as widely embraced as in the heyday of all good friends over here, global economy.
Would this create a way for FOSS projects to charge SaaS companies for monetized use of software by offering a compliant version?
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.
Why are there no reminders here about the difference between open source and free (= libre) software ?
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).
Well, there is a difference. Open source software includes certain things that may not be included in libre software, such as access to source code, customer participation in development, etc.
Open source can be different from "free as in beer" but certainly not different other than as a philosophical/marketing thing from "free as in freedom" as the FSF uses the libre term.
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.
I think "libre" means something different to me. All OSS is libre, but not all libre software is open source. For instance, freeware distributed solely in binary form is libre.
But nobody taught me this definition. Not sure where I got it. So I could very well be wrong.
> For instance, freeware distributed solely in binary form is libre.
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.
Why is this relevant in this context? The question is which entity should be liable for abiding by this regulation, and the clear intention is that the answer is the one that Stallman himself would agree with: responsibility should sit entirely with whoever is distributing the software and making money off of it.
That's not a fundamental feature of open source, or a fundamental restriction of free software. E.g the GPL is approved by OSI, and the MIT license is approved by the FSF.
The distinction is really much more about philosophical objectives and marketing than it is about anything material.
Because Libre software is included under the umbrella of Open Source. If I'm writing an article about car regulations, I don't need to specifically mention cars with leather interiors unless the regulation treats them differently.
This is a good question. I’d hope that just hosting a free repo wouldn’t confer responsibility.
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.
The problem is it's not a suply chain in the classical sense.
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.
Almost all datasheets have an explicit "as-is" disclaimer. It is in the manufacturer's best interest to ensure their accuracy, but the reader is assumed to be a skilled professional who would be able to spot any mistakes.
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.
Data sheets tend to also be (at least subtle) wrong all the time, at least that is what I have heard many times by now from people working with electric hardware/supply chains.
> a project that makes money isn’t a hobby anymore
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.
This is, as per usual, big companies trying to scare you into believing regulations meant for them will hurt the little guys. Learn to recognize this news pattern and disregard it immediately.
The EU is probably the leading body of government trying to drive FOSS adoption.
> This is, as per usual, big companies trying to scare you into believing regulations meant for them will hurt the little guys.
Except those regulations hurt the little guys more than the big companies.
Even if the big companies can't buy their way out of compliance, compliance inherently costs less for them and regulatory bodies are more willing to work with a big company than a small group of hobbyists, leading to the big company being able to follow the law with nary a hiccup whereas the hobbyists get destroyed by zealous enforcement.
This isn't true for a myriad of reasons. Smaller organizations are usually inherently more compliant, their smaller scale makes it far easier and cheaper for them to become compliant, and enforcement agencies are less interested in investing significantly in enforcement actions against them.
...their smaller scale makes it far easier and cheaper for them to become compliant...
This is often somewhat true. However, as I have observed in several USA contexts, large organizations are often exempted (whether explicitly or not) from pesky new regulations, citing this very point. For example, I personally attended a California PUC meeting in which VZN and SBC were exempted from "lifeline" regulations that continued to be imposed (with nonzero costs) on the small CLEC that employed me. Large organizations have to keep lawyers and lobbyists employed, so they might as well keep them busy. Creating regulations and exempting themselves is common practice.
In Europe, small companies tend to be exempted. E.g. no GDPR data protection officer required when less than 250 people in the company. 10, 50 and 100 are also personnel counts seen on a regular base.
In practice, a lot of companies stop growing just below the limit, and e.g. split in parts that have supplier relations to each other. No, we don't have 2000 employees. We are a group of 200 companies, owned by the same owners, and having 10 employees each.
THe data protection officer is the least of the costs they avoid. Medical staff, prevention and protection officer, union representative, ... The list goes on and on. I've heard that a company of 99 and 110 people de facto have the same amount of people doing work, the 10 extra people are all the extra laws that go in effect at exactly 100 employees. SO
There is also impact on worker protection. If your people go on strike, or if you want to do mass layoffs, you just dissolve a few companies.
I presume board requirements are a lot smaller for such tiny companies, too.
Well, that is the thing, I am free to offer food on the street, yet I am suject to the same kind of health regulations as any kind of restaurant.
Same applies to any kind of business.
Why should FOSS be any different?
Maybe this is the culmination of the bazaar idea after all, including quickly stuffing the products back into a bag and running away from the law enforcement official between the crowd, by not having either a license or the expected quality.
Shockingly it's actually the fact you gave them food poisoning that decides that one. But I wouldn't be surprised if the Europeans thought that in need of fixing too.
There is a difference between being held accountable if your negligence ends up hurting someone vs. proactive audits and reporting requirements - the second has overhead even for those that already have high standards, overhead that is unreasonable outside a business setting.
Proactive audit system seems to be better one to me. It is more predictable - you know in advance which rules you are supposed to follow. It also allows for widely accepted risk standard know in advance to both customers and providers.
The "do what you want and we will punish you hard if luck strikes badly" is less predictable. It has unfair results. It leads to both excessive risk avoidance (because if you are unlucky punishment is disproportionate) and risk taking customer is unable to proactively avoid.
And if FOSS is not a business, it's excluded from this regulation as well.
If you make business with said FOSS you need to provide security just like how a food truck making food from open recipes has to make sure to not poison people either.
What if you give self baked cookies to a restaurant owner, and he sells them? Then the commercial entity assumes the risks and is supposed to safety check them.
Should government destroy all holly bushes? No. All berries? Certainly not.
Speech is a natural right and software is speech, so it can't be meaningfully viewed any other way, unless you're mindlessly parroting representative government deliberations.
It should be different because software is different from physics objects like food, it works differently and people interact with it differently.
Imagine you were making cookies for your friends, and Nabisco happened to get one of the cookies somehow. Should you be responsible if they decide to use the ability, conferred from having one cookie, to create an infinite number of copies of that cookie (without checking it for defects or even really investigating it much) and start selling them across the country? I’d say probably not. But our legal framework doesn’t cover it, because physical objects don’t work like that, unlike software.
We could also look at software as more like a recipe. If Nabisco decided to copy my cookie recipe, they’d unambiguous be responsible for checking it and making sure it wasn’t actually poisonous. We also have cook books, I guess if you put a poisonous recipe in a cookbook you’d have some responsibility. But this is all manageable because cooking recipes are pretty short and easy enough to verify, and the foot-guns of the hobbyist cooking field are mostly well known.
A closer recipe analogy is probably — Nabisco probably gets their bulk supplies from a network of suppliers, who have to manage things like contamination levels and fitness for a given purpose. But now we’re hitting the point where the analogy is at least as complicated as the software supply network; I’m sure there are lots of shared responsibilities and regulations in that network, and it is all professionalized and for-profit.
Here in New Mexico, there's a whole class of food preparation (specifically, involving food that does not need refrigeration to stay "safe" for a specified time period) that is NOT subject to the same kind of health regulations as a restaurant.
It's one of the smartest laws I've seen in this area. Want to run a small coffee shack with some cakes, cookies etc? No need for a certified kitchen, "fully trained" cook, etc. The only thing you have to do is take a course that helps differentiate between refrigeration-required and no-refrigeration required food.
Interesting to think how this model would apply in the software context...
Restaurant regulations in EU do not mandate any special education for cooks. Also I don't know what you mean by "certified kitchen", it is not really a thing. There are regulations around handling and storing food, ventilation and what not in EU countries.
And those do apply to small stands and full kitchens. But if you want to claim they are unreasonable, then you should argue by existing ones rather then made up ones.
In the USA, to prepare food for commercial purposes, you generally need to have a kitchen that has been inspected and permitted for such things. You cannot, for example, use your own home kitchen (this varies by state, but that's generally true). Some states require training courses for all users of these kitchens (and some do not). Some require that the kitchen can only be used when someone trained is present.
I did not make anything up. The New Mexico law I mentioned went into effect only a few years ago. Before that, it would be illegal to, for example, bake a cake in your home kitchen and offer it for sale. This is no longer the case.
When I introduce a product to users I have to take care of its post-market cybersecurity. This is healthcare reality for years and now comes to all products.
The interesting here is: What is a product? Most open source is not. The millions of libraries are not products. A product accumulates the various aspects (cybersecurity, license, ....) into a package. If I buy the software from a vendor I will make him responsible for it. If I hack it together on my self, this duty is on me.
Open Source will survive that. But open source owners will get tons of questions and should be better be prepared to answer questions. GitLab and GitHub are already working on the consumer side with their security analysis features.
But the rub is that open source owners have no actual obligation to you. So while you might want them to be "prepared with answers" they don't actually need to be. Some will want to be because they want their software to be used and up-to-date. But others have likely shelved their software, or just don't care to solve your security problems for you but will accept a patch if you provide one.
And its literally what developers that are taking open source software and using it to sell something need to understand. The sellers are adding that value and taking that risk. If I go to the store, buy some wood, build a shelf from the wood and sell the shelf. Then it burns my customers house down, its on me not Home Depot.
That's where OSS companies like Suse or RedHat come in: they do provide support for their distributions. And, unlike Amazon, they also employ many maintainers and if they don't employ them, they sometimes submit patches to upstream so are good OSS citizens.
That is all fair. The premise is the article headline that open source or Foss is dead. An open source software no one can use is a dead software. So the success of a Foss software might not only depend on functional aspects in Future but also on non functional aspects like the Cybersecurity management.
And do not think that this influence will not happen. There are reason why the non functional requirement licensing has switched to MIT from previously more LGPL constructs.
Having said all that... Yes, no one is obligated to answer.
> The European Union has a commendable love for the safety of its citizens. Armed with the keys to a market of 300 million of the world's richest consumers
It is whether, for companies that offer paid support for FOSS, the obligations are towards the paying customers or all.
The same with FOSS which is used as a basis for commercial products. E.g. Google makes money off Android, but is AOSP with no Google stuff also covered by this law?
And how does it affect companies providing support for software they do not own? (e.g. consultancies).
How is this take? Free and Open Source Software isn't owned by anyone.
Being a contributor, even to my own pet project, cannot compel me to contribute my valuable time to the project in ways that I do not so chose. And you can't compel me either to spend my money to hire some third party security firm to audit this code that isn't owned by me or anyone.
If some third party wants to compile this un-owned piece of code and sell it to another, the onus is on them to comply with security regulations.
What I find interesting in this context: Most FOSS licenses have a no-warranty and no fitness for any purpose clause:
GPL 3: there is no warranty for the program, to the extent permitted by applicable law. except when otherwise stated in writing the copyright holders and/or other parties provide the program “as is” without warranty of any kind, ...
BSD-3-Clause: this software is provided by the author ``as is'' and any express or implied warranties, including, but not limited to, ...
Apache 1.1: this software is provided ``as is'' and any expressed or implied * warranties, ...
Which means that the liability lies entirely with the user if they use the software for something critical.
Depending on the jurisdiction, courts might strike down or ignore parts of a license. On the other hand, you might not care what a court says, depending on your travel plans.
Security is the job of the operating system, not applications. The seK4 kernel makes it possible to build operating systems that actually enforce security, rather than hope applications do the right thing.
If this push isn't stopped... we'll all be taking a crash course on microkernels and the principle of least privilege. (A long overdue crash course, but that's my opinion, and not widely shared)
So far, world cybersecurity has been good enough. In an average year, if you ask 100 people what problems they experienced, data breach related issues are not going to dominate the list.
While I'm generally a big fan of heavy regulation, there's just so much tech that doesn't matter, that we just use to make other things that don't matter easier.
I would much rather see the regulation confined to domain specific things, stuff that directly deals with finances, life safety, industrial, etc.
106 comments
[ 5.3 ms ] story [ 184 ms ] threadThe EU is basically an association for German business owners and landowners. Happy to impede technological progress if it serves their interests.
That's not true at all, and I don't see which interest there would be in hampering FOSS development.
TFA this thread is based on is low quality. It’s breathless in its criticism of the legislation but uses hyperbole instead of calmly laying out the issues.
The Maven Central guy puts it plainly - the proposed legislation doesn’t penalise OSS developers, unless they distribute software they also get a commercial benefit from. But that describes the operator of Maven Central, who publishes software and has some commercial interests tied to it. However they cannot possibly take on liability for every published package. In that case they would be left with no choice but to block EU users.
Maybe, but remember that Ursula von der Leyen herself has been advocating for a while for EU's "digital sovereignty" (not having to depend on products and services form non-EU countries) and the easiest way to achieve that would be to heavily rely on FOSS.
But is it also the most profitable way for politicians.
Looks like everyone here has forgotten that the EU copyright stance is basically to shovel money to the US.
I really wish people here would judge politicians by the outcome of their actions and not by what they say.
https://torrentfreak.com/europes-odd-anti-piracy-stance-send...
Some proof of that would be nice. The phrase "it was even listed as one of the reasons for Brexit" sends my personal prior in the direction of it being a lie, though I am quite willing to adjust if there is some evidence.
Regulatory capture. It's very much intended by whoever really drafted that bill.
Well, I'm pretty sure that these same US software companies are still there lobbying in their own interest, in a complete absence of transparency.
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?
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.
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.
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.
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).
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 distinction is really much more about philosophical objectives and marketing than it is about anything material.
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.
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.
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.
The EU is probably the leading body of government trying to drive FOSS adoption.
Except those regulations hurt the little guys more than the big companies.
Even if the big companies can't buy their way out of compliance, compliance inherently costs less for them and regulatory bodies are more willing to work with a big company than a small group of hobbyists, leading to the big company being able to follow the law with nary a hiccup whereas the hobbyists get destroyed by zealous enforcement.
This is often somewhat true. However, as I have observed in several USA contexts, large organizations are often exempted (whether explicitly or not) from pesky new regulations, citing this very point. For example, I personally attended a California PUC meeting in which VZN and SBC were exempted from "lifeline" regulations that continued to be imposed (with nonzero costs) on the small CLEC that employed me. Large organizations have to keep lawyers and lobbyists employed, so they might as well keep them busy. Creating regulations and exempting themselves is common practice.
Perhaps things work differently in Europe.
In practice, a lot of companies stop growing just below the limit, and e.g. split in parts that have supplier relations to each other. No, we don't have 2000 employees. We are a group of 200 companies, owned by the same owners, and having 10 employees each.
There is also impact on worker protection. If your people go on strike, or if you want to do mass layoffs, you just dissolve a few companies.
I presume board requirements are a lot smaller for such tiny companies, too.
Same applies to any kind of business.
Why should FOSS be any different?
Maybe this is the culmination of the bazaar idea after all, including quickly stuffing the products back into a bag and running away from the law enforcement official between the crowd, by not having either a license or the expected quality.
Because it's not a business. Health regulations for restaurants also don't apply to your kitchen at home, even if you are inviting friends for dinner.
The "do what you want and we will punish you hard if luck strikes badly" is less predictable. It has unfair results. It leads to both excessive risk avoidance (because if you are unlucky punishment is disproportionate) and risk taking customer is unable to proactively avoid.
If you make business with said FOSS you need to provide security just like how a food truck making food from open recipes has to make sure to not poison people either.
Holly bushes grow berries that you shouldn't eat.
Should government destroy all holly bushes? No. All berries? Certainly not.
Speech is a natural right and software is speech, so it can't be meaningfully viewed any other way, unless you're mindlessly parroting representative government deliberations.
Imagine you were making cookies for your friends, and Nabisco happened to get one of the cookies somehow. Should you be responsible if they decide to use the ability, conferred from having one cookie, to create an infinite number of copies of that cookie (without checking it for defects or even really investigating it much) and start selling them across the country? I’d say probably not. But our legal framework doesn’t cover it, because physical objects don’t work like that, unlike software.
We could also look at software as more like a recipe. If Nabisco decided to copy my cookie recipe, they’d unambiguous be responsible for checking it and making sure it wasn’t actually poisonous. We also have cook books, I guess if you put a poisonous recipe in a cookbook you’d have some responsibility. But this is all manageable because cooking recipes are pretty short and easy enough to verify, and the foot-guns of the hobbyist cooking field are mostly well known.
A closer recipe analogy is probably — Nabisco probably gets their bulk supplies from a network of suppliers, who have to manage things like contamination levels and fitness for a given purpose. But now we’re hitting the point where the analogy is at least as complicated as the software supply network; I’m sure there are lots of shared responsibilities and regulations in that network, and it is all professionalized and for-profit.
It's one of the smartest laws I've seen in this area. Want to run a small coffee shack with some cakes, cookies etc? No need for a certified kitchen, "fully trained" cook, etc. The only thing you have to do is take a course that helps differentiate between refrigeration-required and no-refrigeration required food.
Interesting to think how this model would apply in the software context...
And those do apply to small stands and full kitchens. But if you want to claim they are unreasonable, then you should argue by existing ones rather then made up ones.
I did not make anything up. The New Mexico law I mentioned went into effect only a few years ago. Before that, it would be illegal to, for example, bake a cake in your home kitchen and offer it for sale. This is no longer the case.
The interesting here is: What is a product? Most open source is not. The millions of libraries are not products. A product accumulates the various aspects (cybersecurity, license, ....) into a package. If I buy the software from a vendor I will make him responsible for it. If I hack it together on my self, this duty is on me.
Open Source will survive that. But open source owners will get tons of questions and should be better be prepared to answer questions. GitLab and GitHub are already working on the consumer side with their security analysis features.
And do not think that this influence will not happen. There are reason why the non functional requirement licensing has switched to MIT from previously more LGPL constructs.
Having said all that... Yes, no one is obligated to answer.
...for appropriate pay.
More like 450m
It is whether, for companies that offer paid support for FOSS, the obligations are towards the paying customers or all.
The same with FOSS which is used as a basis for commercial products. E.g. Google makes money off Android, but is AOSP with no Google stuff also covered by this law?
And how does it affect companies providing support for software they do not own? (e.g. consultancies).
Being a contributor, even to my own pet project, cannot compel me to contribute my valuable time to the project in ways that I do not so chose. And you can't compel me either to spend my money to hire some third party security firm to audit this code that isn't owned by me or anyone.
If some third party wants to compile this un-owned piece of code and sell it to another, the onus is on them to comply with security regulations.
GPL 3: there is no warranty for the program, to the extent permitted by applicable law. except when otherwise stated in writing the copyright holders and/or other parties provide the program “as is” without warranty of any kind, ...
BSD-3-Clause: this software is provided by the author ``as is'' and any express or implied warranties, including, but not limited to, ...
Apache 1.1: this software is provided ``as is'' and any expressed or implied * warranties, ...
Which means that the liability lies entirely with the user if they use the software for something critical.
If this push isn't stopped... we'll all be taking a crash course on microkernels and the principle of least privilege. (A long overdue crash course, but that's my opinion, and not widely shared)
While I'm generally a big fan of heavy regulation, there's just so much tech that doesn't matter, that we just use to make other things that don't matter easier.
I would much rather see the regulation confined to domain specific things, stuff that directly deals with finances, life safety, industrial, etc.