Prospects for free software in cars

April 10, 2018

This article was contributed by Andy Oram

Car manufacturers, like most companies, navigate a narrow lane between the benefits of using free and open-source software and the perceived or real importance of hiding their trade secrets. Many are using free software in some of the myriad software components that make up a modern car, and even work in consortia to develop free software. At the recent LibrePlanet conference, free-software advocate Jeremiah Foster covered progress in the automotive sector and made an impassioned case for more free software in their embedded systems. Foster has worked in automotive free software for many years and has played a leading role in the GENIVI Alliance, which is dedicated to incorporating free software into in-vehicle infotainment (IVI) systems. He is currently the community manager for the GENIVI Alliance.

First, Foster talked about the importance of software in modern vehicles. He pointed out that software increasingly becomes the differentiator used to market cars. Horsepower no longer sells these vehicles, Foster says—features do. He claims that some companies even sell the car at cost (the old "razor/blades" or "printer/ink" business model) and make their money on aftermarket apps and features. Companies are finding it effective to get hardware from other manufacturers while improving the user experience through their software. Some of these features contribute to safety (such as alerts that help you drive within the lane or parallel park), and some may be critical, such dashboard icons that warn the driver of electrical system problems or low brake fluid.

Second, Foster introduced the special requirements that free software has to face in automobiles. The requirements and challenges facing car manufacturers are daunting, and free software will have to adapt to meet them, he said. Physical safety and software security are obvious priorities. Many automobile components are no longer purely mechanical and are, instead, electronically controlled based on sensor data, so software is part of the vehicle-safety equation.

Next, Foster turned to the benefits free software offers car manufacturers. Cars use specialized microcontrollers for different functions: one type for braking, another for measuring wheel speeds, and so on. The sheer variety of hardware is one selling point for free software, which anyone can port so it tends to turn up quickly on new systems.

Foster cited two other advantages free software offers to cars: low cost and ease of customization. For instance, the software can be upgraded to conform to the ISO 26262 safety standard (summarized by a National Instruments white paper) and brought to a high Automotive Safety Integrity Level (ASIL). The Linux kernel has not achieved this conformance, but work is being done by Nicholas McGuire at the Open Source Automation Development Lab (OSADL), in conjunction with the Linux Foundation Real Time working group, to certify the Linux kernel and a small C library for safety-critical systems. Certification is difficult because it must be done on hardware and software together, and therefore does not apply to a different version of the kernel on the same hardware, or to the same version of the kernel on different hardware. But, since Linux is free software, the certification process can be undertaken by any organization.

Do car companies understand the value of free software? Increasingly, Foster says, they do. A lot of car development goes on in Germany, where the younger employees of manufacturers are especially attuned to the value of free software. German engineers also tend to respect quality and are willing to critique technical choices (the Volkswagen emissions scandal aside), which are traits that favor free software.

On the other hand, the value of the aftermarket, as described earlier, makes manufacturers hesitate to offer truly open systems. What if users could freely customize their cars? That would eat into the profits that manufacturers could make with their own add-on tools and apps. Manufacturers can cite safety as another concern. Foster hopes that regulation, such as "right to repair" bills, could shake companies free from their attempts to control the aftermarket and thus indirectly remove barriers to the use of free software.

The acceptance of copyleft by manufacturers is qualified and unstable. Many prefer the Mozilla Public License (MPL) 2.0. The mix of software from different companies and sources complicates compliance with the GPL. Companies that putatively release free software tend not to nurture real communities, but instead just "throw it over the wall." Interestingly, auto companies that use GPL software tend to stick to software licensed under the GPLv2 and refuse to move to the GPLv3. Foster cites a couple reasons for this conservatism. Most peeving to them is the requirement that any update systems allow users to install any updates they make themselves, or obtain from third parties. This is often known as an "anti-Tivoization" clause and is mentioned in an earlier LWN article about GENIVI.

Next, the GPLv3 requires full installation information, which companies fear may force the release of trade secrets. Foster believes that this requirement would not force car companies to offer as much as they are afraid it does. But they would certainly have to share private keys that allow changes to code. The GPLv3 also prohibits the code's developers from asserting patents in order to restrict others from using the code. Foster said that this requirement is also implied by the GPLv2, but it's not explicit and therefore does not scare the manufacturers.

