|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
 |
|
|
|
|
|
|
|
Eine Distri dessen Maintainer sich darüber streiten ob ein Mozilla, der aus markenrechtlichen Gründen nicht mehr so heissen darf, free oder nonfree ist, will einen BSD-Kernel anbieten? Das wäre am 1. April der Brüller geworden.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Die Trademark-License der Mozilla Foundation ist wirklich ein rechtliches Problem - gut dass das thematisiert wurde.
Ein BSD lizenzierter Kernel mit LGPL lizenzierter libstdc und GPL lizenziertem Userland ist absolut kein Problem - die Lizenzen vertragen sich wunderbar.
So what?!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Das die Sache nicht 'einfach nur peinlich' war hat sich z.B. darin gezeigt, dass die Mozilla Foundation eine spezielle Lizenz für Debian aufgesetzt hat um den 'Wünschen' von Debian nachzukommen. Ich hab die Diskussion leider nicht bis am Schluss verfolgt.
Ich frag mich manchmal bei Debian auch - sie sind extrem. Andererseits, Debian macht das idR im Interesse der Community. Eine wirklich 'freie' Distribution zu haben hat viele Vorteile. Du kannst z.B. basierend auf Debian eine neue Distri aufbauen/vertreiben ohne dir allzugrosse Sorgen um Lizenzprobleme zu machen. Ein anderer Aspekt ist der Druck der durch solche, teilweise harte Massnahmen auferlegt wird. Das eine oder andere Softwareprojekt überlegt es sich dann nochmals ob sie ihre SW wirklich unter diesen 'speziellen' Bedingungen rausgeben möchte... eine imho wünschenswerte Entwicklung. Je nach Situation ists nämlich nicht ganz 'egal' welche Lizenzbedingungen jetzt da wirklich vorhanden und es geht nicht einfach drum das man den Usern ein Stück SW liefert (ja, ich wär z.B. auch heidenfroh wenn Debian endlich von Haus aus einen mplayer hätte - oder Java[1]).
Gruss
Reto
1) Ja? Wieso baut Sun so ne 'coole' Sache[2] auf und verbauens sich dann in der OSS Community mit so Lizenzen (passt nichtmal in nonfree)? Klar, z.B. Gentoo umgeht dieses Problem indem man als User das JRE Tarball selber runterladen und im distfiles Ordner platzieren muss... ist DAS die Lösung? Ehrlich?
2) Ne, keine Diskussion ob Java wirklich cool ist ;). Java hat viele Kanten und Ecken, aber ich denke unterm Strich wars ne Bereicherung für die Informatik Branche.
|
|
|
|
|
|
|
|
|
|
|
|
|
"Eine wirklich 'freie' Distribution zu haben hat viele Vorteile."
Genau darum geht es, denn eine Distribution (ich spreche hier nur von main, der Rest ist ja eh innoffiziell) ist nur frei, wenn sie zu 100% frei ist. Wenn sie nur 99.99% oder 50% frei ist, bleibt sie ingesammt unfrei.
Deshalb stoert es mich auch immer, wenn Leute von z.B. SuSe/RedHat/Mandriva/$whatever als eine freie GNU/Linux Distribution sprechen - wirklich frei (100% frei eben), sind die alle nicht. Da gibt es etliche Pakete, die man z.B. zwar frei verteilen/benutzen kann, aber gewisse zusaetzliche Einschrenken (z.B. nur nicht-kommerziell) haben.
Mplayer: soll demnaechst eventuell in Debian kommen, haengt noch in der NEW Queue.
Sun Java: es gibt bei Debian auch ein ensprechendes Build-Package.
|
|
|
|
|
|
|
|
|
|
|
|
|
Das Problem mit mplayer ist nicht die Lizenz, sondern die scheiss-Softwarepatente auf den Codecs. Die Version die dann in Debian reinkommt ist entsprechend abgespeckt.
--
"The more prohibitions there are, The poorer the people will be"
-- Lao Tse
|
|
|
|
|
|
|
|
|
|
|
|
|
<nitpick> Njein. Die Lizenz eines Programmes muss erlauben, falls patentgeschuetztes Material enthalten ist, dieses lizenzkostenfrei, ohne zeitliche Begrenzung und unwiderrufbar nutzen zu koennen. </nitpick>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"Auch das MPlayer "bald" in debian rein kommt ist genauso ein Gerücht"
Dann hast du die ensprechenden Threads auf debian-legal diesmal nicht gelesen.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Dann hast du sie halt zuwenig aufmerksam gelesen. Drei der vier alten 'Vorwuerfe' warum Mplayer nicht paketierbar ist, sind nicht mehr aktuell.
Nur die Verletzung von ein paar Patenten (in den nativen Codecs, die win32-Codecs sind sowieso illegal. DeCSS ist sowieso auch nicht mehr drin) ist noch uebrig, und im Moment gibt es noch keine Grundsatzenscheidung, wie man mit Softwarepatenten umgehen soll. Deshalb gibt es im Moment keinen Grund, Mplayer nicht hineinzulassen.
Nach Sarge und nach Entscheid ueber Softwarepatente in der EU muss man sich sowieso damit auseinandersetzen, was man mit den Paketen macht, die offensichtlich Patente verletzen (z.B. eine Wiederbelebung von non-US, diesmal wegen Patenten). Aber soweit sind wir noch nicht...
Ich persoenlich finde Mplayer in Debian nicht noetig, xine ist genauso gut.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
LOL, ich würde eher sagen, du hast die Diskussionen selber nicht gelesen. Such im Archiv nach den alten Diskussionen. Keines der Gründe die "gelöst" wurden war überhaupt jemals ein Problem. Es ging nur darum, dass die debian legal Leute MPlayer nicht mochten und irgendwelche an den Haaren herbeigezogenen Gründe suchten, damit es ja nicht rein kommt. Und wenn man diese "Gründe" ausseinandergenommen und als ungültig dargelegt hatte, wurde die ganze Sache einfach tod geschwiegen. Es ist nur der Hartnäckigkeit von Darius und Andrea zu verdanken, dass es überhaupt noch Ansätze gibt MPlayer in debian reinzubringen. Die anderen MPlayer Entwickler haben debian schon vor Jahren als zu fanatisch abgeschrieben.
Die Behauptung dass die win32 codecs illegal sind ist schlicht weg falsch! Ja, es stimmt, dass die redistribution einiger dieser Codecs nicht explizit erlaubt ist, aber der grösste Teil von ihnen ist 1) frei verteilbar und/oder 2) speziell für MPlayer erstellt worden.
DeCSS ist schon vor Jahren aus MPlayer geflogen, weil nicht gemaintaint. libdvdcss wird schon seit iirc 4 Jahren unterstützt und seit 3 Jahren hat MPlayer seinen eigenen Fork im code.
Mit Patenten musste man sich schon vorher ausseinandersetzten. Nur wird es den meissten erst jetzt bewusst, dass es sowas überhaupt gibt. Und wenn du dich informiert hättest, dann wüsstest du, dass jegliche nicht-triviale Software von Softwarepatenten betroffen ist, dh 99% von dem was in debian ist verletzt mindestens ein Softwarepatent. Und da bald Softwarpatente weltweit durchgedrückt werden müsste man ein non-earth einführen.
Last but not least: es heisst MPlayer, grosses M, grosses P, kleines "layer".
PS: falls du weiterdiskutieren willst, schick mir ein mail, symlink ist nicht das geeignete Medium hierzu
|
|
|
|
|
|
|
|
|
|
|
|
|
"Keines der Gründe die "gelöst" wurden war überhaupt jemals ein Problem."
opendivx code? keine copyrights/lizenz/herkunft des codes? Das *waren* Probleme, jetzt aber nicht mehr aktuell.
"Und wenn man diese "Gründe" ausseinandergenommen und als ungültig dargelegt hatte, wurde die ganze Sache einfach tod geschwiegen."
Jap, war leider beim zweiten Versuch, Mplayer hineinzukriegen so.
"Ja, es stimmt, dass die redistribution einiger dieser Codecs nicht explizit erlaubt ist, aber der grösste Teil von ihnen ist 1) frei verteilbar und/oder 2) speziell für MPlayer erstellt worden."
Solange nicht ein ensprechendes License-Statement in Codec-Tarball ist, sind sie illegal (und es hat bis heute *kein* License-Statement enthalten). Oder anderst: Wenn man nicht schreibt, dass sie legal sind, sind sie illegal.
"DeCSS ist schon vor Jahren aus MPlayer geflogen, weil nicht gemaintaint. libdvdcss wird schon seit iirc 4 Jahren unterstützt [...]"
Ja, mein Fehler, war zu unpraezise. Ich meinte mit DeCSS jegliche Implementierung und nicht explizit DeCSS, sondern auch libdvdcss.
"Mit Patenten musste man sich schon vorher ausseinandersetzten."
Man hat aber bisher aber noch keine Richtlinie in Debian, wie man konkret damit umgehen will. Mehr habe ich nicht gesagt.
"dann wüsstest du, dass jegliche nicht-triviale Software von Softwarepatenten betroffen ist, dh 99% von dem was in debian ist verletzt mindestens ein Softwarepatent."
Ja und? Dazu habe ich doch gar nichts gesagt. Abgesehen davon macht es sehr wohl einen Unterschied ob eine Software ein Trivialpatent verletzt, dass hoechstwahrscheinlich nicht einklagbar ist oder nicht eingeklagt werden wird, und zwischen solchen Patenten (im speziellen bei Video/Audio Kompressionsalgorithmen), bei denen man bei einer allfaelligen Patentverletzung hoechstwahrscheinlich ensprechend verklagt wird. Deshalb (Achtung, nicht meine Meinung) gibt es Leute, die meinen, man sollte Mplayer nicht hineinlassen weil er ueber kurz oder lang sowieso gleich wieder entfernt werden muesste.
"es heisst MPlayer, grosses M, grosses P, kleines "layer"."
Ich schenk dir ein 's/Mplayer/MPlayer/g', hoffentlich hast du Freude daran :)
|
|
|
|
|
|
|
|
|
|
|
|
|
opendivx code? keine copyrights/lizenz/herkunft des codes? Das *waren* Probleme, jetzt aber nicht mehr aktuell.
Die waren längst gelöst, als MPlayer sich um eine Aufnahme in Debian bemühte. Mehr noch: Als sie noch nicht gelöst waren, wehrten sich die Entwickler aktiv gegen eine Packetierung.
Solange nicht ein ensprechendes License-Statement in Codec-Tarball ist, sind sie illegal (und es hat bis heute *kein* License-Statement enthalten). Oder anderst: Wenn man nicht schreibt, dass sie legal sind, sind sie illegal.
Das ist ein Streitfall, in dem sich die Juristen keinesfalls einig sind. Wie auch immer: Die W32-Codecs sind nicht Teil der MPlayer-Distribution, sondern werden separat zum Download angeboten. Auch ohne sie lassen sich die meisten Dateien abspielen. Genau so macht es auch Xine.
Ja, mein Fehler, war zu unpraezise. Ich meinte mit DeCSS jegliche Implementierung und nicht explizit DeCSS, sondern auch libdvdcss.
libdvdcss ist zwar Teil der offiziellen Distribution, lässt sich aber einfach raustrennen. MPlayer kann dann dynamisch gegen eine externe libdvdcss binden. Genauso machen es auch Xine und VLC. Übrigens hat libdvdcss mit DeCSS mit Ausnahme der Absicht (Entschlüsselung von DVDs) nichts gemeinsam.
Man hat aber bisher aber noch keine Richtlinie in Debian, wie man konkret damit umgehen will. Mehr habe ich nicht gesagt.
Nur wirkt es etwas wenig glaubwürdig, wenn manche Software mit Hinweis auf Softwarepatente abgewiesen wird, während andere Software mit den genau gleiche Problemen in die Distri wandert.
Abgesehen davon macht es sehr wohl einen Unterschied ob eine Software ein Trivialpatent verletzt, dass hoechstwahrscheinlich nicht einklagbar ist oder nicht eingeklagt werden wird,
Uh, das grosse Problem mit Softwarepatenten ist, dass auch Trivialpatente eingeklagt werden können und auch eingeklagt werden. Nicht selten mit Erfolg, weil sich die Begklagten den Prozess schlicht nicht leisten können.
--
Linux ist eine Turboprop. HURD ist ein Düsenjetprototyp, der seinen Heimatflughafen nie verlassen hat.
|
|
|
|
|
|
|
|
|
|
|
|
|
"Die waren längst gelöst, als MPlayer sich um eine Aufnahme in Debian bemühte."
Beim ersten Versuch waren sie eben nicht geloest (Mplayer >0.50), ab dem zweiten (jetzt sind wir beim dritten), sind die geloest. Wie ich gesagt habe..
"Das ist ein Streitfall, in dem sich die Juristen keinesfalls einig sind."
Quatsch. Wenn nichts steht, gilt einfach Urheberrecht, und das automatisch. Ergo keine explizite Erlaubnis == illegal.
"Die W32-Codecs sind nicht Teil der MPlayer-Distribution[...]"
sagte ich ja bereits...
"libdvdcss ist zwar Teil der offiziellen Distribution, lässt sich aber einfach raustrennen."
sagte ich ja bereits...
Nur wirkt es etwas wenig glaubwürdig, [...] Uh, das grosse Problem mit Softwarepatenten ist,[...]"
Tja, wie ich gesagt habe.. da wird man halt noch eine gemeinsamen Standpunkt finden werden muessen (post-Sarge).
|
|
|
|
|
|
|
|
|
|
|
|
|
Beim ersten Versuch waren sie eben nicht geloest (Mplayer >0.50), ab dem zweiten (jetzt sind wir beim dritten), sind die geloest. Wie ich gesagt habe..
In 0.90 waren sie gelöst. Die MPlayer-Jungs haben selbst bis zu dieser Version klar festgelegt, dass jegliche Binaries aus technischen Gründen unerwünscht und darüber hinaus illegal sind. Ob jemand anderes vorher schon versuchte, MPlayer in Debian zu bringen, entzieht sich meiner Kentnis.
Quatsch. Wenn nichts steht, gilt einfach Urheberrecht, und das automatisch. Ergo keine explizite Erlaubnis == illegal.
Nah dran, aber nicht ganz. ;-) Der Urheber muss mal in irgend einer Form die Erlaubnis erteilt haben. Die Lizenz muss aber nur mit dem Code mitgegeben werden, wenn dies so verlangt wurde. Juristisch ist die LICENSE-Datei als Vertrag sowieso nicht anerkannt.
"Die W32-Codecs sind nicht Teil der MPlayer-Distribution[...]"
sagte ich ja bereits...
"libdvdcss ist zwar Teil der offiziellen Distribution, lässt sich aber einfach raustrennen."
sagte ich ja bereits...
Schön. Aber warum sind das dann Hinderungsgründe gegen eine Aufnahme von MPlayer in Debian?
Tja, wie ich gesagt habe.. da wird man halt noch eine gemeinsamen Standpunkt finden werden muessen (post-Sarge).
Und es wirkt sehr unglaubwürdig, wenn man drei Jahre dokumentierte Diskriminierung damit begründet, man habe noch keine allgemeine Regelung gefunden (aber diese komme bald). In einem System wohlgemerkt, wo suscht jede Hafechäs reglementiert isch.
--
Linux ist eine Turboprop. HURD ist ein Düsenjetprototyp, der seinen Heimatflughafen nie verlassen hat.
|
|
|
|
|
|
|
|
|
|
|
|
|
"In 0.90 waren sie gelöst."
Das habe ich doch alles schon gesagt.. Liest du eigentlich auch, was ich davor geschrieben habe?
"Der Urheber muss mal in irgend einer Form die Erlaubnis erteilt haben."
Wenn diese angeblich erteilte Erlaubnis aber *nirgens* auffindbar ist, dann geht man davon aus, dass es sie wohl nie gegeben hat. Die Beweislast liegt bei dem, der eine entsprechende Erlaubnis vorgibt zu besitzen, nicht bei anderen.
"Schön. Aber warum sind das dann Hinderungsgründe gegen eine Aufnahme von MPlayer in Debian?"
Weil die damals verwendete DeCSS-Implementierung nicht so einfach rauszukriegen war, wie die jetzt verwendete libdvdcss. Am besten liest du einfach nochmal durch, was ich oben geschrieben habe.
Die win32-Codecs waren nie das problem, da nicht offiziell (habe ich bereits gesagt), verbleibend sind nur die eventuellen Patentverletzungen in den nativen Codecs (habe ich ebenfalls bereits gesagt, narf).
"man habe noch keine allgemeine Regelung gefunden"
Ist trotzdem so, leider.
|
|
|
|
|
|
|
|
|
|
|
|
|
"In 0.90 waren sie gelöst."
Das habe ich doch alles schon gesagt.. Liest du eigentlich auch, was ich davor geschrieben habe?
Du hast geschrieben, beim ersten Versuch, MPlayer in Debian zu bringen, seien die Probleme nicht gelöst gewesen. 0.90 war der erste, offizielle Versuch. Wenn irgendwas davor war, war dies erstens nicht vom MPlayer-Team, und zweitens gegen dessen Willen.
Wenn diese angeblich erteilte Erlaubnis aber *nirgens* auffindbar ist, dann geht man davon aus, dass es sie wohl nie gegeben hat. Die Beweislast liegt bei dem, der eine entsprechende Erlaubnis vorgibt zu besitzen, nicht bei anderen.
Die LICENSE-Datei ist kein Beweis. Höchstens ein Indiz. Wenn der Urheber behauptet, er wisse von nichts, siehts ohnehin düster aus.
Weil die damals verwendete DeCSS-Implementierung nicht so einfach rauszukriegen war, wie die jetzt verwendete libdvdcss.
Das Gegenteil ist der Fall. DeCSS war nie Bestandteil von MPlayer. MPlayer konnte lediglich (via libdvdread) darauf zugreifen.
Die win32-Codecs waren nie das problem, da nicht offiziell (habe ich bereits gesagt),
OK, das hab ich anders verstanden. Aber gut.
verbleibend sind nur die eventuellen Patentverletzungen in den nativen Codecs (habe ich ebenfalls bereits gesagt, narf).
Und da hat man noch keine allgemeine Regelung gefunden, ich weiss. Seit über drei Jahren schiebt man die vor sich her. Letztes Mal, als in der Schweiz die Bearbeitung einer Volksinitiative so lange ging, gab es einen solchen Tumult, dass verbindliche Fristen eingeführt wurden. ;-)
--
Linux ist eine Turboprop. HURD ist ein Düsenjetprototyp, der seinen Heimatflughafen nie verlassen hat.
|
|
|
|
|
|
|
|
|
|
|
|
|
"0.90 war der erste, offizielle Versuch."
Nein, irgendwas vor 0.50 war der erste offizielle Versuch. Kannst du nachlesen auf den ensprechenden Mailinglisten..
"Die LICENSE-Datei ist kein Beweis. Höchstens ein Indiz."
Das sehen Gerichte anderst, vergl. alle GPL-vs.-$evil_corp Prozesse.
"Wenn der Urheber behauptet, er wisse von nichts, siehts ohnehin düster aus."
Das ist ein anderes Problem, wenn 'Urkunden' gefaelscht werden. Darum geht es nicht.
"DeCSS war nie Bestandteil von MPlayer. MPlayer konnte lediglich (via libdvdread) darauf zugreifen."
Mir egal, wie die vorherige verwendete Implementierung hiess. Diese war jedenfalls nicht so einfach rauszupatchen und jede Software, die diese enthaelt, ist fuer Debian nicht paketierbar.
"Letztes Mal, als in der Schweiz die Bearbeitung einer Volksinitiative so lange ging, gab es einen solchen Tumult, dass verbindliche Fristen eingeführt wurden. ;-)"
Tja, Projekte nicht kommerzieller Art getragen von Freiwilligen haben nicht nur Vorteile.
|
|
|
|
|
|
|
|
|
|
|
|
|
Nein, irgendwas vor 0.50 war der erste offizielle Versuch.
Defintiv nicht. Und würdest du das auf den mplayer-devel Listen behaupten, würdest du dafür wahrscheinlich gelyncht. Zu jenem Zeitpunkt versuchte das Team, eine Packetierung um jeden Preis zu vermeiden. Also wenn irgendwas kam, dann war das ein Maverick.
Das sehen Gerichte anderst, vergl. alle GPL-vs.-$evil_corp Prozesse.
Ich kenne die Prozesse, und die kurze Antwort ist "Nein". Wenn du die lange Antwort wissen willst, mail mich bitte direkt an. Meine Adresse findest du auf meiner Homepage.
Mir egal, wie die vorherige verwendete Implementierung hiess. Diese war jedenfalls nicht so einfach rauszupatchen und jede Software, die diese enthaelt, ist fuer Debian nicht paketierbar.
Herrje, liest du eigentlich, was ich schreibe? Man musste sie gar nicht rauspatchen. Es war eine externe Library, und wenn die nicht da war, wurde sie nicht genutzt. Punkt und aus.
Tja, Projekte nicht kommerzieller Art getragen von Freiwilligen haben nicht nur Vorteile.
Offensichtlich
--
Linux ist eine Turboprop. HURD ist ein Düsenjetprototyp, der seinen Heimatflughafen nie verlassen hat.
|
|
|
|
|
|
|
|
|
|
|
|
|
"Defintiv nicht."
Nope. Versuch 1:Anfang, Ende. Den Thread dazwischen darst du selber lesen (und im speziellen diesen auf -legal). Zu dieser Zeit war Mplayer Version 'irgendwas vor 0.50' aktuell.
"Ich kenne die Prozesse, und die kurze Antwort ist "Nein"."
Ebenfalls, aber die Antwort ist 'ja'.
"Wenn du die lange Antwort wissen willst, mail mich bitte direkt an. Meine Adresse findest du auf meiner Homepage."
Meine steht sogar neben meinem Namen, da darfst du die lange Antwort gerne hinschicken.
"Man musste sie gar nicht rauspatchen. Es war eine externe Library, und wenn die nicht da war, wurde sie nicht genutzt. Punkt und aus."
Du hast recht, es war auch damals schon extern. Allerdings war es DeCSS (das wirkliche original, vergl. CVS von 20010701).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Wofuer braucht man denn ein absolut freies System?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ich glaube, du verwechselst da auch was. Das Mozilla-Foundation-vs.-Debian Problem besteht im wesentlichen aus zwei Dingen:
- Wenn Mozilla-{Firefox,Thunderbird} mit nicht 'offiziellen' Extensions ausgestattet wird und/oder andere Standardeinstellungen hat, darf er nicht mehr Mozilla-{Firefox,Thunderbird} heissen.
- Die Logos von Mozilla-{Firefox,Thunderbird} sind non-free.
Der Linux-Kernel sollte aus anderen Gruenden nach non-free (Firmware und andere binary-blobs etc., das ist aber alles post-sarge), nicht aber wegen dem Namen selbst: Die GPL fordert nicht eine Umbenennung des veraenderten Programmes bei einer davon abgeleiteten Version. Die alten Mozilla Trademarks forderten aber genau das.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Hast du dazu einen Thread parat? Den muss ich wohl nicht gelesen haben.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
"Debian ist in seiner Auslegung von free und nonfree noch um Dimensionen radikaler als RMS."
Klar, und das ist auch gut so. Die FSF z.B. betrachtet ein Spiel, dessen Engine frei ist aber die Graphiken, Sounds etc. unfrei sind, trotzdem insgesammt als frei. Das ist definitiv falsch, und warum sollte man einer falschen Einschaetzung folgen? Nur weil sie von der FSF ist?
"[...] feuerfeste Unterwäsche zulegen."
Nicht noetig, im Gegensatz zum Markenrecht sind die Lizenzmischungen (GPL, LGPL und BSD) relativ trivial.
|
|
|
|
|
|
|
|
|
|
|
|
|
Die FSF z.B. betrachtet ein Spiel, dessen Engine frei ist aber die Graphiken, Sounds etc. unfrei sind, trotzdem insgesammt als frei. Das ist definitiv falsch, und warum sollte man einer falschen Einschaetzung folgen?
Wie kommst Du auf die Idee?
Die Einschaetzung ist korrekt. Was zählt ist das Program (=die Engine), nicht die Daten. Denn dann hast Du die Moeglichkeit ein eigenes Spiel mit der Engine zu programmieren.
Bei freien Daten ohne freier Engine, musst Du die Engine programmieren. Viel Spass.
|
|
|
|
|
|
|
|
|
|
|
|
|
Das Spiel als Gesammtes ist nicht frei, weil du keine oder nicht alle der vier Freiheiten fuer die Grafiken/Sounds hast.
Die Engine alleine fuer sich gesehen ist schon frei, das ist klar. Die FSF (namentlich Georg Greve) sagt aber, das Spiel als gesamtes mit den Grafiken/Sounds ist frei.
Ob man dem zustimmen will, ist jedem selber ueberlassen. Ich und viele andere tun das jedenfalls nicht.
|
|
|
|
|
|
|
|
|
|
|
|
|
Ja gut. Dann splittet man das Paket in die Engine (im main-Teil) und in die Supportfiles ([Sound, Graphiken etc, Startscripts] im contrib-Teil).
|
|
|
|
|
|
|
|
|
|
|
|
|
Ein Programm in main darf nicht auf Dinge in contrib Dependen..
|
|
|
|
|
|
|
|
|
|
|
|
|
Ein Programm in main darf nicht auf Dinge in contrib Dependen..
Das bräuchte es auch nicht. Es müßte eben in Contrib ein Metapaket sein das die Engime aus main und Grafik, Sound etc. aus contrib installiert. Alternativ könnte man natürlich auch in den Paketen in Contrib untereinander und zu der Engine in main Abhängigkeiten einbauen.
Das Problem ist viel mehr und das ist wohl auch gemeint, was ist wen ich eine OSS-Engime aber Sounds, Grafik & Co. unter einer CSS Lizenz bzw. einer nicht konformen Lizenz habe?
Grüße
sturmkind
REALITY.SYS corrupted! reboot universe [Y,n]?
|
|
|
|
|
|
|
|
|
|
|
|
|
Was heisst nicht konform?
Wenn die Supportfiles nicht den Richtlinien im main entsprechen, aber denjenigen in contrib, kann man es in den contrib Ast setzen mit einer Dependency auf die Engine, die in main ist.
Die Engine hat keine Dependencies und ist in Main.
Kein Problem. Schliesslich kann man mit ihr andere Spiele programmieren.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Sunday 10. April 2005, 13:20 MEW (#24)
|
|
|
|
|
moment, an contrib gibt es die gleichen anforderungen wie an main, mit einer ausnahme: es darf dependencies auf andere pakete in contrib oder non-free geben
im konktreten fall müsste die engine (wenn sie dependencies hat) nach contrib, wenn nicht dann kann sie nach main
die art gehört in jedem fall nach non-free
falls die engine keine dependencies zur art hat, könnte man jetzt in contrib ein meta paket bauen
|
|
|
|
|
|
|
|
|
|
|
|
|
Ich gehe davon aus, dass die Engine keine Dependencies zur Art hat (vgl. Z-Code Interpreter)
|
|
|
|
|
|
|
|
|
|
|
|
|
seit wann ist radikalität peinlich?
|
|
|
|
|
|
|
|
|
|
|
|
|
Sehe ich das falsch oder könnte man den BSD-Kernel aufgrund der BSD-Lizenz nicht auch unter die GPL stellen?
Grüße
sturmkind
REALITY.SYS corrupted! reboot universe [Y,n]?
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Sunday 10. April 2005, 13:28 MEW (#25)
|
|
|
|
|
Wenn du dir den Haß sämtlicher BSD-Entwickler auf
der Welt zuziehen willst, bitte.
Außerdem sind noch Teile mit 4-Clause UCB-Lizenz
drin, die gehen nicht.
|
|
|
|
|
|
