Tesla maakt deel broncode onder GPL-licentie openbaar

Tesla heeft een deel van de broncode van zijn software voor auto's online gezet. Daarmee heeft het een eerste stap gezet om te voldoen aan de GPL-licentie voor het gebruik van delen van Linux. Tesla voldoet niet helemaal aan de voorwaarden van de licentie.

De Software Freedom Conservancy zegt al vijf jaar met Tesla te werken aan het openbaar maken van de code, een proces dat langzaam verloopt door de betrokkenheid van meerdere bedrijven. Tesla moet een deel van de code openbaren, omdat zijn auto's code gebruiken van de Linux-kernel en van Busybox. Onder de voorwaarden van het gebruik van die software moeten fabrikanten eigen aanpassingen daaraan beschikbaar stellen.

De code staat nu op de GitHub-pagina van Tesla. Het gaat daarbij om Linux en BuildRoot. Tesla maakt andere delen van de code, met daarin onder meer eigen applicaties, niet openbaar. Dat is ook niet nodig volgens de GNU GPL-licentie.

Tesla heeft mensen die in het verleden interesse hebben geuit in het bekijken van de code, een mail gestuurd, meldt Elektrek. Het openbaren van de broncode kan beveiligingsonderzoekers helpen kwetsbaarheden te vinden in de software van Tesla, die na een patch vervolgens de software veiliger maken.

Reacties (74)

[84hannes]

Tesla moet een deel van de code openbaren, omdat zijn auto's code gebruiken van de Linux-kernel en van Busybox.

Ik denk echt dat dit te kort door de bocht is. Code vrijgeven hoeft alleen als je deze wijzigt of mee compileert met je eigen code. Blijkbaar doet Tesla dat.

Het openbaren van de broncode kan beveiligingsonderzoekers helpen kwetsbaarheden te vinden in de software van Tesla, die na een patch vervolgens de software veiliger maken.

Het zou interessant zijn als iemand de bron van dit nieuwsbericht induikt om samen te vatten wat die wijzigingen in de Linux Kernel nu zijn, of ze bruikbaar zijn voor anderen en of ze significant zijn. Als Tesla er alleen wat zaken uit gegooid heeft die ze niet nodig hebben, dan is het weinig boeiend voor derden.

[Arnoud Engelfriet]

Tesla moet in ieder geval de oorspronkelijk GPL delen vrijgeven, dus de broncode van Linux zelf en van Busybox meeleveren met hun product. Dat is gewoon een eis van de GPL, en staat los van de eis dat je soms eigen code ook moet vrijgeven. Het maakt niet uit of die broncodes zijn aangepast of uitgebreid of dat ze slechts een mere aggregation zijn met je eigen software. Je geeft iemand Linux, dan geef je de broncode erbij, punt.

[84hannes]

Tesla moet in ieder geval de oorspronkelijk GPL delen vrijgeven (...) Het maakt niet uit of die broncodes zijn aangepast

Als de broncode van de Linux-kernel die ze gebruiken precies hetzelfde is als de code op kernel.org, dan denk ik niet dat ze een github account hoeven aan te maken. Verwijzen naar kernel.org (waarschrijnlijk met commit hash etc.) lijkt me dan voldoende. Ik durf er dan ook vanuit te gaan dat Tesla wijzigingen heeft gemaakt.

[Arnoud Engelfriet]

Juridisch gezien moeten ze echt een zipfile meeleveren met de broncodes. Praktisch gezien zegt iedereen inderdaad "zie kernel.org" maar naar de letter klopt het niet. En als de FSF zich ermee gaat bemoeien, is die letter héél belangrijk.

[deadinspace]

Juridisch gezien moeten ze echt een zipfile meeleveren met de broncodes.

Of een aanbod om de broncode op verzoek te verschaffen (sectie 3b van GPLv2):

b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code ...

Doet verder weinig af aan je originele punt overigens, maar dit maakt het wel makkelijker voor Tesla om aan de GPL te voldoen. Een pagina in de owners' manual oid zou al volstaan denk ik, ipv een USB stick meeleveren.

[Reactie gewijzigd door deadinspace op 22 juli 2024 19:38]

[mashell]

En moet die zipfile in de auto aanwezig zijn? Of mag die op de website staan? Want het is toch niet helemaal logisch dat een auto verplicht met een USB stick met de source code moet worden uitgeleverd. Die GNU licentie schiet hier wel een beetje z'n doel voorbij.

[Anoniem: 85014]

En waarom niet? Dat ze inderdaad en effectief dat op een USB stick zetten en meegeven bij de auto.

Wat juist is daar mis mee? Waarom is dat onlogisch?

Wees er ook maar zeker van dat veel techneuten, zoals ikzelf, die code zouden bestuderen, gebruiken en verbeteren. Wat precies en exact de bedoeling is van de gpl.

[mashell]

Omdat verreweg de meeste klanten van de auto niet weten wat ze er mee aan moeten. De verwart dat alleen maar. Bang zijn om de USB stick voor iets anders te gebruiken. Overschat ook het bestuderen van open source code niet. Bijna niemand doet dat, het is voor de meeste mensen gewoon niet leuk, je bent dan immers niet creatief bezig.

[Anoniem: 85014]

Tja. Dat is toch wat de GPL licentie zegt. Als zelf copyright eigenaar van een stuk GPL software die op de Tesla draait moet, van mij, Tesla mijn copyright eerbiedigen.

