Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Anyone want to get the source code for the Linux (etc.) in your car?

This site may earn commission on affiliate links.
To me it would seem to be invading the authoring rights of those who write software on top of Linux. It must be their *freedom* to open source, or not, their own intellectual achievements. It is *their* intellectual work to which *they* have the copyright, not Richard Stallman's. If the above were the case, it would make me hope that GPL, or any other license that limits the freedom of people to exercise their own copyright for their own work, will never rule the world.
No one is required to write software based on GPLd code. If they choose to do so, they are required to abide by the rules of the license granted to them. In any case, they never lose their Copyright rights. The GPL was never intended to grant freedom to software developers - it was intended to grant freedom to the people who receive GPLd software.

My only point there was that the legality of it has not been tested in court.
That's because anyone who has been caught violating the GPL and pressed on the issue has always come around and complied with the license before it got to that point.
 
If I was in Tesla's shoes, I wouldn't care about restricting access to proprietary drivers or the base OS that their software runs on. There's not lot of intellectual property value in drivers these days and they probably haven't made major changes to the OS.

I would care about restricting access to the source code for the various pieces of software that control the car. That's a whole new software platform. The value of that intellectual property is huge.

On a more technical level, it should be possible to use an existing generic CAN-bus driver (for example), which is (or would be) part of standard Linux, so that no proprietary software is needed at the kernel level at all. That driver would need to allow Tesla to create a library which provides an API for third-party apps.

However such a driver would need to be configurable in such a way that non-Tesla apps cannot access the CAN-bus driver directly. Or something in that direction.

Regarding GPL/Linux, it sounds like they have not yet found an acceptable solution for kernel modules, and as if GPL3 is going in the wrong direction. They should come up with something much better, more flexible, if they intend to "proceed" towards "world domination".

3) If #1 weren't the case, no one in their right mind would use Linux as a base OS for an embedded system where a software bug can kill people.

