From the wording of the clauses quoted, I don’t see how this would impact open source developers. If I publish an open source project on GitHub, none of these restrictions apply to me. I’m not selling anything to any customer.
Sure, if I were selling the software, then I need to comply with the restrictions. But that is cost of business in EU. The argument becomes that it’s basically a new tax for software vendors. It’s not really about open source per se.
Does anyone know of a good, as in, reasonably non-partisan summary of the CRA? The entire proposal is a little too legalese-heavy for me to manage to get through it properly. Plus the “official” stance from its proponents is not something I want to take at face value too much because I know better than to trust politicians.
But so far all I’ve read in this regard points to things that I don’t consider dire at all, as it seems to amount to:
Forcing the “software supply chain” crowd to treat it like an actual supply chain and stop grabbing people’s hobby projects
Requiring companies to have an auditable, traceable software supply chain – “auditable” and “traceable” are actually inherent part of any other “supply chain” out there but for some reason we need to state the obvious here. I would absolutely welcome that. I am willing to bet a fair quantity of beverage that at least one library or binary on the rootfs of an embedded Linux gadget in your house isn’t packaged from a stable release, but from some arbitrary git revision which happened to have the right fix for some weird compile error or whatever. Wanna bet on which CVE fixes it doesn’t have?
Requiring companies that depend on packaged software to audit their packaged stuff and update it periodically. I’m also firmly on board with that. The alternative is what the vendor of your favourite embedded Linux gadget above likely does – that is, pay some outsourcing company to update everything to the latest stable release once every 6-12 months or so, and hope for the best.
Not allowing commercial reuse of projects that are open source, and have corporate backing, but not substantial enough to guarantee a stream of stable, audited releases. I’m totally cool with that.
Most of the feedback I’ve seen from the industry sounds legitimate, but I can read corporate material between the lines and lots of it seems to come from companies whose primary concern is that they might have to, gasp, ensure the software they use for their commercial offerings is good, and even – oh dear! – pay for the development of the software they integrate in their offerings.
The article makes it sounds like what’s going to happen is that lots of open source software that, say, BMW relies on for their IVI systems is going to die. What’s equally likely, though, is that BMW, along with everyone else who mooches insists software is free as in freedom but is mostly there for the part where it’s free as in beer, will start pitching in, lest they revert to the awful days of the late ’90s when they had to pay a lot more for proprietary code that was a lot less friendlier to its integrators and a lot worse, too.
It sounds an awful lot like the sort of rules the EU, the US, and pretty much every civilized jurisdiction has on electrical and electronic equipment. EU law allows me to tinker with things on my own, publish schematics, and even gift LED Christmas cards to my friends. But the bar for selling my shit is a lot higher. Some of the regulations can be gamed, some of them are obsolete, some are useless, but having seen my share of fake CE-stamped devices I cannot overstate how positive their overall impact has been.
Not allowing commercial reuse of projects that are open source, and have corporate backing, but not substantial enough to guarantee a stream of stable, audited releases. I’m totally cool with that.
Stated exactly like that it seems like one bridge too far. Let me take an example, my own crypto library: infrequent releases, and one fairly out-of-date audit. Yet I have happy users using it to secure their embedded devices. That they actually sell. The question is, should that be disallowed?
I would say it depends. I’m okay with forcing them to provide guarantees for all the code they sell, including mine. But just because my code doesn’t come with sufficient guarantees doesn’t mean they shouldn’t be allowed to provide those guarantees themselves. My crypto library isn’t sufficiently audited? They can do (or pay for) the missing audit.
(It is by the way one of the major points of my library: being small enough that you can take it (and maintain it) as if it was your own, without ballooning your maintenance costs out of proportion.)
But just because my code doesn’t come with sufficient guarantees doesn’t mean they shouldn’t be allowed to provide those guarantees themselves. My crypto library isn’t sufficiently audited? They can do (or pay for) the missing audit.
My current understanding (but IANAL and all) is that they would be allowed to provide those guarantees themselves – they can pay for the audit (along with other users, if they’d like to) upstream, or they can fork it and handle the regulatory aspects – including any development, testing, and auditing cost that incurs – on their own. It’s what gets sold to the users that’s subject to the regulation.
FWIW, this is actually how it works in other fields, too. Over the years, I’ve seen it working in various ways. For instance, I’ve worked with OEM vendors who sold products that were not specifically CE marked but were designed for it. They just had no reason to go through the regulatory hoops with third parties before they had interested customers (these weren’t devices you could self-assess). They offered various kinds of guarantees that it would pass the required tests, and you’d either seek certification through a notified body at your end, or at theirs, whichever was more convenient. I’ve seen both working. (And I’ve obviously seen the bad angle here, too – vendors who swore their products were designed for some spec but absolutely wasn’t – which is why all this is “not very uncommon” rather than standard practice).
I’m not sure what the CRE says about release frequency, if anything, but IMHO infrequent releases aren’t a problem; in fact, I’d be very happy if something – even in the form of provisions related to packaging unfinished software – resulted in less frequent releases that woudl give us a break from the maelstrom created at the unfortunate intersection of “release early, release often” and “move fast and break things”.
they might have to, gasp, ensure the software they use for their commercial offerings is good, and even – oh dear! – pay for the development of the software they integrate in their offerings.
Sounds an awful lot like kicking the ladder. Which is kinda common once you start seeing it. Both US and EU hugely favor large businesses that can actually produce the proper paper trail.
In order not to hamper innovation or research, free and open-0source software developed or supplied outside the course of a commercial activity should not be covered by this Regulation.
There will be new expenses for companies like Docker, I guess, but I don’t see how it affects most open source projects.
Linux is a commercial product, developed in a commercial environment, by many commercially funded engineers. Seems like these laws would apply there.
Similar for many of the large oss projects.
For the big overtly commercial projects like chrome, Firefox, webkit, etc the quotes in the article would seem to rule out the nightly builds many web devs use.
RHEL is an operating system. Linux is a kernel. RHEL is a commercial product, Linux is not. I’m pretty sure /u/olliej was talking about the Linux project, not Linux-based operating systems, since talking about “Linux” as one entity (“Linux is a commercial product”) doesn’t make sense if “Linux” is used to refer to some large set of operating systems.
I am talking about the linux kernel itself, but I’m talking about it in the way that it is actually used: The vast vast majority of linux users are not downloading and building the linux sources directly. They’re using the linux kernel as provided by their vendor.
A plain reading of “Commercial product” does not mean “sold standalone”, otherwise that would make the law trivially circumventable, e.g. “We aren’t selling X, we’re selling support for X”. To claim that the above are not commercial entities for which linux is a component of a commercial product is fairly obviously nonsense.
Alright, so we agree on that. Linux isn’t a commercial product, but Linux is a core component of a lot of commercial products. And of course, the companies which sell a commercial product with Linux as a core component will contribute to Linux development.
I would be interested to know how exactly the regulation treats that. While I think “Linux is a commercial product” is incorrect, “Linux is developed or supplied (in part) in the course of a commercial activity” is certainly correct. My guess is that RHEL/Oracle/IBM/Amazon/etc will have to make sure their product conforms to whatever requirements apply, which includes making sure that Linux conforms; meaning Linux could in principle ignore the regulation, but if it wants to continue being part of commercial products, it must meet the requirements which are imposed upon those commercial products.
“X isn’t a commercial product, it’s just a core component of innumerable commercial products, developed largely by commercial interests, for commercial purposes”?
Anyway, even if we take your definition which is I think “linux is a hobby OS, and no core developers are paid to develop it for its commercial value and use”, it’s still borked under this articles interpretation of the law:
For all the people who work on the linux kernel for a corporation that uses linux as a commercial product, linux is a commercial product.
Afaict, that means that from their point of view, non-commercial contributors need to also treat linux as a commercial product. Which is where the problem happens: unpaid contributors can’t afford the EU rules - unless the EU is willing to pay all contributors that work on software that the EU benefits from, why would any of those people want to do anything but say “my code may not be used in the EU” and add an #ifndef EU around their code? If those contributors don’t do that, and don’t conform to the EU’s rules that are detached from reality, how can RedHat, IBM, ARM, Intel, etc work on or contribute to linux, when some people are not treating it as a commercial product and so are failing to provide the guarantees that the law ostensibly requires, unless they are using their own forks that strip out all such contributions?
You seem to make no distinction between a project being non-commercial but used as a component in products by third-party entities, and a project itself being a commercial product. I do not understand that perspective. I do not know if the law agrees with you or with me on that topic.
I am not disagreeing with you on the point that this affects companies which are using Linux as part of a commercial product, which in practice affects Linux since Linux wants to be usable as part of commercial products. The concerns you outline seem like those I wrote in my earlier comment.
The point I’m trying to say is that from the point of view of this legislation, it seems like linux would be considered a commercial product - sufficiently that commercial developers would have difficulty having “non commercial” developers involved in what they were shipping.
I’m clearly not explaining my concern here very well.
It’s not “oh noes, giant ass corporations will have to spend more”, it’s “giant ass corporations won’t contribute to, or allow changes from people who can’t also afford the new costs, leading to a divergence between projects like linux, and what is actually shipped”. Given those corporations do fund much of the core kernel dev, what happens if they start saying “contributors must agree to meet eu requirements”?
That’s my concern. I don’t give [insert your own favorite expletives] about a corporation that profits from OSS having to spend some more money to ensure they’re not shipping monstrously unsound products, or supporting people who bought a product expecting some basic level of security and support. I’m concerned about the impact on things like he ability for hobbyist devs being able to participate, etc.
From the wording of the clauses quoted, I don’t see how this would impact open source developers. If I publish an open source project on GitHub, none of these restrictions apply to me. I’m not selling anything to any customer.
Sure, if I were selling the software, then I need to comply with the restrictions. But that is cost of business in EU. The argument becomes that it’s basically a new tax for software vendors. It’s not really about open source per se.
Does anyone know of a good, as in, reasonably non-partisan summary of the CRA? The entire proposal is a little too legalese-heavy for me to manage to get through it properly. Plus the “official” stance from its proponents is not something I want to take at face value too much because I know better than to trust politicians.
But so far all I’ve read in this regard points to things that I don’t consider dire at all, as it seems to amount to:
Most of the feedback I’ve seen from the industry sounds legitimate, but I can read corporate material between the lines and lots of it seems to come from companies whose primary concern is that they might have to, gasp, ensure the software they use for their commercial offerings is good, and even – oh dear! – pay for the development of the software they integrate in their offerings.
The article makes it sounds like what’s going to happen is that lots of open source software that, say, BMW relies on for their IVI systems is going to die. What’s equally likely, though, is that BMW, along with everyone else who
moochesinsists software is free as in freedom but is mostly there for the part where it’s free as in beer, will start pitching in, lest they revert to the awful days of the late ’90s when they had to pay a lot more for proprietary code that was a lot less friendlier to its integrators and a lot worse, too.It sounds an awful lot like the sort of rules the EU, the US, and pretty much every civilized jurisdiction has on electrical and electronic equipment. EU law allows me to tinker with things on my own, publish schematics, and even gift LED Christmas cards to my friends. But the bar for selling my shit is a lot higher. Some of the regulations can be gamed, some of them are obsolete, some are useless, but having seen my share of fake CE-stamped devices I cannot overstate how positive their overall impact has been.
Stated exactly like that it seems like one bridge too far. Let me take an example, my own crypto library: infrequent releases, and one fairly out-of-date audit. Yet I have happy users using it to secure their embedded devices. That they actually sell. The question is, should that be disallowed?
I would say it depends. I’m okay with forcing them to provide guarantees for all the code they sell, including mine. But just because my code doesn’t come with sufficient guarantees doesn’t mean they shouldn’t be allowed to provide those guarantees themselves. My crypto library isn’t sufficiently audited? They can do (or pay for) the missing audit.
(It is by the way one of the major points of my library: being small enough that you can take it (and maintain it) as if it was your own, without ballooning your maintenance costs out of proportion.)
My current understanding (but IANAL and all) is that they would be allowed to provide those guarantees themselves – they can pay for the audit (along with other users, if they’d like to) upstream, or they can fork it and handle the regulatory aspects – including any development, testing, and auditing cost that incurs – on their own. It’s what gets sold to the users that’s subject to the regulation.
FWIW, this is actually how it works in other fields, too. Over the years, I’ve seen it working in various ways. For instance, I’ve worked with OEM vendors who sold products that were not specifically CE marked but were designed for it. They just had no reason to go through the regulatory hoops with third parties before they had interested customers (these weren’t devices you could self-assess). They offered various kinds of guarantees that it would pass the required tests, and you’d either seek certification through a notified body at your end, or at theirs, whichever was more convenient. I’ve seen both working. (And I’ve obviously seen the bad angle here, too – vendors who swore their products were designed for some spec but absolutely wasn’t – which is why all this is “not very uncommon” rather than standard practice).
I’m not sure what the CRE says about release frequency, if anything, but IMHO infrequent releases aren’t a problem; in fact, I’d be very happy if something – even in the form of provisions related to packaging unfinished software – resulted in less frequent releases that woudl give us a break from the maelstrom created at the unfortunate intersection of “release early, release often” and “move fast and break things”.
Sounds an awful lot like kicking the ladder. Which is kinda common once you start seeing it. Both US and EU hugely favor large businesses that can actually produce the proper paper trail.
There’s more about this in the feedback submitted by a group of open source internet infrastructure software developers, including my employer isc.org. (Although isc.org is based in the US, most of our software engineers are in Europe.)
And previously on the NLnetLabs blog and more recently on the isc.org blog
I’m not sure I believe the headline.
Page 15 of the proposal says:
There will be new expenses for companies like Docker, I guess, but I don’t see how it affects most open source projects.
Linux is a commercial product, developed in a commercial environment, by many commercially funded engineers. Seems like these laws would apply there.
Similar for many of the large oss projects.
For the big overtly commercial projects like chrome, Firefox, webkit, etc the quotes in the article would seem to rule out the nightly builds many web devs use.
What makes Linux a commercial product? Has anyone ever bought a copy of the kernel?
Yes. What is RHEL, if not a commercial Linux distribution? You pay Red Hat money to use it.
RHEL is an operating system. Linux is a kernel. RHEL is a commercial product, Linux is not. I’m pretty sure /u/olliej was talking about the Linux project, not Linux-based operating systems, since talking about “Linux” as one entity (“Linux is a commercial product”) doesn’t make sense if “Linux” is used to refer to some large set of operating systems.
I am talking about the linux kernel itself, but I’m talking about it in the way that it is actually used: The vast vast majority of linux users are not downloading and building the linux sources directly. They’re using the linux kernel as provided by their vendor.
Oracle, IBM, RedHat, numerous cloud providers, etc
A plain reading of “Commercial product” does not mean “sold standalone”, otherwise that would make the law trivially circumventable, e.g. “We aren’t selling X, we’re selling support for X”. To claim that the above are not commercial entities for which linux is a component of a commercial product is fairly obviously nonsense.
Alright, so we agree on that. Linux isn’t a commercial product, but Linux is a core component of a lot of commercial products. And of course, the companies which sell a commercial product with Linux as a core component will contribute to Linux development.
I would be interested to know how exactly the regulation treats that. While I think “Linux is a commercial product” is incorrect, “Linux is developed or supplied (in part) in the course of a commercial activity” is certainly correct. My guess is that RHEL/Oracle/IBM/Amazon/etc will have to make sure their product conforms to whatever requirements apply, which includes making sure that Linux conforms; meaning Linux could in principle ignore the regulation, but if it wants to continue being part of commercial products, it must meet the requirements which are imposed upon those commercial products.
“X isn’t a commercial product, it’s just a core component of innumerable commercial products, developed largely by commercial interests, for commercial purposes”?
Anyway, even if we take your definition which is I think “linux is a hobby OS, and no core developers are paid to develop it for its commercial value and use”, it’s still borked under this articles interpretation of the law:
For all the people who work on the linux kernel for a corporation that uses linux as a commercial product, linux is a commercial product.
Afaict, that means that from their point of view, non-commercial contributors need to also treat linux as a commercial product. Which is where the problem happens: unpaid contributors can’t afford the EU rules - unless the EU is willing to pay all contributors that work on software that the EU benefits from, why would any of those people want to do anything but say “my code may not be used in the EU” and add an #ifndef EU around their code? If those contributors don’t do that, and don’t conform to the EU’s rules that are detached from reality, how can RedHat, IBM, ARM, Intel, etc work on or contribute to linux, when some people are not treating it as a commercial product and so are failing to provide the guarantees that the law ostensibly requires, unless they are using their own forks that strip out all such contributions?
You seem to make no distinction between a project being non-commercial but used as a component in products by third-party entities, and a project itself being a commercial product. I do not understand that perspective. I do not know if the law agrees with you or with me on that topic.
I am not disagreeing with you on the point that this affects companies which are using Linux as part of a commercial product, which in practice affects Linux since Linux wants to be usable as part of commercial products. The concerns you outline seem like those I wrote in my earlier comment.
As a follow up, it appears the US government takes an even stronger position on OSS being commercial software, hence my concern about what the EU thinks seems reasonable: https://dodcio.defense.gov/Open-Source-Software-FAQ/#q-is-oss-commercial-software-is-it-cots
The point I’m trying to say is that from the point of view of this legislation, it seems like linux would be considered a commercial product - sufficiently that commercial developers would have difficulty having “non commercial” developers involved in what they were shipping.
I don’t see the problem. Giant companies exploiting “open source” for their own benefit have some new expenses. Boo hoo.
The headline makes it sound like run of the mill open source projects have a dire crisis on their hands, when they really don’t.
I’m clearly not explaining my concern here very well.
It’s not “oh noes, giant ass corporations will have to spend more”, it’s “giant ass corporations won’t contribute to, or allow changes from people who can’t also afford the new costs, leading to a divergence between projects like linux, and what is actually shipped”. Given those corporations do fund much of the core kernel dev, what happens if they start saying “contributors must agree to meet eu requirements”?
That’s my concern. I don’t give [insert your own favorite expletives] about a corporation that profits from OSS having to spend some more money to ensure they’re not shipping monstrously unsound products, or supporting people who bought a product expecting some basic level of security and support. I’m concerned about the impact on things like he ability for hobbyist devs being able to participate, etc.