Ik eis inderdaad dat voor die code, die van mij is, want ik heb er copyright op, dat Tesla daarover mijn copyright eerbiedigt. En dat wil dus zeggen dat bij herdistributie de (rechten van de) GPL licentie en de code aan de ontvanger moeten gegeven worden.

Dat is een eis. Dat is niet iets dat ik (lief) vraag (met mijn mooie blauwe ogen). Ik eis dat. Juridisch.

Als Tesla dat niet wil. Dan moet het oprotten en mijn code niet gebruiken.

ps. Kijk in de AUTHORS file en daar zie je mijn naam staan op lijn drie. Ik meen dit. Jazeker. Ik ben copyright owner van een deel van code die op Tesla auto's draait (Pelagicore is software leverancier voor oa. Tesla). Akkoord dat voor tracker-ivi de code dus gepubliceerd is. Zo hoort het ook. Het hoort ook zo voor alle GPL en LGPL software.

[kikker81]

Ik zou het prima vinden als ik een auto zou kopen en alle blauwdrukken, 3dmodellen en tekeningen die gebruikt zijn voor het ontwerpen en assembleren zouden op een usb stick worden mee geleverd.
Als ik het zelf nooit gebruik, dan de garage wel. Zo is het ook met de software. Het is handig als je het nodig hebt, en het zit niet in de weg als je het niet gebruikt.

[Anoniem: 85014]

Precies. Maar onder het mom van dat jij en je garagist niet blijken te bestaan weten quote verreweg de meeste klanten van de auto unquote niet wat ze er mee aan moeten.

Dus moeten copyright plichten volgens sommigen maar niet uitgevoerd worden.

NEEN dus. Die moeten WEL uitgevoerd worden. Juridisch wel. Dit gaat niet over 'hoe het aanvoelt voor de meeste mensen'. Dit gaat over juridisch geldende copyrights die een juridisch contract worden van zodra je de software op dusdanige manier, als Tesla doet, in gebruikt neemt.

Er is niets optioneel aan. Telsa moet dit doen. Het gaat niet over wat verreweg de meeste klanten van de auto goed of slecht vinden. Het gaat er over dat Telsa géén toestemming heeft de software te gebruiken tenzij ze dat doen volgens de overeenkomsten in het copyright. Die is veel gevallen de GPL en/of LGPL. Dus niet volgens een door hunzelf verzonnen copyright. Maar enkel en alleen de copyright die vastgelegd is door de auteurs van de software. Die auteurs zijn in hoofdzaak niet de mensen van Telsa btw.

[LinuxMan]

Juridisch gezien moeten ze echt een zipfile meeleveren met de broncodes. Praktisch gezien zegt iedereen inderdaad "zie kernel.org" maar naar de letter klopt het niet. En als de FSF zich ermee gaat bemoeien, is die letter héél belangrijk.

juridisch gezien hoeven ze het deel van de code dat onder de GPL valt + build scripts + wijzigingen op die specifieke code toch alleen beschikbaar te stellen aan alle potentiële afnemers/klanten? Het is toch niet specifiek in de GPL beschreven hoe je dat moet ontsluiten?

Zou een usb aansluiting in elke Tesla niet al voldoende zijn?

En stel dat jij een (al dan niet betaalde) overeenkomst met kernel.org sluit, of een mirror draait, mag je dan nog steeds niet verwijzen naar kernel.org?

[MSalters]

Klopt helemaal..

GPL is inderdaad alleen relevant voor de ontvangers van de binaire code (dus Tesla-eigenaren); alleen die hebben een recht op de bijbehorende source code.

Zipfile in de auto en een USB aansluiting of WiFi is inderdaad voldoende; dat zijn allebei gangbare methoden. Uiteraard mag je ook naar een website verwijzen, en dat kan ook met kernel.org zijn, zolang je als Tesla zijnde maar kunt garanderen dat die site beschikbaar is. Maar ook CloudFlare en AWS zijn geen ongebruikelijke hosting partners.

[84hannes]

Is een github-fork beter?

[latka]

Je mag de distributie verplichting niet doorschuiven.

[Scarp]

GPL gaat over distributie. Als jij in je product GPL code gebruikt dan zal je de broncode van jou product beschikbaar moeten stellen voor anderen als die erom vragen. Jij mag ook iemand er niet van weerhouden om zelf weer van die code een product te maken en onder GPL verder te distribueren. Als jij gewoon een applicatie (bv een word processor) maakt die onder Linux draait dan hoeft dit niet natuurlijk.

Linux drivers moet je bv wel onder GPL laten vallen want die voegen iets toe aan Linux.

Tesla kan ook gewoon nee zeggen en het op een rechtszaak aan laten komen. Daar zijn er vrij weinig van geweest dus is lastig.

[The Zep Man]

GPL gaat over distributie. Als jij in je product GPL code gebruikt dan zal je de broncode van jou product beschikbaar moeten stellen voor anderen als die erom vragen.

Onwaar. Uit de GPL:

mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.

Alleen distributie met GPL software is dus niet voldoende om iets te verplichten om GPL te zijn.

Zie ook deze analyse van de GPL.

The "viral" clause of the GPL speaks of works "derived from" the Program. This is our main source of confusion in understanding the GPL.

Let's have a look at a few specific cases:

1. A modified version of the original program.
2. Code that calls the original program via fork and exec.
3. Code that is linked with the original program (read: library).

Reading the license text, the first case is clearly a work "derived from" the original program. The second clearly is not.

De derde is een discussiepunt (lees het vooral verder, erg interessant), maar het is zeker dat code die GPL code uitvoert geen afgeleid werk is, en daarom niet onder de GPL valt. Het is dus niet zo dat distributie en uitvoering van code met verschillende soorten licenties altijd in conflict is.

