BMW are complying with the GPL | Hacker News Reader

BMW are complying with the GPL

shkspr.mobi

423 pointsedent113 comments

Interesting: BMW did share the OSS they used, and in the process they also revealed lots of outdated packages in use. This of course leads me to wonder: Vulnerabilities?

It is after all an Internet-connected vehicle.

Despite the article author's recognition given for BMW's OSS compliance, I am dismayed to see yet another example of likely inconsideration given toward implementation of security in the engineering of an Internet-connected vehicle.

This sort of negligence is eventually going to result in some rather ugly outcome.

Total guess: as a regulated company, they may have to get approval for their code, which would include validated versions of 3rd party code. If they have to go through that with any new version of 3rd party code, they may not want to make that effort.

Well, the first time a hacker vehicle exploit results in one or more deaths of the driver and/or passengers of one of these Internet-connected vehicles, it's going to be all over the news. Right around then... and when the lawsuits hit, some execs/directors are going to realize that such effort is far less costly than the PR disasters that can unfold when corners are cut.

I mean, obviously some people at Volvo thought that actual emissions compliance was far too costly to bother with --and that didn't even result in a vehicle accident or personal injury. Certainly their bottom line has had a major impact as a result. The potential for PR disaster with Internet-connected vehicles is certainly much more concerning.

The inevitability of some such future tragedy and resulting media-fueled PR disaster for one or more vehicle manufactures is a certainty. It's only a matter of when and which vehicle manufacturer(s) will be liable. When that happens, I’m certain that such sizable companies can figure out how to streamline the approval process with whatever regulatory bodies might be involved, or they’ll just learn to live with the pain… for being for less than the much greater pain of a PR disaster.

You're confusing Volvo with Volkswagen.

Which just goes to show the real impact of that PR disaster -> none. People can't even remember correctly which of the 3 or 4 largest car brands in the world it was.

Their stock price dropped by like 40% in a few days. I think that trumps "one person on the internet got a name confused."

I'm not following Volkswagon stocks, but did they bounce back up after a while or are they stuck in a down? If they're still down than yes that trumps, but if it got back up after a while I guess some people made loads of money on this debacle but VW seems unharmed.

They bounced back a bit, but they're still more than 20% off what they where the day before the scandal broke and att almost half of their 12 month peak.

That's not obvious at all. Their share price has now recovered half way to where it was, so you should call that a 20% drop when comparing to what people remember today (not the few days after news broke). Not only that, it was already in an even bigger decline during the year leading up to the emissions scandal, and that decline instantly stopped. Compared to the pre-scandal trend, you could almost argue that their share price has improved since the scandal.

Look at the graph. http://finance.yahoo.com/echarts?s=VOW.DE+Interactive#{"allo...

http://www.wired.com/2016/03/survey-finds-one-4-americans-re...

True, I typo'd. Thank you for correcting me.

> Well, the first time a hacker vehicle exploit results in one or more deaths of the driver and/or passengers of one of these Internet-connected vehicles

It's the infotainment system according to one of the original blog posts. And in fairness the previous post was all about the updates they were providing - albeit unencrypted.

Wasn't the Wired article reported Jeep hack done via the infotainment system (through an improperly implemented one-way connection to the canbus, from memory)?

Yes, precisely: "Miller and Valasek’s exploit uses a burner phone’s cellular connection to attack the Jeep’s internet-connected entertainment system." http://www.wired.com/2015/07/hackers-remotely-kill-jeep-high...

It doesn't matter if it's the infotainment system so long as it's connected to the rest of the electronics. Yes, hacks have already exploited critical vehicle controls via Internet infotainment systems. So long as vehicle manufacturers do not physically separate the electronics, such vulnerabilities will surface. Currently, the standard practice is to build out the electronics for a vehicle as a single system.

I'd rather wait until your claims of security issues and remote hacks are verified for the particular vehicle here.

All of this is just crying wolf so far.

Remote-drive vulnerabilities have been demonstrated in infotainment systems, proving that the class of vulnerabilities is real. There's no need to prove it can happen for every single vehicle to be concerned about general best practices.

Yes there is. If this system have no write ability onto the relevant CAN-bus, the class of vulnerability you talk about (which comes from the Jeep hack) does not exist.

But sure - best practices should be followed.

> Currently, the standard practice is to build out the electronics for a vehicle as a single system.

What do you mean by this? The car itself is a single unit so you can assume the electronics inside communicate at some level (CAN networks usually), but the electronics are separated. You have a control unit for the engine, another one for the ABS, another for the gearbox and many others for various body control functions. Some of them communicate with each other over the CAN, but only transmit/receive messages of particular interest. For example, the ABS unit in some cases tells the engine control unit the vehicle speed. The engine control unit transmits the engine RPM to the body control unit for obvious reasons. The same for the anti-theft mechanism.