Totally agree (in so far as your description of #1 reflects the facts).

- - - Updated - - -

No one is required to write software based on GPLd code.

In a world of limited options, that is a very limited truth, i.e. a non-truth. Especially if Linux is becoming a market leader in areas such as Supercomputers and/or embedded devices.

If they choose to do so, they are required to abide by the rules of the license granted to them. In any case, they never lose their Copyright rights. The GPL was never intended to grant freedom to software developers - it was intended to grant freedom to the people who receive GPLd software.

*Perhaps*, but that sounds like a rather self-serving argumentation (not by you, but by the GPL people), and is not necessarily the sign of something good going on. Not at all.

That's because anyone who has been caught violating the GPL and pressed on the issue has always come around and complied with the license before it got to that point.

Again, that is not necessarily a sign of something good happening.
 
I think it's not currently clear if a Linux kernel loadable module can be non-GPL'ed. I believe it's pretty clear that new applications and libraries used by those apps can be non-GPL.

As for the Tivoization trick, that is clearly legal because Tivo did it and Stallman/FSF came up with GPL3 in response. Google "Tivoization" or check out Tivoization - Wikipedia, the free encyclopedia for more details, particularly Linus Torvald's stance on GPL/GPL2. Lots of people were very pissed off at Tivo. I'd be willing to bet large amounts of money that if the Tivo trick had violated GPL2, Stallman would have sued rather than develop GPL3.

And as for the insurance companies, check out the fine print on your policy. The details will vary from company to company and state to state but in general, insurance companies will treat cars with "non-standard" modifications differently. How different will depend on the modification. But if you replaced the factory anti-lock brake system with your own customized version, I suspect most companies would either refuse to cover you or raise your rate sky high because your risk profile is now very different. And if you get into an accident with coverage "X" and after the fact, your insurance company determines that you should have bought coverage "Y" instead, you will be hosed. They will refuse to cover you because you didn't have the right coverage in effect.

Just for laughs, try asking your insurance company what they'd do if you replaced some of the core software in you car with your own software and see what they say. Or were going to modify the anti-lock brake system. Make very sure to tell them the changes are your own custom mods, not modifications produced by an established tuner shop like Dinan, etc.

So while I'm sure you can get the Linux source, maybe even with all the drivers, it won't do you any good. Tesla almost certainly has set things up so that you won't be able to load your customized software onto the car. And if you manage to bypass the protections, the cost of insuring will car will go through the roof, assuming that anyone is willing to insure it at all.

And if you get into an accident and an arguable case can be made that your software was responsible, there's a good chance you'll be sued. And if the accident is gruesome enough or the DA feels like making an example out of you, they'll try and prosecute you for criminal negligence, manslaughter or something similar.
 
Last edited:
I think it's not currently clear if a Linux kernel loadable module can be non-GPL'ed. I believe it's pretty clear that new applications and libraries used by those apps can be non-GPL.
It's pretty clear that directly linked modules are not allowed - but as someone said before you can work around this by creating a GPLed module that provides an API for your non-GPL code to interface with. Nvidia and AMD do this for example with their closed-source video drivers.

Just for laughs, try asking your insurance company what they'd do if you replaced some of the core software in you car with your own software and see what they say. Or were going to modify the anti-lock brake system.
Stop spreading this myth. Linux (and the GPL) have nothing to do with the core car's systems as far as anyone can tell - only the infotainment system.

Could you hack the infotainment system to mess with other systems in the car? Probably by making it spam the CAN bus system. But you're not going to be hacking the ABS system here - that code is most likely embedded into a dedicated hardware controller.
 
What is the point of having the source anyhow? I know I can get the Tegra3 SDK plus drivers, and that'll get me pretty close to the same starting point as Tesla... then what? I'm supposed to load my own stuff into the system somehow and... do what?

Ok, let's say I did get the source. Now what? Maybe I can work up a way to do MP3 playlists and then I need to release that work back to the open source and Tesla can use it on their general release? Is that the idea? Is that what you are proposing?
 
I think it's not currently clear if a Linux kernel loadable module can be non-GPL'ed. I believe it's pretty clear that new applications and libraries used by those apps can be non-GPL.

You're right. /usr/src/COPYING has a specific preamble from Linus that states the kernel GPL doesn't cover programs that use the UNIX/POSIX userspace API, and it's been fairly well-tested in cases. Firmware is also well-tested -- the mere fact a device driver sends a message to a hardware device doesn't GPL-poison the firmware. The extension of the ABI/API concept to the kernel ABI/API for LKM's, however, is still a gray area. Some lawyers think that a kernel GPL challenge of a LKM because it needs kernel header files to link would be "laughed out of the courtroom", and others believe the derived-work argument would be successful.

There was one hell of an argument on linux-kernel about 10 years ago where Linus spelled out his positions on it, and some posts that have refined his views since. The most pertinent posts and opinions over the years are collected here:

http://yarchive.net/comp/linux/gpl_modules.html

There are some norms that are established, where case law is settled. Firmware is safe and protected. User-space is safe and protected. So, what you do is put your brains in the firmware and user-space, then use a GPL'ed shim that simply passes standard-interface (e.g., IOCTL) messages between them. This is only necessary, by the way, if you need any kernel work at all...

To put us back on track, it really would be stupid for Tesla to build anything into kernel space given the kernel's capabilities today. The kernel simply facilitates the transfer of information across various buses (CAN, USB, etc.) and everything else can be handled in userspace or firmware, free of the GPL taint.

Bottom line, I still don't see what the cage-rattling is all about here. Does the OP think he's going to get any special trade secrets out of Tesla, or just trying to rattle some cages? Any smart company knows better than to embed its trade secrets into Linux at this point in time, so what good is forcing Tesla to put a copy of stock Linux kernel source up on a web site?
 
Last edited:
Stop spreading this myth. Linux (and the GPL) have nothing to do with the core car's systems as far as anyone can tell - only the infotainment system.

Could you hack the infotainment system to mess with other systems in the car? Probably by making it spam the CAN bus system. But you're not going to be hacking the ABS system here - that code is most likely embedded into a dedicated hardware controller.

You're missing the point here. As I understand it, the Tesla software system is designed as multiple standalone processing systems and programs so that the main system driving the touchscreen can crash and the rest of the car will still work.

However, that main system is designed to interact with the rest of the car's systems in a much more integrated way than a typical car today. And as I understand it, that main system is software that runs on Linux.

Look at the driver profiles and integration with the side mirrors. Look at the way the system can dynamically adjust steering and suspension settings. At one point in the future, the driver profiles could set mirror preferences, climate control, seat heaters, steering and suspension settings, hill creep, regen, even acceleration profiles.

It's not just an infotainment system. It's also an integrated control and configuration system. It can and does tell the other systems in the car what they should do. Fortunately, it doesn't tell them how they should go about doing it. So if the primary system crashes, the rest of the systems keep working.

The true danger of messing with the primary system is that a mistake could cause the software to dictate the wrong settings to the other systems. Or keep changing them as you roll down the road. Or both. Will those system behave sanely if their settings are flipped hundreds of times a second? And some of those settings don't make sense? Don't know.

The nightmare danger is that somehow, someone manages to bypass the safeguards around shutting down or booting new engine management or battery pack management software. Both of which I suspect were written by Tesla and are designed to allow OTA updates. Hopefully someone very paranoid wrote the code in those systems so that even if the infotainment system tells it to shut down or reboot, it'll check to verify that the car is shut down before proceeding.

If I'm a Tesla software architect (which I'm not), I'm confident I can engineer a system that will not misbehave like this. But all bets are off if people can mess with my software or swap in a different kernel underneath my software.
 