Linux drivers moet je bv wel onder GPL laten vallen want die voegen iets toe aan Linux.

Ik draai Linux drivers die een andere licentie hebben dan GPL. Belangrijkste woord is 'ik' in die zin. De GPL verplicht de gebruiker niet om enkel GPL software te draaien. Ook is iedereen vrij om Linux (GPL) en de niet-GPL software los te distribueren, mits de licentie van de andere software dat toestaat. Het makkelijkste en meest duurzame is natuurlijk in broncodevorm, maar zie bijvoorbeeld een NVIDIA die een closed-source binary blob driver levert.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 19:38]

[84hannes]

Alleen distributie met GPL software is dus niet voldoende om iets te verplichten om GPL te zijn.

Wellicht ben ik de bron van de verwarring door onzorgvuldige formulering, maar @Scarp heeft het niet over bundelen van binaries, maar over het gebruik van code:

Als jij in je product GPL code gebruikt dan zal je de broncode van jou product beschikbaar moeten stellen

Technisch staat dat ook in dit Tweakers artikel, maar ik denk dat 'het gebruik van code' te vaag omschreven is om er vanuit te gaan dat iedereen het verschil met 'gebruiken van binaries' zal zien. Het is immers populair te zeggen dat computers source code draaien, terwijl ze altijd binaries draaien die eventueel op hun beurt source code interpreteren (denk aan een browser die JavaScript draait).

[SuperDre]

Je hoeft niet de broncode van jouw product beschikbaar te stellen, alleen de gewijzigde code die jij gebruikt hebt (das in iedergeval zoals ik het begreep). Dus gebruik ik de code en wijzig ik er niets aan maar bouw daar bovenop iets, dan hoef ik dat wat ik er bovenop bouw niet te publiceren.

[latka]

Hangt ervan af wat je doet: een functie in de Linux kernel erbij maken dan moet je alles leveren. Een programma maken wat je onder Linux kunt starten: alles mag.

[MSalters]

Je hoeft niet de broncode van jouw product beschikbaar te stellen, alleen de gewijzigde code die jij gebruikt hebt (das in iedergeval zoals ik het begreep)..

Er zijn Open-Source licenties die zo werken, o.a. de MPL, maar de GPL eist dat je alle code openbaar maakt.

[Anoniem: 334725]

Als jij de code aan iemand oplevert dan moet de source code erbij op de delen waar GPL op staat. End of story. Code hoeft niet publiekelijk te zijn maar wel beschikbaar voor je klanten. Deze klanten kunnen deze code wel publiekelijk maken maar dat is een persoonlijke keuze.

[Anoniem: 85014]

Die klanten hebben een onvervreemdbaar recht om die code publiek te maken. M.a.w. jij kan die mensen niet, op geen manier, tegenhouden dat te doen. Dus ook niet door andere contracten met hen te maken (non-disclosure agreements en zo).

Uiteraard zijn er heel wat mensen die van zodra ze een kopie hebben, gebruik zullen maken van dat onvervreemdbaar recht om alles zo breed mogelijk te verspreiden.

[RatedR]

Code vrijgeven hoeft alleen als je deze wijzigt of mee compileert met je eigen code. Blijkbaar doet Tesla dat.

Want wat is het nut van code vrijgeven als je deze niet wijzigt?

[Reactie gewijzigd door RatedR op 22 juli 2024 19:38]

[un1ty]

@RatedR, zoals 84hannes nadrukkelijk citeert, dit is niet zoals het in het bovenstaande artikel vermeld staat. Ik denk dat Tweakers er goed aan doet om op te letten op dit soort 'taal foutjes'.

Zoals in het artikel staat; maak je gebruik van Linux? Code openbaar maken!

Terwijl er bedoelt wordt; wijzig je iets aan de Linux kernel? Dan moeten deze wijzigingen openbaar gemaakt worden! (Tenzij voor privé gebruik natuurlijk).

Edit. Onder 'wijzig je Linux' kan je ook lezen; neem je -delen- van de Linux broncode op in je eigen project.

[Reactie gewijzigd door un1ty op 22 juli 2024 19:38]

[jimshatt]

psst... 'taalfoutjes' schrijf je zonder spatie

[latka]

Als je code van partij X gebruikt en die gaat failliet kun je hier niet naar verwijzen. Dus zelf publiceren is een must.

[MSalters]

Het voorkomt dat je van 10 sites een kernel bij elkaar moet rapen. Juist omdat Linux geforked mag worden kun je dus niet garanderen dat de Tesla build rechtstreeeks van kernel.org geforked is. Als Tesla hun build van distributie A hebben geforked, die het op hun beurt van B hebben geforked, etcetera, en iedereen heeft een paar wijzigingen, dan wordt het een rotklus om de source tree te reconstrueren.

[SSDtje]

"Het zou interessant zijn als iemand de bron van dit nieuwsbericht induikt om samen te vatten wat die wijzigingen in de Linux Kernel nu zijn."

Nu kon ik zo snel de wijzigingen niet vinden, maar wellicht dat ik deze later nog tegen kom, en mocht dat zo zijn, dan wordt i hier later nog toegevoegd.
Maar kon er wel iets over vinden:

BLACK DUCK - MANAGING AND SECURING OPEN SOURCE SOFTWARE IN THE AUTOMOTIVE INDUSTRY = het gehele stuk.