Car companies' aversion to the GPLv3 has deleterious effects on the software in their cars, according to Foster. Often they just choose code distributed under more permissive licenses (or "push-over licenses," as Richard Stallman called them in a LibrePlanet keynote). They may also refuse to upgrade their GPLv2-licensed code because the upgrade falls under the GPLv3. Thus, they will have to tolerate the bugs and security flaws that remain in the old code. Foster says that car manufacturers were among the downstream users whose behavior led the Yocto project to provide limited support for old GPLv2 versions.

To make GPL software more attractive to automobile companies, Foster suggested that the developer could sell exceptions, as done by various companies along the way. In other words, the developers could strip the anti-Tivoization clause and installation requirements when licensing the code to the manufacturer. Foster has written an article on this topic.

Foster had other observations about the effect of using free software. He urged regulators to read code. The US Federal Aviation Administration (FAA) has hundreds of staff who can check the source code of airplanes, and Foster attributes the remarkable safety of air travel partly to this.

In general, I got a fairly positive sense from Foster's talk of the progress that free software is making in the automotive industry. Whether they really adopt an open approach to development or undermine it with technical or legal sophistry remains an open question, however.

Index entries for this article
GuestArticles	Oram, Andy
Conference	LibrePlanet/2018

to post comments

Prospects for free software in cars