Could you hack the infotainment system to mess with other systems in the car? Probably by making it spam the CAN bus system. But you're not going to be hacking the ABS system here - that code is most likely embedded into a dedicated hardware controller.

I'm almost afraid to post this, but you definitely can hack safety critical systems from the infotainment equipment. Once on the CANBUS, security is near enough to non-existent. See, for example, http://www.autosec.org/pubs/cars-usenixsec2011.pdf
 
I'm almost afraid to post this, but you definitely can hack safety critical systems from the infotainment equipment. Once on the CANBUS, security is near enough to non-existent. See, for example, http://www.autosec.org/pubs/cars-usenixsec2011.pdf

We've already seen on the development/debug screens posted elsewhere here, that there is more access than is being used in the user-accessible "infotainment".
 
Dude. Seriously? Do you not think Tesla already has enough issues at the moment, between, you know, trying to make the damn cars to begin with, no doubt having to sue their suppliers for breach of contract to deliver quality parts, and the god awful NADA lawsuits in 4 states???

I'm all for free software believe me, and in that I do mean free as in liberty, not free as in beer, but please. Just. Stop.

Besides which, it's unlikely they made any changes to the kernel or GNU user space programs.

Actually, it's guaranteed that they did. Configuration options. Which is what I originally asked them about. The kernel has something like 10,000 configuration choices, and I want to know which ones they used, which I have a right to know.

Well, if nobody else wants it, I'll get the information when I get my car. Since I have a legal right to it.

- - - Updated - - -

Sorry, the release of a stock Linux 3.0 kernel with 12 lines added, if even that, that call hooks in a private, non-GPL kernel module, as well as the source code to fileutils, coreutils, etc. does nothing to open up the car to "user modifications". It doesn't teach you anything about the car's code.

Except for what configuration options they chose, which is *exactly what I want to know*.

- - - Updated - - -

You seem very eager to find something (no offence intended), but why not just write Tesla and ask?

Because so far they've refused. Duh. I have been emailing them back and forth for over a year.

"Other priorities" is really not a good excuse for paying no attention to either community norms or legal compliance.

- - - Updated - - -

I want them to release what's required by the various open source licenses just because I think that's important.

I'm interested in an API to program against, but I'm not likely to pour through the code itself unless I have a problem to solve. I love coding, but I've got to have a problem in mind or it's like reading the dictionary.
Let me tell you what I actually expect to do with the information. I expect to see a problem with the car's behavior, perhaps vampire load or slow response time on a touchscreen, I expect to look through the configuration options and say "Hey! Why didn't you turn on RT_SLEEP?" (or whatever, fake example) and then I expect to email Tesla with my partially informed debugging work, to assist their debugging. Many eyes make bugs shallow, and all that.
 
Let me tell you what I actually expect to do with the information. I expect to see a problem with the car's behavior, perhaps vampire load or slow response time on a touchscreen, I expect to look through the configuration options and say "Hey! Why didn't you turn on RT_SLEEP?" (or whatever, fake example) and then I expect to email Tesla with my partially informed debugging work, to assist their debugging. Many eyes make bugs shallow, and all that.

Except you'll only make problems worse, because you'll have near-zero context at all. You'll have a configuration file to a kernel. Armed with only "the car loses an average of 10 miles range per day" and the kernel configuration file, you'll only cause more problems than help with your well-reasoned "Hey!" message.

Having near-zero context is hardly what I call "informed debugging work" at all, much less "partially".

Have fun storming the castle!
 
Has anyone requested a copy of the Linux that runs on the model S?

A fair amount of software that runs on the model S is GPLed such as the Linux kernel. As an owner of the model S, Tesla is obligated to make available the source code if asked either for free or for a reasonable fee. Of course this does not extend to all of the software. It would be interesting to see what GPLed and LGPLed software is being used on the model S. I am pretty sure that the GUI is written using Qt (probably non-LGPLed version).