The most common challenges were GPL license violations, with 75 percent of applications containing components under the GPL family of licenses, but only 45 percent of those applications were in compliance with GPL obligations. As auto OEMs work with software providers, a growing set of open source components is making its way into automobile systems. Open source code is being channeled through countless supply chains in almost every part of the automotive ecosystem. To make progress in defending against open source security threats and compliance risks, both auto OEMS and their suppliers must adopt open source management practices that:

FULLY INVENTORY OPEN SOURCE SOFTWARE:
Organizations cannot defend against threats that they do not know exist. A full and accurate inventory (bill of materials) of the open source used in their applications is essential.

MAP OPEN SOURCE TO KNOWN SECURITY VULNERABILITIES:
Public sources, such as the National Vulnerability Database provide information on publicly disclosed vulnerabilities in open source software. Organizations need to reference these sources to identify which of the open source components they use are vulnerable.

IDENTIFY LICENSE AND QUALITY RISKS:
Failure to comply with open source licenses
can put organizations at significant risk of litigation and compromise of IP. Likewise, use of out-of-date or poor quality components degrades the quality of applications that use them. These risks also need to be tracked and managed.

ENFORCE OPEN SOURCE RISK POLICIES:
Many organizations lack even basic documentation and enforcement of open source policies that would help them mitigate risks. Manual policy reviews are a minimum requirement, but as software development becomes more automated so too must management of open source policies.

ALERT ON NEW SECURITY THREATS:
With more than 3,500 new open source vulnerabilities discovered every year, the job of tracking and monitoring vulnerabilities does not end when applications leave development. Organizations need to continuously monitor for new threats as long as their applications remain in service.

En wellicht ook nog interesant om te lezen:
Klik = Fossbytes.com - Tesla Starts Open Sourcing Some Software Code After Facing Criticism

En voor de mensen die nog meer vragen hebben over GPL = General Public License, of GNU = GNU is Not Unix, kunnen hier op zo'n beetje alle vragen die je er over kan/kunt hebben een andwoord vinden:
Frequently Asked Questions about the GNU Licenses (gnu.org)

Edit: Typo

[Reactie gewijzigd door SSDtje op 22 juli 2024 19:38]

[Blokker_1999]

[...]
Code vrijgeven hoeft alleen als je deze wijzigt of mee compileert met je eigen code. Blijkbaar doet Tesla dat.

Als het zo simpel was dan zou het geen jaren duren voordat Tesla de code vrijgeeft. Het is trouwens niet zo dat dit enkel moet als je aanpassingen maakt. De GPL stelt zeer specifiek dat elke gebruiker van de software onder GPL licentie het recht heeft om de code op te vragen bij het bedrijf dat de software heeft uitgegeven. In dit geval mag dus elke Tesla eigenaar alle GPL code opvragen bij Tesla en is Tesla onder de licentievoorwaarden verplicht van hen deze code te geven of aan te geven waar de specifieke code gevonden kan worden.

[stuiterveer]

Op het begin van het artikel staat:

Tesla voldoet niet helemaal aan de voorwaarden van de licentie.

Maar... er wordt op het eind van het artikel gezegd:

Tesla heeft mensen die in het verleden interesse hebben geuit in het bekijken van de code een mail gestuurd, meldt Elektrek.

Dat komt nogal tegenstrijdig over, voldoen ze nu wel of niet aan de licentievoorwaarden?

Vanuit het gelinkte artikel trouwens:

“Conservancy has been engaging with Tesla on its GPL compliance since June 2013, when we advised Tesla that we had received multiple reports of a GPL violation regarding Tesla’s Model S. Customers who purchased Tesla’s Model S received on-board system(s) that contained BusyBox and Linux, but did not receive any source code, nor an offer for the source. In parallel, we also asked other entities to advise Tesla about GPL compliance. We know that Tesla received useful GPL compliance advice from multiple organizations, in addition to us, over these years.”

But this week, Tesla started on the road to compliance by releasing some of its source code on GitHub.

They sent out an email to those who requested the code:

“I’m reaching out you since you are someone who has expressed interest or requested open source code from Tesla in the past.

We would like to let you know that we now have two repositories on GitHub that might be of interest. You can find them here:

https://github.com/teslamotors/buildroot

https://github.com/teslamotors/linux

Today they contain the buildroot material that is used to build the system image on our Autopilot platform, and the kernel sources for those boards as well as the Nvidia Tegra-based infotainment system in Model S/X. It is expected to be amended with material for other systems in the car in the near future.

Currently the material that is there is representative of the 2018.12 release, but it will be updated with new versions corresponding to new releases over time.

It does not contain the proprietary applications Tesla has built on top of this system image such as the actual Autopilot software stack, Nvidia proprietary binaries, etc.

Work is underway on preparing sources in other areas as well, together with a more coordinated information page. We wanted to let you know about this material as it is available now while work continues on the other parts.

For further questions, please contact [e-mail].”

Wat ik me dan wel weer afvraag: hoe snel hadden ze eigenlijk moeten reageren? Want ze hebben weliswaar 4-5 jaar op een antwoord laten wachten (wat verdomd lang is), maar wat is de gewenste termijn?

[cavey]

Hoezo is het lang? Als jij als bedrijf aan de GPL wilt voldoen, maar sommige onderdelen van je software zijn verwerkt met GPL en die wil je dan net niet openbaren, dan zal je de GPL eruit moeten schrijven zodat je dat deel niet vrij hoeft te geven. Hier kan best een aantal jaar overheen gaan, los van het juridische uitzoek werk welk onderdeel waar is gebruikt en of het onder LGPL valt of GPL, en of het dan nog onder GPL2 of GPL3 valt.

