Wie ihr sicher wisst sind Open Source, Freie Software und Freeware nicht
das selbe. Zuerst nochmal eine kurze Zusammenfassung:
Open Source: Der Quellcode ist öffentlich. Lizenzen können aber beliebig
einschränken, was man damit tun darf.
Freeware: Die Software ist Gratis*, zumindest auf den ersten blick. Muss
nicht zwangsläufig Open Source sein.
Freie Software: Die Software muss nicht zwangsläufig Freeware sein.
Jeder muss die Software jedoch uneingeschränkt weiterentwickeln, nutzen,
weitergeben und veröffentlichen können.
Bei den FOSS Lizenzen gibt es solche, die Copy-Left sind, und solche,
die es nicht sind. Copy-Left bedeutet, die selbe Lizenz, oder eine
Kompatible muss verwendet werden. Copy-Left Lizenzen, insbesondere die
GPL, werden normalerweise bei grösseren Projekten verwendet, um zu
verhindert, das jemand daraus ein Closed Source Produkt macht oder als
teil eines solchen verwendet. Bei kleinen Projekten, wo dies nicht
sinnvoll währe, werden hingegen permissivere Lizenzen verwendet, wie
z.B. die MIT Lizenz, die nur sehr wenige Einschränkungen aufweist.
Die Microsoft ♥ Linux Campagne dürfte jedem bekannt sein. Microsoft
unterstütze Open Source Projekte & Linux allgemein rein aus gutem
willen, habe die meisten & grössten Open Source Projekte, etc. Nicht das
ich der Sache je getraut hätte, aber soweit so gut, daran ist erstmal
nichts grundsätzlich falsch.
Microsoft nutzt, und ihnen gehört mittlerweile, GitHub. Sie haben ihre
Projekte unter https://github.com/Microsoft. Aber nicht nur Projekte von
Microsoft sind dort, auch Projekte von Leuten, die ihre Projekte unter
der Organisation veröffentlichen wollen, oder mal bei MS waren oder dort
hin kommen.
Als ich mal zu einem Projekt, zu dem ich schon mal eine
Bugfix/Erweiterung beigetragen hatte, dort ein neuer Bug bemerkt wurde,
wollte ich den beheben. Das Repo war in der Zwischenzeit aber zur
Microsoft Organisation verschoben worden, was an sich ja noch kein
Problem gewesen wäre. Jedoch musste ich feststellen, dass Microsoft
fordert, das bei allen Repos unter der Microsoft Organisation bei
Beiträgen einem CLA zugestimmt wird. Ich nahm damals an, das es den
selben Zweck eines DCOs erfüllen sollte, und lediglich für zusätzliche
Rechtssicherheit bezüglich der Rechte des Authors der Änderungen
bezüglich der Rechte an diesen und dessen Veröffentlichung sorgen
sollte. Nach durchlesen des CLA kam ich aber zum Schluss, das dieses
ausschliesslich Microsoft allen die Möglichkeit gab, ihre und die
Rechtssicherheit der Mitentwickler zu sichern, aber andere, die das
Projekt Forken, um damit in eine andere Richtung zu gehen, sich später
nicht auf das CLA stützen könnten, da dieses immer spezifisch mit
Microsoft abgeschlossen wurde. Nicht allen die gleichen rechtlichen
Möglichkeiten zu geben widersprach deshalb meinen Idealen an freie
Software, weshalb ich das CLA nicht zustimmen konnte, neben ein paar
anderen bedenken. Ich bot an, die Commits mit einem DCO zu versehen,
aber da dies nicht Microsofts Richtlinien entsprach, kahm es nicht zu
einer Einigung. Sowas kann es halt geben, es ist wie es ist.
Ablauf zusammengefasst:
* https://github.com/Microsoft/node-pty/issues/167 - Eine Limitation
ist mir aufgefallen
* https://github.com/Microsoft/node-pty/pull/169 - Ein Fix dafür
* Repo wurde zur Microsoft Organisation verschoben.
* https://github.com/Microsoft/node-pty/issues/206 - Ein Bug wurde
bemerkt
* https://github.com/Microsoft/node-pty/pull/207 - Bugfix von mir,
konnte aber wegen nicht Übereinkunft bezüglich der CLA nicht angenommen
werden
Soweit so gut, nichts besonderes soweit. Dass ein Vertrag nicht zustande
kommt, weil man sich nicht einigen kann, ist nichts besonderes, und dass
MS ein CLA fordert auch nicht so ungewöhnlich für eine Firma.
Vor kurzem wurde ich aber auf eine neue Masche aufmerksam, die sich
"open core" nennt. Dabei ist die Grundsoftware Open Source, und hat auch
eine FOSS Lizenz, aber es gibt auch eine Enterprise Version mit einer
Closed Source Lizenz, mit mehr Features, Bug- und Security fixen. Es
gibt mehrere Methoden, wie das Lizenz technisch gelöst ist:
1) Eine Lizenz, die Sublicensing erlaubt und kein Copy-Left hat
2) Dual Licensing, das Projekt steht unter 2 Lizenzen, eine FOSS, eine
nicht.
3) Das Open Source Projekt hat eine FOSS Lizenz, aber Änderungen werden
nur angenommen, wenn man einer CLA zustimmt, die jemandem die nötigen
Rechte gibt, um das unter einer anderen Lizenz verkaufen zu können.
Wikipedia fokussiert sich im Moment eher auf 3, und ist sehr
aufschlussreich:
https://en.wikipedia.org/wiki/Open-core_model
Nun hab ich Microsofts CLA
(https://opensource.microsoft.com/pdf/microsoft-contribution-license-agreement.pdf)
unter dem Gesichtspunkt nochmal angeschaut.
Microsoft sagt zwar https://cla.opensource.microsoft.com/> We appreciate community contributions to code repositories open sourced by
Microsoft.
> By signing a contributor license agreement, we ensure that the community is free
to use your contributions.
Aber ich glaub irgendwie nicht mehr, das das der einzige Grund ist.
Abschnit 5.a:
> 5. Licenses.> a. Copyright License. You grant Microsoft, and those who receive the Submission
directly or
> indirectly from Microsoft, a perpetual, worldwide, non-exclusive, royalty-free,
irrevocable license in the
> Submission to reproduce, prepare derivative works of, publicly display, publicly
perform, and distribute
> the Submission and such derivative works, and to sublicense any or all of the
foregoing rights to third parties
Jetzt kommt mir langsam der üble verdacht: Könnte es sein, das MS es
darauf abgesehen hat, abzuwarten, bis ein paar der Projekte unter der
Microsoft Github Organisation populär genug werden, um dann eine
Kostenpflichtige Closed Source Enterprise Version davon zu erstellen,
während das ursprüngliche Projekt verrottet?
Was MS vorhaben könnte, ist wohl schwerlich zu erraten. ;-))
Aber allein die "Metadaten" von Github sind sicherlich wertvoll. So
lassen sich neue Ideen abschöpfen oder erkennen, welche
Trends/Probleme/Wünsche die Community bewegen.
Dann lassen sich die Sachen entweder nachprogrammieren oder man versucht
ein sog. vendor-lock-in, d.h. man bietet eine so komfortable
Schnittstelle an, daß das eigene Produkt zu einer Art Quasi-Standard
wird (klappt aber meistens nur eine begrenzte Zeit, dann kommt eine
andere Schnittstelle).
Die ganzen Lizenzen finde ich persönlich inzwischen total verwirrend.
Noch dazu, wenn ein guter Teil der Copyrightklauseln in englischer
Sprache (unter angelsächsischem Rechtssystem) verfaßt sind.
DPA schrieb:> Copy-Left Lizenzen, insbesondere die GPL, werden normalerweise bei> grösseren Projekten verwendet, um zu verhindert, das jemand daraus ein> Closed Source Produkt macht oder als teil eines solchen verwendet. Bei> kleinen Projekten, wo dies nicht sinnvoll währe, werden hingegen> permissivere Lizenzen verwendet, wie z.B. die MIT Lizenz, die nur sehr> wenige Einschränkungen aufweist.
Kannst du so pauschal nicht sagen.
Erstens ist natürlich BSD selbst ein eher großes Projekt und unter
BSD-Lizenz, ähnliches gilt für die MIT-Projekte mit ihrer Lizenz. Aber
auch Apache hat, angefangen beim klassischen Server einige größere
Projekte, und die Apache-Lizenz ist sehr ähnlich zu MIT oder BSD.
Während diese „virulente“ Eigenschaft der GPL von Einigen sehr stark
gemocht wird, hat sie auf der anderen Seite (auch unter den Autoren von
FOSS) ebenso viele Gegner.
Muss man in diesem Thread nicht weiter diskutieren, ich wollte nur gern
den Zusammenhang „groß -> GPL, klein -> permissive Lizenz“ korrigiert
haben.
Was Microsoft dazu bewogen hat, vermag ich auch schwer zu beurteilen.
Sicher haben sie irgendwie erkannt, dass ihnen in manchen Bereichen
(siehe Smartphones) deutlich die Felle davon schwimmen, und dass man
sich anderweitig umsehen muss. Ich hielte es nicht einmal für
ausgeschlossen, dass sie irgendwann den Windows-Quellcode freigeben, so
wie es vor vielen Jahren Sun mit Solaris gemacht hat. Auch die hatten
erkannt, dass die Geheimhaltung des OS-Quellcodes sowieso nicht das ist,
was ihnen Geld in die Kasse spült. Mit Windows ist das ja im Grunde kaum
anders.
DPA schrieb:> Jetzt kommt mir langsam der üble verdacht: Könnte es sein, das MS es> darauf abgesehen hat, abzuwarten, bis ein paar der Projekte unter der> Microsoft Github Organisation populär genug werden, um dann eine> Kostenpflichtige Closed Source Enterprise Version davon zu erstellen,> während das ursprüngliche Projekt verrottet?
Nun ja, ich denke du hast in deinen Äußerung zu dem Thema schon Recht,
aber mal praktisch gedacht, die MIT Versionen wird man jederzeit Forken
können und anderswo oder auf github selbst weiterentwickeln können.
Die MIT Version verliert dadurch auch keine Features oder Funktionen und
es werden dadurch auch nicht mehr Bugs, es ist lediglich die Cloused
Source Version die vielleicht neue Features bekommt und in der Bugs
gefixt werden, die in der MIT Version noch nicht gefixt wurden, aber
diese extra Arbeit, die so eine CS Version von der MIT Version abhebt,
die muss erst einmal gemacht und die wird dann Microsoft machen müssen.
Die MIT Version bleibt daher das was sie ist und kann jederzeit
weiterentwickelt werden.
Im Prinzip sehe ich da jetzt auch keinen großen Unterschied zu den
dutzenden anderen MIT oder BSD Projekten, die noch eine CS
Nebenentwicklung laufen haben.
Oftmals ist es auch so, dass die CS Nebenentwicklung Geld in die Kassen
der Firma bringt, die die CS Nebenentwicklung macht und durch die
Vollzeitentwickler fällt dann oftmals auch die ein oder andere
Verbesserung für die Open Source Version ab.
Bei vielen Libraries hat sich z.B. gezeigt, dass eine mögliches offene
freie Open Source Lizenz wie die MIT, BSD oder zlib Lizenz besser ist,
als die LGPL, weil bei den ersteren die Firmen mit ihren
Vollzeitarbeitskräften viel mehr in das Open Source Projekt
zurückbringen und die Library selbst unter einer wesentlich freieren
Lizenz als die LGPL viel akzeptierter ist.
Auch die Qt Lib wird bspw. unter einer dualen Lizenz entwickelt.
Aber wenn du jetzt denkst, dass das jetzt wirklich ein Problem ist, dann
solltest du versuchen noch mehr Leute in der Open Source Community zu
erreichen.
svensson schrieb:> Was MS vorhaben könnte, ist wohl schwerlich zu erraten. ;-))>> Aber allein die "Metadaten" von Github sind sicherlich wertvoll. So> lassen sich neue Ideen abschöpfen oder erkennen, welche> Trends/Probleme/Wünsche die Community bewegen.
Man kann so auch fleißige Programmierer rekrutieren. Es fehlt nur noch
eine automatisierte Möglichkeit deren Codequalität zu messen.
Wenn MS da aber eine Lösung finden könnte, dann könnte mit der
Datengrundlage von Github die guten Entwickler, die dort mitwirken, vom
Markt abschöpfen.
Habe eher den Eindruck, die Freie Software schläft von selbst ein.
Microsoft braucht da überhaupt nichts mehr bekämpfen.
"Wir alle stellen unsere Arbeit frei zur Verfügung, dürfen dafür die
Arbeit anderer Menschen frei benutzen." Das alte Ideal der freien
Software passt nicht mehr in unsere heutige Konsumgesellschaft
Den Benutzern ist die Freiheit egal geworden. Die Bloatware und Spyware
der Smartphone-Hersteller nehmen die meisten Leute einfach so hin. Ist
halt so. Ein problemloser Appstore ist wichtiger als die Freiheit selbst
zu entscheiden wer was mit unseren Geräten macht.
Und die alten Stallman Anhänger kommen nach und nach zu der Einstellung
– wieso soll ich umsonst arbeiten? Für Google/Apple/Facebook? Für diese
Coutch-Potatos die sich auf Instagram rumtreiben?
Wir könnten ja ein dezentrales Repository auf unseren PC aufbauen.
Torvalds hatte Git ist für dezentrale Repositories konzipiert. Dicke
Rechner und DSL-Flatrate haben wir sowieso. Aber das langweilige
Tagesgeschäft macht niemand mehr freiwillig.
> auf eine neue Masche aufmerksam
Schwer zu sagen, welcher Effekt überwiegt. Die Qt zum Beispiel war
ursprünglich nur kommerziell. Die eingeschränkte GPL Version gab
Trolltech erst Jahre später frei.
Nano schrieb:> DPA schrieb:>> Jetzt kommt mir langsam der üble verdacht: Könnte es sein, das MS es>> darauf abgesehen hat, abzuwarten, bis ein paar der Projekte unter der>> Microsoft Github Organisation populär genug werden, um dann eine>> Kostenpflichtige Closed Source Enterprise Version davon zu erstellen,>> während das ursprüngliche Projekt verrottet?>> Nun ja, ich denke du hast in deinen Äußerung zu dem Thema schon Recht,> aber mal praktisch gedacht, die MIT Versionen wird man jederzeit Forken> können und anderswo oder auf github selbst weiterentwickeln können.
Bei MIT Projekten trifft das zu. Microsoft könnte das aber auch mit GPL
und beliebig anders Lizenzierten Projekten unter der Microsoft
Organisation tun, immerhin haben sie durch das CLA ja von allen die
Einwilligung.
> Die MIT Version verliert dadurch auch keine Features oder Funktionen und> es werden dadurch auch nicht mehr Bugs, es ist lediglich die Cloused> Source Version die vielleicht neue Features bekommt und in der Bugs> gefixt werden, die in der MIT Version noch nicht gefixt wurden, aber> diese extra Arbeit, die so eine CS Version von der MIT Version abhebt,> die muss erst einmal gemacht und die wird dann Microsoft machen müssen.
Nicht zwangsläufig. Manchmal übernehmen Open Core Projekte Bugfixes und
Features nur in die kostende Version. Und gerade bei Bugfixes finde ich
es unverantwortlich, wenn diese der FOSS Version vorenthalten bleiben.
> Die MIT Version bleibt daher das was sie ist und kann jederzeit> weiterentwickelt werden.
Sofern der Entwickler unabhängig ist. Klar, man könnte es Forken, aber
damit ein Projekt genutzt wird, müssen die Nutzer diesem vertrauen. Das
ist gerade bei Forks von bekannten Projekten schwierig. Und dann kann es
dazu kommen, dass das die Open Source Projekte verwaisen, veralten, und
schliesslich unbrauchbar werden. Das ist unter anderem mit den
ursprünglichen Open Source Versionen der ganzen Android Apps passiert:
https://arstechnica.com/gadgets/2018/07/googles-iron-grip-on-android-controlling-open-source-by-any-means-necessary/Nano schrieb:> Oftmals ist es auch so, dass die CS Nebenentwicklung Geld in die Kassen> der Firma bringt, die die CS Nebenentwicklung macht und durch die> Vollzeitentwickler fällt dann oftmals auch die ein oder andere> Verbesserung für die Open Source Version ab.
Manchmal, mit viel glück. Ansonsten muss man sich überlegen, wie man das
gleiche anders umsetzt, ohne Copyright Probleme zu bekommen. Und vom
Gewinn bekommt der Entwickler meist sowieso nichts ab.
Ich finde es sowieso nicht so prickelnd, wenn Firmen zu viel Einfluss
über Softwareprojekte bekommen. Diese verfolgen eventuell andere Ziele,
als der Rest der OSS Comunity. Ich finde, von Freier Software allein
kann man in der regel nicht leben, und Geld ist nicht weshalb ich sie
schreibe. Deshalb finde ich sollte Freie Software und dessen Derivate
frei bleiben und aus Eigeninteresse sowie gutem Willen entwickelt
werden, und nicht um irgendwelche Wirtschaftsinteressen zu erfüllen.
Nano schrieb:> Aber wenn du jetzt denkst, dass das jetzt wirklich ein Problem ist, dann> solltest du versuchen noch mehr Leute in der Open Source Community zu> erreichen.
Das ist einfacher gesagt, als getan.
DPA schrieb:> immerhin haben sie durch das CLA ja von allen die Einwilligung.
Das ist übrigens nicht anders als die FSF selbst. Bevor du bei GCC oder
Binutils irgendwas mehr als einen Dreizeiler beisteuern kannst, musst du
ihnen schriftlich die Rechte abtreten (Copyright-Abtretung, was es so im
europäischen Recht gar nicht gibt).
Nano schrieb:> Man kann so auch fleißige Programmierer rekrutieren. Es fehlt nur noch> eine automatisierte Möglichkeit deren Codequalität zu messen.
Es gibt schon Firmen, die sich darauf spezialisiert haben. Da kommt von
zeit zu zeit eine Mail, wo jemand nachfragt. Die Entlohnung, die sie
bieten, lohnt sich für mich als Schweizer aber nicht.
Der letzte Stallman Anhänger schrieb:> Den Benutzern ist die Freiheit egal geworden.
Mir nicht.
> Die Bloatware und Spyware der Smartphone-Hersteller nehmen die meisten Leute
einfach so hin.
Ich nicht. Ich habe mir ein librem5 devkit besorgt, und devuan (meine
Lieblings distro) darauf portiert, bzw. Ich arbeite noch daran:
https://github.com/Daniel-Abrecht/librem5-image-builder
Ich bin noch dabei von Google auf Duck Duck Go zu wechseln. Danach muss
ich nur noch den wechsel von Twitter auf Mastodon abschliessen, dann bin
ich Frei.
> Ist halt so. Ein problemloser Appstore ist wichtiger als die Freiheit> selbst zu entscheiden wer was mit unseren Geräten macht.
Finde ich nicht. Ich habe die Hoffnung noch nicht aufgegeben, und werde
an einer besseren Zukunft arbeiten.
Jörg W. schrieb:> DPA schrieb:>> immerhin haben sie durch das CLA ja von allen die Einwilligung.>> Das ist übrigens nicht anders als die FSF selbst. Bevor du bei GCC oder> Binutils irgendwas mehr als einen Dreizeiler beisteuern kannst, musst du> ihnen schriftlich die Rechte abtreten
Die FSF mag das zwar empfehlen, aber die wenigsten Projekte fordern
sowas, und ich würde sowas auch nicht tun. Bei einigen Projekten wie dem
Linux Kernel, ist es sogar explizit so geregelt, dass der beigesteuerte
Code weiterhin unter dem Copyright desjenigen, der ihn geschrieben hat,
steht. Und bei eigentlich allen anderen Projekten, die ich bisher
gesehen habe, setzt jeder seinen eigenen Namen bei der Copyright notice
ein. Ist Witzigerweise auch so im Beispiel, wie man die GPL verwendet:
https://www.gnu.org/licenses/gpl-howto.en.html
Sowie im Lizenztext selbst, Abschnitt 17:
https://www.gnu.org/licenses/gpl.txt
DPA schrieb:> Die FSF mag das zwar empfehlen
Du hast mich falsch verstanden: sie empfehlen das nicht, sondern sie
setzen das selbst so durch. Nennenswerte Teile in GCC oder Binutils
bekommst du ohne diese Copyright-Abtretung nicht durch, und der ganze
Zirkus geht nur über Papier und Sackpost (oder ging zumindest damals nur
so, als ich den Kram gemacht habe).
Damit meine ich jetzt nicht, dass das irgendeine Eigenschaft ihrer
Lizenz wäre, sondern etwas, was sie als Organisation so durchziehen –
so, wie es eben Microsoft für deren Organisation auch tut.
Was machen überhaupt die ganzen MS-Hasser , die einst bei GitHub sich
eingerichtet hatten ?
SourceForge hat mittlerweile auch GIT eingeführt , BitBucket ?
Ich hatte die Open Source Lizenz-Texte nie ganz begriffen ....
Es geht bei GNU und Linux-Quellcode in den Dateien nicht hervor , warum
der Copyright-Nehmer gewechselt hatte , usw.
Auch ist die gesamte Software-Branche etwas "verlogen" in meinen Augen ,
und es ist egal , ob Microsoft, GNU, BSD, Apple ....
Nie erfährt man , auf welchem Betriebssystem die Open Source Pakete
einst geschrieben , und erfolgreich kompilliert wurden ,
und beim Selberkompillieren kann man aus vielen negativen Erfahrungen
lernen , oder es ganz sein lassen , weil verschwendete Lebenszeit !
Immer nur : Download ↓↓↓
Es ist eigentlich auch egal, weil man eigentlich ständig zu spät kommt ,
bzw. der Entwicklung hinterherläuft .
Hau Wech schrieb:> Nie erfährt man , auf welchem Betriebssystem die Open Source Pakete> einst geschrieben , und erfolgreich kompilliert wurden
Erstens sollte man nie "nie" sagen (ein einzelnes Gegenbeispiel würde
das ja bereits ad absurdum führen), zweitens ist es natürlich bei gut
geschriebener Software auch gar nicht wichtig.
Ich erinnere mich an einen Film vom Ende der Neunziger, der das Szenario
des OP zu 100% beschreibt...
Ein riesen Software Konzern, dessen Chef erschreckend viel Ähnlichkeit
mit Bill Gates hat unterstützt Startups und stellt Infrastruktur bereit
nur um hinterher die Ideen abzuziehen.
Ich kann mich nur ums verrecken nicht mehr an den Namen erinnern... Es
war irgendein Schlagwort im Zusammenhang mit Kartellen und/oder zu
großen Konzernen. Es ist auf jeden Fall mal wieder Zeit den anzuschauen.
Jörg W. schrieb:> DPA schrieb:>> Die FSF mag das zwar empfehlen>> Du hast mich falsch verstanden: sie empfehlen das nicht, sondern sie> setzen das selbst so durch. Nennenswerte Teile in GCC oder Binutils> bekommst du ohne diese Copyright-Abtretung nicht durch
Stimmt wohl. So gesehen ist die FSF nicht weniger gefährlich für Freie
Software wie Microsoft. Als einziger Copyright holder von gcc, binutils,
glibc,... bedeutet auch, dass sie die Lizenzbedingungen jederzeit selbst
ändern könnten.
Dann muss ich wohl irgendwann mal auf clang umsteigen, das wollte ich
sowieso früher oder später tun. Nach dem Handyprojekt kann ich mein
Distro Projekt fortsetzen. Da nehme ich dann vermutlich gleich noch musl
stat glibc, aber das alles wird ein paar Jährchen brauchen. Obwohl, die
verwenden dann keine Copyleft Lizenz mehr. Einen Tod muss man wohl
sterben, wie man so schön sagt.
Was hat sich die FSF sonst noch so unter den Nagel gerissen? (Nur mal
so, dass ich für den Fall der Fälle, damit ich schonmal alternativen
raussuchen kann)
Hau Wech schrieb:> Was machen überhaupt die ganzen MS-Hasser , die einst bei GitHub sich> eingerichtet hatten ?
Das gleiche wie immer, auf mehrere Pferde setzen, dann ist es egal, wenn
eines abkratzt. Bei git kann man in der .git/config für ein remote
mehrere urls angeben. Dann hab ich ein Remote pro Service Provider + nen
origin remote auf alle. Ein git push, und es ist überall. Ich hab vor,
die Dinger auch noch mal selbst zu hosten, bzw. die Repos auf meinem
eigenen Server zuhause öffentlich zugänglich zu machen. Aber ich konnte
mich noch nicht für eine GitLab-Artige Software entschieden. Das ganze
anständig abzusichern und alle Pros und Cons der verfügbaren Software
abzuwägen ist aufwändig.
JJ schrieb:> Ich kann mich nur ums verrecken nicht mehr an den Namen erinnern...
Der Film würde mich auch interessieren, teil uns bitte mit, falls er dir
wieder einfällt.
Jörg W. schrieb:> Ich hielte es nicht einmal für> ausgeschlossen, dass sie irgendwann den Windows-Quellcode freigeben, so> wie es vor vielen Jahren Sun mit Solaris gemacht hat. Auch die hatten> erkannt, dass die Geheimhaltung des OS-Quellcodes sowieso nicht das ist,> was ihnen Geld in die Kasse spült. Mit Windows ist das ja im Grunde kaum> anders.
(ich hänge im Vergleich fest..)
Microsoft hat ja vor einiger Zeit die ersten DOS-Quellcodes freigegeben.
Toll, oder?
Die interessanten Quellcodes der Sysinternals leider nicht.
MS hat sich SPJ gekrallt
https://www.microsoft.com/en-us/research/people/simonpj/
(das war wohl das Ziel von SPJ, seitem kommt eigentlich nicht mehr viel
von dem)
SUN hatte Java..mit Java durch die Wirtschaftskrise)
Ubuntu dagegen..
(die Linuxe haben Ruby und Python Konsolen vorinstalliert - will sagen:
der bessere "Basic"-Ersatz?)
SUN: Open Office, aber an den Volkshochschulen gibt es Excel-Kurse (UND:
die Lizenzen da, also selbst bei einfachsten
Tabellenkalkulations-Programmen..(sch..))
Außerdem ist das bei MS so, dass man vermutlich gar nicht einfach so
Quellcodes veröffentlichen kann. Einige "Schätze" müssten die
(eventuell) selbst zuerst reversen.
Bei Windows und Dos machten viele kommerzielle Programme (und
Programmierer) die Suppe fett.
(bei > 5000 Mitarbeitern gehen ganze Landkreise oder Stadtteile
wirtschaftlich flöten)
(inklusive einige Unix-Schulen, je nachdem)
rbx schrieb:> Außerdem ist das bei MS so, dass man vermutlich gar nicht einfach so> Quellcodes veröffentlichen kann.
Das war bei Solaris gewiss nicht anders.
Jörg W. schrieb:> Das war bei Solaris gewiss nicht anders.
Dann kann man den Punkt schon mal abhaken. Allerdings kommen bei den
Tabellenkalkulationsprogrammen noch Patentschwierigkeiten(-geschichten
hinzu.
DPA schrieb:> Aber ich glaub irgendwie nicht mehr, das das der einzige Grund ist.> Abschnit 5.a:>> 5. Licenses.>> a. Copyright License. You grant Microsoft, and those who receive the
Submission
> directly or>> indirectly from Microsoft, a perpetual, worldwide, non-exclusive, royalty-free,> irrevocable license in the>> Submission to reproduce, prepare derivative works of, publicly display,
publicly
> perform, and distribute>> the Submission and such derivative works, and to sublicense any or all of the> foregoing rights to third parties
Und jetzt überlegen wir mal kurz was passieren kann, wenn es diese
Vertragsbedingung(en) nicht geben würde... Jemand hat, egal ob das
Projekt nun von/bei MS ist oder nicht, nach vielleicht ein paar Jahre
keinen Bock mehr oder verlässt ein Projekt im Streit und sagt, ich habe
das Urheberrecht und verbiete euch ab jetzt meinen Code weiter
einzusetzen... Geht nicht? Doch.
Ansonsten mal nachlesen wie es andere machen:
https://cla.developers.google.com/about/google-individual
1
"You hereby grant to Google and to recipients of software distributed by Google a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works."
"You hereby grant to the Foundation and to recipients of software distributed by the Foundation a perpetual, worldwide, nonexclusive, nocharge, royaltyfree, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and
2
distribute Your Contributions and such derivative works."
Arc N. schrieb:> Und jetzt überlegen wir mal kurz was passieren kann, wenn es diese> Vertragsbedingung(en) nicht geben würde... Jemand hat, egal ob das> Projekt nun von/bei MS ist oder nicht, nach vielleicht ein paar Jahre> keinen Bock mehr oder verlässt ein Projekt im Streit und sagt, ich habe> das Urheberrecht und verbiete euch ab jetzt meinen Code weiter> einzusetzen... Geht nicht? Doch.
Nein, das geht nicht. Du kannst eine Lizenz nicht mehr (einfach so)
zurück ziehen, wenn du sie erstmal gegeben hast. Du kannst neue
Versionen unter einer neuen Lizenz veröffentlichen, sofern du die
entsprechenden Rechte daran (oder zumindest des meisten davon) hast.
Jemand anderes könnte auch behaupten, es währe sein Code gewesen, und es
währe von jemand anderem unrechtmäßig veröffentlicht worden. Letzteres
ist, weshalb es die DCO gibt, und weshalb viele CLAs verwenden, wo man
bestätigt, die Rechte zu haben. Effektiv sollten diese aber keinen
Unterschied machen. So oder so wird im zweifel der betroffene Codeteil
erstmal entfernt und/oder ersetzt. Dann muss das Gericht entscheiden,
wer nun recht hat. Ja, man kann auch klagen ohne recht zu haben, und mit
dem richtigen Richter kann man je nachdem trotzdem durchkommen. Das in
CLAs häufig drin steht, dass dass man alle seine Rechte überträgt, dient
im Idealfall nur dazu, möglichst alle Rechte am gesammten Werk zu haben,
damit sich die Rechtslage vereinfacht, und somit Rechtsunsicherheiten zu
minimieren.
Arc N. schrieb:> und von der Linux-Foundation bzw. der Cloud Native Computing Foundation
Das sind zwei komplett andere Organisationen. Wem das Copyright an der
Webseite der Cloud Native Computing Foundation gehört, ist völlig egal.
Auch, das die Linux-Foundation andere Firmen und Projekte auf diese
weise Unterstützt, spielt hier erstmal keine rolle. Wobei diese Firmen
und deren Projekte aber der wahre Grund für das CLA bei der Cloud Native
Computing Foundation sein werden.
Die Linux-Foundation verwendet für ihre eigenen Projekte, insbesondere
den Linux Kernel, das DCO: https://developercertificate.org/, und
verlangt kein zusätzliches CLA oder dergleichen. Und im DCO gibt man
seine Rechte keiner spezifischen juristischen Person ab.
Der einzige Grund, warum Unternehmen CLAs verwenden, ist, weil Gerichte
und Richter mit herkömmlichen Lizenzen mehr Erfahrung haben. Und der
einzige Grund, warum man zum Schutz DCOs oder CLAs haben wollen würde,
ist, um mehr Rechtssicherheit zu haben, und nicht, weil das sonst
irgendwas an der Rechtslage ändern würde. (Ausser eben, wenn Unternehmen
die CLAs für was anderes verwenden wollen.)
Github sieht das übrigens ähnlich, und macht es explizit, dass man beim
beitragen von Code bestätigt, das unter der selben Lizenz zu tun, und
man bestätigt, dass man das darf. Auch wieder aus gründen der reduktion
von Rechtsunsicherheiten:
https://help.github.com/articles/github-terms-of-service/#6-contributions-under-repository-license
Sogar mit hinweis, das das vorher auch sowieso schon so war.
DPA schrieb:> Die Microsoft ♥ Linux Campagne dürfte jedem bekannt sein. Microsoft> unterstütze Open Source Projekte & Linux allgemein rein aus gutem> willen, habe die meisten & grössten Open Source Projekte, etc.
Das ist falsch. Microsoft möchte gerne Geld verdienen und nicht pleite
gehen. Ungefähr so wie knapp 100% aller anderen (normalen) Unternehmen
auch.
> Jedoch musste ich feststellen, dass Microsoft fordert, das bei> allen Repos unter der Microsoft Organisation bei Beiträgen einem> CLA zugestimmt wird.
Als das bei Ubuntu bekannt wurde, gab es einen heftigen, aber kurzen
Schrei. Seitdem machen das alle und es ist nichts besonderes mehr.
> Nach durchlesen des CLA kam ich aber zum Schluss, [...]
Jeder Fork hat genau die Rechte der Lizenz, also z.B. GPL.
Das entsprechende Unternehmen, mit dem du einen CLA abschließt, hat
darüber hinaus weitere Rechte - in erster Linie das Recht zur
Relizenzierung.
Dafür gibt es im Übrigen gute Gründe.
> Vor kurzem wurde ich aber auf eine neue Masche aufmerksam, die sich> "open core" nennt. Dabei ist die Grundsoftware Open Source, und hat auch> eine FOSS Lizenz, aber es gibt auch eine Enterprise Version mit einer> Closed Source Lizenz, mit mehr Features, Bug- und Security fixen.
Du hast schonmal von "Android" gehört?
Du hast schonmal von "VirtualBox" gehört?
Beide Projekte fahren dieses Modell und sind damit überaus erfolgreich.
> Jetzt kommt mir langsam der üble verdacht: Könnte es sein, das MS es> darauf abgesehen hat, abzuwarten, bis ein paar der Projekte unter der> Microsoft Github Organisation populär genug werden, um dann eine> Kostenpflichtige Closed Source Enterprise Version davon zu erstellen,> während das ursprüngliche Projekt verrottet?
Warum sollten sie das tun?
Es steht jedem Unternehmen frei, ein solches Projekt in der letzten
freien Version zu forken und die Enterprise-Features selbst (öffentlich
oder nichtöffentlich) zu entwickeln. Das Risiko, dass der Fork das
eigentliche Projekt ersetzt (wie z.B. MariaDB, LibreOffice), mag zwar
kleiner sein, ist aber trotzdem real.
Aus meiner Sicht geht es um Infrastruktur. Google verschenkt Android
Core ("AOSP"), fährt aber eine extrem harte Linie gegenüber Android.
Apple veröffentlicht MacOS X Core ("Darwin"), fährt aber eine extrem
harte Linie gegenüber OSX. Beide Unternehmen profitieren davon.
Warum sollte Microsoft nicht davon profitieren dürfen, .NET Core zu
veröffentlichen?
S. R. schrieb:> DPA schrieb:>> Die Microsoft ♥ Linux Campagne dürfte jedem bekannt sein. Microsoft>> unterstütze Open Source Projekte & Linux allgemein rein aus gutem>> willen, habe die meisten & grössten Open Source Projekte, etc.>> Das ist falsch. Microsoft möchte gerne Geld verdienen und nicht pleite> gehen. Ungefähr so wie knapp 100% aller anderen (normalen) Unternehmen> auch
Ich gebe lediglich wieder, worum es bei der Campagne geht. Das dies
nicht den tatsächlichen gründen entspricht, ist mir durchaus klar. Ich
dachte, das "rein aus gutem willen" währe ein ausreichend guter ironie
indikator.
S. R. schrieb:> Das entsprechende Unternehmen, mit dem du einen CLA abschließt, hat> darüber hinaus weitere Rechte - in erster Linie das Recht zur> Relizenzierung.
Nicht ganz, lediglich der sublizenzierung, das ist nicht ganz das selbe.
Relizenzierung gienge noch einen schritt weiter. Wäre aber vermutlich
auch mit CLA nicht machbar, selbst wenn es darin stünde. Allzugross ist
der unterschied aber auch wieder nicht.
S. R. schrieb:> Es steht jedem Unternehmen frei, ein solches Projekt in der letzten> freien Version zu forken und die Enterprise-Features selbst (öffentlich> oder nichtöffentlich) zu entwickeln. Das Risiko, dass der Fork das> eigentliche Projekt ersetzt (wie z.B. MariaDB, LibreOffice), mag zwar> kleiner sein, ist aber trotzdem real.
Bei Lizenzen ohne CopyLeft, in der regel ja. Bei denen mit aber nicht.
Wobei es da natürlich schlupflöcher gibt. Wenn es z.B. eine komplet
unabhängige Anwendung ist, die die andere aufruft. Oder wenn es nur ein
Interface nutzt, aber per default eine eigene Implementierung nutzt.
Oder wenn es ein Plugin ist und die verwendete Lizenz das erlaubt, etc.
S. R. schrieb:> Warum sollte Microsoft nicht davon profitieren dürfen, .NET Core zu> veröffentlichen?
Das ist was anderes. Da ist ja wohl jedem Klar, dass man sich damit an
Microsofts Ökosystem anklebt, ob nun OSS oder nicht. Ist ja nur ein Teil
des ganzen, und der rest wird später dann immer irgendwan wieder
"interressant".
Der letzte Stallman Anhänger schrieb:> Den Benutzern ist die Freiheit egal geworden. Die Bloatware und Spyware> der Smartphone-Hersteller nehmen die meisten Leute einfach so hin. Ist> halt so. Ein problemloser Appstore ist wichtiger als die Freiheit selbst> zu entscheiden wer was mit unseren Geräten macht.
Mööh, das war den Leuten noch nie nicht egal. Das Internet war nur in
den 90ern deutlicher geprägt von Enthusiasten. Den Durchschnittsbenutzer
interessiert es nicht, unter welcher Lizenz sein Instant Messenger
steht, solange er damit kostenlos Nachrichten verschicken kann.
Daniel A. schrieb:> S. R. schrieb:>> Es steht jedem Unternehmen frei, ein solches Projekt in der letzten>> freien Version zu forken und die Enterprise-Features selbst (öffentlich>> oder nichtöffentlich) zu entwickeln. Das Risiko, dass der Fork das>> eigentliche Projekt ersetzt (wie z.B. MariaDB, LibreOffice), mag zwar>> kleiner sein, ist aber trotzdem real.>> Bei Lizenzen ohne CopyLeft, in der regel ja. Bei denen mit aber nicht.
Hä?
Die .NET-Runtime (Core CLR) oder Visual Studio Code stehen unter
BSD-Lizenz, Typescript unter Apache-Lizenz. Damit darf ich die jederzeit
forken und selbstständig weiterentwickeln. Das gilt auch für die GPL,
denn sonst wäre es keine freie Software...
Es steht mir frei, den Linux-Kernel (GPL) zu forken.
Es steht mir frei, private Interfaces für meinen Fork zu entwickeln und
Programme dagegen linken zu lassen.
Es steht mir frei, diesen modifizierten Linux-Kernel unter anderem Namen
massiv zu verbreiten, unabhängig vom Original.
Google macht das und nennt das "android-kernel".
> S. R. schrieb:> Ist ja nur ein Teil des ganzen, und der rest wird später dann> immer irgendwan wieder "interressant".
Dank freier Lizenzen aber nie so interessant, wie du es dir gerade
vorstellst. :-)
S. R. schrieb:> Du hast schonmal von "VirtualBox" gehört?>> Beide Projekte fahren dieses Modell und sind damit überaus erfolgreich.
Bei VirtualBox sehe ich das eher nicht. Deren USB 2.0 ist seit Jahren
einfach nur grottig schlecht, gehört aber zum Close-Source-Anteil,
sodass sich auch niemand extern hinsetzen kann, das weiterzuentwickeln.
So ein „Halbe-Halbe-Modell“ funktioniert nur solange gut, solange es
auch wirklich Entwicklungskapazität dahinter gibt. Offenbar hat Oracle
das Modell aber einfach nur von Sun mit übernommen, ohne jedoch an
dieser Stelle noch was zu tun (und Betriebssysteme jenseits des
Mainstreams wie FreeBSD gucken sowieso in die Röhre).
Eigentlich schade drum. Wenn sie daran nichts machen, sollten sie auch
den Popo in der Hose haben, das einfach auch noch zu Opensourcen. Wird
aber mit Oracle ganz gewiss nicht passieren.
S. R. schrieb:> Daniel A. schrieb:>> S. R. schrieb:>>> Es steht jedem Unternehmen frei, ein solches Projekt in der letzten>>> freien Version zu forken und die Enterprise-Features selbst (öffentlich>>> oder nichtöffentlich) zu entwickeln. Das Risiko, dass der Fork das>>> eigentliche Projekt ersetzt (wie z.B. MariaDB, LibreOffice), mag zwar>>> kleiner sein, ist aber trotzdem real.>>>> Bei Lizenzen ohne CopyLeft, in der regel ja. Bei denen mit aber nicht.>> Hä?>> Die .NET-Runtime (Core CLR) oder Visual Studio Code stehen unter> BSD-Lizenz, Typescript unter Apache-Lizenz. Damit darf ich die jederzeit> forken und selbstständig weiterentwickeln. Das gilt auch für die GPL,> denn sonst wäre es keine freie Software...
Das Problem ist, dass bei einer Lizenz ohne CopyLeft oder sonstige Regel
die es verbietet, mit erlaubtem sublicensing, du Code, den du
hinzufügst, so lizenzieren könntest, dass die Nutzer dadurch für den
teil und für das daraus entstehende Produkt nur einen Teil der Rechte
haben, die die ursprüngliche Lizenz bietet. Beim sublicensing, sofern
nichts anderes in der ursprünglichen Lizenz steht, musst du nicht alle
Rechte weitergeben, du kannst dir Aussuchen, welche du weitergeben
willst. Mit anderen Worten, du kannst bei der Enterprise Version für die
hinzugefügten Teile rechte wie z.B. die der Veröffentlichung und
Weitergabe und des Modifizieren nicht mit Einschliessen. So lässt es
sich besser verkaufen, deshalb bevorzugen Firmen Lizenzen ohne Copyleft,
mehr Möglichkeiten. Wäre ja blöd, wenn man das verkauft, und die Leute
veröffentlichen das einfach so, wie z.B. bei der GPL.
S. R. schrieb:>> S. R. schrieb:>> Ist ja nur ein Teil des ganzen, und der rest wird später dann>> immer irgendwan wieder "interressant".>> Dank freier Lizenzen aber nie so interessant, wie du es dir gerade> vorstellst. :-)
Sofern man denn die richtige Lizenz für den Zweck gewählt hat.
S. R. schrieb:> Es steht mir frei, diesen modifizierten Linux-Kernel unter anderem Namen> massiv zu verbreiten, unabhängig vom Original.
Nur wenn Du alle Sourcen für Deinen privaten Kernel ebenfalls
mitlieferst denn jeglicher Code den Du da hinzugefügt oder geändert hast
muss dann ebenfalls unter der GPL stehen sobald Du das verbreiten
willst. Diese klitzekleine Lizenzauflage musst Du erfüllen wenn Du in
den Genuß des Linux-Codes kommen willst, geschenkt gibts nämlich nichts.
> musst Du erfüllen
Nicht unbedingt. Wenn du bei Valve oder Nvidia arbeitest, kannst du
sogar mit den GPL Fundamentalisten verhandeln. Ein Closed-Source Modul
schreiben und die erforderlichen Schnittstellen von EXPORT_SYMBOL_GPL
auf EXPORT_SYMBOL ändern lassen.
Der letzte Stallman Anhänger schrieb:> Ein Closed-Source Modul> schreiben und die erforderlichen Schnittstellen von EXPORT_SYMBOL_GPL> auf EXPORT_SYMBOL ändern lassen.
Ist aber riskant. Wenn es den Entscheidungsträgern mal etwas zu bunt
wird, hat man pech gehabt. Vor kurzem hatte zfsonlinux mal wieder ein
Problem:
* https://github.com/zfsonlinux/zfs/issues/8259 - Ein Symbol wuede
entfernt
* https://lkml.org/lkml/2019/1/10/733https://lkml.org/lkml/2019/1/11/44 - Greg Kroah-Hartman (quasi Linuses
Vertreter wenn es um den code geht, rein einflussmässig) sagt pech
gehabt
* https://lkml.org/lkml/2019/1/15/305 Leute, die ZFS wollen, und denen
der Rest egal ist, versuchen ihn erfolglos umzustimmen
Solche Sachen passieren ständig. In dem Fall konnte zfsonlinux die
Funktion, vermutlich mit kleineren Performance Einbussen, einfach
entfernen. Wäre das was zentraleres gewesen... dann wäre es das jetzt
gewesen für zfs auf Linux.
Es ist schon interessant, dieser stille Kampf zwischen Freier Software
und Freierer Software zu beobachten. Und alle wollen sie immer selbst
die Freisten sein. Ich sehe mich hier im GPL/CopyLeft Team, das ist die
echte Freiheit.
DPA schrieb:> Und alle wollen sie immer selbst> die Freisten sein. Ich sehe mich hier im GPL/CopyLeft Team, das ist die> echte Freiheit.
Die Freiheit des einen beschneidet halt manchmal die Freiheit des
anderen. Die Befreiung der Sklaven und die Garantie daß sie von nun an
frei bleiben beschneidet die Freiheit der Sklavenhändler. Die Befreiung
des Codes und die Garantie daß er frei bleibt beschneidet die Freiheit
derer die sich den Code gerne nehmen und wieder einsperren wollen.
Man muß bei solchen Konflikten dann halt abwägen wessen Freiheit einem
wichtiger ist. Mir zum Beispiel ist in den meisten Fällen die Freiheit
des Codes den ich irgendwann in die Freiheit entlassen habe wichtiger
als die Freiheit derer die ihn gerne wieder einsperren wollen würden.
Das fühlt sich auch etwas nachhaltiger an als ihn einfach nur
freizulassen aber keinerlei Vorkehrungen für den weiteren Verbleib zu
treffen. Immerhin hat man sich viel Mühe gegeben und Zeit investiert den
Code zu hegen und zu pflegen, da möchte man nicht daß er beim ersten
Schritt vor die Tür gleich in ein dunkles Loch gezerrt und mißhandelt
und ausgebeutet wird. Man gibt ihm also einen Freibrief [GPL] mit den
alle beachten müssen und der ihn vor sowas beschützt.
Bernd K. schrieb:> Das fühlt sich auch etwas nachhaltiger an als ihn einfach nur> freizulassen aber keinerlei Vorkehrungen für den weiteren Verbleib zu> treffen.
Die "Gegen-Sichtweise" dazu ist jedoch, dass diese Herangehensweise dazu
führen kann, dass manchen potenziellen Nutzern diese erzwungene Freiheit
(und der Zwang, sie zu vererben) zu weit geht, und sie stattdessen
lieber derartige Code außer acht lassen – und dann vielleicht eher die
zweitbeste Lösung bevorzugen, die derartige Forderungen nicht hat.
Gerade im Embedded-Bereich brauchst du einem Kunden mit einer GPL
einfach nicht kommen, die winken da nur ab. Apache/MIT/BSD geht gerade
noch, je nach Rechtsabteilung.
Jörg W. schrieb:> Die "Gegen-Sichtweise" dazu ist jedoch, dass diese Herangehensweise dazu> führen kann, dass manchen potenziellen Nutzern diese erzwungene Freiheit> (und der Zwang, sie zu vererben) zu weit geht
Und, bist du ein Mensch/Lebewesen, oder eine Firma/sonstiges Konstrukt?
Ich bin ein Mensch. Meine Programme sollen Mir und all meinen anderen
Mitmenschen von nutzen sein, für immer.
Deshalb ist es mir scheiss egal, wenn Firmen ihre Eigeninteressen nicht
durchsetzen können. Ich bin keine Firma, und die Firmen (sollten) sich
weiterhin versuchen gegenseitig zu übertrumpfen. Ob sie ein Freies
Programm nun nutzen wollen oder gar stehlen können, oder nicht, sollte
auf die Wirtschaft keinen Einfluss haben, denn kein
Wirtschaftsteilnehmer wird bevorzugt, und damit habe auch ich und meine
Mitmenschen keinen Vorteil, wenn man ihnen die Möglichkeit gibt.
Andererseits ist es Problematisch, wenn man es tut. Unsere Freiheit und
Privatsphäre, letzten Endes vielleicht sogar unser aller Leben, stehen
auf dem Spiel.
Ist es nicht eher in unserem Interesse, für das Wohl der Menschheit zu
sorgen, als für das Wohl der Unternehmen? Sollten wir unsere Zukunft
wirklich wegwerfen, um an den Käse in den Mausefallen der Firmen zu
kommen?
DPA schrieb:> Meine Programme sollen Mir und all meinen anderen Mitmenschen von nutzen> sein, für immer.
Oder im Zweifelsfalle auch niemandem, weil sie unter diesen Umständen
niemand zu nutzen gewillt ist? Das ist ja letztlich die Frage dabei.
Mir ist es meist lieber, wenn sie andere einfach nutzen können. Sollten
sie damit einen geschäftlichen Vorteil haben, ist das in Ordnung für
mich – ich veröffentliche den Code nicht aus irgendeiner Religion
heraus, sondern weil ich es sinnvoll finde, dass auch andere ihn
benutzen dürfen. Wer das geschäftlich nutzen will, wird ohnehin vor
allem seine eigene Arbeitsleistung dann für den Support gegenüber seinen
Kunden einbringen müssen.
Einfachere Codeteile werfe ich daher unter „Beerware license“ heraus,
das ist der geringste Overhead und die wenigsten Restriktionen.
Bei allen Projekten, an denen man irgendwie „nur“ mitarbeitet, richte
ich mich für meine Beiträge komplett nach dem, was im jeweiligen Projekt
üblich ist, ob das nun GPL, BSD, MIT, Apache oder sonstwas ist.
Jörg W. schrieb:> DPA schrieb:> Meine Programme sollen Mir und all meinen anderen Mitmenschen von nutzen> sein, für immer.>> Oder im Zweifelsfalle auch niemandem, weil sie unter diesen Umständen> niemand zu nutzen gewillt ist? Das ist ja letztlich die Frage dabei.
Warum sollte mich das kümmern, ob jemand das nutzen will ist nicht meine
entscheidung. Ausserdem kenne ich keine (natürliche) Person für die
das einen Grund darstellen würde, es nicht zu nutzen.
> Mir ist es meist lieber, wenn sie andere einfach nutzen können.
Aber das lönnen sie doch! Viel mehr noch als andernfalls!
> Sollten> sie damit einen geschäftlichen Vorteil haben, ist das in Ordnung für> mich – ich veröffentliche den Code nicht aus irgendeiner Religion> heraus, sondern weil ich es sinnvoll finde, dass auch andere ihn> benutzen dürfen.
Soso, sobald es dem Gemeinwohl dienen soll, muss es eine unsinnige
Religion sein. Vergessen wir mal nicht, dass das nichtmehr
uneingeschränkt benutzt werden darf, wenn es erstmal Closed Source/Open
Core ist. Klar, der alte verrottete Teil schon noch, wenn dich das
wieder beruhigt schlaffen lässt. So will ich meine Software nicht
gebraucht sehen, und langfristig nützt das auch keinem.
> Wer das geschäftlich nutzen will, wird ohnehin vor> allem seine eigene Arbeitsleistung dann für den Support gegenüber seinen> Kunden einbringen müssen.
Nun, diese Dienstleistung lässt sich auch so für eigentlich alles immer
gut anbieten.
DPA schrieb:> Soso, sobald es dem Gemeinwohl dienen soll, muss es eine unsinnige> Religion sein.
Dient sie nicht wirklich vielmehr deiner ganz persönlichen Eitelkeit,
und das „Gemeinwohl“ ist einfach nur vorgeschoben, weil es damit so
schön klingt?
Ich denke nicht, dass ein paar Codezeilen von mir die Welt retten
würden, da muss ich nicht so tun, als müsste ich diese Weltenrettung
dann auch noch allen Nachkommen für die nächsten 1000 Jahre erhalten.
Wenn die Codezeilen überhaupt jemandem irgendwas helfen, freut es mich
– aber ich schreibe das ja in erster Linie, um meine Probleme zu
lösen. Dass es auch die Probleme anderer lösen könnte, indem ich es
freigebe, ist ein netter Nebeneffekt.
(Code nur für andere schreibe ich auch, aber dafür werde ich dann
bezahlt.)
Na, ein wenig kommt es ja schon noch auf die innere Haltung an.
Ich hätte mich aber über Solaris/Sun Studio retten ziemlich gefreut
(cooles ZFS, Java Entwicklung, Fortran (sogar Ruby on Rails),
Virtualisieren lernen und so..)
(Zitat aus der OpenSolaris Bible:
"We also want to acknowledge the thousands of engineers over the past 40
years who have contributed to the code that is now OpenSolaris")
Jörg W. schrieb:> DPA schrieb:>> Soso, sobald es dem Gemeinwohl dienen soll, muss es eine unsinnige>> Religion sein.>> Dient sie nicht wirklich vielmehr deiner ganz persönlichen Eitelkeit,> und das „Gemeinwohl“ ist einfach nur vorgeschoben, weil es damit so> schön klingt?
Definitiv nicht. Es ist ja wohl unbestreitbar, das alle immer abhängiger
von proprietären Diensten werden. Ich tue halt was dagegen, und deshalb
soll ich jetzt Eitel sein?
> (Code nur für andere schreibe ich auch, aber dafür werde ich dann> bezahlt.)
Das gute zeug, bei dem sich die GPL lohnen würde, verkaufst du also, das
ist ja auch nicht falsch.
Aber wenn das mal jemand anders handhabt beschimpfst du ihn einfach als
Eitlen Religionswahnsinnigen? Für wen hälst du dich eigentlich? (Das war
eine Rethorische Frage).
Vielleicht kannst du es ja mit sachlichen Argumenten versuchen. Warum
sollte es langfristig besser für alle Menschen sein, keine CopyLeft
lizenz zu verwenden, obwohl Firmen keinen wirtschaftlichen Vorteil
gegenüber anderen Firmen dadurch erlangen, diese den code genausogut
selbst erstellen oder kaufen oder einfach wieder freigeben könnten, und
dies den Code langfristig verwaisen lassen könnte, womit er dan weniger
läuten nützt?
Daniel A. schrieb:> Definitiv nicht. Es ist ja wohl unbestreitbar, das alle immer abhängiger> von proprietären Diensten werden.
Keineswegs. Wenn ich mir den heute vorhandenen Pool an FOSS ansehe,
dann ist das um Welten besser als vor 30 … 40 Jahren.
> Ich tue halt was dagegen, und deshalb> soll ich jetzt Eitel sein?> Vielleicht kannst du es ja mit sachlichen Argumenten versuchen. Warum> sollte es langfristig besser für alle Menschen sein, keine CopyLeft> lizenz zu verwenden
Das habe ich doch gar nicht behauptet oder verlangt.
Wer eine solche Lizenz gern benutzen mag, soll sie doch nehmen – aber er
soll bitte aufhören, selbige in fast religiösem Fanatismus als die
Rettung der Welt anzupreisen und alle anderen davon überzeugen zu
wollen, dass sie es ihm gleich tun müssten. Ich habe dazu eine andere
Meinung, deshalb verteufele ich sie nicht (ein Teil meiner FOSS-Werke
steht auch unter GPL), aber wenn meine nicht-GPL-Software (bspw.
avr-libc) in proprietären Projekten verschwindet, weil sich eine kleine
Bude, die irgendwas mit AVRs baut, keine GPL ans bein binden würde (und
all ihr Know-How in die Öffentlichkeit stellt), dann bin ich darüber
nicht traurig. Sollen sie machen, auch sie benutzen letztlich meine
Software.
Ok, Sorry, ich hab's wohl auch etwas übertrieben.
Ich muss zugeben, ich habe auch einige Projekte, die ich unter einer
nicht-copyleft Lizenz (meistens MIT), veröffentlicht habe, weil es mir
dort sinvoller erschien.
Jörg W. schrieb:> Daniel A. schrieb:>>> Definitiv nicht. Es ist ja wohl unbestreitbar, das alle immer abhängiger>> von proprietären Diensten werden.>> Keineswegs. Wenn ich mir den heute vorhandenen Pool an FOSS ansehe,> dann ist das um Welten besser als vor 30 … 40 Jahren.
Das ist wahr. Aber ich kenne leider immer noch nur wenige die diese
einsetzen. Ich kenne einen Designer, der schwört auf Photoshop auf Mac.
Meine Eltern kann ich nicht von Windows abbringen, sie wollen es gar
nicht erst versuchen. Alle die ich kenne nutzen Android oder IPhones,
und kommunizieren über WhatsApp, Facebook, Twitter und co. Auf der
Arbeit und bei Schulen sind die Arbeitsrechner alle auf Windows.
Microsoft Word ist immer noch teil des IT Unterrichts. etc.
Zugegeben, es ist viel Aufwand alles umzustellen, ich bin selbst noch
nicht ganz fertig. Trotzdem hoffe ich, dass das irgendwann besser wird.
Daniel A. schrieb:>> Keineswegs. Wenn ich mir den heute vorhandenen Pool an FOSS ansehe,>> dann ist das um Welten besser als vor 30 … 40 Jahren.>> Das ist wahr. Aber ich kenne leider immer noch nur wenige die diese> einsetzen.
Finde ich nicht, aber vielleicht bin ich da in den „falschen“ Kreisen
unterwegs. :)
> Ich kenne einen Designer, der schwört auf Photoshop auf Mac.
Was sicher einen Grund hat.
Apple baut wirklich gute Hardware, und wenn jemand einen ladenneuen
aktuellen Laptop haben will, der kein Windows benutzt und trotzdem
Hersteller-Support fürs OS hat, dann ist ein Mac oft die bessere Wahl
als Linux. Linux auf einem 2 Jahre alten Laptop hat dann viel bessere
Chancen.
Letztlich ist der Mac seit OSX untendrunter ein recht gut aufgeräumtes
UNIX.
> Meine Eltern kann ich nicht von Windows abbringen, sie wollen es gar> nicht erst versuchen.
Meine Schwiegereltern benutzen seit geraumer Zeit ein Linux und freuen
sich darüber, dass wir sie da viel besser fernwarten können als noch zu
Windows-Zeiten. Ein, zwei Windows-only-Anwendungen laufen dann auf dem
virtualisierten alten Windows2000 in einer VM.
> Alle die ich kenne nutzen Android oder IPhones,> und kommunizieren über WhatsApp, Facebook, Twitter und co.
Android ist doch Linux. :-)
Statt Whatsapp kann man den Leuten Telegram nahelegen. Signal ist auch
nett, aber ausschließlich Ende-zu-Ende verschlüsselt hat halt auch
Nachteile. Man kommt dann an alte Chats gar nicht mehr ran. Telegram
bietet eine ganz gute Balance, und seit ihrem Kampf gegen die russische
Aufsichtsbehörde nehme ich ihnen durchaus ab, dass sie nicht einfach so
jedem x-beliebigen Geheimdienst einen Zugang darauf einräumen.
> Auf der> Arbeit und bei Schulen sind die Arbeitsrechner alle auf Windows.
Auf der Arbeit bei uns schon lange nicht mehr.
> Microsoft Word ist immer noch teil des IT Unterrichts. etc.
Wobei das ja eher nur ein Stellvertreter für "Officartige
Textbearbeitung" ist; wer das mal gemacht hat, kommt auch mit
Open/Libreoffice zurecht.
Aber ja, in den Schulen hält Microsoft immer noch mächtig den Fuß in der
Tür, natürlich auch mit schönen Schul-Konditionen.
> Zugegeben, es ist viel Aufwand alles umzustellen, ich bin selbst noch> nicht ganz fertig. Trotzdem hoffe ich, dass das irgendwann besser wird.
Ich musste mich nie umstellen. OK, von FreeBSD auf auch ein wenig Linux
vielleicht. :)
Jörg W. schrieb:> Apple baut wirklich gute Hardware
Dass soll ja stark abgenommen haben. Immer mehr, inklusive SSD, auf dem
Mainboard eingelötet. Akkus so eingeklebt, dass man sie nicht
unbeschädigt herausnehmen kann. Die Anschlüsse sind auch alle weg.
Anscheinend versuchen sie auch immer wieder, Reparaturen zu verhindern,
indem sie, unter anderem, mit Hardware Herstellern sich einigen, dass
diese gewisse Chips nur an sie Verkaufen, indem sie beim Zoll alles
abfangen lassen, was nach Apple teil aussieht, selbst wenn es ein
Original teil ist, und indem sie Reparaturen als Fälschungen versuchen
darzustellen. Die offiziellen Reparaturstellen sollen auch total
überteuert sein, und bei den Reparaturen teils auch noch pfuschen, wenn
sie nicht gleich den ganzen Mac ersetzen. Ersatzteile dürfen von diesen
auch nicht herausgegeben oder verkauft werden. Dazu kommen dann noch
Technische Massnahmen, wie man z.B. bei den TouchID Sensoren, die sie
bei I Phones nachträglich kaputt machten, sah. Und auf den neusten Macs
kann man kein Linux mehr installieren, ist nun ganz abgeschottet. Es ist
kein Key dafür mehr dabei, eigene kann man nicht installieren, und die
Option, den check auszuschalten, mit der Apple das rechtfertigt,
funktioniert anscheinend nicht, aber Apple behauptet einfach, das müsse
wohl ein Linux Problem sein, wie üblich, aber das ist halt schwierig zu
wiederlegen.
Den Leuten geht es doch hauptsächlich um das Apple Ökosystem, das OS ist
nun mal auf die PCs abgestimmt.
Jörg W. schrieb:>> Alle die ich kenne nutzen Android oder IPhones,>> und kommunizieren über WhatsApp, Facebook, Twitter und co.>> Android ist doch Linux. :-)
Android ist ein Fork davon. Wenn man das ganze System betrachtet, macht
Google dort alles anders, teils auch bei Kernel Geschichten. Anderes
Grafiksubsystem (Gralloc + SurfaceFlinger), andere IPC Lösung (Binder),
anderer Display Server, eigene c library, etc. Abgesehen von den
Smartphone Herstellern, die alles immer mehr abschotten, ist das andere
Grafiksubsystem das Hauptproblem, wenn man ein normales Linux auf einem
Handy laufen lassen will. Obwohl, dass soll sich angeblich langsam
bessern. Selbst angebliche Linux Phones, wie z.B. Ubuntu Phones mit
Ubuntu Touch, haben einen eigenen Display Server für Gralloc, brauchen
OTA Updates statt nen Package Manager zu verwenden, und sind immer noch
stark abgeschottet. So oder so findet man eigentlich keine Android
Phones, die komplett ohne proprietäre Dienste und Anwendungen auskommen
würden, oder wo man einfach so sein eigenes System drauf packen kann.
Deshalb habe ich mir ein Librem5 + DevKit gekauft, dort kann ich dann
tatsächlich mein System selbst aussuchen & aufbauen, und bin nicht
weiter eingeschränkt. Sogar am Bootloader kann ich herumbasteln.
Jörg W. schrieb:>> Zugegeben, es ist viel Aufwand alles umzustellen, ich bin selbst noch>> nicht ganz fertig. Trotzdem hoffe ich, dass das irgendwann besser wird.>> Ich musste mich nie umstellen. OK, von FreeBSD auf auch ein wenig Linux> vielleicht. :)
Ich versuche nicht nur, nur noch freie Software zu verwenden, sondern
auch, möglichst keine Abhängigkeit zu einzelnen externen Dienstleistern
mehr zu haben, zumindest, wo es vermeidbar ist. Und selbst bei freier
Software vermeide ich solche, die zu viel lock-in potential haben. Das
ist schon ziemlich aufwendig.
DPA schrieb:> Jörg W. schrieb:>> Apple baut wirklich gute Hardware>> Dass soll ja stark abgenommen haben.
Kann ich von dem, was ich mitbekommen habe, nicht bestätigen.
> Immer mehr, inklusive SSD, auf dem> Mainboard eingelötet. Akkus so eingeklebt, dass man sie nicht> unbeschädigt herausnehmen kann.
Ja, und? Wenn ein 2011 gekauftes Macbook auch 2019 noch mit dem ersten
Akku vernünftig läuft, dann muss man den eben auch gar nicht wechseln.
Dann kann er von mir aus auch eingeklebt sein.
Leute, die nur 08/15-Notebooks kennen, bei denen spätestens nach 3
Jahren der Akku platt ist, können sich das allerdings nicht vorstellen …
> Ersatzteile dürfen von diesen> auch nicht herausgegeben oder verkauft werden.
Weiß ich nicht. Was in den vielen Jahren kaputt gegangen ist, war zuerst
das DVD-Laufwerk, das konnte man problemlos bei ebay kaufen und selbst
tauschen. Danach war die Festplatte hinüber, auch da eine
08/15-SATA-Platte gekauft und eingebaut. Grundinstallation direkt aus
dem BIOS über das Internet …
(Wie es mit iPhones aussieht, habe ich allerdings keine eigenen
Erfahrungen.)
> Und auf den neusten Macs> kann man kein Linux mehr installieren, ist nun ganz abgeschottet.
Ganz ehrlich: wenn ich mich für so'ne teure Kiste entscheide, dann doch
nicht, um danach ein Linux zu installieren. Dafür kann ich einen Laptop
für einen viel geringeren Preis kaufen.
> Den Leuten geht es doch hauptsächlich um das Apple Ökosystem, das OS ist> nun mal auf die PCs abgestimmt.
Ja, ist es. Mit dem letztes Jahr neu installierten und damals aktuellen
Betriebssystem fühlt sich die alte Kiste übrigens immer noch genauso
flott an wie damals, als sie neu war. Das bekommst du nach so vielen
Softwareneuerungen wohl weder mit Linux noch Windows in der Form hin.
> Android ist ein Fork davon. Wenn man das ganze System betrachtet, macht> Google dort alles anders, teils auch bei Kernel Geschichten. Anderes> Grafiksubsystem (Gralloc + SurfaceFlinger), andere IPC Lösung (Binder),> anderer Display Server, eigene c library, etc. Abgesehen von den> Smartphone Herstellern, die alles immer mehr abschotten, ist das andere> Grafiksubsystem das Hauptproblem, wenn man ein normales Linux auf einem> Handy laufen lassen will.
Dann nimm doch ein Handy, wo du LineageOS drüberbügeln kannst. Die
gibt's auch zur Genüge, und du bekommst einen Opensource-Nightly-Build.
Dass man für andere Grafikhardware andere Ansteuerung braucht, ist ja
wohl ziemlich normal … es war vor 20 Jahren auf dem PC nicht ganz
einfach, ausreichend Doku für selbtgeschriebene Grafiktreiber zu
bekommen – ich habe mal ein Weilchen damals bei XFree86 mitgearbeitet.
> So oder so findet man eigentlich keine Android> Phones, die komplett ohne proprietäre Dienste und Anwendungen auskommen> würden, oder wo man einfach so sein eigenes System drauf packen kann.
LineageOS kommt als Build völlig ohne Google-Tools daher, die musst du
separat dazu auswählen. Dabei kannst du dir aussuchen, wieviel du von
denen nehmen willst.
Wenn du dich komplett gegen Google entscheidest, hast du aber eben auch
keinen Playstore, und damit fehlt dir die App-Vielfalt, die du sonst
hast. Aber machbar wäre es.
Jörg W. schrieb:> Dass man für andere Grafikhardware andere Ansteuerung braucht, ist ja> wohl ziemlich normal
Es geht aber nicht um die Ansteuerung der Grafikhardware durch den
Treiber, sondern um die Interaktion des Userspace mit dem
Graphikinterface des Kernels. Das grundlegende Interface sollte immer
das gleiche sein, erweitern kann man es je nach Treiber ja trotzdem.
Dass sich Userspace Anwendungen nicht unbedingt um solchen kram kümmern
müssen, ist der von Sinn Kernel Schnittstellen. Eigentlich ist diese art
der Abstraktion in der regel sogar der Sin eines Interface allgemein.
Zugegeben, dri/mesa ist auch nicht besonders gut darin, es gibt zwar
mittlerweile den modesetting Treiber und dumb Buffers, aber ob das
Funktioniert ist immer eine Glückssache. Dass da einfach ohne Absprache
oder mithilfe bei mainline gralloc nebenher entwickeln wurde, statt bei
dri zu helfen, war einfach unverantwortlich. fbdev war in der Hinsicht
besser, da man dort immer auf die selbe weise, und recht einfach, etwas
anzeigen konnte, auch wenn es andere nachteile hatte.
Bei anderen Interfaces ist das übrigens auch kein Problem. Alle Audio
Sachen gehen letztendlich über alsa (ja, auch wenn Pulseaudio, jack,
oder das OSS Kompatiblitätslayer dazwischengeschalten wird, es spielt
keine rolle.) USB hat libusb, ttys haben alle das selbe Interface, alle
Netzwerk Sachen, Packetbasierten Datenverbindungen, etc. gehen über die
selben Socket Interfaces, etc.
DPA schrieb:> Jörg W. schrieb:>> Dass man für andere Grafikhardware andere Ansteuerung braucht, ist ja>> wohl ziemlich normal>> Es geht aber nicht um die Ansteuerung der Grafikhardware durch den> Treiber, sondern um die Interaktion des Userspace mit dem> Graphikinterface des Kernels.
Früher™ machte das noch jeder X-Server selbst direkt auf der Hardware.
Dass sowas in den Kernel gewandert ist, war erst viel später. Wenn sich
nun für andere herausstellt, dass das entsprechende Kernel-API nicht
ihren Anforderungen entspricht, dann ist es doch recht und billig, dass
sie dafür halt ein neues API aufsetzen. Gerade bei Linux sind APIs ja
sowieso nie in Stein gemeißelt und ändern sich immer mal wieder.
> Wenn du dich komplett gegen Google entscheidest, hast du aber eben auch> keinen Playstore, und damit fehlt dir die App-Vielfalt, die du sonst> hast. Aber machbar wäre es.
Ich finde, man kommt auch ganz gut ohne das ganze Google-Zeugs aus.
Zumindest gilt das für mich. Wenn man in Fdroid das IzzyOnDroid
Repository hinzufügt, ist eigentlich das meiste abgedeckt. Und über den
Yalp-Store könnte man auch theoretisch (kostenlose) Apps aus dem
Playstore herunterladen.
Wenn man z.B. TWRP startet, hat man ja ein mehr oder weniger
funktionelles Linux-System, was sich via ADB shell auch recht
komfortabel remote bedienen lässt.
Ich hatte auch zwischenzeitlich versucht, eigene native Programme zu
schreiben und dann von dort aus zu starten, aber außer Bildschirm, Touch
und Remote Console scheint da noch nicht viel initialisiert zu sein.
Jörg
Jörg W. schrieb:> Gerade bei Linux sind APIs ja> sowieso nie in Stein gemeißelt und ändern sich immer mal wieder.
Das kommt ganz drauf an. Bei allem in /sys gibt es eigentlich keine
Einschränkungen. Bei den restlichen, bereits bestehenden userspace APIs
ist die policy aber eigentlich, dass diese kompatibel zu den momentanen
Anwendungen bleiben sollen, also nichts kaputt gehen darf. Ausserdem
will man durchaus neue userspace APIs vermeiden falls möglich, da diese
bei der Weiterentwicklung zu problematischen Altlasten führen können,
die man noch weiter Supporten muss, weil es Anwendungen gibt, die diese
Verwenden. Deshalb gibt es z.B. immer noch das das OSS Interface, das im
Kernel anscheinend intern über das alsa subsystem umgesetzt ist.
Mittlerweile gibt es glaub ich auch einen userspace wrapper. Aus
ähnlichen gründen gibt es auch angaben in /proc von Dingen, die es in
der Form eigentlich gar nicht mehr gibt. Da wird eigentlich nur was
entfernt oder geändert, wenn es über ein paar Jahre als veraltet
markiert war, nichts kaputt machen kann, oder falls es
Sicherheitsrelevant ist. Obwohl, bei DRI scheinen manchmal andere regeln
zu gelten.
----
Unabhängig davon, Ich hab gerade gesehen, warum Alsa OSS abgelöst hat,
anscheinend ist OSS auch mal kurz die proprietarisierung widerfahren:
https://en.wikipedia.org/wiki/Open_Sound_System#Free,_proprietary,_free
DPA schrieb:> Unabhängig davon, Ich hab gerade gesehen, warum Alsa OSS abgelöst hat
Wobei es aber eben auch ein wenig symptomatisch für Linux ist, dann
gleich ein neues, inkompatibles API zu entwerfen. Wie im Artikel
ebenfalls beschrieben ist, hat FreeBSD stattdessen einfach auf dem
existierenden API weitergearbeitet und sich nicht drum geschert, dass
4Front da eine kommerzielle Variante parallel angeboten hat.
Hätte man auch bei Linux so handhaben können.
Dass das alte X11-API sich für Smartphones mit Touchbedienung nicht
sonderlich gut eignet, und man deshalb was anderes implementiert hat,
kann ich verstehen. Apple hatte beim Entwurf von OSX auch mal X11 in
Erwägung gezogen, aber eben dann doch lieber mit Quartz eine neue
Grafikschnittstelle implementiert, um ihre Anforderungen umzusetzen,
statt ein Dutzend weiterer X11 extensions zusammenzunotnageln.
Jörg W. schrieb:> DPA schrieb:>> Unabhängig davon, Ich hab gerade gesehen, warum Alsa OSS abgelöst hat>> Wobei es aber eben auch ein wenig symptomatisch für Linux ist, dann> gleich ein neues, inkompatibles API zu entwerfen. Wie im Artikel> ebenfalls beschrieben ist, hat FreeBSD stattdessen einfach auf dem> existierenden API weitergearbeitet und sich nicht drum geschert, dass> 4Front da eine kommerzielle Variante parallel angeboten hat.>> Hätte man auch bei Linux so handhaben können.
Hätte man das getan, währen die neuen OSS Treiber proprietär geblieben,
und wir hätten vermutlich heute bei PCs unter Linux keinen
funktionierenden Sound mehr, oder zumindest nicht ohne doppelte Arbeit.
> Dass das alte X11-API sich für Smartphones mit Touchbedienung nicht> sonderlich gut eignet, und man deshalb was anderes implementiert hat,> kann ich verstehen.
DRM/DRI/mesa liegt eine schicht tiefer. X11 nutzt mesa. Wayland nutzt
Mesa. Vor kurzem hat Google auch mal das erste Phone vorgestellt, das
angeblich auf DRI aufsetzt. SurfaceFlinger hätte man von Anfang an
problemlos auf DRI oder mesa aufsetzen lassen können, wenn man halt dort
etwas mitgeholfen hätte, und nicht etwas eigenes (gralloc), gemacht
hätte. Immerhin wurde DRI in dem Zeitraum noch aktiv weiterentwickelt
und unterlief noch grösseren Design Änderungen.
DPA schrieb:> Hätte man das getan, währen die neuen OSS Treiber proprietär geblieben,> und wir hätten vermutlich heute bei PCs unter Linux keinen> funktionierenden Sound mehr
FreeBSD widerspricht dieser These.
> oder zumindest nicht ohne doppelte Arbeit.
Die hat man ja mit ALSA erst recht gehabt, ist also auch kein Argument.
Gerade an OSS kann man ganz gut sehen, dass es eben nicht einfach mal so
damit getan ist, nur weil's die Lizenz hergibt, zu versuchen, so etwas
plötzlich als proprietäre Software zu vermarkten. Da muss man schon
mächtig was an Mehrleistung bieten, bevor dafür Leute gewillt sind, Geld
auszugeben. Dabei hatte 4Front damals nicht so schlechte Karten, denn
ihre Treiber konnten deutlich mehr als das, was an Opensource bis dato
zustande gekommen war.
Jörg W. schrieb:> DPA schrieb:>> Hätte man das getan, währen die neuen OSS Treiber proprietär geblieben,>> und wir hätten vermutlich heute bei PCs unter Linux keinen>> funktionierenden Sound mehr>> FreeBSD widerspricht dieser These.
FreeBSD hatte auch damals schon viel weniger Einfluss als Linux. Der
markt war für 4Front ohne Linux nicht gross genug, aber mit Linux hätte
das sicher anders ausgesehen.
Jörg W. schrieb:>> oder zumindest nicht ohne doppelte Arbeit.>> Die hat man ja mit ALSA erst recht gehabt, ist also auch kein Argument.
Das alsa Interface musste nur einmal erstellt werden, und ein paar
Treiber portiert. Nach dem initialen Aufwand, gab es keinen erhöhten
Aufwand mehr. Hätte man Stattdessen zukünftig immer proprietäre Treiber
reverseengineeren müssen, oder noch schlimmer, versuchen müssen es aus
Lizenzgründen immer anders zu lösen, hätten immer mindestens 2 Linux
Treiber geschrieben, einer proprietäre, und einer offen mit
Verrenkungen. Das ist nicht nur doppelter Arbeitsaufwand, es hätte den
offenen Treibern geschadet. Man hätte eine ähnliche Situation wie heute
bei den Grafiktreibern gehabt. Das finde ich nicht sinnvoll.
Jörg W. schrieb:> Gerade an OSS kann man ganz gut sehen, dass es eben nicht einfach mal so> damit getan ist, nur weil's die Lizenz hergibt, zu versuchen, so etwas> plötzlich als proprietäre Software zu vermarkten.
Die Leute sind (oder waren?) eben nicht blöd. Sie konnten es selbst
besser und Frei für alle machen, also haben sie es getan. Alsa spielt
nun in einer ganz anderen Liga.
> Da muss man schon mächtig was an Mehrleistung bieten
Das ändert sich so langsam aber sicher.
Die Ansteuerung der Soundchips konnten wir noch selbst rekonstruieren.
Wenn der Chiphersteller ein NDA und Closed-Source verlangte, konnten wir
alles nötige mit Reverse-Engineering heraus finden.
Die Wlan-Chips waren schon an er Grenze. Bei den heutigen Embedded
Processors oder den 3D-Graphicchips haben wir ohne Doku des Herstellers
keine Chance mehr.
Inzwischen kann sich eine Firma wie 4Front ganz einfach durchsetzen. Die
unterschreiben ein NDA und der Hardwarehersteller verhandelt darauf hin
nicht mehr mit den Entwicklern freier Software.
DPA schrieb:>> FreeBSD widerspricht dieser These.>> FreeBSD hatte auch damals schon viel weniger Einfluss als Linux.
Es ging um deine Behauptung, dass Linux mit dem OSS-API keinen
funktionierenden Sound mehr hätte.
Das ist schlicht falsch, und als Beispiel dafür habe ich FreeBSD
angebracht.
Aber mittlerweile gebe ich es auf, mit dir hier zu diskutieren. Du lässt
ausschließlich deine vorgefertigte Meinung gelten. Ist OK, dann bleib
einfach dabei, aber da brauchen wir nicht weiter reden.
Jörg W. schrieb:> DPA schrieb:>>>> FreeBSD widerspricht dieser These.>>>> FreeBSD hatte auch damals schon viel weniger Einfluss als Linux.>> Es ging um deine Behauptung, dass Linux mit dem OSS-API keinen> funktionierenden Sound mehr hätte.
Lies den Ganzen abschnitt, statt nur den ersten Satz. Hätte 4Front mit
Linux einen ausreichend grossen Markt bekommen, hätten diese anders
Reagiert, und die Situation heute wäre damit auch eine ganz andere.
> Das ist schlicht falsch, und als Beispiel dafür habe ich FreeBSD> angebracht.
Hätte Linux anders gehandelt, wäre der Markt für proprietäre OSS Treiber
vorhanden gewesen, womit dann automatisch auch FreeBSD keinen Sound mehr
gehabt hätte.
BSD basierte Systeme wurde damals von firmen gemieden, da noch nicht zu
ganz 100% sicher geklärt war, wer darauf sonst noch so Ansprüche haben
könnte.
DPA schrieb:> Lies den Ganzen abschnitt, statt nur den ersten Satz. Hätte 4Front mit> Linux einen ausreichend grossen Markt bekommen, hätten diese anders> Reagiert, und die Situation heute wäre damit auch eine ganz andere.
Ich sehe das nicht so. Aber wir werden uns da nicht einig. Du brauchst
dein Schreckegespenst, dass irgendwer Böses „Freie Software zerstören“
möchte. Sollst du haben, wenn du das brauchst. Ich brauche das nicht,
und ich bin nun schon lange genug bei vielen FOSS-Projekten dabei, um da
einiges erlebt zu haben und nicht nur bei Wikipedia nachlesen zu müssen.
> BSD basierte Systeme wurde damals von firmen gemieden
Du meinst, von solchen Firmen wie Sun (SunOS 4), HP (HP/UX < 10.x) oder
DEC (Ultrix/OSF1)? ;-)
BSDs Sourcecode wurde von den Linuxianern gemieden, selbst der, bei dem
die rechtliche Situation völlig eindeutig war (wie der Netzwerkcode).
Da spielt meines Erachtens zu einem guten Teil „NIH” mit rein. (Nicht,
dass die BSDs vor sowas gefeit gewesen wären.)
Jörg W. schrieb:> S. R. schrieb:>> Du hast schonmal von "VirtualBox" gehört?>> Beide Projekte fahren dieses Modell und sind damit überaus erfolgreich.> Bei VirtualBox sehe ich das eher nicht. Deren USB 2.0 ist seit Jahren> einfach nur grottig schlecht, gehört aber zum Close-Source-Anteil,> sodass sich auch niemand extern hinsetzen kann, das weiterzuentwickeln.
Es wird aber auch niemand daran gehindert, ein eigenes USB 2.0 oder 3.0
auf der Open-Source-Basis zu implementieren. Ich fahre mit der USB
1.1-Unterstützung aber gut genug, daher habe ich keinen Leidensdruck.
Bernd K. schrieb:> S. R. schrieb:>> Es steht mir frei, diesen modifizierten Linux-Kernel unter anderem Namen>> massiv zu verbreiten, unabhängig vom Original.>> Nur wenn Du alle Sourcen für Deinen privaten Kernel ebenfalls> mitlieferst denn jeglicher Code den Du da hinzugefügt oder geändert hast> muss dann ebenfalls unter der GPL stehen sobald Du das verbreiten> willst.
Logisch. Aber das ändert ja nichts daran, dass ich meine Hardware so
bauen kann, dass sie nur mit meinem modifizierten Kernel läuft. Linux
erlaubt das explizit (weil GPLv2). Wäre dem nicht so, würde ein großer
Anteil der Nutzung sofort wegbrechen.
> Diese klitzekleine Lizenzauflage musst Du erfüllen wenn Du in> den Genuß des Linux-Codes kommen willst, geschenkt gibts nämlich nichts.
Android besteht aus erstaunlich wenig GPL (hauptsächlich Kernel und
OpenJDK-Bibliotheken). Google bemüht sich nach Kräften, die
verbleibenden Anteile zu ersetzen (z.B. Toybox statt Busybox) oder
komplett ohne auszukommen (z.B. bionic).
Jörg W. schrieb:> Gerade im Embedded-Bereich brauchst du einem Kunden mit einer GPL> einfach nicht kommen, die winken da nur ab. Apache/MIT/BSD geht gerade> noch, je nach Rechtsabteilung.
Bei uns sind nur GPLv3/LGPLv3 explizit verboten, GPLv2 erlaubt.
Wobei natürlich noch dazu kommt, dass rein interne Projekte naturgemäß
nicht veröffentlicht werden und daher die Lizenzbedingungen nicht
gelten.
DPA schrieb:> Ich bin ein Mensch. Meine Programme sollen Mir und all meinen anderen> Mitmenschen von nutzen sein, für immer.
Wie schön. Damit ist dein Code für viele Menschen nicht benutzbar:
Nämlich für alle, die ihn in einem professionellen Umfeld (d.h.
Firmenumfeld) benutzen wollen.
> Ich bin keine Firma, und die Firmen (sollten) sich> weiterhin versuchen gegenseitig zu übertrumpfen.
Du empfiehlst den Firmen allen ernstes, ihre eigenen Betriebssysteme zu
schreiben? Jede ihr eigenes, proprietär, inkompatibel zu allen anderen
und inkompatibel zum Rest der Welt? Ohne die Möglichkeit, sich sinnvoll
von der Konkurrenz abzuheben? Gratuliere, hier ist dein Schild.
DPA schrieb:> Jörg W. schrieb:>> Dass man für andere Grafikhardware andere Ansteuerung braucht, ist ja>> wohl ziemlich normal>> Es geht aber nicht um die Ansteuerung der Grafikhardware durch den> Treiber, sondern um die Interaktion des Userspace mit dem> Graphikinterface des Kernels.
Wenn die Schnittstelle zwischen Userspace und Grafikhardware ungeeignet
für den gewünschten Anwendungsfall ist, dann hat man zwei Möglichkeiten:
Ein neues Interface entwickeln oder Funktionalität aufgeben.
> Das grundlegende Interface sollte immer> das gleiche sein, erweitern kann man es je nach Treiber ja trotzdem.
Äh, nein. Wenn jeder Treiber seine eigenen Erweiterungen mitbringen
darf, dann kannst du dir die Schnittstelle auch gleich schenken: Denn
dann ist es eine hardwarespezifische Schnittstelle.
> fbdev war in der Hinsicht besser, da man dort immer auf die selbe> weise, und recht einfach, etwas anzeigen konnte, auch wenn es> andere nachteile hatte.
Öh, nein. Wenn meine Hardware nur "tiled vyuy" anzeigen kann und meine
Anwendung nur "rgb24" ausgibt, dann hast du genau nichts gewonnen.
Schreibt die Spezifikation vor, dass rgb24 notwendig ist, kannst du dir
Performance und Batterielaufzeit schenken. Ein schönes Beispiel ist das
aktuelle Projekt von Linux-Sunxi für Hardware-Videodekodierung - die
haben nämlich genau das Problem.
Zumal fbdev sowieso unbeschleunigt ist und an sich nur als kleinster
gemeinsamer Nenner taugt. Für einen Bootloader angemessen, für ein
Betriebssystem ungeeignet.
> Bei anderen Interfaces ist das übrigens auch kein Problem. Alle Audio> Sachen gehen letztendlich über alsa
Also ist so wunderbar generisch, dass die Anwendung ziemlich intime
Details zur Hardware kennen muss, um Audio vernünftig ausgeben zu
können. Auf deinem Rechner merkst du davon nicht viel ("die Welt ist
AC97/HDA"), aber komplexe Hardware auf einem SoC kannst du vergessen.
Wetten, dass dein generischer ALSA-Player auf einem Snapdragon schon an
Stereo scheitert? Über den Kopfhöreranschluss brauchen wir garnicht erst
zu reden.
Aktuelle mobile Chipsets haben zwar wunderbare Kamera-Unterstützung für
alles mögliche und werden auch brav über V4L2 angesteuert, aber dennoch
ist keine einzige hardwareunabhängige Anwendung in der Lage, den
Sensor überhaupt einzuschalten. Geschweige denn ein Bild zu liefern, zu
fokussieren oder einen Weißabgleich durchzuführen.
Wenn ich meine Anwendung so schreiben muss, dass sie die
V4L2-Schnittstelle für einen OMAP oder Snapdragon bedienen kann,
funktioniert sie auf einem Allwinner, Rockchip oder STE trotzdem nicht.
Oder für aktuelle Intel-Chipsätze, die haben nämlich genau aus diesem
Grund keine funktionierende Kameraunterstützung mehr unter Linux.
Ich empfehle den Vortrag hier:
https://elinux.org/images/b/b9/Complex-Cameras-on-Linux-Mauro-Carvalho-Chehab-Samsung.pdf
(gibt's auf Youtube). Bis Libcamera zuverlässig funktioniert, gehen noch
ein paar Jahre ins Land. Bis dahin wirst du keine Kamera haben -
Windows, Android und OSX schon.
Gag am Rande: Schonmal bedacht, dass die Stromlast des Blitzes einer
Smartphone-Kamera die Spannung des Akkus soweit einbrechen lassen kann,
dass das System spontan neu startet? Deine Kamera-App muss darauf auch
Rücksicht nehmen und den Strom reduzieren, sonst werden deine Kunden
bockig. Zum Glück hast du ja keine... :-)
Joerg W. schrieb:> Wenn man z.B. TWRP startet, hat man ja ein mehr oder weniger> funktionelles Linux-System, was sich via ADB shell auch recht> komfortabel remote bedienen lässt.
Ein Android-System besteht im Prinzip aus drei Linux-Kerneln:
"Recovery", "Charger", "Android".
> Ich hatte auch zwischenzeitlich versucht, eigene native Programme zu> schreiben und dann von dort aus zu starten, aber außer Bildschirm, Touch> und Remote Console scheint da noch nicht viel initialisiert zu sein.
Die Hardware-Unterstützung in jedem Modus ist anders, siehe hier:
https://source.android.com/devices/architecture/kernel/modular-kernels#file-locations
Ich fand das irritierend, dass man ein vollständiges Linux zum Laden
braucht, aber die Hardware selbst trifft zunehmend weniger
Entscheidungen. Das Betriebssystem muss Ladeströme, Temperaturgrenzen
und den Batteriezustand im Betrieb sowieso berücksichtigen, also kann
man die Funktionen im Lademodus gleich mitbenutzen...
S. R. schrieb:> Gag am Rande: Schonmal bedacht, dass die Stromlast des Blitzes einer> Smartphone-Kamera die Spannung des Akkus soweit einbrechen lassen kann,> dass das System spontan neu startet? Deine Kamera-App muss darauf auch> Rücksicht nehmen
LOL, was? Das klingt eher nach fehlkonstruierter Hardware. Keine
Kameraapp der Welt muß auf so einen Nonsens Rücksicht nehmen.
S. R. schrieb:> Jörg W. schrieb:>> S. R. schrieb:>>> Du hast schonmal von "VirtualBox" gehört?>>> Beide Projekte fahren dieses Modell und sind damit überaus erfolgreich.>> Bei VirtualBox sehe ich das eher nicht. Deren USB 2.0 ist seit Jahren>> einfach nur grottig schlecht, gehört aber zum Close-Source-Anteil,>> sodass sich auch niemand extern hinsetzen kann, das weiterzuentwickeln.>> Es wird aber auch niemand daran gehindert, ein eigenes USB 2.0 oder 3.0> auf der Open-Source-Basis zu implementieren. Ich fahre mit der USB> 1.1-Unterstützung aber gut genug, daher habe ich keinen Leidensdruck.
Nur warum sollte das jemand tun? Mit qemu+KVM, plus noch Hypervisoren
wie z.B. libvirt, hat man eine freie Emulationssoftware, die teils noch
Effizienter sind, die man genauso benutzerfreundlich machen könnte, und
bei denen vermutlich selbst USB3 gehen würde. Wozu also als freiwilliger
Entwickler mit VirtualBox seine Zeit verschwenden?
S. R. schrieb:> DPA schrieb:>> Ich bin ein Mensch. Meine Programme sollen Mir und all meinen anderen>> Mitmenschen von nutzen sein, für immer.>> Wie schön. Damit ist dein Code für viele Menschen nicht benutzbar:> Nämlich für alle, die ihn in einem professionellen Umfeld (d.h.> Firmenumfeld) benutzen wollen.
Natürlich ist es auch dort verwendbar. Du kannst Linux, gcc, etc.
benutzen, um damit deine davon unabhängige, Closed Source Anwendung zu
entwickeln, du kannst Support für jegliche dieser Dinge anbieten, du
kannst es zu den gleiche Konditionen erweitern und veröffentlichen. Du
kannst lediglich den Code nicht in eine Closed Source Anwendung
einbauen, und falls eine Library GPL statt LGPL verwendet, kannst du die
in deinem CSS Programm nicht nutzen, andernfalls aber geht selbst das.
Du kannst GPL Programme auch mit CSS Programmen zusammen ausliefern,
sofern du das in den Lizenzen korrekt deklarierst, welche Programme
unter der GPL stehen, und die GPL Programme nicht der Umgehung der GPL
dienen. Auch im professionellen Umfeld hat man somit fast keine
Einschränkungen, und die, die Bleiben, stellen nur sicher, dass man OSS
nicht nur ausnutzt und nichts zurück gibt. (In nichts schliesse ich hier
CSS Beiträge an OSS mit ein, diese verwende ich nicht, und nützen mir
damit auch nichts, nein binary blobs schaden mir hier sogar!). Ich finde
das äusserst fair Bedingungen. Sie können es benutzen, die lüge ist,
dass sie es benutzen wollen. Stehlen würden sie es natürlich schon
gerne, aber das ist nicht das selbe.
>> Ich bin keine Firma, und die Firmen (sollten) sich>> weiterhin versuchen gegenseitig zu übertrumpfen.>> Du empfiehlst den Firmen allen ernstes, ihre eigenen Betriebssysteme zu> schreiben? Jede ihr eigenes, proprietär, inkompatibel zu allen anderen> und inkompatibel zum Rest der Welt? Ohne die Möglichkeit, sich sinnvoll> von der Konkurrenz abzuheben? Gratuliere, hier ist dein Schild.
Nein. Wenn Unternehmen die Verwendung von GPL Code bei sich generell
verbieten, ist das nicht mein Problem. Es ist deren Entscheidung, sich
sinnloserweise dermassen einzuschränken. Gib nicht mir oder der GPL die
schuld für die Dummheit vieler Unternehmen.
Ausserdem, du weisst, das Monopole der Wirtschaft schaden? Was habe ich
davon, es Firmen zu erleichtern, sich einen Vorteil zu verschaffen aka.
ein Monopol aufzubauen? Warum sollte ich ihnen bei ihren
anti-kompetitiven Bestrebungen helfen? Insbesondere, wenn ich deren
Produkte sowieso nicht verwende? Was hab ich davon? Zu verlieren hab ich
hier aber vieles.
S. R. schrieb:> DPA schrieb:>> Jörg W. schrieb:>>> Dass man für andere Grafikhardware andere Ansteuerung braucht, ist ja>>> wohl ziemlich normal>>>> Es geht aber nicht um die Ansteuerung der Grafikhardware durch den>> Treiber, sondern um die Interaktion des Userspace mit dem>> Graphikinterface des Kernels.>> Wenn die Schnittstelle zwischen Userspace und Grafikhardware ungeeignet> für den gewünschten Anwendungsfall ist, dann hat man zwei Möglichkeiten:> Ein neues Interface entwickeln oder Funktionalität aufgeben.
Oder das Interface erweitern.
>> Das grundlegende Interface sollte immer>> das gleiche sein, erweitern kann man es je nach Treiber ja trotzdem.>> Äh, nein. Wenn jeder Treiber seine eigenen Erweiterungen mitbringen> darf, dann kannst du dir die Schnittstelle auch gleich schenken: Denn> dann ist es eine hardwarespezifische Schnittstelle.
Wenn du sicherstellst, dass die Grundfunktionalität im allgemeinen teil
gegeben ist, nicht. Dann kann ein Generisches Programm das durchaus
verwenden, ohne die Hardware zu kennen.
>> fbdev war in der Hinsicht besser, da man dort immer auf die selbe>> weise, und recht einfach, etwas anzeigen konnte, auch wenn es>> andere nachteile hatte.>> Öh, nein. Wenn meine Hardware nur "tiled vyuy" anzeigen kann und meine> Anwendung nur "rgb24" ausgibt, dann hast du genau nichts gewonnen.> Schreibt die Spezifikation vor, dass rgb24 notwendig ist, kannst du dir> Performance und Batterielaufzeit schenken. Ein schönes Beispiel ist das> aktuelle Projekt von Linux-Sunxi für Hardware-Videodekodierung - die> haben nämlich genau das Problem.
Es gibt 2 Ansätze. Entweder, man legt fest, Format XY muss funktionieren
und kann dann sagen, Format Z wäre nativ und schneller, und Programme
die das können, sollen es bevorzugen, oder man macht eine Library, die
alle Formate implementiert, und die nötige Konvertierung macht oder
sonst wie eine generische Schnittstelle bietet.
> Zumal fbdev sowieso unbeschleunigt ist und an sich nur als kleinster> gemeinsamer Nenner taugt. Für einen Bootloader angemessen, für ein> Betriebssystem ungeeignet.
Das ist falsch. Es gab mal einen FBDev Treiber, der per ioctl OpenGL
unterstützte. Hätte man eine solche API standardisiert, wäre das kein
Problem gewesen. Aber nun haben wir ja DRM/DRI, das das tut, und nach
Jahren ein äquivalent zu Framebuffers wieder implementiert, nähmlich
dumb Buffers. Geht doch.
>> Bei anderen Interfaces ist das übrigens auch kein Problem. Alle Audio>> Sachen gehen letztendlich über alsa>> Also ist so wunderbar generisch, dass die Anwendung ziemlich intime> Details zur Hardware kennen muss, um Audio vernünftig ausgeben zu> können. Auf deinem Rechner merkst du davon nicht viel ("die Welt ist> AC97/HDA"), aber komplexe Hardware auf einem SoC kannst du vergessen.> Wetten, dass dein generischer ALSA-Player auf einem Snapdragon schon an> Stereo scheitert? Über den Kopfhöreranschluss brauchen wir garnicht erst> zu reden.
Allzuviele Formate gibt es nicht, und alsa besitzt ein Plugin, um
zwischen diesen zu konvertieren. Wenn man das, zusammen mit dmix korrekt
Konfiguriert, gibt es hier keine Probleme. Und wenn dir das zu
kompliziert ist, gibt es Soundserver. Pulseaudio, Jack, etc.
> Aktuelle mobile Chipsets haben zwar wunderbare Kamera-Unterstützung für> alles mögliche und werden auch brav über V4L2 angesteuert, aber dennoch> ist keine einzige hardwareunabhängige Anwendung in der Lage, den> Sensor überhaupt einzuschalten. Geschweige denn ein Bild zu liefern, zu> fokussieren oder einen Weißabgleich durchzuführen.
Weist du, wie man das Lösen könnte? Indem man eine generische
Schnittstelle für genau diesen noch fehlenden Zweck definiert. Die kann
man auch mit ioctls zum bestehenden dazu tun. Aber man muss es halt
standardisieren, also einheitlich machen. Oder eben ne Library dafür,
aber das ist halt mehr Aufwand.
> Wenn ich meine Anwendung so schreiben muss, dass sie die> V4L2-Schnittstelle für einen OMAP oder Snapdragon bedienen kann,> funktioniert sie auf einem Allwinner, Rockchip oder STE trotzdem nicht.> Oder für aktuelle Intel-Chipsätze, die haben nämlich genau aus diesem> Grund keine funktionierende Kameraunterstützung mehr unter Linux.
UV4L2 kann soweit ich weiss zwischen verschiedenen Videoformaten
konvertieren. Sollte das der Fall sein, wäre das entweder eine
Regression von UV4L, oder ein schweres Problem mit den Treibern, das man
unbedingt beheben muss. Um eine Einschränkung des UV4L Schnittstelle
handelt es sich definitiv nicht, ich hab mir die API Dokumentation doch
früher schon mal angeschaut.
Und meine Kameras funktionieren zumindest alle einwandfrei, ob ich die
jetzt mit VLC öffne, oder mit einer der python libraries, da hatte ich
noch nie ein Problem.
Zusammengefasst, ich sehe das Problem nicht. Du kannst Anwendungen
haben, die überall gehen. Du kannst diese trotzdem noch Optimieren, so
dass Hardware spezifische Dinge zur Beschleunigung ausnutzen.
Klar, jemand muss das Interface definieren, und viele müssen es
anschauen, sich koordinieren, und erweitern. Und jemand muss es noch
implementieren. Aber das Prinzip funktioniert perfekt, solange alle
zusammen arbeiten. Was will man mehr? Und was würdest du stattdessen
vorschlagen, dass alles nur auf genau einer Hardware laufen soll? Also
wirklich...
Bernd K. schrieb:> LOL, was? Das klingt eher nach fehlkonstruierter Hardware.
Moderne Hardware besteht inzwischen zu einem Großteil aus Software. Es
fällt nur mehr auf, weil diese Software zunehmend von Spezialprozessoren
ins Betriebssystem wandert.
> Keine Kameraapp der Welt muß auf so einen Nonsens Rücksicht nehmen.
Doch. Aber unter Android gibt es nur genau eine Anwendung, die kommt vom
Hersteller und nennt sich "Camera HAL".
Deine Android-App muss sich nicht mehr darum kümmern.
Eine V4L2-Anwendung müsste es (scheitert aber schon lange vorher).
Daniel A. schrieb:>>> Ich bin keine Firma, und die Firmen (sollten) sich>>> weiterhin versuchen gegenseitig zu übertrumpfen.>>>> Du empfiehlst den Firmen allen ernstes, ihre eigenen Betriebssysteme zu>> schreiben? Jede ihr eigenes, proprietär, inkompatibel zu allen anderen>> und inkompatibel zum Rest der Welt? Ohne die Möglichkeit, sich sinnvoll>> von der Konkurrenz abzuheben? Gratuliere, hier ist dein Schild.>> Nein. Wenn Unternehmen die Verwendung von GPL Code bei sich generell> verbieten, ist das nicht mein Problem. Es ist deren Entscheidung, sich> sinnloserweise dermassen einzuschränken. Gib nicht mir oder der GPL die> schuld für die Dummheit vieler Unternehmen.
Es ist keine Dummheit.
Zwei Beispiele:
- Jedes Land dieser Welt hat Gesetze zur Verwendung von Funkfrequenzen
(Polizeifunk, Flugfunk abhören und so weiter). Ein Hersteller von
Funkgeräten muss technisch sicherstellen, dass dieses Funkgerät nicht
auf diesen Frequenzen funktioniert. Der Hersteller ist in der Haftung.
- In manchen Ländern dieser Welt ist gesetzlich festgeschrieben, dass
eine Kamera bei der Aufnahme eines Fotos ein Geräusch (mit
Mindestlautstärke) machen muss bzw. dass bei der Videoaufnahme ein
optischer Hinweis erfolgen muss. Hersteller müssen sicherstellen, dass
eine solche Funktion nicht abschaltbar ist, der Hersteller ist in der
Haftung.
Jetzt nehmen wir mal an, Android nutzt Linux und Linux sei unter GPLv3
(-only). Die GPLv3 erzwingt (Tivoization-Klausel), dass ich den Source
verändern können und den veränderten Source auf dem Gerät laufen lassen
können muss. Daraus folgt indirekt auch (m.W. noch nicht juristisch
geprüft), dass ich keine Binary Blobs für Hardwaretreiber verwenden darf
- weil auch das ist Software.
Frage: Wie willst du den Gesetzen des Landes genügen können, in dem du
deine Waren verkaufen möchtest?
Einzige Einschränkung: Die Option "wir bauen die Hardware so, dass sie
den Gesetzen genügt" ist nicht zulässig. Die Gesetze in verschiedenen
Ländern widersprechen sich und ändern immer mal wieder. Außerdem ist es
finanziell nicht tragbar, für jedes Land eine eigene Hardware-Version zu
entwickeln.
> Ausserdem, du weisst, das Monopole der Wirtschaft schaden?
Ja. Ich weiß aber auch, dass es der Wirtschaft schadet, wenn man
Unternehmen ihre Existenzgrundlage nimmt.
Denn dann hat man keine Unternehmen.
> Was habe ich davon, es Firmen zu erleichtern, sich einen Vorteil> zu verschaffen aka. ein Monopol aufzubauen?
Hmm. Du willst also, dass Firmen lieber zusammenarbeiten und ihr
proprietäres Zeug gemeinsam entwickeln... um es dann patentieren und
gesetzlich festschreiben zu lassen? So wie bei exFAT, MPEG oder MS
Office?
Mir ist es lieber, wenn $FIRMA seine Entwicklung öffentlich macht als
hinter verschlossenen Türen. Das setzt aber voraus, dass ich $FIRMA
nicht dafür kaputtschlage, dass sie es tun.
Und das wiederum setzt voraus, dass ich darüber nachdenke, warum $FIRMA
das in manchen Bereichen nicht sinnvoll machen kann (oder schlicht nicht
machen darf - wie in vielen stark regulierten Branchen).
> Insbesondere, wenn ich deren Produkte sowieso nicht verwende?
Ich glaube, dieser Satz ist die wichtigste Information von dir in diesem
Thread. Hersteller von Produkten, die du nicht benutzt, sind dir egal.
S. R. schrieb:>> Keine Kameraapp der Welt muß auf so einen Nonsens Rücksicht nehmen.>> Doch. Aber unter Android gibt es nur genau eine Anwendung, die kommt vom> Hersteller und nennt sich "Camera HAL".>> Deine Android-App muss sich nicht mehr darum kümmern.> Eine V4L2-Anwendung müsste es (scheitert aber schon lange vorher).
Du weisst, was ein HAL ist? Das ist auch nur ein Interface. Der Blitz
Treiber im Kernel könnte sich genauso gut darum kümmern. Dennoch wäre es
eigentlich ein Hardware Problem, wenn das Gerät zuviel Strom verbraucht.
S. R. schrieb:> Daniel A. schrieb:>>>> Ich bin keine Firma, und die Firmen (sollten) sich>>>> weiterhin versuchen gegenseitig zu übertrumpfen.>>>>>> Du empfiehlst den Firmen allen ernstes, ihre eigenen Betriebssysteme zu>>> schreiben? Jede ihr eigenes, proprietär, inkompatibel zu allen anderen>>> und inkompatibel zum Rest der Welt? Ohne die Möglichkeit, sich sinnvoll>>> von der Konkurrenz abzuheben? Gratuliere, hier ist dein Schild.>>>> Nein. Wenn Unternehmen die Verwendung von GPL Code bei sich generell>> verbieten, ist das nicht mein Problem. Es ist deren Entscheidung, sich>> sinnloserweise dermassen einzuschränken. Gib nicht mir oder der GPL die>> schuld für die Dummheit vieler Unternehmen.>> Es ist keine Dummheit.>> Zwei Beispiele:> - Jedes Land dieser Welt hat Gesetze zur Verwendung von Funkfrequenzen> (Polizeifunk, Flugfunk abhören und so weiter). Ein Hersteller von> Funkgeräten muss technisch sicherstellen, dass dieses Funkgerät nicht> auf diesen Frequenzen funktioniert. Der Hersteller ist in der Haftung.
Was haben Firmware mit den GPL Programmen, die ich veröffentliche, zu
tun? Diese sind nur selten überhaupt für Firmware nutzbar, da es sich
hier um sehr Hardwarespezifische aufgaben handelt. Die FSF stellt sich
auf den Standpunkt, dass Firmware, zumindest wenn sie nicht verändert
werden kann, als Hardware zu betrachten ist, obwohl ich das nicht
Sinvoll finde.
Ich sehe kein Problem darin, den Quellcode zu veröffentlichen. Wenn man
selbst das gerät so manipuliert, dass es nicht mehr Gesetzeskonform ist,
sollte es keine rolle spielen, ob man das Hard-, Soft-, oder sonst wie
tut, es handelt sich dann nicht mehr um das Gerät, das der Hersteller
verkauft hat. Es stimmt wohl, dass die FCC in den USA da ziemliche
A********* sein können, und die Gerichte dort manchmal noch viel
unvernünftiger sind als an den meisten orten Europas.
> - In manchen Ländern dieser Welt ist gesetzlich festgeschrieben, dass> eine Kamera bei der Aufnahme eines Fotos ein Geräusch (mit> Mindestlautstärke) machen muss bzw. dass bei der Videoaufnahme ein> optischer Hinweis erfolgen muss. Hersteller müssen sicherstellen, dass> eine solche Funktion nicht abschaltbar ist, der Hersteller ist in der> Haftung.
Bei Android könnte ich das immernoch anderweitig deaktivieren. Hier wäre
es auch besser, wenn die Hersteller den Code veröffentlichen würden oder
müssten, denn dann wäre es einfacher, die veralteten Gesetzt zu
überarbeiten, und Rechtssicherheit dafür zu schaffen.
Die Unternehmen wollen das Risiko aber natürlich nicht freiwillig
eingehen, und auch keine sonstigen Gerichtskosten riskieren. So wird
sich vermutlich an der veralteten Gesetzeslage in manchen Ländern
vorerst nichts ändern.
> Jetzt nehmen wir mal an, Android nutzt Linux und Linux sei unter GPLv3> (-only). Die GPLv3 erzwingt (Tivoization-Klausel), dass ich den Source> verändern können und den veränderten Source auf dem Gerät laufen lassen> können muss. Daraus folgt indirekt auch (m.W. noch nicht juristisch> geprüft), dass ich keine Binary Blobs für Hardwaretreiber verwenden darf> - weil auch das ist Software.>> Frage: Wie willst du den Gesetzen des Landes genügen können, in dem du> deine Waren verkaufen möchtest?
Indem man es einfach soweit tut, wie dies zumutbar ist. Gesetze sind
nicht in Stein gemeisselte Dinge, die man entweder Bricht oder auch
nicht. Solche Dinge sollten, zumindest in der Theorie, bei einem
verfahren berücksichtigt werden. Ist hat ein wenig riskant.
S. R. schrieb:>> Was habe ich davon, es Firmen zu erleichtern, sich einen Vorteil>> zu verschaffen aka. ein Monopol aufzubauen?>> Hmm. Du willst also, dass Firmen lieber zusammenarbeiten und ihr> proprietäres Zeug gemeinsam entwickeln... um es dann patentieren und> gesetzlich festschreiben zu lassen? So wie bei exFAT, MPEG oder MS> Office?
In Europa und der Schweiz gibt es keine Softwarepatente.
Selbstverständlich schliesst dies nicht zwangsläufig aus, das neuartige
Verfahren/Ideen patentiert werden, jedoch wird es heute schwierig sein,
hier etwas zu finden, dass so oder so ähnlich noch nie gemacht wurde.
In der Schweiz haben wir zusätzlich noch Art 21 des URG:
https://www.admin.ch/opc/de/classified-compilation/19920251/index.html#a21> 1 Wer das Recht hat, ein Computerprogramm zu gebrauchen, darf sich die> erforderlichen Informationen über Schnittstellen zu unabhängig> entwickelten Programmen durch Entschlüsselung des Programmcodes> beschaffen oder durch Drittpersonen beschaffen lassen.>> 2 Die durch Entschlüsselung des Programmcodes gewonnenen> Schnittstelleninformationen dürfen nur zur Entwicklung, Wartung sowie zum> Gebrauch von interoperablen Computerprogrammen verwendet werden, soweit> dadurch weder die normale Auswertung des Programms noch die rechtmässigen> Interessen der Rechtsinhaber und -inhaberinnen unzumutbar beeinträchtigt werden.
Daniel A. schrieb:> Du weisst, was ein HAL ist?> Das ist auch nur ein Interface.
Welches im Gegensatz zu den Kernel-Treibern (welche die Hardware
ansteuern) an den Erfordernissen der Software ausgerichtet sind.
> Dennoch wäre es eigentlich ein Hardware Problem,> wenn das Gerät zuviel Strom verbraucht.
Ich lache mal kurz.
Moderne Smartphones können nur einen Bruchteil ihrer Leistungsfähigkeit
nutzen, weil sie sonst überhitzen. Thermal Management ist ein
wesentlicher Bestandteil solcher Geräte.
>> Jedes Land dieser Welt hat Gesetze zur Verwendung von Funkfrequenzen>> (Polizeifunk, Flugfunk abhören und so weiter). Ein Hersteller von>> Funkgeräten muss technisch sicherstellen, dass dieses Funkgerät nicht>> auf diesen Frequenzen funktioniert. Der Hersteller ist in der Haftung.>> Was haben Firmware mit den GPL Programmen,> die ich veröffentliche, zu tun?
Im Gegensatz zu GPLv2 sind GPLv3 und LGPLv3 innerhalb eines Produkts
viral. Wenn du eine Bibliothek unter GPLv3 veröffentlichst und ich die
in ein Android-Produkt einbaue, dann verletze ich damit die
Lizenzbedingungen, wenn ich nicht das gesamte Produkt öffne. Was
wiederum dazu führt, dass ich dieses Produkt nie hätte herstellen oder
verkaufen dürfen...
> Wenn man selbst das gerät so manipuliert, dass es nicht mehr> Gesetzeskonform ist, sollte es keine rolle spielen, ob man das> Hard-, Soft-, oder sonst wie tut, es handelt sich dann nicht> mehr um das Gerät, das der Hersteller verkauft hat.
Das wird in verschiedenen Ländern der Welt sehr verschieden gesehen...
vermutlich sogar innerhalb eines Gebäudes von verschiedenen Richtern.
>> In manchen Ländern dieser Welt ist gesetzlich festgeschrieben, dass>> eine Kamera bei der Aufnahme eines Fotos ein Geräusch (mit>> Mindestlautstärke) machen muss bzw. dass bei der Videoaufnahme ein>> optischer Hinweis erfolgen muss. Hersteller müssen sicherstellen, dass>> eine solche Funktion nicht abschaltbar ist, der Hersteller ist in der>> Haftung.>> Bei Android könnte ich das immernoch anderweitig deaktivieren.
Auf unseren Geräten für die betroffenen Märkte ist das nicht möglich,
ohne die Kamerafunktionen zu verlieren.
> Hier wäre es auch besser, wenn die Hersteller den Code> veröffentlichen würden oder müssten, denn dann wäre es> einfacher, die veralteten Gesetzt zu überarbeiten, und> Rechtssicherheit dafür zu schaffen.
Es geht nicht darum, die Gesetze an die Wünsche der Entwickler
anzupassen, sondern gesetz- und lizenzkonforme Geräte herstellen zu
können.
Das ist mit (L)GPLv3 überall da nicht möglich, wo die Regulierungs- oder
Gesetzeslage eine Manipulierbarkeit (aus gutem Grund) ausschließt.
Es geht hier nicht um "veraltete, zu überarbeitende Gesetze", sondern
darum, dass gewisse Dinge schlicht verboten sind. Zum Beispiel Spionage,
ungewünschte Überwachung oder heimliche Nacktfotos. Und wenn der
Gesetzgeber der Meinung ist, dass man das über die Kameras lösen kann,
dann hast du als Kamerahersteller nicht die Freiheit, das zu ignorieren.
> S. R. schrieb:>> Hmm. Du willst also, dass Firmen lieber zusammenarbeiten und ihr>> proprietäres Zeug gemeinsam entwickeln... um es dann patentieren und>> gesetzlich festschreiben zu lassen? So wie bei exFAT, MPEG oder MS>> Office?>> In Europa und der Schweiz gibt es keine Softwarepatente.
Im Großteil der Welt sind sie dennoch Realität. Und ob sie relevant sind
oder nicht ist auch egal, denn wenn ihre Verletzung ein Existenzrisiko
darstellt, dann macht man es trotzdem nicht.
Wenn die Firma am Ende des Gerichtsprozesses nicht mehr existiert,
spielt es keine Rolle, ob sie im Recht war oder nicht. Oder frag mal
Kachelmann, was ihm seine Freisprüche beruflich gebracht haben.
> Selbstverständlich schliesst dies nicht zwangsläufig aus,> das neuartige Verfahren/Ideen patentiert werden, jedoch> wird es heute schwierig sein, hier etwas zu finden, dass> so oder so ähnlich noch nie gemacht wurde.
Das haben die Physiker im 19. Jahrhundert auch gedacht.
Und dann kam erst Einstein und dann die Quantenphysik.
S. R. schrieb:>> Dennoch wäre es eigentlich ein Hardware Problem,>> wenn das Gerät zuviel Strom verbraucht.>> Ich lache mal kurz.>> Moderne Smartphones können nur einen Bruchteil ihrer Leistungsfähigkeit> nutzen, weil sie sonst überhitzen. Thermal Management ist ein> wesentlicher Bestandteil solcher Geräte.
Naja, sobald das Librem5 da ist, werde ich ja sehen, was da dran ist.
Ich bin da ja auch teil der Community. So oder so, mit den Freeze & CPU
CGroups, und den CPU Frequenz governos, sollte das kein Problem sein so
umzusetzen, dass man davon fast nichts merkt.
S. R. schrieb:> Daniel A. schrieb:>> Was haben Firmware mit den GPL Programmen, die ich veröffentliche, zu tun?> Im Gegensatz zu GPLv2 sind GPLv3 und LGPLv3 innerhalb eines Produkts> viral. Wenn du eine Bibliothek unter GPLv3 veröffentlichst und ich die> in ein Android-Produkt einbaue, dann verletze ich damit die> Lizenzbedingungen, wenn ich nicht das gesamte Produkt öffne. Was> wiederum dazu führt, dass ich dieses Produkt nie hätte herstellen oder> verkaufen dürfen...
Wie ich schon schrieb:
Daniel A. schrieb:> Diese sind nur selten überhaupt für Firmware nutzbar, da es sich> hier um sehr Hardwarespezifische aufgaben handelt.
Abgesehen von ein paar crypto Libraries, sehe ich nicht, was für
Libraries dir bei Firmware gross helfen sollen. Hast du ein Beispiel,
für etwas, das Praktisch gewesen wäre, aber leider unter der GPL stand?
So oder so, die meisten Programme und Libraries sind zu gross, haben zu
viele Abhängigkeiten, oder sind aus anderen Gründen sowieso nicht für
Firmware nutzbar.
S. R. schrieb:> Auf unseren Geräten für die betroffenen Märkte ist das nicht möglich,> ohne die Kamerafunktionen zu verlieren.
Da lache ich auch mal kurz. Oder soll das eine Herausforderung sein?
S. R. schrieb:> wo die Regulierungs- oder> Gesetzeslage eine Manipulierbarkeit (aus gutem Grund) ausschließt.
Es kann keinen guten Grund für so einen unsinnige Gesetzgebung geben.
Egal was damit bezweckt werden will, der Kollateralschaden ist größer
und eine Wirksamkeit bezüglich irgendeines "Problems" kann auch nicht
nachgewiesen werden.
Bernd K. schrieb:> Es kann keinen guten Grund für so einen unsinnige Gesetzgebung geben.
Wenn man Waffen verbietet, hat man weniger Probleme mit bewaffneten
Gewalttaten. Wenn man Funkgeräten den Zugang zum Flugfunk verbietet, hat
man weniger Probleme mit unbefugten Eingriffen in den Flugfunk.
Wer es drauf anlegt, kann sowohl Funkgeräte passend modifizieren als
auch Waffen besorgen.
Davon abgesehen ist es für ein Unternehmen relativ egal, ob die Gesetze
sinnvoll sind oder nicht, es muss sich (prinzipiell) trotzdem dran
halten. Eine Firma ist kein Parlament.
Mit Medizintechnik fange ich jetzt garnicht erst an.
S. R. schrieb:> Es geht nicht darum, die Gesetze an die Wünsche der Entwickler> anzupassen, sondern gesetz- und lizenzkonforme Geräte herstellen zu> können.>> Das ist mit (L)GPLv3 überall da nicht möglich, wo die Regulierungs- oder> Gesetzeslage eine Manipulierbarkeit (aus gutem Grund) ausschließt.
Interessant, sind dort auch Android-Phones verboten? Schließlich kann
man die ja auch Lightning umflashen?
S. R. schrieb:> Bernd K. schrieb:>> Es kann keinen guten Grund für so einen unsinnige Gesetzgebung geben.>> Wenn man Waffen verbietet, hat man weniger Probleme mit bewaffneten> Gewalttaten. Wenn man Funkgeräten den Zugang zum Flugfunk verbietet, hat> man weniger Probleme mit unbefugten Eingriffen in den Flugfunk.>> Wer es drauf anlegt, kann sowohl Funkgeräte passend modifizieren als> auch Waffen besorgen
Genau, es ist nicht zumutbar von Unternehmen zu erwarten, dass sie
solche Modifikationen verhindern, und damit spricht auch rechtlich
nichts dagegen, Firmware unter einer Freien Lizenz zu veröffentlichen.
Es stimmt, dass es sicher Richter gibt, die das anders sehen werden,
insbesondere auch, weil es keine Prezedenzfälle dafür gibt. Man bräuchte
eine art GPL-Firmware-versicherung, die den Firmen diese Risiken
abnimmt, und sie vor Gericht vertreten kann. Wenn alles gut läuft,
würden dann die Risiken nach den ersten paar Prozessen recht schnell
verschwinden.
vn n. schrieb:> Interessant, sind dort auch Android-Phones verboten?
Es gibt keine (L)GPLv3-lizenzierte Software in Android.
Daniel A. schrieb:>> Wer es drauf anlegt, kann sowohl Funkgeräte passend modifizieren als>> auch Waffen besorgen>> Genau, es ist nicht zumutbar von Unternehmen zu erwarten, dass sie> solche Modifikationen verhindern, und damit spricht auch rechtlich> nichts dagegen, Firmware unter einer Freien Lizenz zu veröffentlichen.
Falsch. Aber mit dir darüber weiter zu diskutieren bringt nichts.
S. R. schrieb:> vn n. schrieb:>> Interessant, sind dort auch Android-Phones verboten?>> Es gibt keine (L)GPLv3-lizenzierte Software in Android.
Erstens ist das natürlich falsch, der Android-Kernel steht unter GPL.
Zweitens war das nicht die Frage. Du behauptest, es gäbe Länder, in
denen man ein Gerät mit Kamera nicht verkaufen darf, wenn man die
Firmware gegen eine ersetzen kann, bei der gewisse Funktionen
deaktiviert sind (Kameraton). Bei Android ist das i.A. durch Austausch
gegen ein Custom-ROM möglich. Wie erklärst du dir diese Unvereinbarkeit?
Ich glaube, du bist einfach nur ein Dampfplauderer, der uns hier einen
vom Pferd erzählt...
vn nn schrieb:> Erstens ist das natürlich falsch, der Android-Kernel steht unter GPL.
Der Android-Kernel steht unter GPLv2, nicht unter (L)GPLv3.
Das sind verschiedene Lizenzen. Lern lesen.
vn nn schrieb:> Du behauptest, es gäbe Länder, in denen man ein Gerät mit Kamera> nicht verkaufen darf, wenn man die Firmware gegen eine ersetzen> kann, bei der gewisse Funktionen deaktiviert sind (Kameraton).
Korrekt. Und es ist Aufgabe des Herstellers, dafür zu sorgen, dass diese
Funktion für den Benutzer nicht abschaltbar ist.
Eine mögliche Lösung ist es, das ROM vor Manipulationen zu schützen.
Womit wir zum nächsten Punkt kommen:
vn nn schrieb:> Bei Android ist das i.A. durch Austausch gegen ein Custom-ROM möglich.
Auf Geräten mit aktiviertem Secure Boot kannst du kein Custom-ROM
booten, ohne entsprechende Sicherheitsvorkehrungen zu umgehen (was im
Übrigen je nach Land und Einsatzzweck selbst schon strafbar ist). Das
genügt dem Gesetz.
Selbst, wenn der Hersteller einen Bootloader-Unlock anbietet, muss das
nicht für Geräte in den entsprechenden Märkten aktiv sein. Damit sind
diese Geräte effektiv vor Manipulationen geschützt.
Solltest du jetzt mit "aber es gibt immer Bugs" und "guck mal
xda-developers.com" kommen: Ja, mag sein. Ist aber irrelevant.
vn nn schrieb:> Ich glaube, du bist einfach nur ein Dampfplauderer,> der uns hier einen vom Pferd erzählt...
Wenn du meinst. Ich bin kein Jurist.