To the subject: Having outdated drivers in production level software is common practice. During final validation of the SW, before start of production, if some drivers are found outdated (even declared invalid by the driver/package owner), people do not jump to upgrade immediately. It undergoes a process of analysis: is there any critical bug which the new version fixes? Does it impact the current project configuration? If not, why upgrade? You run the risk of introducing a regression => requires extra validations which can take weeks or months. Nobody will approve that just to fix some bug without functional impact in that particular system. So when you claim that a certain package has to be updated to the latest version, you have to come up with arguments. "Newest is always better" does not count. There are countless examples when newer versions of some piece of SW fixed some bug but broke something that was working. SW updates after the majority of the validation process is finished happens only on a NEED TO HAVE basis.

And the CIO at Target probably said "It's only the HVAC system." :)

> Well, the first time a hacker vehicle exploit results in one or more deaths of the driver and/or passengers of one of these Internet-connected vehicles, it's going to be all over the news.

Michael Hastings, anyone?

Not Volvo - Volkswagen.

Correct. I typoed.

I suspect the first time that happens, automakers will move away from FOSS so that the can at least hide what outdated junk they're using.

Or they will phrase it as "Hacker uses open sourced BMW code to find a vulnerability resulting in a fatal vehicle crash", "If they hadn't opensourced it, it wouldn't have happened!"

Exactly this. All software in safety critical components needs to be validated. Validation is very expensive, especially if you can't argue that it's "industry standard" software, so an already validated piece of software nearly always wins over alternatives.

From the looks of it, they used the OSes the chipmakers provide in their reference packages. The stlinux stuff seems ripped pretty much verbatim from stlinux 2.4 [0] and the rest seems to be from Freescale/NXP's reference linux for their i.MX series [1]. Automakers, like a lot of other entities, rarely make their own distros themselves, but rather tend to use the reference OS provided by the chipmakers.

[0] ftp://ftp.stlinux.com/pub/stlinux/2.4/

[1] http://www.nxp.com/products/microcontrollers-and-processors/...

Excellent reply.

Indeed, quite true.

Though none of this excuses any negligence, no matter if it is the vendor of the manufacturer.

With software this old, there certainly are vulnerabilities, probably full on exploits available, that have also long since been patched. The attack surface of new products using old software is much higher than it ought to be. And consider not is it in need of updating before it's being driven off the lot, it's likely to have service updates for a time frame shorter than its useful service life.

We're doing this wrong.

You'd be surprised at the amount of effort to apply upstream patches or fixes to older vendor software. Many vendors also maintain older forks indefinitely. I've spent an inhumane amount of time applying/porting modern security fixes to ancient codebases.

The root of the problem is: you buy a part, and to use the part you need some software to talk to it. The vendor, along with the part, supplies you with some sample code, which uses some ancient kernel and ancient GPLv2 utilities. If you use their code, then you perpetuate the problem. If you choose not to, then they won't help you when you have issues.

Why do vendors use such ancient software? Vendors care deeply about their IP, and to some extent tivoization does happen with individual products, but more usually through obfuscation. Not a whole lot of open firmware for wireless chipsets, is there?

Customer demand can change things, but vendors are afraid of their customers stealing their technology, and taking it to a cheaper competitor, or building it themselves. This stuff happens all the time. So they give you some code that talks some foreign language to their part or give it a seemingly black box blob of code to run and suddenly it's a black box to you too.

Patents (for hardware), and China's lack of concern for IP theft are the root of all of this.

I think there is something more primal going on too.

Vendors might at some time chose to say "freeze" and now we will just deliver this same binary blob, or at best generate new binary blobs from an ancient source stack we have under version control.

Making changes means, at best, going through an expensive testing procedure. At worst, there is no such procedure and all change is an anethema.

So they only make changes when they have to, and as the cost of staying obsolete increases, so does the cost of becoming up to date.

I tend to agree, but remember that for many vendors providing code that doesn't run/isn't tested on some LTS kernel means no one will use it. Or, you'll incorporate the vendor delivering support as part of the deal.

Many times I've spent late nights babysitting an employee from $VENDOR debugging/fixing/rewriting their driver to play nice with our stack.

I would guess that they have a package filter to prevent those vulnerabilities to be exploited. It seems a rather standard practice in places where updating is not a easy option, either because it breaks things or because of bureaucratic verification process, but where filter rules can easily be kept updated.