Dan nog heen en weer communiceren met allerlei projecten en mensen van de betreffende OSS en dan ben je per geval al een paar weken verder voor je uberhaupt duidelijkheid hebt over het hoe en wat.

Wat de gewenste termijn is: open communicatie met betrokken ontwikkelaars/teams (dus niet zozeer met degene die vragen om de code, maar belanghebbenden). En dat lijkt gebeurd te zijn.

[MSalters]

Zo werkt het niet. Als jij een binary hebt verspreid met GPL code erin, dan moet alle source code daarvan geleverd worden. Het leveren van een vervangende niet-GPL binary is geen optie. Voor nieuwe auto's kun je dat nog wel doen, maar je bestaande klanten hebben rechten onder de GPL waaraan je moet voldoen.

Daar hoeft geen jaren overheen te gaan. Een redelijke termijn is weken. Bij mijn vorige werkgever was de source release een paar uur na de binary release.

Communicatie met de betrokken ontwikkelaars is daarentegen niet nodig. Source code is een recht van downstream, niet upstream. Tenzij de ontwikkelaars toevallig een Tesla hebben zijn ze geen klant en hebben ze geen GPL rechten.

[cavey]

Zit wat in, dan is hun due diligence gewoon traag (kort door de bocht). Moest je reactie wel even twee keer lezen voor ik doorhad wat je nou precies bedoelde. Top, jammer dat ik geen + meer kan geven.

[Anoniem: 85014]

Maar iedere ontvanger heeft wel een onvervreemdbaar recht om die kopie weer door te geven. Zolang hij de ontvangere maar opnieuw de GPL licentie ervoor geeft (wat de volgende ontvanger ook weer dat onvervreemdbaar recht geeft).

[Resistor]

Eerste stap naar community ondersteuning (en later het terugtrekken van softwarematige ondersteuning van Tesla zelf?)

Prototype was 30 juni 2008 aangekondigd, en 10 jaar na aankondiging het 'aan de community geven' qua software kan een besparing opleveren voor ze voor de eerste series. En ook positieve reclame als er extra dingen bij komen, zoals een 'ultra zuinig' modus (in tegenstelling tot de 'ludricous', 0-100 in 10 seconden, top op 140km/h en een bereik van opeens 580km op een lading)

[84hannes]

Eerste stap naar community ondersteuning (en later het terugtrekken van softwarematige ondersteuning van Tesla zelf?)

Ik mag hopen dat er voor certificering van software voor auto's zoveel stappen vereist zijn, dat jan-met-de-pet hier niet of slechts met heel veel geld en moeite aan kan voldoen. Moet je je voorstellen wat er gebeurt als iemand een slecht/niet getest stuk software uitrolt omdat hij denkt daar iets sneller mee te kunnen rijden, door bijvoorbeeld de schoksensoren voor de airbag uit te schakelen.

[Reactie gewijzigd door 84hannes op 22 juli 2024 19:38]

[26779]

De maintainer is uiteindelijk degene die een pull request merged of niet. Er kan nog zoveel code aangeleverd worden, Tesla zal zelf besluiten of bepaalde code wel of niet geimplementeerd wordt.

[SuperDre]

Maar het gaat er ook om of deze mensen dan zelf hun tesla aanpassen met eigen code, DAT is iets dat zeker niet zomaar zal mogen, net zo min dat je hier in Nederland zomaar met experimentele onderdelen mag rondrijden zonder goedkeuring van de RDW.

[26779]

Wie zijn probleem is het dan? Die van Tesla of van degene die de auto zelf aanpast? Ieder ander merk auto gaat toch ook zijn handen er van af halen als een handige sleutelaar vanalles modificeert aan zijn auto? De verantwoording komt dan volledig bij de eigenaar/gebruiker van de auto te liggen.

[SuperDre]

Klopt, maar de berichtgeving als er iets gebeurd zal niet meteen aanwijzen dat het om een eigen modificatie gaat. Naast dat het dus bekeken moet worden of het dus zoveel mogelijk voorkomen kan worden dat mensen zelf gaan hannessen met de software van hun auto..

[84hannes]

Tesla zal zelf besluiten of bepaalde code wel of niet geimplementeerd wordt.

Dat lijkt me in beginsel geen probleem, maar @Resistor had het ook al over

en later het terugtrekken van softwarematige ondersteuning van Tesla zelf?

Ik zeg niet dat Tesla de verantwoordelijke moet zijn, van mij mag ook een ander bedrijf de verantwoordelijkheid (voor testen en certificering) op zich nemen, maar liever niet een anonieme ontwikkelaar. Dat accepteert men wellicht voor een mobiele telefoon of andere intieme electronica, maar hopelijk niet voor de moordmachine die auto heet.

[LinuxMan]

[...]
Ik mag hopen dat er voor certificering van software voor auto's zoveel stappen vereist zijn, dat jan-met-de-pet hier niet of slechts met heel veel geld en moeite aan kan voldoen. Moet je je voorstellen wat er gebeurt als iemand een slecht/niet getest stuk software uitrolt omdat hij denkt daar iets sneller mee te kunnen rijden, door bijvoorbeeld de schoksensoren voor de airbag uit te schakelen.

In principe is dit goed geregeld in Nederland. Ik vraag me alleen wel af of de RDW goed in staat is om software aanpassingen te beoordelen. Ik denk dat het personeel van de RDW toch vooral uit mensen met een mechanica en materiaal achtergrond bestaat - nog weinig software-kwaliteits-deskundigen.

