This sounded awesome right up to the point that they said that this was a hotly pursued space due to advertising potential to a captive audience. If I am in my own car and my music is interrupted with an ad every time I drive by a McDonalds - I would find that extremely annoying.
On the other hand, if you could lease a car at a subsidized price in exchange for ads, that might be an attractive offer to some.
Once you got past all the requirements these 'ads' would have to adhear to, to not be distracting or dangerous, it becomes a pretty limp form of advertising.
The reason people own nice dash-systems, and iPods is so they dont have to listen to ads. There is absolutely no way anyone would buy a car that forces ads on them unless it was HEAVILY subsidized.
This is beyond retarded, and if advertising really is their motivation, this will fail hard.
Why isnt having a cool fancy dashboard without ads enough? Doesn't that do enough to make the car desirable, and competitive?
It ought to be flatly illegal to visually advertise through an in-car app. An ad is designed to engage attention; visually engaging a driver is the last thing we want on the road. It's beyond stupid.
YOU ARE PASSING A GAS STATION. PLEASE STOP AND BUY IT.
YOU ARE PASSING A SANDWICH SHOP. PLEASE SWERVE LEFT AND BUY SANDWICH.
This is actually already the case in a few European countries I am aware of. Not all streets, but next to the highways there can't be any visible billboards.
A chocolate company in Cleveland ran a promotion where the company would pay you $150 per month for three years if you bought a specially wrapped and painted Volkswagon Beetle with their colors and logos plastered on it.
In Switzerland, most car shops offer a deal that when you leave a big sticker with the garage's name and slogan and perhaps a marketing claim on your newly bought car, you get some reduction on the maintenance work each year.
Trivia fact: you can get a ticket in the UK for driving an obviously commercial vehicle through a Royal Park. A few years back my wife got a ticket in Holyrood Park in Edinburgh for driving along a road that cuts through the edge of the park in a car that had the logo of the company she worked for at the time.
The NY Times added the part about the captive audience and advertising potential.
Ford's developer page and its press release concern themselves with apps of the type they already bundle with Sync (i.e., ad-free). Indeed, Ford's developer page warns that content which distracts the driver (including but not limited to visual distractions) will not be accepted into the Sync app store.
My new BMW has a Yelp app, which might be the kind of thing they're talking about. I'm pretty sure your car isn't going to advertise to you without you asking for it; that sounds like a regulation nightmare.
Since we are on the topic: I wish Tesla would finally live up to their obligations and release the GPLed parts of their product (that includes, at a minimum, the Linux kernel with all modifications).
Are we sure they aren't complying with the GPL? After all, it only requires distribution of source to those who receive the compiled code. Which is to say, unless you have a Tesla in your garage, you have no claim to the source.
As far as I know, it's always been that if you distribute something with GPL code, you must make the source available to anyone that requests it. Not only to your customers. One can change though, for the costs of making it available.
The thing you mentioned is applied to licensing. A person is only under obligations by the license if he/she distributes anything that uses GPL code. If people only run a piece of GPLed software, or if they make changes only for personal use, they're not under GPL license obligations.
> if you distribute something with GPL code, you must make the source available to anyone that requests it
That's only true if you're operating under section 3(b) of the GPLv2: explicitly offering source via mail order. If you offer GPLv2 source via mail order, you have to honor mail order requests from anyone. However, you aren't required to offer the source via mail order at all, as per section 3.
In the GPLv3, the analogous section, 6(b), is actually further constrained: if you explicitly offer GPLv3 source via mail order, you're only obliged to honor requests from people that have the object code in their possession.
I've replied with my understanding of it in more details to your other comment at http://news.ycombinator.com/item?id=5030865 (in case other people want to follow the conversation).
GPL compliance (sigh) and a new SDK for a vehicle aren't really the same topic. They just happen to have cars in common. If I left a comment about the camshaft on my Jeep, that wouldn't be on topic, even though it's about cars.
That aside, what do you hope to gain from their GPL compliance? Pop open the GPL compliance kit from, say, a Netgear router and you get a kernel, a few drivers, and the toolchain used to build it. And BusyBox. How useful will the drivers for things in a Tesla be to you? Do you own a Tesla, or is it just curiosity?
If it's curiosity, well, I wish we weren't enforcing that with the GPL.
> If it's curiosity, well, I wish we weren't enforcing that with the GPL.
It's simple, either you comply with the GPL or you don't distribute GPL-based code. As an author of GPL licensed software, I think it's pretty damned arrogant for someone like you to imply curiosity isn't a good enough reason to get back modifications in accordance with the chosen license. Who are you to judge? And anyway, what reason could possibly be more worthy than curiosity?
It's the authors' choice, not the peanut gallery's; and if they hadn't intended for all distributed modifications to be made available under the GPL, they would have chosen BSD or another license instead. And if you don't like that, too bad.
Because "for curiosity" isn't a term stated in any GPL license. You can be offended as much as you want for them not releasing it but unless you own a Tesla they don't have to share their modifications with you. If you are unhappy with that, I suggest sharing your work under a different license.
I'm perfectly fine with that, but you seem confused about the argument here. GPL code distributors don't have the right to say curiosity, or any other reason, is invalid cause to enforce the GPL.
And while I do not have standing to request GPL licensed code from Tesla, they have a legal obligation to either distribute that code directly, or a provide a transferable offer to distribute that code, to their customers. Code properly distributed as such inevitably would make it back out into the wider open source community; this is the design of the GPL. If Tesla currently does not meet this obligation under the GPL, that is a problem.
Yes, they are legally obligated to share their modifications with their customers. No arguments here.
> Code properly distributed as such inevitably would make it back out into the wider open source community; this is the design of the GPL
The design of the GPL is to protect the users rights to use, access and modify the software in perpetuity. There is no provision in the license that modifiers have to share modified works with the author specifically - they just have to make it accessible to the people they are distributing it to.
Being the author of a GPL work and wanting access to those changes because you are merely curious or want those changes to be merged into the original work, the unfortunate reality is that the GPL will do squat for you in that regard.
I think Niten's point is that some Tesla customer would request the GPL code and decide to make an open distribution of it, as would be their right (but not their obligation). It seems overwhelmingly likely to happen.
> Yes, they are legally obligated to share their modifications with their customers. No arguments here.
Nope, if you distribute something with GPL code, you must make the source available to anyone that requests it. Not only to your customers. And you can't put any kind of filter on reasons for the request.
One can only charge a "reasonable" amount for the work of making it available (CD, hosting, etc).
The only corner case I see is if they claim that they are selling a device (like the whole car) as a single package and there is only a single package of code along with it.
> if you distribute something with GPL code, you must make the source available to anyone that requests it. Not only to your customers. And you can't put any kind of filter on reasons for the request.
That's patently false for both the GPLv2 and GPLv3. For v2, see section 3. Only one of the three compliance options requires universal fulfillment of requests for source.
GPLv3 has no similar requirement. The closest analogue to v2's section 3(b) has its scope explicitly limited to "anyone who possesses the object code."
GPLv2 makes no such distinction or limitation in section 3.
I states that distribution of binaries must include either: a) Complete corresponding machine-readable source code; or b) Written offer to give any third party a complete machine-readable copy of the corresponding source code;
Item c) applies only to non-commercial cases, which is not the case here.
So if they are not doing a), they need to do b). And written does not imply regular mail (which you mentioned in your other reply), it can be anything on their web page or an e-mail.
If every distributed copy includes full source, then that's covered. Otherwise any request must be fulfilled, as there should be a written notice offering it somewhere. There is no limitation to who can request it.
GPLv3 on the other hand is more "legalese" and harder to read. Section 6 mentions possession of object code only for item b), which is the case for "written notice". So it will only apply if there is such written notice upon distribution.
Item c) is only for non-commercial cases. Items d) and e) require making source electronically available. Item a) says that if it is a physical product it needs to include full sources in some media.
If the distributor doesn't do d) or e), they need to do a) or b).
So, nowhere it is "patently false". Only if using GPLv3, and the binaries being provided along with a physical product, then there is no obligation to provide the code to any request.
The "corner case" I mentioned in my comment is related to item a). The limitation on item b) is actually something I had never noticed before.
But I have no idea which license version Tesla uses, so I don't know if this applies.
PS: Just to clarify one thing: trying to download a file from a URL or via P2P also constitutes a request. It's just on another media.
I apologize for my tone, and I think we're in agreement. "Patently false" is a bit extreme, but we seem to agree that it's possible to comply with the GPLv2 without being required to distribute source to anyone that asks. That's section 3(a): include source alongside the object code. If the Tesla cars come with a CD-ROM or a USB stick containing the source, then they're in compliance.
I mention mail order because, oddly, the GPLv2 actually requires that you provide source via postal mail to people if you're opting to comply under 3(b). That subsection states that in response to a written offer, you must provide source "on a medium customarily used for software interchange." That's interpreted by the FSF's GPL FAQ as "if any [third party] would rather get the source on physical media by mail, you are required to provide that" [0].
There's an additional entry in the FAQ [1] specifically covering the definition of third parties for GPLv2: "If you choose to provide source through a written offer, then anybody who requests the source from you is entitled to receive it."
So written-offer-for-source appears to be the exceptional case for GPLv2: you have to provide it on physical media, and to anyone that asks. But if you choose to distribute source alongside the binaries, per section 3(a), then you're free from that obligation.
Given that GPLv3's section 6(b) intentionally constrained this to only people who possess the object code, it feels like the universality of v2's section 3(b) is a bit of a fluke, and not representative of the goals of the GPL. Thus, in responding to your claim that "you must make the source available to anyone that requests it. Not only to your customers." I'd argue that the GPLv2 clearly and explicitly allows you to only make source available to your customers, if you comply with 3(a).
I don't own a Tesla, so I don't have legal standing. But I care about the company, I want it to succeed.
Heres the problem: they employ a dozen of people that know very well of the obligations under the GPL. They use GPLed software in core parts of their products. There are possibly thousands of copyright holders for the used GPL software. Taken together, thats a highly combustible mix.
Why do you care? The GPL doesn't alleviate the obligations of its users based on what jspthrowaway2 finds to be a valuable pursuit. (Presuming the GP is a customer eligible to receive the modifications under the GPL terms)
I was notified today that GM also came out with there API today. Seems a bit odd that they would both release the exact same feature on the same day. I wonder how similar their SDK's will be. http://media.gm.com/media/us/en/gm/news.detail.html/content/...
GM's is cool too because they have an API that allows you to remotely get vehicle data through Onstar. This allows approved apps to get data like fuel level, vehicle alarm alerts, oil life, fuel economy, remote start/stop, location, speed and direction etc. Not sure Ford has anything like that..
Ford's AppLink-enabled apps run on your iOS/Android phone and the vehicle's voice control and buttons are additional interfaces to control the app that's running on your phone. So regular Pandora from Google Play or the App Store has the code to integrate with AppLink vehicles in it already.
This is different from GM's approach, where the apps are built to run on the vehicle's own hardware.
We just entered a GM Connected Car app in the ATT Hackathon in Las Vegas this past weekend. GM provides an Eclipse plugin that has the SDK and emulator. GM's API is Javascript-based and your app is HTML5/CSS and JS code.
The Nissan Pathfinder for example has a pin on the ECM that when grounded loads the engine profile from the upper 256K of RAM vs the normal lower 256K of RAM. If you modify an engine profile to set limits of 5 MPH and 1000 RPM and load it into the upper 256K and wire that pin to the dome light switch, you have an amazing anti-theft system.
I'd label it more as "heterogenous security." If everyone modded their own car, a thief is forced to develop novel attacks for each car.
Immobilisers have two major issues. The first is code weakness. Many of the early ones used static keys. In '98 when Germany mandated them for new cars, BMW and others switched to using the odometer reading as a shared secret. Newer ones often use weak 40-bit keys. The second issue is that most immobilizers simply cut the ignition circuit and the fuel pump circuit. If you know where the relays are on a model of car you can short circuit them.
Immobilisers have dramatically reduced rates of drive-away car theft in Australia where they became mandatory a while ago. They might not be completely foolproof, but they certainly do stop the vast, vast majority of criminals.
I can't imagine the amount of penetration testing they'd need to do before opening up core components of a car. I would not want to be in charge of that project.
Ford has offered this type of functionality (read-only, of course) for the last 15 years at least.
They had at that time a parallel cable (remember those printers) interface to their engine that would let you get all kinds of information. I coded to it - it was quite fun.
This doesn't seem like the sort of thing you'd want to expose to the general public. With computers, you are generally pretty safe from breaking anything permanently. Engines, on the other hand, are not only subject to a host of regulations but also very easy to destroy with a few errors.
Serious hackers would of course be very interested, but allowing the general public to cause thousands of dollars in damage to their engine with a few keystrokes seems like a setup for a PR nightmare. Also, I mentioned the regulations- I doubt the EPA and CARB would be happy.
I don't like this reasoning. We already give people physical access to their cars' engines. They can do as much damage just as easily, but they don't because they'd rather have a functional car.
Open up access to the computer and it would be the same thing. Most people would leave it alone and those who didn't would know ahead of time what they're getting into.
"Certain kinds of apps will be barred, like games, elaborate video and anything that would require extensive reading."
..
"Ford also announced nine new apps that would be part of the Sync system, including The Wall Street Journal, USA Today..."
Which means that briefly we'll live in a time where a stack overflow vulnerability will cause your car to break or accelerate at very inappropriate times.
Just google for "researchers car software vulnerability" (without quotes) to see what I'm talking about.
It seems like you know that hackable cars are already the norm. Hopefully, with a focus on security and open software development, cars will become more secure.
When I bought my 2009 Ford Fusion it was marketed as having "Microsoft Sync", the Sync name has stuck around but I haven't seen any mention of Sync being or derived from Microsoft technology in Ford's marketing in the last couple year (nor in the article). I wonder if that is still the back end of it or if Ford rebuilt Sync from the ground up?
It is going to make a huge difference whether dealerships work to set up accounts for customers. If ford apps try to survive on ad support it is going to turn into a pile of garbage apps and irritating ads.
Perhaps the article mentioned advertising as an example of a source of apps; perhaps non-advertiser-funded apps are just what the SDK lets anyone build.
On the other hand, if you could lease a car at a subsidized price in exchange for ads, that might be an attractive offer to some.