{"id":100422,"date":"2021-06-03T16:23:37","date_gmt":"2021-06-03T14:23:37","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/proekt-gcc-razreshil-priyom-izmenenij-bez-peredachi-fondu-spo-prav-na-kod"},"modified":"2021-06-03T16:23:37","modified_gmt":"2021-06-03T14:23:37","slug":"proekt-gcc-razreshil-priyom-izmenenij-bez-peredachi-fondu-spo-prav-na-kod","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/proekt-gcc-razreshil-priyom-izmenenij-bez-peredachi-fondu-spo-prav-na-kod","title":{"rendered":"Das GCC-Projekt hat \u00c4nderungen ohne die \u00dcbertragung der Rechte an den Code an die Open Source Foundation zugelassen.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Das Komitee, das die Entwicklung des GCC-Compiler-Sets leitet (GCC Steering Committee), hat die Praxis der verpflichtenden \u00dcbertragung von Eigentumsrechten am Code an die SPI Foundation eingestellt. Entwickler, die \u00c4nderungen am GCC vornehmen m\u00f6chten, sind nicht mehr verpflichtet, eine CLA-Vereinbarung mit der SPI Foundation zu unterzeichnen. Zur Teilnahme an der Entwicklung gen\u00fcgt es nun, zu best\u00e4tigen, dass der Entwickler das Recht auf die Code\u00fcbertragung hat und nicht versucht, fremden Code f\u00fcr sich zu beanspruchen. <\/p>\n
Entwickler, die nicht bereit sind, einen CLA-Vertrag mit der Free Software Foundation zu unterzeichnen, haben die M\u00f6glichkeit, die Bedingungen des Developer Certificate of Origin (DCO) zu nutzen, die seit 2004 bei der \u00dcbertragung von \u00c4nderungen zum Linux-Kernel angewendet werden. Gem\u00e4\u00df den DCO-Regeln wird die Autorenschaft durch das Hinzuf\u00fcgen der Zeile \u201eSigned-off-by: Name und E-Mail des Entwicklers\u201c zu jeder \u00c4nderung verfolgt. Durch das Hinzuf\u00fcgen dieser Signatur zu einem Patch best\u00e4tigt der Entwickler sein Urheberrecht an dem \u00fcbergebenen Code und stimmt dessen Verbreitung im Rahmen des Projekts oder als Teil des Codes unter einer Open-Source-Lizenz zu. <\/p>\n
Fr\u00fcher mussten Entwickler eine spezielle Vereinbarung unterzeichnen, die alle Eigentumsrechte an ihrem Code an die OSS-Stiftung \u00fcbertrug. Jetzt wird eine solche Vereinbarung auf Wunsch unterzeichnet, und der Entwickler kann die Rechte an seinem Code behalten. Somit werden die Eigentumsrechte am GCC-Code k\u00fcnftig zwischen der OSS-Stiftung und den Entwicklern verteilt, die die Vereinbarung nicht unterzeichnet haben. <\/p>\n
Eine solche Verteilung erschwert die Anpassung der Verbreitungsbedingungen f\u00fcr das Projekt, da f\u00fcr eine Lizenz\u00e4nderung das pers\u00f6nliche Einverst\u00e4ndnis jedes Entwicklers erforderlich ist, der die Rechte nicht an die FSF \u00fcbertragen hat. Das Zur\u00fcckziehen der Rechte von der FSF wird jedoch den m\u00f6glichen Wechsel zu zuk\u00fcnftigen GPL-Versionen nicht komplizieren, da GCC unter der Lizenz \u201eGPLv3 oder neuer\u201c verbreitet wird, was eine \u00c4nderung der Lizenz auf GPLv4 ohne separate Zustimmung jedes Entwicklers erm\u00f6glicht. Zu den positiven Effekten des Verzichts auf die obligatorische \u00dcbertragung der Rechte am Code geh\u00f6rt die erh\u00f6hte Attraktivit\u00e4t der Beteiligung von Unternehmen an der Entwicklung von GCC sowie von Mitarbeitern gro\u00dfer Firmen, die zuvor zus\u00e4tzliche Zustimmung f\u00fcr die Unterzeichnung von Vertr\u00e4gen bei verschiedenen Institutionen und Rechtsdiensten einholen mussten. So hat beispielsweise Apple einst auf die \u00dcbertragung ihrer \u00c4nderungen an GCC an die FSF verzichtet und sich stattdessen auf die Entwicklung von LLVM konzentriert. <\/p>\n
Indem der SPO-Fonds die Eigentumsrechte in einer Hand b\u00fcndelte, trat er als Garant f\u00fcr die Beibehaltung der Verbreitungspolitik der Projekte nur unter freien Lizenzen auf und erf\u00fcllte die Aufgabe, die Gemeinschaft vor \u00c4nderungen des urspr\u00fcnglich festgelegten Entwicklungskurses zu sch\u00fctzen (zum Beispiel verhinderte er die m\u00f6gliche Einf\u00fchrung einer doppelten\/commerziellen Lizenz oder die Herausgabe geschlossener propriet\u00e4rer Produkte durch separate Vereinbarungen mit den Codeautoren). Der SPO-Fonds konnte auch an der Beilegung von Rechtsstreitigkeiten im Namen der Entwickler teilnehmen und eigenst\u00e4ndig Entscheidungen \u00fcber \u00c4nderungen der Lizenzbedingungen treffen (zum Beispiel den Wechsel auf eine neue Version der GPL-Lizenz forcieren). <\/p>\n
Einige Entwickler haben die Entscheidungen des GCC-Managementausschusses kritisiert, der einen Beschluss ohne vorherige Diskussion in der Community gefasst hat. Es fand zwar eine Diskussion statt, jedoch konzentrierte sich diese auf die Sinnhaftigkeit einer weiteren Zusammenarbeit zwischen dem GCC und dem GNU-Projekt sowie der Free Software Foundation. Echos dieser Diskussion spiegeln sich in der im Ank\u00fcndigung genannten Aussage wider: \u201eDer GCC wurde als Teil des GNU-Projekts gegr\u00fcndet, hat jedoch das Stadium erreicht, in dem er als autonomes Projekt agieren kann.\u201c <\/p>\n
Die Bedenken beziehen sich darauf, dass ohne zentralisierten Rechtebesitz am gesamten Code Verwirrung bei der Genehmigung von Lizenzfragen entstehen k\u00f6nnte. W\u00e4hrend fr\u00fcher alle Anspr\u00fcche auf Lizenzverletzungen durch die Zusammenarbeit mit einer Organisation geregelt wurden, wird nun die Quelle von Verst\u00f6\u00dfen, einschlie\u00dflich unbeabsichtigter, unvorhersehbar und erfordert eine Abstimmung mit jedem einzelnen Beteiligten. Als Beispiel wird die Situation mit dem Linux-Kernel angef\u00fchrt, wo einzelne Kernel-Entwickler Klagen anstrengen, unter anderem um pers\u00f6nlichen Gewinn zu erzielen. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"