Maar dat uitrollen heb je de RDW niet voor nodig - dat kun je (illegaal) ook zelf doen. Hoeveel mensen rijden er niet al rond met een andere chip die niet door de RDW is goedgekeurd? Met een huidige auto is het niet moeilijk. Ik ken iemand die zelf een cruise control op zijn canbus heeft gemaakt. Vanaf de canbus kun je de motor aansturen, snelheid uitlezen, toeren uitlezen, etc. PID controller schrijven en klaar. Of het verantwoord is dat is een andere vraag, en je verzekering zal ook weigeren om uit te keren. (hij heeft het gelukkig nooit op de openbare weg getest) De Tesla heeft alleen nog veel meer sensoren en veel meer actuatoren, dus het is veel complexer. (en dus ook meer kans dat het fout gaat)

[84hannes]

De Tesla heeft alleen nog veel meer sensoren en veel meer actuatoren, dus het is veel complexer

Het is weliswaar complexer, maar het bestaat ook al. Als Tesla dit deel van hun software vrij zou geven, dan zou het aantrekkelijk zijn om hier en daar wat wijzigingen door te voeren (minimal accuspanning verlagen, maximale stroom verhogen etc.). Gelukkig reken ik er op dat Tesla hiervoor een ander (realtime) OS gebruikt, en zo niet, dat het niet statisch gelinkt is aan de Linux-kernel. Als hun wijziging bestaat uit kernelondersteuning voor al hun sensoren en actuatoren, dan zou het goed kunnen dat de regelsoftware gewoon als applicatie (in userland) draait. Deze software hoeft Tesla dan niet vrij te geven. Mochten ze er toch voor kiezen die vrij te geven (academisch wel interessant) dan kunnen we alleen maar hopen dat Tesla een goede bootloaderbeveiliging heeft gebouwd en dat mensen niet gaan denken: ik heb betaald voor de auto dus ik mag er mee doen wat ik wil.

[Anoniem: 105188]

Goede stap, deze voorwaarden in GPL is iets wat veel bedrijven negeren en het werd eens tijd dat er weer een groot bedrijf werd aangepakt als een herinnering naar de andere. Helaas zal dit maar tijdelijk zijn, net zoals Linksys destijds zal je een kleine piek krijgen (omdat het dan even hip is) en daarna zwakt het heel snel af.

Waarschijnlijk zit er niks bijzonders in de code, maar afspraak is afspraak en als je zelf ooit onderhoud of een update uit wil voeren dan is dit een eerste stap. Dan kijk ik vooral naar Chinese fabrikanten, die de GPL aan hun laarslappen en je wordt opgezadeld met een apparaat waar geen onderhoud of upgrade aan mogelijk is.

[SuperDre]

maarja, vaak genoeg ook dat de source wel beschikbaar is, maar niemand geinteresseerd is om de boel nog verder te onderhouden.. Leuk voor de hobbyist die weet waar die mee bezig is, maar de groep is vaak wel maar heel erg klein.

[unclero]

Wat bij veel bedrijven ook meespeelt is dat de kleinere bedrijven (minder dan 30 werknemers) vaak ook zoiets hebben van: "Ja hallo, we gaan geen delen van ons IP vrijgeven." en als developer strijk je je baas natuurlijk liever ook niet tegen de haren in .
Met wat onderhandelen (dat het vaak té duur is om de code die onder GPL valt, eruit te slopen en in iets aparts te zetten, want vaak is het zo dat het uiteindelijke product voortborduurde op een eerdere snelle proof-of-concept dat in een paar nachtjes op een studentenkamer in elkaar gezet was, in de tijd dat GPL 'zorgen voor morgen' waren) valt er vaak nog wel van te maken dat "als we 50.000 units verkopen, dán kunnen we wel gaan praten over GPL compatibiliteit". Maar dat zijn van die beloftes uit de categorie "we gaan ooit een rewrite doen" en "jouw loon gaat ooit nog omhoog".

[Anoniem: 105188]

"Ja hallo, we gaan geen delen van ons IP vrijgeven."

Daar ga je dus al de fout in he. Het is niet jou IP, dat wist je toen je eraan begon. Als je dat niet wil dan moet je geen Linux gebruiken, dan pak je QNX ofzo, iets waar je wel voor moet betalen. Iets gratis pakken en niks terug willen geven, zo werken die dingen niet he.

Ik kan me nauwelijks geloven dat iemand op een studentenkamertje aan kernel hacking doet, ook dat het moeilijk is om applicatie en kernel van elkaar te scheiden. Dat is ook de grote fout die veel mensen maken in hun denken, de applicatie of driver is niet linux.

[unclero]

Daar ga je dus al de fout in he. Het is niet jou IP, dat wist je toen je eraan begon.

Je wilt niet weten hoe vaak een proof-of-concept al niet opgeleverd is met de kanttekening: "dit is niet netjes, quick-and-dirty, dit moeten we herschrijven voordat we het als product in willen zetten", en vervolgens komen er een aantal development iteraties en gaat iets naar productie om er daarna heel lang niet meer naar om te kijken.

Als je dat niet wil dan moet je geen Linux gebruiken, dan pak je QNX ofzo, iets waar je wel voor moet betalen. Iets gratis pakken en niks terug willen geven, zo werken die dingen niet he.

Een POC die vanaf een studentenkamertje komt mag in de eerste instantie niets kosten. Een werkgever/ondernemer die daar vervolgens mee verder gaat zet die lijn doorgaans voort.

