Hallo, Ich habe folgende Frage, vielleicht kann mir jemand helfen und weiß Bescheid. Wie allen bekannt ist, fast alle oder fast alle Unterhaltungselektronik läuft unter Linux Betriebssystem. Und wie vor 15 Jahren üblich war, sollte die Hersteller die Sources Code öffentlich zugänglich tun. Gilt es immer noch? Falls ich bei Hersteller den Link nicht finde, kann ich als privater Hersteller anschreiben und um ein Link bitten? Danke für Ihre Mühe!
Moin, Jük P. schrieb: > Und wie vor 15 Jahren üblich war, > sollte die Hersteller die Sources Code öffentlich zugänglich tun. Gilt > es immer noch? Nein, das galt noch nie. Der Hersteller muss dich, wenn du das Dingens kaufst, wo was drinnen ist, was unter die GPL faellt darauf hinweisen, das da was drinnen ist. > Falls ich bei Hersteller den Link nicht finde, kann ich als privater > Hersteller anschreiben und um ein Link bitten? Das kannst du machen, vielleicht funktioniert es auch. Aber der Hersteller darf dir auch Geld abknoepfen, wenn du auf Herausgabe seiner sourcen bestehst. Er hat ja ggf. auch Unkosten, wenn er den Krempel z.b. zusammensucht und fuer dich auf eine CD brennt. Gruss WK
1. Ja. die Lizenz schreibt vor, dass der Quellcode zumindest den Käufern offengelegt werden muss. 2. Nein, es nicht verboten, beim Hersteller nachzufragen. Matthias
:
Bearbeitet durch User
Jük P. schrieb: > Wie allen bekannt ist, fast alle oder fast alle Unterhaltungselektronik > läuft unter Linux Betriebssystem. Nein, das wußte ich nicht. Ich denke mal, vieles läuft ganz ohne OS direkt aus dem Flash, z.B. mein Onkyo TX-8050. Er hat Ethernet und ne Webseite mit den Sender-URLs zum Speichern.
Jük P. schrieb: > Wie allen bekannt ist, fast alle oder fast alle Unterhaltungselektronik > läuft unter Linux Betriebssystem. Das wäre toll.
Tim 🔆 schrieb: > Jük P. schrieb: >> Wie allen bekannt ist, fast alle oder fast alle Unterhaltungselektronik >> läuft unter Linux Betriebssystem. > > Das wäre toll. Es ist bestuemmpt toll 45 Sekunden zu warten, bis so ein *$DRECKSDING* fertig gebootet hat. Frueher™ war so etwas noch jedem $ENTWICKLER wichtig. Die Schnellheizkathoden eines Braunschen Farbstrahlrohrs sind da deutlich schneller.
Motopick schrieb: > Tim 🔆 schrieb: >> Jük P. schrieb: >>> Wie allen bekannt ist, fast alle oder fast alle Unterhaltungselektronik >>> läuft unter Linux Betriebssystem. >> >> Das wäre toll. > > Es ist bestuemmpt toll 45 Sekunden zu warten, bis so ein > *$DRECKSDING* fertig gebootet hat. > Frueher™ war so etwas noch jedem $ENTWICKLER wichtig. > Die Schnellheizkathoden eines Braunschen Farbstrahlrohrs > sind da deutlich schneller. Ich meinte halt im Gegensatz zu anderen Betriebssystemen, wenn schon eins drauf sein muss. Auf meinem TV-Receiver läuft z. B. Windows. Ganz super...stürzt ja nur alle paar Tage ab und überschreibt dann die vorhergehende Aufnahme. Kann natürlich unter Linux auch passieren, aber da könnte man eben mal reinschauen.
Tim 🔆 schrieb: > Kann natürlich unter Linux auch passieren, aber > da könnte man eben mal reinschauen. Die Anwendung, die Videos auf die Festplatte schreibt, wird dir der Hersteller höchstwahrscheinlich nicht ausliefern.
Es geht um Kernel Linux Sources Code, wie oben auch steht. Ich probiere mal Hersteller anzuschreiben)
Tim 🔆 schrieb: > Auf meinem TV-Receiver läuft z. B. Windows Was ist das für einer? Nur als Warnung für die Mitleser....
TV-Geräte sind recht speziell. Da kannst Du Sendungen auf einem USB-Medium aufzeichnen. Natürlich verschlüsselt wegen Urhebergedöns. D.h. Du kannst die Sendungen nur wieder auf genau diesem einen TV-Gerät abspielen. Und deshalb dürfen die auch nicht die Sourcen rausgeben, sonst könntest Du ja einfach die Verschlüsselung umgehen.
Peter D. schrieb: > Und deshalb dürfen die auch nicht die Sourcen rausgeben, sonst könntest > Du ja einfach die Verschlüsselung umgehen. Natürlich dürfen die das. Der Key für die Verschlüsselung wird da ja nicht drin stehen. Oliver
Motopick schrieb: > Die Schnellheizkathoden eines Braunschen Farbstrahlrohrs > sind da deutlich schneller. A: Es dauert keine 45sek bis ein smart TV gebootet hat. B: Die Netflix und Prime App auf so einem 3,5T schweren Löwe Glasbaukasten mit 3m Bautiefe läuft eher schleppend. C: Die Auflösung des Löwe bleibt minimal hinter der heute üblichen zurück. D: OLEDs und TFT erzeugen keine Röntgenstrahlung. Ich werde es nie verstehen: Mit ausgefeilter High Tech in einem weltumspannenden Netzwerk rumheulen wie verkackt die moderne Technik ist und das früher alles besser war. Auf meinem Oszi läuft Linux, auf dem Speki, auf dem TV, dem Smartphone. Alle Geräte sind binnen Sekunden gestartet. Dauert kein Stück länger als mit meinem alten Tek und seiner proprietären SW. Das Tek war auch viel teurer als der verachtenswerte neue Linux Schnickschnack. Also was genau ist das Problem?
Oliver S. schrieb: > Peter D. schrieb: >> Und deshalb dürfen die auch nicht die Sourcen rausgeben, sonst könntest >> Du ja einfach die Verschlüsselung umgehen. > > Natürlich dürfen die das. Der Key für die Verschlüsselung wird da ja > nicht drin stehen. Irgendwo innerhalb des Geräte MUSS der Key ja stehen. Und die App muss irgendwie an diesen Key herankommen. Wenn also der Key vielleicht nicht direkt in der App steht, so muss doch auf jeden Fall die "Bedienungsanleitung" dafür, wie man an den Key kommt, in der App stehen. Aus kryptografischer Sicht ist das nahezu gleichwertig.
Moin, Ob S. schrieb: > Irgendwo innerhalb des Geräte MUSS der Key ja stehen. Und die App muss > irgendwie an diesen Key herankommen. Nee MUSS er natuerlich nicht. "Der Key" kann auch von einem supderdupergeheimen-nicht-oss-Haufen Software unter bestimmten Bedingungen (Ja, wo lauf' ich denn hier gerade, wer laeuft denn hier noch so, wo bin ich, geht's mir gut...) mehr oder weniger clever und mehr oder weniger sichtbar "aus dem Hut gezaubert werden". Und diese Zaubertricks unterliegen natuerlich nicht der GPL. Und das Zusammenspiel zwischen GPL und nicht-GPL Software ist manchmal trivial, manchmal halt weniger...Erlaubt ist, was gefaellt :-) Gruss WK
Oliver S. schrieb: > Natürlich dürfen die das. Der Key für die Verschlüsselung wird da ja > nicht drin stehen. Wenn Du den Quellcode hast, siehst Du doch, wo die Verschlüsselung bzw. Entschlüsselung aufgerufen wird. Einfach diese Zeilen löschen.
Peter D. schrieb: > Wenn Du den Quellcode hast, siehst Du doch, wo die Verschlüsselung bzw. > Entschlüsselung aufgerufen wird. Einfach diese Zeilen löschen. Du hast keine Ahnung. Nein, du wirst niemals den Quellcode einer Applikation zu sehen bekommen.
:
Bearbeitet durch User
Klaus schrieb: > Nein, du wirst niemals den Quellcode einer Applikation zu sehen > bekommen. Meine Rede: Peter D. schrieb: > Und deshalb dürfen die > auch nicht die Sourcen rausgeben, sonst könntest Du ja einfach die > Verschlüsselung umgehen.
Auch oft: Du kriegst zwar den Linux-Quelltext mit den herstellerspezifischen Modifikationen darin, kannst den vielleicht auch compilieren, kriegst ihn aber nicht zum laufen. Weil der Bootloader im Gerät überprüft, ob der Kernel vom Hersteller signiert ist. Den Private-Key zum signieren muss der Hersteller natürlich nicht rausgeben... Das hat man in der GPLv2 leider nicht vorhergesehen, GPLv3 wäre da besser...
Εrnst B. schrieb: > muss der Hersteller natürlich nicht > rausgeben... Ist doch eh blanke Theorie. Wenn der Hersteller nicht will, dann muss ich langwierige Prozesse anstrengen. Nach einem Jahrelangen Rechtsstreit für ein paar Mio, bekomme ich dann den veralteten Code als Paperback, alle Variablennamen durch kryptische Nummern ersetzt, jede Formatierung entfernt, mit Fehlern und Lücken. Da ackere ich mich dann 5J durch und klage auf Herausgabe der noch fehlenden Teile? Klage einreichen darf ich in USA und ob ich das als Drittanbieter überhaupt darf, ist wohl noch strittig. Da der private nicht über die Mittel verfügt, wird der Hersteller nicht mal Antworten.
Sobald ich die Anfrage gestartet habe, werde ich hier auch das Ergebnis schreiben. Die Japaner sind viel netter als manche hier, das weiß ich ganz genau. Und bisher habe ich gute Erfahrungen mit den japanischen Herstellern gemacht. Danke an alle Beteiligten.
Jük P. schrieb: > Die Japaner sind viel netter als manche hier Stichwort 'Gesichtsverlust' Japaner können 'Hau ab und fick dich selbst' äußerst nett und zuvorkommend klingen lassen. Ein Japaner versteht aber durchaus was da gerade gesagt wurde.
Εrnst B. schrieb: > GPLv3 wäre da > besser... Aha, und was genau ändert die GPLv3 vs GPLv2 bei einem proprietärem Bootloader mit Signaturprüfung? Den Key für die Prüfung muss der Hersteller überhaupt nicht offenlegen, warum sollte er das müssen? Und wo bitte steht in der GPLv3 das ich ein Dokument(hier der Key), dass ich mit einer Opensource-Software verwende irgendwo freigeben müsste, da würden sich die ganzen GnuPGP Nutzer aber freuen. Der Key wird in irgend einem TPM ähnlich Chip, vermutlich direkt im SoC integriert, stehen. Da kommst du von außen gar nicht ran, das ist weder vorgesehen noch notwendig um zu prüfen ob die Signatur passt. Im übrigen weil hier immer alle so auf GPL und "kommerziell" rumreiten. In der GPL steht nichts von "kommerziell". In der GPL steht einfach nur "distribute". D.h. selbst wenn du als Hobbybastler einen Firmwareblob ins Netz stellst welcher GPL Code enthält, musst Du dafür sorgen das mindestens der verwendete GPL Code zur Verfügung steht, in vielen Fällen aber auch dein eigener Code selbst, z.B. wenn gegen den GPL Code gelinkt wird. ("Derived work" und so)
Andreas M. schrieb: > Aha, und was genau ändert die GPLv3 vs GPLv2 bei einem proprietärem > Bootloader mit Signaturprüfung? Section 6: ... any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made => Sie müssen dir ALLES geben, was du brauchst um eine veränderte Software auf das Gerät zu bringen. Kann ein Secret Key sein, dessen Signatur der Bootloader akzeptiert, oder eine Möglichkeit die Signaturprüfung im Bootloader abzuschalten.
Ich habe lange Zeit einen Humax PVR benutzt, der lief auch mit Linux. Aber die PVR Anwendung war eine Blackbox. Es konnten nur wenige zusätzliche Tools installiert werden aber an der eigentlichen PVR Software ließ sich nichts ändern. Das war auch legal, die Quellen musste Humax afaik nie rausrücken.
Smartphones laufen mit Android unter Apache Lizenz, und die Verschlüsselung in einem seoaraten proprietären RTOS. Das nur mal so nebenbei. Was den Linux kernel angeht, der unterliegt der GPLv2. Somit verstoßen nahezu alle Smartphone-Hersteller dagegen. Anfragen bei chinesischen Herstellern verlaufen im Sande. Bei denen im deutschen Markt vertretenen Markennamen findet man den Kernel Sourcecode online, aber meistens kompilieren die nicht sauber. Es drängt sich der Verdacht auf es werden absichtlich falsche Sources veröffentlicht.
Εrnst B. schrieb: > Andreas M. schrieb: >> Aha, und was genau ändert die GPLv3 vs GPLv2 bei einem proprietärem >> Bootloader mit Signaturprüfung? > > Section 6: > > ... any methods, procedures, authorization keys, or other information > required to install and execute modified versions of a covered work in > that User Product from a modified version of its Corresponding Source. > The information must suffice to ensure that the continued functioning of > the modified object code is in no case prevented or interfered with > solely because modification has been made > > => Sie müssen dir ALLES geben, was du brauchst um eine veränderte > Software auf das Gerät zu bringen. Nur dass die Anwendung, die letzten Endes für die Funktion des Gerätes verantwortlich ist, nicht unter GPL stehen wird sondern unter einer proprietären Lizenz.
Le X meinte: > Nur dass die Anwendung, die letzten Endes für die Funktion des Gerätes > verantwortlich ist, nicht unter GPL stehen wird sondern unter einer > proprietären Lizenz. Das kann aber dem Engineer auch Vorteile bringen. Etwea wie beim Bose "TV Speaker". Da der unter freeRTOS läuft, das dabei den meisten Code ausmacht, der ja bekannt ist, kommt mal leichte an die eigendliche Anwendung heran, zumal diese ja auf die bekannte API des RTOS aufsetzt und damit leichter zu disassemblieren ist. mfg
Dergute W. schrieb: > Ob S. schrieb: >> Irgendwo innerhalb des Geräte MUSS der Key ja stehen. Und die App muss >> irgendwie an diesen Key herankommen. > > Nee MUSS er natuerlich nicht. Doch, natürlich muss er. Erkläre doch mal, wie die App funktionieren können soll, wenn der Key (oder meinetwegen auch eine Generierungs- oder Beschaffungsvorschrift dafür) nicht irgendwo persistent im Gerät verankert wäre. > "Der Key" kann auch von einem supderdupergeheimen-nicht-oss-Haufen > Software unter bestimmten Bedingungen (Ja, wo lauf' ich denn hier > gerade, wer laeuft denn hier noch so, wo bin ich, geht's mir gut...) > mehr oder weniger clever und mehr oder weniger sichtbar "aus dem Hut > gezaubert werden". Das ist dann statt Beschaffung halt Generierung. Dann liegen halt die Parameter zur Generierung irgendwo persistent im Gerät und in der App ist statt einer Vorschrift zur Keybeschaffung eine Vorschrift zur Keygenerierung hinterlegt. Kryptografisch ist das alles ein- und dieselbe Soße. Das Geheimnis ist vollständig auf dem Gerät verfügbar. Fertig und aus. Was sich ändert, ist nur der Aufwand, um an den Key zu kommen. Solange es hardwaremäßig keine Möglichkeit gibt, Code in einem gesicherten Speicherbereich auszuführen, ist der Aufwand einigermaßen überschaubar. Viele günstige Receiver haben keine entsprechende Möglichkeit. Weil: hätten sie sie, wären sie nicht mehr ganz so günstig...
Ob S. schrieb: > Dergute W. schrieb: >> Ob S. schrieb: >>> Irgendwo innerhalb des Geräte MUSS der Key ja stehen. >> >> Nee MUSS er natuerlich nicht. > > Doch, natürlich muss er. Erkläre doch mal, wie die App funktionieren > können soll, wenn der Key (oder meinetwegen auch eine Generierungs- oder > Beschaffungsvorschrift dafür) nicht irgendwo persistent im Gerät > verankert wäre. Der liegt im RPMB Replay Protected Memory, nicht im Telefonspeicher. Alexander schrieb: > Die SPU ist so gebaut dass selbst ein physischer Extraktionsversuch des > Masterkeys, den man für eine Offline-Entschlüsselung benötigen würde, > nicht zerstörungsfrei ablaufen kann.
armselig: Politik hat Einzug gehalten in den Linux kernel. https://www.heise.de/news/Linux-Mehrere-russische-Maintainer-fliegen-raus-9992741.html
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.