Posted Apr 10, 2018 17:33 UTC (Tue) by tshow (subscriber, #6411) [Link] (3 responses)

I haven't worked in the car industry, but I have worked in the graphics card industry, before and just as the big players were starting to open up. At the time, if you asked about support for free operating systems, the initial response you'd get was about trade secrets. If you probed a little deeper, however, it tuned out that (at least at the company I was at) the real fears were (a) that open specs would help their competitors find patent violations, and (b) open software would shine daylight on copyright violations and benchmark cheating. Particularly in upper management, there was a fear that they couldn't be sure what shenanigans the engineering troops had got up to, possibly under deniable orders.
Of course, (cough, volkswagen emissions scandal, cough) malfeasance in proprietary code is safe from scrutiny forever...

Prospects for free software in cars

Posted Apr 11, 2018 7:54 UTC (Wed) by mjthayer (guest, #39183) [Link] (1 responses)

Sounds like you are saying that better tools for analysing binaries for violations of various sorts might be the path to more software freedom.

Prospects for free software in cars

Posted Apr 12, 2018 13:02 UTC (Thu) by ortalo (guest, #4654) [Link]

IMHO, manufacturers are not wise enough to realize that their use of confidentiality is ill oriented from a global point of view. But their are certainly smart enough to engage in an easy asymetric race with those trying to analyze their software: they are sure to win (ideas like documentation retention, in the field encryption, legal retorsion, etc. pop up in seconds - in fact, they are already done).

Prospects for free software in cars

Posted Apr 12, 2018 13:11 UTC (Thu) by ortalo (guest, #4654) [Link]

Very thought-raising though rather depressing comment... They do that in fear of their own little felony being revealed. So human.
The only way I found out this loop hole for the moment is to convince law makers to decree manufacturers liability by default (especially in the absence of available free, complete and a priori information on the equipements potentialy involved in an accident).
With such default liability, the entire management line may feel more obligated to actually face their eventual responsibility (i.e. analyse, delegate if needed, treat if possible, assume if necessary, etc.) ; instead of just occulting it (i.e. passing the hot potato to the next one or hiding as much as possible under the carpet).

Prospects for free software in cars

Posted Apr 10, 2018 18:28 UTC (Tue) by aigarius (subscriber, #7329) [Link] (10 responses)

I do work in car industry (specifically BMW) and basically the author is correct. Car industry is really, really slow place to *any* kind of change due to super long release cycles. It takes up to 8 years to develop a new car model from scratch. Sooo, even more than Debian :) So if you were looking for some car-based software project that would reflect current attitude towards open source, then you'd only see that on the market in 6-8 years. But there are people on the inside that are driving for change, easy stuff first, then something harder.

One thing that I do not agree with the author is assigning the ther reluctance to customer-modifiable car software to a profit motive. There are very few car companies that actually offer much in the way of for-profit software services on their cars after they are sold. The motivation is solidly in the safety and reliability area - a faulty component in the car can affect other systems. Even if there is direct connection between the components via one of many in-car communication busses, then even just disturbing the 12V common power system can have bad side-effects on the performance of other car systems. Add in autonomous driving software and you are really in for a ride.

It is more likely that some cars would start coming out with a modified Android tablet as the in-vehicle infotainment platform (which you then could possibly re-flash as all the functionality is in apps) communicating with a infotainment hub device (using the same software as now, receiving commands from apps on the tablet over in-car WiFi). Kind of an open-API car.

Prospects for free software in cars

Posted Apr 11, 2018 7:28 UTC (Wed) by k8to (guest, #15413) [Link] (3 responses)

It's funny how everyone wants to use Android for arbitrary form factor work, like kiosks and and in-dash entertainment, and yet Google is strongly resistant to taking android outside the approved form factors.

I dunno the solution here. Maybe Google will decide to sell Android to the people who want it, or maybe sailfish might eventually get some love.

Prospects for free software in cars

Posted Apr 12, 2018 13:34 UTC (Thu) by ortalo (guest, #4654) [Link] (2 responses)

In my opinion, it's not the form factor, it's the application field. Those who want to use Android in (critical) systems just want the software, they do not want the (critical) liability; they also silently want Google to take that. This is probably what Google does not want to allow (especially via a third-party). Just my personal (unreliable) feeling, but I doubt that Android is ready for this kind of domain, and even if it was, the price would certainly be very different (and the supply contract certainly extremely long and dense).

Prospects for free software in cars

Posted Apr 12, 2018 18:02 UTC (Thu) by flussence (guest, #85566) [Link]

Android's native environment used to be considered critical systems. Smartphones these days are so notoriously flaky with all the Windows-style crapware installed on them that hardly anyone is up in arms at dropped calls or sporadic reboots any more. I already don't trust it to reliably get me through to the emergency services if the need arises, no way do I want it in charge of a 3-ton guided missile that can create a need for them in the first place.

Prospects for free software in cars

Posted Apr 12, 2018 18:40 UTC (Thu) by aigarius (subscriber, #7329) [Link]

For starters anyone doing Android in this kind of area would likely use AOSP, so there is no relationship with Google, no arbitrary third-party app access and there is still full control of the platform. What Android gives you there is an abstraction layer to run your in-car services on top of, as apps. The key is that then you are just securing the operating system layer and relying on sandboxing to protect your car systems from malicious apps.

Prospects for free software in cars

Posted Apr 11, 2018 7:50 UTC (Wed) by mjthayer (guest, #39183) [Link] (3 responses)

> One thing that I do not agree with the author is assigning the ther reluctance to customer-modifiable car software to a profit motive. There are very few car companies that actually offer much in the way of for-profit software services on their cars after they are sold. The motivation is solidly in the safety and reliability area - a faulty component in the car can affect other systems.

The freedom to replace the software on safety-critical components is certainly one thing. The freedom for other people to replace the software in safety-critical components of their own car which will be sharing the road with yours might be another. Even if there are laws to regulate it there will always be people with enough self-confidence (in several ways) to push the laws.

Prospects for free software in cars

Posted Apr 11, 2018 15:31 UTC (Wed) by miahfost (guest, #51602) [Link]

Indeed, many car owners 'chip' their cars using grey market ECUs to change the fuel mixture to squeeze out a little more performance. This can produce a miniature environmental catastrophe by creating clouds of black smoke and pollutants pouring from the exhaust pipe. This pushing of the law is dangerous to the health of lots of people and I think there is a fair argument for regulating the practice.

Prospects for free software in cars

Posted Apr 13, 2018 1:35 UTC (Fri) by wookey (guest, #5501) [Link]

The freedom to replace the software on safety-critical components is certainly one thing. The freedom for other people to replace the software in safety-critical components of their own car which will be sharing the road with yours might be another. Even if there are laws to regulate it there will always be people with enough self-confidence (in several ways) to push the laws.

They can already do this with all the mechanical components. There is no reason to make things more restrictive just because some components are now software. People (especially regulators and manufacturers) get all restrictive and nervous as soon as something is made of software, but that's because they can understand a 3rd-party track-rod end, or even engine, but not changing software components. But we know better: software is a replaceable component (that needs to meet certain criteria to make it suitable for the job), just like hardware is. The volkswagen debacle demonstrates beautifully why this software should be inspectable and replaceable. Surprisingly the people most on our side in this are farmers, who have very expensive machinery that they used to be able to repair, but no longer can, because proprietary software. They want a 'right to repair/maintain', just like we do. https://www.youtube.com/watch?v=F8JCh0owT4w

Prospects for free software in cars

Posted Apr 13, 2018 8:25 UTC (Fri) by nhippi (subscriber, #34640) [Link]

Car tuning is a popular hobby, and definitely not all the mods people are safe. Not mention all the DYI people saving money fixing their breaks etc. The horror stories from car inspectors would be entertaining until you remember that these people share the roads... The risks don't really change much now that we are venturing from hardware modding to software tuning.

Prospects for free software in cars

Posted Apr 11, 2018 15:24 UTC (Wed) by miahfost (guest, #51602) [Link] (1 responses)

I think you're absolutely right aigarius, the safety issue is foremost in the car maker's minds. But one can't help sometimes and look at the after-market and its sizeable profits and imagine the car makers thinking they would like a slice of that pie. In addition, some technology add-ons are very popular and lucrative, like Volvo's On Call system to site one example. These systems are often very expensive, a typical top of the line IVI system can cost 3,000 Euros, so there is a lot at stake in ensuring that users cannot bring in external apps or software.

Prospects for free software in cars

Posted Apr 13, 2018 15:05 UTC (Fri) by aigarius (subscriber, #7329) [Link]

People can now bring in third party applications and software, via Android Auto and Apple Carplay. And that is a double-edged sword. In cars with really cheap and simple infotainment system such approach can help elevate your offering to a commodity level - now all your cars have Google Maps and Spotify.

On the other hand this makes it harder on the top end manufacturers, where the systems are actually better than what a smartphone can provide. It is hard to sell an expensive car if its infotainment is functionally equivalent to a Corolla. So one has to out-Android the Android or you risk losing much more than the 3k€ for the professional model of the IVI - you risk losing a sale.

Luckily there are some nuances to in-car usage that Android is not very well equipped to handle, like the fact that it is really hard to control things with a touchscreen while you are driving. Scroll wheels work much better. But Android apps are not as easy to adapt to that kind of input. There is also a plethora of extra sensors in a car that a tablet simply can not have, such as wheel rotation and steering angle sensors that can give you positioning information when GPS is not available or seat occupancy sensors with positional microphones to detect who is giving a command and adjusting climate only in the position where they are sitting.

Free software for whom?

Posted Apr 10, 2018 18:54 UTC (Tue) by epa (subscriber, #39769) [Link] (7 responses)

The discussion about GPL3 touches on an important issue. Is it really ‘free software’ in your car if you have no ability to change it? Under legal pressure the manufacturer might grudgingly release a tarball of source code, but you can’t even be sure that corresponds to what is running, let alone use it to build and install a modified version.

If free is to be about freedom, not price, then talking of free software in cars is a misnomer. It would be better to say ‘Linux in cars’, or ‘locked-down software systems where you can possibly view the source code’.

Free software for whom?

Posted Apr 10, 2018 21:53 UTC (Tue) by ay (guest, #79347) [Link] (6 responses)

From the vendor side, it's important that the units (in this case let's say various control units) run the binaries the vendor tested and shipped and not some modified binary. There may be safety, security, and reliability/compliance issues. For example I could attack some car system, get the ability to reflash an ECU, and cause something to go wide open throttle and injure people, a dealer tech could reflash the wrong unit, etc. As such these systems boot signed code, which is where GPL3 becomes a problem. Should the vendor compromise security and safety for textbook-definition software freedom? Probably not. Should they have to provide infrastructure for me to put the ECUs into 'development, I own it!' mode and provide signing infrastructure for my own hobby binaries? Probably not, that's a lot of effort and expense, they would need to give me a way to enroll my own keys, sign the binary, etc. and test that. I doubt the underlying bootloader vendor (ex: Vector) would be able to support it without a lot of work.

I've been involved in building several "Tivoized" devices, it was never about DRM or locking people out of freedom and always about security (usually for the customers: assurance they aren't running hacked code) and safety. Ultimately this isn't going to get resolved and I'm afraid GPL3 systems will simply go away in production. Everywhere I've recently dealt with had a "no GPL3" policy for those reasons.

Free software for whom?

Posted Apr 11, 2018 8:20 UTC (Wed) by epa (subscriber, #39769) [Link] (2 responses)

Yes, these are all good reasons why software running in your car is never likely to be free. So let’s stop pretending and let’s stop calling it free software.

Free software for whom?

Posted Apr 11, 2018 16:44 UTC (Wed) by ballombe (subscriber, #9523) [Link] (1 responses)

I completely agree.

On the other hand, I would not be unhappy if closed devices I buy came will full source code and a binding statement that the source code matches the firmware code certified by a third-party.

Free software for whom?

Posted Apr 19, 2018 10:47 UTC (Thu) by Wol (subscriber, #4433) [Link]

In other words, "Open but not Free".

And yes, I don't know how happy I am with that, but it seems reasonable for safety-critical code.

The other option - which would permit GPL3 - is for the law to recognise that after-market software is the same as aftermarket parts. Then the system could be configured such that the user could add *their* *own* signing key for aftermarket software, and at least if anything happens it's clear whether it's original or aftermarket.

Mind you, it might be interesting to look at what happened with Vauxhall/Opel and the Mark II Zafira recently. I don't remember/know much of the detail, but bearing in mind these vehicles went out of production a good few years ago, and the problem was traced to an aftermarket part, Vauxhall had their dealerships check any suspect vehicle for free. They possibly even fixed it for free. (This was the "Zafiras are bursting into flames" news story...)

Cheers,
Wol

Free software for whom?

Posted Apr 11, 2018 15:39 UTC (Wed) by miahfost (guest, #51602) [Link] (1 responses)

I don't think that safety was Tivo's reason for locking their product, but I'm not familiar with their motivation.

What would you say to using an exception in the GPLv3 to permit the car maker to withhold installation information (but still release all the source code)? RMS says using exceptions is okay, the GPLv3 has a robust mechanism for using them, and there apparently a clause vetted by experienced lawyers available that would allow one to provide an exception to section 6 of the GPLv3. This way you would get all of the benefits of the GPLv3 (which is a better license than v2) plus you'd be excepted from supplying the install info like private encryption keys.

Free software for whom?

Posted Apr 11, 2018 21:28 UTC (Wed) by ay (guest, #79347) [Link]

I suspect that for GPLv3 to have any real future (at least in markets like the one discussed here) RMS would need to be very vocal about exceptions and how they work and really worth to educate legal teams about them. At this point GPLv3 is simply forbidden (certain build systems have a GPLv3 filter to disable external packages with that license). On that note, the last time I had to "remove all GPLv3 code" it was really simple, all we had to replace was rsyslog and that's not terribly compelling as a reason to have GPLv3 by itself (there are after all many syslog implementations and rsyslog features are rarely needed in embedded systems). Actually digging through Yocto or buildroot "package" lists, if you were to drop all GPLv3 ones, is anything of value (to the vendor) lost? I really wonder if the battle (assuming there was one) is already lost and it's too late to discuss exceptions and acceptable ways to ship GPLv3 code simply because no one "needs to".

Looking more broadly, new toolchains are LLVM-based (rust, etc), Google is developing Fuchsia which replaces the Linux kernel, uses an LLVM-based toolchain, and replaces pretty much everything else in the "stack", and so on. There might not be much GPL code left if that succeeds and picks up momentum.

Free software for whom?

Posted Apr 11, 2018 21:24 UTC (Wed) by jhhaller (guest, #56103) [Link]

There are ways around GPL3 anti-Tivoization requirements through governmental regulations. For example, I could imagine a requirement that stated using software not signed by the manufacturer makes the vehicle not legal for street use, with a very restrictive exception process. Even getting access to a signing key for your device might be reason to subject you to file for the exception process before being able to be street legal, with the manufacturer notifying which VINs have had firmware keys released. The exception process is likely required even for the manufacturer to validate their software before deploying it. So, an individual might be able to go through the exception, but it might require 300 8-hour road days on private property before being allowed on public streets. Self driving functionality might require 3 vehicle-years of use before a safety driver was not required.

Show you the code?

Posted Apr 11, 2018 5:36 UTC (Wed) by alison (subscriber, #63752) [Link] (9 responses)

Here it is:

http://oss.bosch-cm.com/

I am impressed by the scope of this release: much more than any license terms are likely to have required.

Show you the code?

Posted Apr 11, 2018 20:13 UTC (Wed) by glenn (subscriber, #102223) [Link] (8 responses)

GPLv3 has huge implications for self-driving vehicles. I work in this industry, and the companies I have worked for have always had a policy of not using GPLv3---this policy is not out of anti-OSS mentality. A company committed to testing what they ship needs methods to guarantee system integrity. One option is to deploy signed read-only (e.g., squashfs) system images. Openness and sharing of code doesn't enter into the equation: The need to maintain the integrity of the software stack, and only deploying what has been tested, is paramount. It's one thing to allow an end-user to update a media center box. It's quite another to allow an end-user to modify a software component in a self-driving software stack---there are safety implications not only to the end-user, but to their passengers, and to those around the vehicle. A new library may contain regressions, which may include subtle changes to timing properties, which many have system-level effects. I imagine in most cases that a library update would be harmless, but you can never be quite sure---testing is necessary. Hence, use of GPLv3 software is not a viable option.

Show you the code?

Posted Apr 12, 2018 13:51 UTC (Thu) by ortalo (guest, #4654) [Link]

Informally speaking, I understand what you mean (and I certainly agree that I would not like the software of the car I am a passenger of to be randomly modified).

However: first, on which ground do you really want to prevent people from hacking the device they bought because it is a car? Maybe what we both want is prevent them from driving with it on public roads, ok. But you go a little too far by saying that they should have no right whatsover to know the software that literally runs them. (IANAL & co. applies heavily here. Let's hope the thread will not degenerate in unproductive legalese.)
Just to add a sense of humor: we are used to run our software and we are not used to be run by software... It will take us time and energy to switch side - if we ever do, especially here...

Second, even if reality gives you reason and no one outside of a few selected people are allowed access to car software: how do you intend to provide guarantees about the correctness of the software? All these guarantees should *already* be ready now, while automatic cars are appearing. How will you prove to the victim of an accident that the manufacturer (or one of its numerous subcontractors) software is not the culprit ; without simply resorting to unilateral arguments? Because in this case, I can already predict you the core of it (with my secret unGPLable crystallball software): "It can't be our fault!"

Show you the code?

Posted Apr 13, 2018 1:46 UTC (Fri) by wookey (guest, #5501) [Link] (1 responses)

Why is it fine that people can change their engines, their exhaust systems, their tyres, their brakes, their bodywork, and their fuel system, but they can't change any component of the software because that 'might be dangerous/isn't tested'? What's so special about software in this context? Yes, stuff needs to be of adequate quality, but we really shouldn't give up on software freedom just because manufacturers really like the control. Manufacturers don't like 3rd-party mechanical repairs/upgrades either, but most countries provide rights to those. We need similar rights to fix our software too.

Show you the code?

Posted Apr 14, 2018 21:12 UTC (Sat) by giraffedata (guest, #1954) [Link]

Why is it fine that people can change their engines, their exhaust systems, their tyres, their brakes, their bodywork, and their fuel system, but they can't change any component of the software because that 'might be dangerous/isn't tested'? What's so special about software in this context?

Two things that make software special: 1) far more complex; and 2) far easier to modify. Multiply those together, and I think that with free software in cars, I'm about thousand times more likely to be run over by a car with home-made motion control software than by a car with home-made brakes.

I like the idea of parties other than manufacturers being able to modify software in cars, but it still has to be limited to parties I can trust to put in all the work that's required to ensure it is safe.

Show you the code?

Posted Apr 16, 2018 15:06 UTC (Mon) by federico3 (guest, #101963) [Link] (4 responses)

Nonsense. Cars can be required by law to run software that has been properly vetted and signed by the vendor or, even better, a 3rd party quality control organization.

This has nothing to do with licensing. The problem exists since decades as mechanics and car enthusiasts can apply unofficial binary patches to engine control firmware.

It's not difficult to sign software and implement checks (in hardware) for a legal go/no-go check.

If you patch your car the tests fails and you can still drive the car on a track, or seek legal validation (as people already do for modified cars), or send patches upstream to have them merged.
It's proper FLOSS and there is no tivoization issue here.

Show you the code?

Posted Apr 16, 2018 19:09 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

> If you patch your car the tests fails and you can still drive the car on a track
How do you make sure such cars do NOT drive on public roads?

> or seek legal validation (as people already do for modified cars)
That'd be a couple of million dollars.

> or send patches upstream to have them merged.
Yeah, sure.

Show you the code?

Posted Apr 16, 2018 22:25 UTC (Mon) by federico3 (guest, #101963) [Link] (1 responses)

> How do you make sure such cars do NOT drive on public roads?

On an always-connected device, with onboard GPSes and maps and a dedicated checksum verification device?

>> or seek legal validation (as people already do for modified cars)
> That'd be a couple of million dollars.

And yet many critical systems have plenty of FLOSS on board and yet they receive approval and often blanket approvals for free for use in aeronautics & so on.

Random examples: the Linux kernel and BSD. They receive patches. Various organizations give approvals for special uses.

>> or send patches upstream to have them merged.
> Yeah, sure.

This comments are really not helpful.

Show you the code?

Posted Apr 16, 2018 23:14 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

> On an always-connected device, with onboard GPSes and maps and a dedicated checksum verification device?
None of this is required by law.

> And yet many critical systems have plenty of FLOSS on board and yet they receive approval and often blanket approvals for free for use in aeronautics & so on.
Automotive systems (never mind avionics) are rigorously tested before each release, with prolonged real-world testing on actual hardware. Presence of FLOSS on them is immaterial.

Show you the code?

Posted Apr 17, 2018 7:17 UTC (Tue) by NAR (subscriber, #1313) [Link]

How do you make sure such cars do NOT drive on public roads?

The same way you make sure people without licence do NOT drive on public roads. Random checks and if someone without licence causes a crash, give them extra fine.

Prospects for free software in cars

Posted Apr 13, 2018 17:14 UTC (Fri) by brouhaha (subscriber, #1698) [Link] (2 responses)

GPLv3 doesn't require anyone to publish their private keys. The requirements can be met by providing a means whereby the user can install one or more additional keys which the device will accept for signature validation. As shipped, the product doesn't need to contain any additional keys, and until and unless additional keys are installed, the product doesn't have to accept software from sources other than the vendor.

The procedure to install additional keys doesn't even need to be especially user-friendly, but it needs to be documented, and plausible that a technically competent person could do it.

Prospects for free software in cars

Posted Apr 14, 2018 0:48 UTC (Sat) by ay (guest, #79347) [Link] (1 responses)

We generally build products to meet customer and business requirements. Being able to provision your own keys on an embedded device is rarely if ever a legitimate requirement so simply not using GPL3 code is the most sensible option to businesses.

I've only seen implications of "replace rsyslog with something else", nothing "of value" was lost when scrubbing a system of GPL3 code.

I personally think that battle is lost and the industry has moved on. They'll tollerate GPL2 especially with the termination clause having been clarified but almost no one is going to accept GPL3 on secure devices.

Prospects for free software in cars

Posted Apr 14, 2018 23:01 UTC (Sat) by mpr22 (subscriber, #60784) [Link]

Under property rights, if you own (rather than renting) the embedded device, and it is possible to load new software onto the device but only if it has a signature the device can verify, then being able to provision your own signing keys is (to a decent zero'th approximation) always a legitimate requirement.

There are exceptions, but the number of those exceptions is a lot smaller than a lot of manufacturers would like.