Ik kan me nauwelijks geloven dat iemand op een studentenkamertje aan kernel hacking doet, ook dat het moeilijk is om applicatie en kernel van elkaar te scheiden. Dat is ook de grote fout die veel mensen maken in hun denken, de applicatie of driver is niet linux.

Wat denk je van een Loadable Kernel Module die gecompileerd is tegen allerlei Linux libraries?

[Anoniem: 105188]

Je kan allerlei dingen aanhalen en met praktische voorbeelden komen. Is allemaal leuk en aardig, maar dat neemt niks weg van het feit dat je als bedrijf je zaken op orde moet hebben. Dat je als bedrijf je eigen processen niet op orde hebt is geen excuus.

Daarnaast begrijp ik niet hoe jij een hele kernel wil includen met een kanttekening, volgens mij begrijp jij niet zo goed hoe dat alles werkt en ben je in de war met andere GPL projecten.

Kernel Modules zijn niet perse GPL, sinds Linux 2.4 bestaat iets als MODULE_LICENCE.

http://linuxmafia.com/faq...etary-kernel-modules.html

Daarnaast zie ik nog steeds een stagiaire niet even een kernel module in elkaar hacken, dat zijn geen dingen die je zonder goede kennis van zaken zomaar kan doen.

[Reactie gewijzigd door Anoniem: 105188 op 22 juli 2024 19:38]

[unclero]

Je kan allerlei dingen aanhalen en met praktische voorbeelden komen. Is allemaal leuk en aardig, maar dat neemt niks weg van het feit dat je als bedrijf je zaken op orde moet hebben. Dat je als bedrijf je eigen processen niet op orde hebt is geen excuus.

Helemaal mee eens. Maar wat ik aan wilde geven was dat de werkelijkheid vaak weerbarstiger is, en dan gaat het niet alleen om GPL compliancy, maar ook om de AVG die over een paar dagen 'komt', of zaken als veiligheid of gebruikerbeveiliging.

Ik persoonlijk schaar License-compliancy, AVG en beveiliging ook onder non-functionele requirements, in die zin dat: Deze non-functionele requirements maken dat, indien niet aan deze requirements wordt voldaan, de klant met een non-functioneel product zit.

Daarnaast begrijp ik niet hoe jij een hele kernel wil includen met een kanttekening, volgens mij begrijp jij niet zo goed hoe dat alles werkt en ben je in de war met andere GPL projecten.

Neuh, het kernel-frotten was maar een voorbeeld. Hetzelfde geldt voor het mee linken van een library. Of een fork maken van een ander project.

Daarnaast zie ik nog steeds een stagiaire niet even een kernel module in elkaar hacken, dat zijn geen dingen die je zonder goede kennis van zaken zomaar kan doen.

Ik hoor weliswaar niet al te beste verhalen over de huidige staat van het ICT-onderwijs in Nederland. Maar in mijn tijd (toen de dotCom-bubbel net uit elkaar begon te spatten) kon je nog zo'n beetje kiezen tussen je eigen virtual machine/compiler/assembler in elkaar zetten of je storten op Andrew Tanenbaum's opus magnum.

De meest fantastische startups zijn begonnen in donkere studentenkamers. En dan heb ik het niet eens over een Google, Microsoft, Facebook of Oracle, maar in iedere moderne incubator of bedrijvenverzamelgebouw is er wel een of ander bedrijf of startup wiens verhaal begint bij: "Tijdens mijn studie...". De reden dat ik deze analogie gebruik is, omdat de weg van 'afstudeerproject/onderzoeksproject' naar 'commercieel produkt' een lange is. Zodra er immers geld en de hypotheken van medewerkers (of die van jezelf) op het spel staan, gaan mensen ineens eerder aangehaalde non-functionele requirements zien als 'optionele requirements' (van die requirements die ooit nog wel komen, als er tijd over is, of geld is, of de 100.000 gebruikers grens bereikt is, of enz). Meest gehoorde reden om aan deze non-functionele requirement niet te voldoen, is een simpelweg: "De klant betaalt er niet voor".
En ik persoonlijk vind dat ronduit schokkend.

[core_dump]

Maakt het voor kwaadwillende veel makkelijker om in te kunnen breken en de besturing van de auto over te nemen..

Maar ja de illusie is nog steeds dat Open Source heilig is en er meteen volksstammen aan goedwillende programmeurs op hun zolderkamertjes gratis de software gaan zitten verbeteren

[Blokker_1999]

Geen idee hoe je er bij komt dat dit het voor kwaadwillenden eenvoudiger zou maken.

Tesla, een bedrijf dat miljarden waard is, maakt gebruik van het werk van vele duizenden vrijwilligers. Iets waar ze anders honderden miljoenen zelf hadden moeten in investeren en die vele vrijwilligers maken dit mogelijk onder specifieke voorwaarden. Dan is het ook maar normaal dat de wensen van die vrijwilligers gerespecteerd worden lijkt mij. Tesla staat niet boven de wet en niet boven de voorwaarden waarmij zij zelf akkoord zijn gegaan toen ze voor deze FOSS tools gekozen hebben.

[core_dump]

Misschien omfat het eenvoudiget is de source te downloaden en te analyseren dan dat je eerst een Tesla moet kopen, en vervilgens de software moet reverse engineeren?

[LinuxMan]

Misschien omfat het eenvoudiget is de source te downloaden en te analyseren dan dat je eerst een Tesla moet kopen, en vervilgens de software moet reverse engineeren?

