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.
:
Bearbeitet durch Moderator
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.
DPA schrieb: > Der Film würde mich auch interessieren, teil uns bitte mit, falls er dir > wieder einfällt. Ha, der Film hieß Antitrust, auf deutsch Startup und es war 2001 https://de.wikipedia.org/wiki/Startup_(Film)
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." |
oder https://www.oracle.com/technetwork/oca-405177.pdf
1 | "you hereby assign to us joint ownership, and to the extent that such assignment is or becomes invalid, ineffective or unenforceable, you |
2 | hereby grant to us a perpetual, irrevocable, non-exclusive, worldwide, no-charge, royalty-free, unrestricted license to exercise all rights |
3 | under those copyrights. This includes, at our option, the right to sublicense these same rights to third parties through multiple levels of |
4 | sublicensees or other licensing arrangements;" |
oder die Apache-Foundation https://www.apache.org/licenses/cla-corporate.txt bzw. https://www.apache.org/licenses/icla.pdf
1 | " You hereby grant to the Foundation and to |
2 | recipients of software distributed by the Foundation a perpetual, |
3 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable |
4 | copyright license to reproduce, prepare derivative works of, |
5 | publicly display, publicly perform, sublicense, and distribute Your |
6 | Contributions and such derivative works." |
und von der Linux-Foundation bzw. der Cloud Native Computing Foundation https://github.com/cncf/cla/blob/master/individual-cla.pdf
1 | "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." |
oder Ubuntu https://assets.ubuntu.com/v1/ff2478d1-Canonical-HA-CLA-ANY-I_v1.2.pdf man ahnt es schon...
1 | "You grant to Us a perpetual, worldwide, non-exclusive, |
2 | transferable, royalty-free, irrevocable license under the |
3 | Copyright covering the Contribution, with the right to |
4 | sublicense such rights through multiple tiers of |
5 | sublicensees, to reproduce, modify, display, perform and |
6 | distribute the Contribution" |
oder die FSF https://www.gnu.org/prep/maintain/maintain.html#Legal-Matters
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.
:
Bearbeitet durch User
> 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/733 https://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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch Moderator
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.