This is why you never connect anything that isn't running a supported and update-able operating system to the internet. That includes your car, your TV, your washing machine, your printer, your fridge, and your old Windows XP box.

On the hardware side, the product development cycle for a car is about 5 years, which design lockins in stages along the way (there's a mad rush for a "land grab" for engine compartment space by suppliers many years in advance to the actual launch of the car).

It wouldn't surprise me if the software had a similarly long development and lock-in cycle.

> Despite the article author's recognition given for BMW's OSS compliance, I am dismayed to see yet another example of likely inconsideration given toward implementation of security in the engineering of an Internet-connected vehicle.

I hear you, but isn't this one of the reasons for wanting compliance around the (L)GPL? It allows us, the owners of the vehicle and users of the software to make that inspection, and hopefully, patch the vulnerabilities in the software, right? (I believe one of the provisions of the LGPL is that it must be possible to replace the LGPL'd software with a different version — this is why most software dynamically links to LGPL libraries: it allows the .so/.dll to be "simply" swapped out for a different one.)

Unless you're using v3 of the LGPL, the provision only extends towards providing separate object files for the program (if statically linked) or separate shared library files for the library (if dynamically linked). It is pretty much useless if you have no means to install a modified binary.

Open-source vulnerabilities are much less scary than closed-source vulnerabilities.

only if the code is updated.

I've got a draft to our CEO sitting in my inbox outlining why we should open source some of our code - the majority of the argument posits that "technical investment" (as a corollary to technical debt) is possible. OSS can be viewed as a "technical share market," and by moving non-competitive code to open source you stand to reap "technical profit" or dividends. Not to mention that open-sourcing code usually entails a major cleanup effort (technical debt removal) prior to release.

I've already got CoreCLR listed as a positive example of this process and I really hope that BMW is rewarded for compliance (with feedback and patches) - having more examples will only strengthen my point that more can be gained by working with open source, instead of merely consuming permissive open source.

Either way, it's great to see compliance from such a large corporate.

Send it. If I can control and extend the computing environment in my car, I will buy that car. I will also release the code I write for it - which creates apps other car makers don't have.

If you end up tweaking the breaking system, just don't do it too late at night and remember putting an "I hacked my car's software" sticker somewhere visible from other cars in the road.

For any of this you'd likely need all the code and, if I'm understanding things correctly, this is only a partial dump (things licensed under GPL).

That is an interesting point in terms of roadworthy legislation, though.

The "braking" system - or was that typo intended?

Either way, you don't need a license or even much in the way of special tools to replace the brake pads, rotors, calipers, or hoses on any vehicles on the road today. The parts are casually sold at tens of thousands of auto stores across the country in enormous volumes every day, many of them to ordinary men and women working on their cars in their garages. Not all of them get it right, but there is no outcry against this maintenance - why should there be a problem with software?

To further assuage your fears, braking systems and other safety-critical components have layers of software and physical fail-safes. If the wheel sensors report unusual data, all-wheel-drive may be disabled. If the anti-lock code doesn't work, you still have regular brakes. If the vacuum assist doesn't work, you still have manual brakes. Similar layers are present in the steering and engine control. If a mechanic applies caliper grease to the brake pads, all of this is for naught - but there is little the software can do to completely disable the brakes.

> Either way, you don't need a license or even much in the way of special tools to replace the brake pads, rotors, calipers, or hoses on any vehicles on the road today.

Some cars sold today require connecting of specialised diagnostics tool which will allow to change brake pads. Without this tool your calipers will not open. What this tool does? It just sends some commands through vehicle CAN bus, but those commands are proprietary, so you need to pay them about $10k-$100k a year to have access to commands for their cars and licence to use them in your tool.

> I've already got CoreCLR listed as a positive example of this process and I really hope that BMW is rewarded for compliance (with feedback and patches) - having more examples will only strengthen my point that more can be gained by working with open source, instead of merely consuming permissive open source.

I guarantee you no benefit will come to BMW for this. The reason is that this is a mostly useless code dump for the purpose of fulfilling the license. It's just a bunch of old code from open source projects you can download off the web. If they made changes to any of those, they're probably minimal, and my experience with such code drops is that they're also unlikely to actually build.

If you release a product as free software, develop it in the open and encourage contributions, it can be a benefit for you.

If you use a GPL'd library in your big proprietary solution, some pesky random internet commenter demands the GPL'd sources and you send him a tarball of an old version of newlib and a linux 2.4 kernel tree with some seriously out of date ARM patches, you won't get anything back, and you probably don't expect to.

is there any email account to sent a resume for that team ? :)