en dan heb je een Linux kernel met een patch om een bepaald stukje hardware aan te kunnen sturen. En dan? Denk je dat ze de machine learning code waar het echte Intellectual Property zit (die in userspace draait en dus niet wordt geraakt door de GPL) ook vrijgeven? Ik denk dat die eventuele wijzigingen op de Linux kernel en busybox maar weinig opleveren om te analyseren.

[MSalters]

De Machine Learning code draait waarschijnlijk niet eens in de auto, daar wil je een cluster GPU's voor gebruiken. Die code mag Tesla dus geheim houden, zelfs als het GPL code zou zijn. De GPL legt voorla verplichtingen op als jde binaries verspreid, maar voor bedrijfs-intern gebruik zijn er nauwelijks verplichtingen.

[jimshatt]

Het zou interessant zijn als ze daarin gebruik maken van AGPL code. Hoe ga je dat beschikbaar maken als die code alleen via een webservice aangesproken wordt? Nou ja, gevalletje hypothetisch schmypothetisch.

[SuperDre]

Nog steeds makkelijker om code door te spitten op fouten, dan decompileren en die sources door te spitten (wat overigens niet eens zo heel veel moeilijker is).

[Menesis]

Tja, heel veel miljardenbedrijven doen dat. Kijk bijv eens in de instagram app onder settings > open source libraries. Vaak geven ze ook weer dingen terug in open source vorm: https://opensource.fb.com
Al weet ik niet of dat in verhouding staat.
Ben natuurlijk wel eens dat ze zich dan een de licenties moeten houden

[Anoniem: 105188]

Dat iets opensource is en dat het daarom makkelijker is om beveiligingsfouten te vinden is een illusie. Dat is alleen mogelijk als Tesla slordig is en juist daarom is die peerreview zo belangrijk, want dat is iets waar ze zelf ook mee geholpen zijn.

Tesla wist dat ze moesten voldoen aan de GPL toen ze Linux gingen gebruiken, als ze daar niet mee eens zijn dan hadden ze een OS moeten gebruiken die niet GPL is. Het aanbod is groot en de keuze is reuze.

[Reactie gewijzigd door Anoniem: 105188 op 22 juli 2024 19:38]

[Lethalis]

Daar zijn bug bounty's voor.

Als jij een bug vindt in open source code van een groot bedrijf, kun je vaak een geldsom daarvoor krijgen.

En dan wordt het ineens een heel andere situatie.

[ATS]

Het is de keuze die Tesla gemaakt heeft. Dat heeft consequenties. Ze hoefden niet voor GPL software te kiezen als basis, maar hebben dat kennelijk toch gedaan. Daar zullen ze wel redenen voor gehad hebben. Dat betekent dat ze software gebruiken met een bepaalde licentie er aan vast die vereist dat ze nu (delen van) hun stack zelf ook open source maken. Nogmaals, dat is de consequentie van de vrije keus die Tesla gemaakt heeft. Ze hadden ook een eigen propretaire stack kunnen bouwen (of kopen ergens).

[DragonChaser]

Voor geinteresseerden, de Github below:
https://github.com/teslamotors

[kikker81]

Waarom mag Tesla hier jaren en jaren over doen? En is het nu nog niet helemaal geregeld?
Dat is toch je reinste concurrentievervalsing als een ander zich wel aan de GPL houdt? Waarom wordt er niet meteen een zaak gestart zodra Tesla een auto uitlevert zonder broncode erbij?

[brinkdinges]

Ik dacht eerst dat dit een of andere flame was. Toen maar even gezocht op het woord 'crap' en 101 hits gevonden in hun repo's Dat boezemt niet heel veel vertrouwen in.

Edit: Ik bedenk me nu dat die comments niet per se van Tesla hoeven te komen.

[Reactie gewijzigd door brinkdinges op 22 juli 2024 19:38]

[stewie]

Erg hoog amateur niveau.. (Je voelt je meteen veilig met zulke taal in de source)

[Reactie gewijzigd door stewie op 22 juli 2024 19:38]

[mashell]

Geeft aan dat ze door mensen met emotie en passie voor hun werk gemaakt zijn. 100x liever zulke code dan code zonder commentaar.

[stewie]

Zo kun je alles verdraaien, het is gewoon amateur niveau (Als Iemand in de Linux gemeenschap dit zou doen, dan zouden ze aan een schandpaal genageld worden)

[MSalters]

Yeah, right.

Die 101 hits in de Tesla code is 52 minder dan in stock Linux.

[stewie]

Maar Linux wordt ook geschreven door duizenden mensen meer en is veel groter, dus een VEEL lager amateur niveau..

[Reactie gewijzigd door stewie op 22 juli 2024 19:38]

[multimho]

Het verschil met proprietary software is dat je dit nu weet en dus iets kan doen aan die stukken code.

Bij propriatary software komen we daar pas achter wanneer een klokkenluider van de CIA of NSA ons wijst op een fractie van exploits die mogelijk zijn met dat soort software.

Liever dat ik weet waar er nog werk zit, dan voor gelogen worden door de blauwe ogen van de "professionele" software ontwikkelaar...

[mashell]

het is gewoon amateur niveau

Tja, het is open source. Daaraan werken amateurs. En ook professionals, maar die hoeven dan niet het saaie werk van het designen, reviewen en documenteren te doen. Al die vrijheid geeft helaas niet altijd het beste resultaat. Ik keur scheldwoorden niet goed, maar een beetje emotie in het commentaar, doen. Zorgt dat iemand die het eventuele onderhoud doet weet waar de zwakke plekken zitten.