Good to see the follow up on this. And for what it's worth, I think Terence has handled this well and is being overly harsh on himself. The original comment was just a throwaway aside and not even an accusation. I don't think he should hold himself responsible for how others took the comment & inflated it.

As the owner of a BMW, he's entitled to ask BMW for a copy of the LGPL source used. Job well done.

Do BMW have any obligation to provide it in any kind of buildable state? This looks like half a buildroot tree, but the build scripts are missing.

"The source code for a work means the preferred form of the work for making modifications to it."

For example, perhaps they have no build scripts, and do it by hand every time.

If BMW developers do it this way, then that's fine by the wording of the GPL. It wouldn't be reasonable to require them to provide anything further than what they already do.

Scripts doesn't necessarily mean software scripts; it could be a script as in a script for a play. If the BMW engineers memorized their lines and know how to do them, they have to write out those lines as a requirement of the GPL. The GPL requires "oral tradition" build scripts to be passed along as well.

  Do BMW have any obligation to provide it in any kind of
  buildable state?

Yes. GPLv2, section 3:

   For an executable work, complete source
   code means all the source code for all 
   modules it contains, plus any associated interface
   definition files, plus the scripts used to control
   compilation and installation of the executable.

I wish people stopped trying to tip-toe around the poor, hurt feelings of BMW. BMW is a big company and can afford to have properly trained customer reps that know how to point to the source code. We're the little guy here trying to figure out how our cars work; BMW is the giant just meeting their bare minimum requirements.

BMW doesn't actually have any feelings - it's a corporation, and it doesn't care how much some hacker is upset when a twitter rep doesn't know what open source is. The only people who care about software licences are people who write software. Deal with it.

> The only people who care about software licences are people who write software.

This is not true in any way - people who use and sell software, such as BMW, spend a lot of time, money, and lawyers on licensing issues.

Corporations care about anything that affects their bottom line, and a distinguished hacker who raises a small ruckus could ultimately build into disaster. It's simply responsible to have your front line know who to refer people to when they ask if you're in compliance with the law.

Frankly I really disagree, to ask BMW to train all it's service reps to provide source code when only a _very_ small portion of the population will be asking for it is a bit ridiculous. Now, I can maybe see some sort of training where they basically tell them to redirect someone to a special rep.

Thank you for your kind words - most appreciated.

Some thoughts:

Most of the companies ship older pieces of software for one important reason: They need to avoid GPL/LGPL/AGPL version 3. Version 3 of GNU GPL gives users more freedom which companies hate.

For GPLv2 the companies had to just give away the source code. But they need not give away a way to change the software in the hardware. Which was then popularized as Tivoization. Version 3 of GNU GPL family of licenses fixed that. But companies didn't.

So you can see a pattern in any hardware (routers, Cars, etc.) and even in OS like Mac, *BSD etc. And the pattern is they always avoid GPL v3. So they always have old gcc, coreutils, bash, and everything else. They say its GPL, but there is a vendor lock-in, as always.

Which is why I find Linus's childish view of the GPL so frustrating. He claims to have never used it for "user freedom" reasons (even though I'm sure that's how Richard Stallman would've persuaded him). If you frame the question of "is tivoisation bad" as "how could a psychopath use my code to harm users" it becomes clear that tivoisation is something we must reject.

Its a fact that Linus doesn't even care about open source[0]. Then how will he be caring about software freedom?

Hope, someday, we shall have GNU Hurd ready. Anyway, GNU guix is getting better.

[0] http://www.techrepublic.com/article/linux-creator-linus-torv...

Indeed. He simply uses it because it's the best software development model. I think open source could use more people like him, though.

P.S. Man, how I love downvotes without any arguments whatsoever.

I didn't down-vote you, but I'll explain why I don't like his view on free software.

Free software is chiefly concerned with user freedom, to ethically treat users of your software. The GPL is the standard example of a free software license, and its purpose is to in perpetuity make sure that all users of your original code will always be able to use it in freedom.

You may notice I didn't reference a "development model". In my opinion, development models are secondary to ethical issues such as user freedom. Yes, it turns out that the "bazaar" model of software development works pretty well, but that doesn't mean that you couldn't have a "cathedral" free software project.

The problem with the "open source" movement is that there is no question about morals and ethics. It's just "here are 10 criteria which will give you good code, but if you find a better way to get good code, more power to you". It's plainly obvious when it comes to issues like vendor lock-in why "open source" doesn't have enough of a moral backing to explain why vendor lock-in is unacceptable. If the code is good quality, why are you complaining about vendor lock-in?

I wish we had more people like Stallman who will bring attention to the important issue here, the issue of user freedom. Proprietary software hasn't been vanquished yet, and it's not going without a fight.

I just read that article and it's slightly depressing:

> Between the launching of Linux and today, we've waded through decades of free and open source holy wars, but Torvalds' first instinct was right: Software doesn't want to be free, necessarily. It just wants to be open enough that developers can get to work with a minimum of fuss.

sigh No, some of us do care about user freedom and are seriously worried about the recent attacks on user freedom done by companies like Amazon.

At least some of the Linux developers care about software freedom:

https://sfconservancy.org/linux-compliance/ https://sfconservancy.org/supporter/

It's not always about avoiding the GPLv3 - and it's certainly not like that for everyone. I would plead laziness, not evil intentions.

Many times, it's just that the product development may have started a long time ago or that they're using some previous product or prototype to build on - which uses even older software versions. Development takes time..

Or they could be using some SDK or vendor supplied base for parts of your products. Then they won't have control over the software versions anyhow, in a way.

It's very complex and somewhat annoying to keep up with updating all software and libraries in proprietary products.

That in itself should probably say something about the security of a lot of shipped products I guess..

The GPLv3 is definatelly the core cause. It is so deep in the minds of those companies, when you talk to them about GPLv3 it is like talking to the devil about holy water.

BMW is one of the core members of the GENIVI Aliance (http://www.genivi.org/) which tries to bring Open Source (not Free Software) to the industry, to make code reuse easier between the companies.

GENIVI has a demo platform (http://wiki.projects.genivi.org/index.php/GENIVI_Demo_Platfo...) which they build with help of Yocto (https://www.yoctoproject.org/). Most of the members of GENIVI use Yocto for internal development too.

GENIVI provides a layer of recipies for Yocto, which is called meta-ivi. In this layer there is a sample configuration file which many use as a starting point for their development. Most of the other layers which provide this local.conf sample file don't have this special line, but this In-Vehicle-Infotainment layer (you can even think of it like a linux distribution) which is used by the car manufacturers has it:

INCOMPATIBLE_LICENSE ?= "GPLv3"

http://git.yoctoproject.org/cgit/cgit.cgi/meta-ivi/tree/meta...

Yep, but it's for patent reasons. I used Yocto for $PRODUCT and we had the same variable set. See my reply to the grandparent (does that make it an uncle or aunt of this reply?)

> Yep, but it's for patent reasons.

I don't see Apache 2 in that list of 1 incompatible license. Apache 2 has an almost identical patent provision (GPLv3 just made the requirement of "apply to all users" slightly stronger).

Because Apache 2 doesn't turn all code it touches into Apache 2 code.

I can use Apache 2 code with my secret, proprietary patent-sauce -- no problem. I never have to release any of it, and I don't have to grant anyone any licenses.

It is only when I contribute to the Apache 2 code that I grant a patent license.

(IANAL)

TL;DR: Companies don't hate "giving users more freedom"

Having worked with IP lawyers on multiple consumer electronic products across multiple companies, I believe you are over-simplifying the situation. Every IP lawyer I've talked to didn't care about tivoization -- if you want to go run your own code on our hardware, great, good luck. The main issue with GPLv3 was always the patent clause: http://www.gnu.org/licenses/gpl-3.0.en.html#section11

I've never met an IP lawyer working for a company with many (hundreds to thousands) of patents allow use of the GPLv3, out of fear that it could undermine their ability to enforce patent rights defensively. Hardware companies produce a ton of patents. The manufacturers of routers, cars, and even Apple care deeply about their patents. They're not willing to toy with some untested clause in a license of some free software, when there is a perfectly usable version of that software without such a clause.

IANAL so I don't know for sure if this is the case, but speaking from experience, this is what lawyers have always told me.

Second, companies generally don't make it easy for users to run custom software on their products for a few reasons. You generally put software on products one of two ways: physically, or over-the-air (wifi/ethernet/some other way). With both methods, "signed" payloads are usually used for one of two reasons: to make sure it is error free. It's difficult to have the device already know the checksum, but calculating a signature against a pre-installed signing certificate is easy and works pretty well. You also get the added benefit of decreasing the surface area for remote attackers, since only the trusted company can sign the payloads. Typically, also, physical writing is "disabled" during assembly (e.g. not populating components, sealing off access, etc.) which helps keep costs down and keep the design looking slick.

The second reason "signed" payloads are used is for "Tivoization". I've never heard anyone say "we don't want customers putting their own software on a device they purchased." No doubt it happens, but it is rare for sure.

Should companies spend more time and resources to make it easy for their customers to modify their devices, in a sane and secure manner? Possibly. But in today's cutthroat consumer-electronics world, you'd be hard pressed to find a company willing to spend that extra engineering effort on something so frivolous.

> TL;DR: Companies don't hate "giving users more freedom"

More freedom doesn't simply means that users can change the code. But, they can also use the code, modify, and redistribute without fear about patents, if they wish.

> The manufacturers of routers, cars, and even Apple care deeply about their patents.

So why do you think Apple chose Apache license for their new swift language? Apache license explicitly gives patent protection to its users.

A language is pure-software. The language isn't entangled in some proprietary hardware features. The language isn't their kernel drivers.

Why would Apple care what you do with their language? You can't bring any harm to their business with it.

> Why would Apple care what you do with their language? You can't bring any harm to their business with it.

Why do you think Microsoft is giving patent promises for C#, .Net and others[0] (But not licensing their software to Apache/GPL)? Yes. Because they can bring harm to their business.

Why Do you think Apple ditched Objective C? For some reason they had to license it under GPL v2. But, as GNU re-licensed everything to GPLv3, they will have to stick with old versions of GCC, binutils, etc. So, they had legal reasons too for yet another language.

Hm... Wait. We shall see the struggle of apple someday, because they can't sue Samsung again, just because they are using patents of Apple which are derived from swift.

And last, why do you think language is not patented? Even some one-liners are patented in the software world![1]

[0] https://msdn.microsoft.com/en-us/openspecifications/dn750984 [1] https://graphics.stanford.edu/~seander/bithacks.html#Integer...

> Why do you think Microsoft is giving patent promises for C#, .Net and others[0] (But not licensing their software to Apache/GPL)? Yes. Because they can bring harm to their business.

I think you continue to over simplify. This actually looks to me like Microsoft is doing their due-diligence in ensuring that the effects of their licensing are well-bounded with respect to patents. GPLv3 et al tend to hand-wave the actual patents covered, and leave it up to someone else to decide which patents actually apply, and how.

Also, it does appear that Microsoft is using the MIT, BSD and Apache licenses[0]

> Why Do you think Apple ditched Objective C?

They didn't. The way I see it is that Swift is to Objective C as C#/.Net is to COM -- which is to say the underlying tech isn't going away anytime soon. They've just made a nice, shiny high-level abstraction. Unless there is some announcement I've missed where Apple said they are throwing away Obj-C and Obj-C tooling and rewriting everything in Swift.

> So, they had legal reasons too for yet another language.

This is a stretch. There was and is nothing preventing Apple from continuing to develop and use and sell product made with Objective C. They don't even care about GCC -- they have Clang.

Also, there are plenty of suitable alternatives to GNU Coreutils, so please don't think that this means anything to Apple. The GPLv2 versions work well for what Apple needs, so they continue to use them. It is convenient for Apple. They could stop using GNU software entirely if they wanted and nothing would change.

> We shall see the struggle of apple someday, because they can't sue Samsung again, just because they are using patents of Apple which are derived from swift.

I have no idea what you mean by this. Companies sue other companies that infringe on their patents because NOT doing so is a tacit license. Why even file a patent then?

To be fair, I think Apple first sued Samsung because their phones looked like iPhones (or so Apple claimed) and were concerned about how that would impact public perception. I don't think has anything to do with software, which is the topic at hand.

> And last, why do you think language is not patented?

Because the language itself, at its core, is agnostic of anything patent-worthy. How the compiler works? Platform support? Potentially patentable. A programming language allows a user to textually express what they want a generic computer to do, and at it's core is not patentable (as far as I understand the US patent system). It gets fuzzy around the edges, but you can't patent a language. It is an abstract idea.

In any case, I get the impression you think these companies are evil. They're not. They're businesses looking out for the interests of their shareholders and their customers. There is no dark agenda against free software. It is just unfortunately complicated for big businesses.

[0] https://en.wikipedia.org/wiki/.NET_Framework#Licensing

I have heard this theory before but the one fact that speaks against it is the Apache license. GPLv3 did not not invents its own patent clause, but rather copied significant parts of apache as a base (stand on the shoulders of giants, avoid NIH, and so on...).

"Each contributor grants you a non-exclusive, worldwide, royalty-free patent license under the contributor's essential patent claims, to make, use, sell, offer for sale, import and otherwise run, modify and propagate the contents of its contributor version."

"each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work"

They did add one major change (beside rewording and reordering), and that was to address the Microsoft-Novell patent agreement. A distributor can not chose to exclusively grant the patent rights to just a selected group, but must do so on a all-or-nothing deal. Once you provide a patent grant and complying with the license, the patent grant is given to everyone who might later receive a copy.

So for all those companies that are happy to distribute apache licensed software but not gplv3 software, and is objecting on the subject of patent clause, one must ask why they have a problem that the patent grant is extended to everyone.

Well, the Apache license is different from GPL in that you are not required to distribute any source, and your "derivative works" do not fall under the license. I can freely use Apache licensed software and jumble in all my patents and even statically link it all together there is no impact to my patents whatsoever.

The point you make covers contributors, which is great! It means if I contribute to an open-source project that uses the Apache license, there are no catches, not even if I contributed something I or my company has patented. So you, as an end user, or consumer of this software, are safe w.r.t. patents. Hurray!

(Again, IANAL!)

> TL;DR: Companies don't hate "giving users more freedom"

Software patents are an example of threatening user freedom, since users can be sued for using software that has patented "ideas" in it.

> I've never met an IP lawyer working for a company with many (hundreds to thousands) of patents allow use of the GPLv3, out of fear that it could undermine their ability to enforce patent rights defensively.

The GPLv3 uses an almost-exact copy of the patent clause in the Apache 2 license (which is used by companies). The only difference is that it requires that the patent rights be transferred in a GPL-like way.

> Second, companies generally don't make it easy for users to run custom software on their products for a few reasons. You generally put software on products one of two ways: physically, or over-the-air (wifi/ethernet/some other way). With both methods, "signed" payloads are usually used for one of two reasons: to make sure it is error free.

All that is necessary is to provide some advanced option to add your own certificate. That's literally it. Once you have the source, you can figure out how to actually push the bloody thing (it'd be nice if a company provided whatever script they use, but they're probably not required to do it). This isn't a very complicated procedure, UEFI did it and that standard is basically owned by Microsoft.

> All that is necessary is to provide some advanced option to add your own certificate. That's literally it. Once you have the source, you can figure out how to actually push the bloody thing (it'd be nice if a company provided whatever script they use, but they're probably not required to do it). This isn't a very complicated procedure

Dude. I wish.

I have seen things you wouldn't believe. Rube-Goldberg publishing mechanisms that couldn't be provided even if you tried. Not to mention getting QA resources to test it, someone to document it for the public, whatever engineering resources are necessary to allow it to be modified (what if it is in ROM?). You're talking millions of dollars of employee time, easy. And we were supposed to have shipped last month.

I want to live in this world of yours too, but it is just not possible today.

Your reasoning doesn't make much sense to me.

Companies are temporary entities, even though they don't like to think of themselves as such. Companies get bought or go bankrupt.

So when I buy a device which only loads signed code, there is no way to know who is going to be able to sign code for my device in the future. I'm also out of luck if I ever want to run my own or someone else's code on my device.

The attack surface is completely dependent on the actual code being signed, so the signature doesn't provide any security benefit to me. And in case there were 3rd party code which is more secure than the vendor code I cannot run it.

From the perspective of the company, the signature provides vendor lock-in and planned obsolescence in return for a relatively small effort of maintaining code signing infrastructure. So there's only an advantage but no disadvantage. The only possible disadvantage is that I am less likely to buy the product, but regular consumers won't know the difference so the company can ignore me.

Omitting hardware components which would help with repair efforts or debugging problems is just as unfriendly. But I understand there can be a huge cost benefits during mass production.

I get where you are coming from, and I'd even say we're on the same page. I love open hardware. I love being able to modify my devices even if I never need to. It brings me comfort. I wish everything was designed like a Chromebook, designed to be hacked on. I applaud those efforts, and vote with my wallet.

Most businesses just can't spend time thinking about this kind of problem. Some have tried, but it appeals to such a niche that it is hardly worth it. When you're a business focused on making money, you don't think about what happens when you're gone. You don't care. I wish that vendor lock-in and planned obsolescence were the reasons to explain this behaviour. At least then it makes sense in an obvious way, if it at least a little scummy. But it just isn't that simple, unfortunately.

One of these things is not like the other… https://github.com/edent/BMW-OpenSource/blob/master/FOSS_S1/...

Probably a file automatically generated when it was transferred to a Windows computer .

Or when somebody used a windows computer to burn the DVD.

Why do they have cups? Is there a 'print from car' button? https://github.com/edent/BMW-OpenSource/tree/master/FOSS_S1/...

They could be providing lots of extra unrelated source code packages to the guy, perhaps just to be thorough and to avoid missing anything, perhaps to just fill the DVD (don't let those ones and zeroes go to waste!), or perhaps to mess with people :) (e.g. throw in a SNES emulator source code to make hackers spend days searching fruitlessly trying to figure out how to make the BMW interface start playing Mario)

You can use LPR to spool audio files to a "printer" that queues those files to be played over speakers. There was a project called gutenbach to do this with CUPS, but last I heard the maintainer went off to grad school. Maybe they are doing something similar?

From what I can see and guess, they seem to be using one of Freescale's reference implementations...probably for the i.mx6, but don't hold me to it. It's got a lot of packages in there that aren't relevant. It's also interesting that they've also included all the source for an sh4-based microcontroller that's somewhere in the chain. Car systems are complicated these days.

Hypothetically, the car might be able to print its own systems report during manufacture. This might not be an entirely far-fetched theory given that a car contains numerous independent computers networked together and not all of them have direct access to a display.

Another possibility is that a "printing" metaphor is being used to communicate certain things between the various car computers. For example, if there's an engine fault, the engine's computer might "print" the fault report to the center console computer. On a modern BMW, the centre console computer shows a log of faults as well as a full service history and upcoming servicing requirements.

Just wonder is anyone tried to get (L)GPL sources from Tesla?

Yes. I asked 2.5 years ago, no reply.

It's worth trying again.

Probably time to get Software Freedom Conservancy involved:

https://sfconservancy.org/copyleft-compliance/

Off-topic: The title and several post refer to BMW as a plural: "BMW are complying" and "Do BMW have any obligation...?"

I know BMW stands for Bavarian Motorworks, a plural, but so does the US, and it is a singular entity today.

Are the people using BMW plural non-American? I've never heard that here in Texas.

It's British English. I see this usage all the time on BBC News. Drives me batty.

They (BMW) are a group of people. They (BMW) are complying.

That's the way I've had it explained to me.

How is that an appropriate explanation, when you--presumably--wouldn't say "The group are complying"?

You're overthinking it. If a group of people are complying, you say "they are complying". Your example is not a valid parallel.

Corporations are viewed as collective nouns to be used with plural verbs, where as "group" is a collective noun that is treated as singular. I can't think of a context in which I'd use a plural verb with it, but I can think of dozens of such nouns that I would. You can say "The group is complying. They have an obligation." without it sounding awkward, however.

Something about formal, notional and situational agreement[0].

The "they" explanation just helped bridge the gap in my mind.

[0] https://en.wikipedia.org/wiki/Comparison_of_American_and_Bri...

I think you would say "the group are complying" when you want to specify that the group as individuals are complying (or when, like me, you don't grammar too well).

Both are used in British English for companies, though the plural form is more common. It (to some extent) depends on which aspect of the company you are emphasising (though usage is not always consistent in that regard).

Consider "TeamA is a football club" and "TeamA are beating TeamB". In the first example, TeamA is considered a singular entity, and you aren't really concerned with its makeup (though "TeamA are a football club" would also be correct). In the second, TeamA is a group descriptor as it is a group of players that are winning the match, not the single legal/business entity.

AFAIK, the plural usage for business names is the most common usage in British English, though it also varies between British dialects (it always surprises me how much dialects vary in English - some areas of England still use an informal form of "you" occasionally, for example)

Singular is typically used when talking about an entity or brand, where as a plural form is taken when talking about the company as a group of people, or when anthropomorphized.

"BMW is a fantastic brand" "BMW are facing tough financial pressure"

There are some interesting things in there. tcpdump? Locally patched one at that? I wonder how is it used... maybe it's just used for debugging, but given that it's part of the deployed packages it's still interesting.

edit: it looks like it was added specifically for IEEE 802.15.4 debugging

As someone who has enforced the GPL for a few decades, I have to note the GPL compliance process isn't done here yet. Someone actually has to verify that the "scripts used to control compilation and installation of the executable"(s) actually work. Is anyone working on that?

Interesting that they use SuperH CPUs. There is an in-progress Debian SH4 port. Debian on your car!

https://wiki.debian.org/SH4

The Linux on Dreamcast effort made a ton of progress running on SH4. I haven't touched it in years, but I remember it being pretty mature, and that was quite a few years ago.

I guess this means that BMWs are basically just a Dreamcast with wheels?

Most of these packages aren't modified at all? Wouldn't it be just enough to provide the Links?

I think GPLv3 lets you just provide links to upstream mirrors if it's unmodified, but GPLv2 doesn't have such a provision.

What about their in-house software that links against this software? Or is it all LGPL?

How would inhouse software affect GPL compliance?

They are possibly distributing a derivative work without releasing the source code, if it GPL licensed.

The string 'open source' appears three times in the article, the word 'free' doesn't appear (outside of the file listing, in the context of things like FreeScale, etc).

The string 'open source' does not appear at all on either:

  http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html

 or

  http://www.gnu.org/licenses/gpl-3.0.en.html

Relevant as we're specifically referring here to the GNU Public Licence.

Reply on news.ycombinator.com