|
Questo articolo nasce da un commento che ho trovato su Molto Linux quando stavo cercando materiale per il mio post su Gnome 3.2: systemd? Gnome OS? Niente più supporto per piattaforme NO-LINUX?. |
Un lettore di quel portale si chiedeva più o meno, ironicamente, che gli gnomi fumassero. A cui alcuni AntiUbuntu radicali (non sono un professionista radicale di Ubuntu, solo che non condivido con chi ama ridicolizzare o ironizzare sugli altri con il solo desiderio di difendere o sminuire qualcosa, siano essi utenti del Sistema Operativo qualunque) hanno risposto con un link a Wikipedia su Accordo collaboratore di Canonical.
Con totale correttezza l'autore del post, MetalByte, ha mostrato che il commentatore stava distogliendo l'attenzione e che Gnome non è esattamente sacro come vorrebbe apparire, per diversi fatti, tra cui la violazione degli standard di freedesktop.org.
Standard che, paradossalmente, Shell Unity e KDE Environment, tra gli altri - anche Gome per molti aspetti - rispettano.
Non per questo motivo ha smesso di attirare la mia attenzione, non solo come avvocato, ma come utente di Ubuntu.
Le informazioni trovate sono piuttosto ricche, ho letto e riletto da qualche ora il contratto di licenza di 1 (una) pagina proposto da Canonical e ci sono dati abbastanza curiosi.
Prima di tutto dobbiamo tenere a mente che Ubuntu è sviluppato da Canonical Ltd. non da Canonical Foundation, per un semplice motivo, Shuttleworth ha creato una società, non una Fondazione.
Secondo, non lasciatevi trasportare dal titolo del link, è vero che possiamo trovare argomenti che non sono espressamente vietati, ma non implicano nulla. Qui in Argentina tutto ciò che non è espressamente proibito è implicitamente consentito.
Non sono a conoscenza della legislazione e della giurisdizione inglese a cui si sottomette il CLA nella sua clausola 12.
Ora, Wikipedia definisce l'accordo del collaboratore di Canonical all'interno della categoria del contratto di licenza del collaboratore. Prima di tutto, quindi, dobbiamo sapere cos'è quest'ultimo.
Secondo Wikipedia Contratto di licenza del collaboratore (CLA) definisce i termini in base ai quali la proprietà intellettuale viene conferita o assegnata a un'azienda o a un progetto. Molto comune nell'open source.
Ci sono generalmente due ragioni che motivano il CLA: (1) per proteggere meglio il progetto, (2) o per riprendere la licenza senza consultare il contributore.
Bene, questo tipo di licenza viene utilizzato da e tra gli altri:
- Apache Software Foundation
- MySQL
- OpenOffice.org
- Fedora (Red Hat) Fedora CLA, simile a Canonical.
- Canonical Ltd.
- Zend per Zend Framework
- Free Software Foundation
- Django
- Node.js
- Diaspora
Ritengo opportuno analizzare alcune clausole del Fedora - Red Hat CLA e confrontarle con quella di Canonical, non solo per le somiglianze inerenti alla classe, ma anche per le evidenti differenze.
Ma anche, a causa della tilde costante di Canonisoft senza considerare gli altri attori dell'Open Source, iniziamo, nel suo CLA Canonical esplicita e definisce gli scopi del suo contratto, e si definisce un «detentore del copyright».
Quindi, quello che fanno è chiedere al contributore / sviluppatore di compilare un modulo attraverso il quale assegnano il copyright a Canonical (e Fedora dove appropriato) e in cambio ricevono il diritto senza royalty, perpetuo, mondiale, utilizzare, copiare, modificare, comunicare e mettere a disposizione del pubblico (se si vuole tramite Internet) e distribuire, in ogni caso in forma originale o modificata, i contributi effettuati o "codice concesso in licenza" chiamandolo in qualche modo.
Canonical mi concede un diritto mondiale, non esclusivo, esente da royalty e perpetuo di utilizzare, copiare, modificare, comunicare e rendere disponibile al pubblico (incluso, senza limitazione, tramite Internet) e distribuire, in ogni caso in un originale o forma modificata, i Contributi Assegnati come desidero.
Clausola II CLA Canonical.
Ora, come procede uno sviluppatore? Basta scaricare il CLA e inviare un'e-mail allegandolo e nel corpo dell'e-mail si dice: "Accetto il Canonical Contributor Agreement allegato". Questo nel caso del CLA di Canonical, che ha suscitato l'interesse di questo articolo.
Così semplice.
Alcuni confronti con Fedora CLA - Red Hat.
Innanzitutto, dobbiamo sapere che sviluppare software per Ubuntu non significa che debba aderire al CLA, sarà richiesto se il software sviluppato o modificato è per il Catalogo software fornito dal CLA, ad esempio qualsiasi modifica degli indicatori, ecc.
Tuttavia, secondo il CLA, lo sviluppatore cede a Canonical garantendo completamente il copyright, logico se Canonical sarà il titolare.
L'incarico viene effettuato garantendo un diritto d'autore non esclusivo, esente da royalty e in perpetuo da utilizzare, copiare, modificare, comunicare e mettere a disposizione del pubblico (se si vuole tramite internet) e distribuire, in ogni caso, sia esso il codice originale o modificati.
In altre parole, Canonical si basa nello stesso modo in cui Canonical premia lo sviluppatore. Clausole 1 e 2 rispettivamente.
Nulla può essere assegnato che sia oggetto di un altro contratto o contratto di lavoro (clausola 9) o codice che possa o possa violare il diritto d'autore.
1. Con la presente cedo a Canonical a pieno titolo la garanzia di tutti i diritti d'autore ora o in futuro sussistenti in qualsiasi parte del mondo in qualsiasi Contributo assegnato. Nella misura in cui questa cessione è per qualsiasi motivo inefficace e soggetta ai diritti di Canonical in 5 di seguito, concedo a Canonical una licenza mondiale, non esclusiva, esente da royalty e perpetua per utilizzare, copiare, modificare, comunicare e creare a disposizione del pubblico (incluso senza limitazione tramite Internet) e distribuire, in ogni caso in forma originale o modificata, i «Contributi Assegnati» come desidera.
2. Canonical mi concede un diritto mondiale, non esclusivo, esente da royalty e perpetuo di utilizzare, copiare, modificare, comunicare e rendere disponibile al pubblico (incluso, senza limitazione, tramite Internet) e distribuire, in ogni caso in un modulo originale o modificato, i Contributi Assegnati come desidero.
Clausole 1 e 2 CLA Canonical
Da parte sua, il Fedora - Red CLA dice:
2. Concessione di licenza del collaboratore. Con la presente concedi a Red Hat, Inc., per conto del Progetto, e ai destinatari del software distribuito dal Progetto:
(a) una licenza di copyright perpetua, non esclusiva, mondiale, interamente pagata, esente da royalty e irrevocabile per riprodurre, preparare lavori derivati, mostrare pubblicamente, eseguire pubblicamente, concedere in sublicenza e distribuire il Contributo e tali opere derivate; e,
(b) una licenza di brevetto perpetua, non esclusiva, mondiale, interamente versata, esente da royalty, irrevocabile (soggetta alla Sezione 3) per fare, avere fatto, utilizzare, offrire di vendere, vendere, importare e trasferire in altro modo il Contributo e le sue opere derivate, laddove tale licenza si applica solo a quelle rivendicazioni di brevetto concesse in licenza da te che sono necessariamente violate dal tuo contributo da solo o dalla combinazione del tuo contributo con il lavoro a cui hai inviato il contributo. Ad eccezione della licenza concessa in questa sezione, ti riservi tutti i diritti, i titoli e gli interessi sui tuoi Contributi.
Clausola 2 CLA Fedora.
Tornando a Canonical, nella clausola 3 si concettualizza che dovrebbe essere inteso come Software, molto comune in materia contrattuale.
E dice che il termine Software utilizzato DENTRO e PER il contratto, si riferisce a tutti i programmi per computer creati come parte del Programma canonico. Elenco che, per ovvi motivi, può essere modificato di volta in volta.
Nella clausola 4, concettualizza i contributi assegnati come modifiche o miglioramenti apportati al codice dallo stesso sviluppatore.
Una delle clausole interessanti è la sesta, poiché in essa il CLA obbliga Canonical ad offrire il codice conforme, e secondo i termini della "Licenza Software Libero", secondo la definizione che la FSF fornisce sull'argomento e aggiorna ogni a volte.
Ma questa è la porta aperta se vuoi, perché Canonical, a sua discrezione, può rendere il software disponibile al pubblico in base ad altri "termini di licenza", che non sono la stessa cosa di "un'altra licenza". Come abbiamo visto, questo è comune e uno degli scopi dell'Accordo di licenza del collaboratore.
Canonical metterà normalmente a disposizione del pubblico i Contributi Assegnati sotto una "Licenza Software Libero", secondo la definizione di quel termine pubblicata di volta in volta dalla Free Software Foundation. Canonical può anche, a sua discrezione, rendere disponibili al pubblico i Contributi assegnati in base ad altri termini di licenza.
Clausola 6 CLA Canonical
Qualcosa di simile accade con Fedora, al punto 2 - (a) il CLA consente a Fedora - Red Hat di sublicenziare, senza menzionare in quali termini o sotto quale licenza.
In confronto, il CLA di Fedora è più permissivo e, se vuoi, dannoso per l'open source, poiché il CLA di Canonical lo costringe a distribuire sotto FSL o altri termini di licenza. Invece Fedora - Red Hat potrà concedere in licenza e sublicenziare sotto qualsiasi licenza e termini desideri.
Ma il più eclatante di tutti, e che salta in difesa, se volete, di Canonical contro Fedora, è che il CLA di quest'ultima al punto 2 - (b) autorizza Fedora - Red Hat, tra le altre cose e in alcune situazioni che il CLA spiega, per vendere il contributo dello sviluppatore.
Allo stesso modo, Canonical non farà valere nei confronti dello sviluppatore alcun brevetto che sia stato violato dallo sviluppatore, esercitando il TUO copyright sul Software o sui Contributi assegnati.
[…] Canonical non rivendicherà né farà valere nei miei confronti alcun brevetto violato da Me esercitando i miei diritti di copyright sul Software e / o sui Contributi assegnati.
Clausola 7 in fine CLA Canonical.
Al contrario, Fedora - Red Hat, nella clausola 3 del suo CLA lascia aperta la possibilità che, in caso di un possibile contenzioso, l'incarico possa cadere e il Collaboratore sia responsabile in tribunale.
Da parte di Canonical, lo sviluppatore non farà valere alcun brevetto contro: (a) Canonical; (b) chiunque riceva il Software o il Contributo assegnato da Canonical; (c) Chiunque abbia ricevuto il Software o Contributi assegnati ai sensi della Licenza Software Libero quando i brevetti vengono violati dall'esercizio del Copyright. Che è logico.
Non rivendicherò o imporrò alcun brevetto contro (a) Canonical (b) chiunque abbia ricevuto il Software e / o i Contributi assegnati da Canonical o (c) chiunque abbia ricevuto il Software e / o i Contributi Assegnati in base a una Licenza Software Libero, laddove tale brevetto venga violato da qualcuno di loro che esercita i diritti di copyright sul Software e / o sui Contributi assegnati. [...]
Clausola 7 CLA Canonical.
Di conseguenza possiamo dire che CLA, utilizzato molto spesso nel mondo open source, è completamente logico e giustificabile. Inoltre, il confronto dei CLA di Fedora - Red Hat e Canonical rivela elementi favorevoli per le parti, di cui beneficiano entrambe (parti e società).
Sicuramente il punto più controverso è la possibilità che entrambe le società (dico entrambe perché le analizziamo brevemente entrambe) siano riservate alla sublicenza. Il Fedora CLA - Red Hat lo dice apertamente ma non chiarisce in quali termini pubblicherà il contenuto, tanto meno in quali termini lo farà in caso di sublicenza.
Nel caso di Canonical, è obbligato a utilizzare la Licenza del software libero in conformità con i termini della Free Software Foundation, ma può modificare arbitrariamente i termini della licenza, come dichiarato nel CLA, "altri termini di licenza" senza che ciò implichi, in alcun Nella maggior parte dei casi, utilizzare una licenza non libera o proprietaria.
Consiglio anche di leggere Progetto Harmony, che è estremamente interessante.
Penso che invece di limitarsi a parlare sarebbe meglio dedicare 10 minuti e analizzare il problema in questione. Dico questo e porto come esempio il caso del commento che ha motivato lo studio e l'assemblea della voce.
Molti che non sono d'accordo con Canonical / Ubuntu o la sua "accettazione", invece di cercare elementi oggettivi, ricorrono a lamentele che non fanno altro che generare Flames e non ci portano da nessuna parte.
Infine, non sono responsabile dell'utilizzo di quanto detto, è solo un'analisi di base del CLA di, in questo caso, entrambe le società.
beh, di per sé canonica è pur sempre un'azienda (e ha il diritto di lasciare quelle "estremità aperte") ... forse adesso è l'amico di tutti, quello che sta mettendo Linux a disposizione delle persone. in futuro le persone inizieranno a chiedersi; Come sono diventato così indispensabile? Non si sono proposti 200 milioni di utenti in 4 anni? Forse allora si comincia a dubitare delle loro azioni. O nessuno si ricorda di Google? Non ha iniziato solo essendo un buon cercatore ... Come ho detto, per me sono solo finali aperti ...
Forse l'esempio di Google è stato la metà di troppo, ma è vero che hanno quell'obiettivo, che lo raggiungano o meno è un'altra questione. Se guardi Linux, è un sistema operativo che può essere definito stabile, ma oggi molti cambiamenti stanno avvenendo in X…. Non solo Canonical ma le distribuzioni in gral. puntano a entrare negli occhi degli utenti ... se continuano così, non credo che gli obiettivi proposti siano così inverosimili. Attenzione, continuo a dare la mia opinione da lontano! = D
Sono d'accordo con il finale aperto. Su quello di 200 milioni di utenti, non può essere paragonato a Google, principalmente perché per crescere a quel numero di utenti dovrebbe accadere:
1- Che nel mondo GNU / Linux le altre distribuzioni non vengono più utilizzate, ed è impossibile, ci sono prodotti di qualità pari o superiore a Ubuntu.
2- Windows, per qualche motivo, ha smesso di essere utilizzato in modo quasi massiccio.
3- Se entri nel mercato di tablet, smartphone e altri, devi vedere che accettazione ha.
4- Tra gli altri.
Penso che sia più un'utopia e un nord da affrontare.
Ora non è che sia amico di tutti, ma oggi è oggetto di critiche, produttive e non produttive, è evidente dal posto che occupa. Succede che molte cose criticate su uno siano presenti anche negli altri. Oppure si trova un elemento e senza approfondirlo viene utilizzato come critica distruttiva, e con soli 5 ′ troviamo una realtà diversa. Come dice il proverbio, è più facile vedere la paglia negli occhi di qualcun altro. Con questo non intendo dire che Fedora - Red Hat sia un orco, ma semplicemente un esempio.
Forse l'open source è anche un modello di business.
«Vogliono entrare negli occhi degli utenti ...» Siamo totalmente d'accordo
Sono d'accordo ragazzi! Penso che ciò che Martín solleva in questo articolo sia fantastico, perché generalmente Ubuntu viene criticato solo x criticare (troll) e molte volte quando approfondiamo gli argomenti ci rendiamo conto che 1) non sono veri o 2) altre distribuzioni fanno lo stesso o "peggio ". Insomma, è un dibattito interessante quello che apre Martín. Onestamente non ero a conoscenza dell'esistenza di queste licenze di contribuzione. Certo, la sua esistenza è logica ma non ci avevo mai pensato.
Mi congratulo con te Martín! Un altro ottimo articolo!
Pablo.
Il tuo articolo è molto interessante, come si suol dire "nessuno sa per chi lavora" Ecco perché leggiamo sempre i contratti!
La domanda è buona, perché non è una questione di leggi, ma strategica. Una cosa è il copyright, un'altra è la licenza, che può essere chiunque.
Ciò che viene trasferito è il copyright. E Canonical distribuisce, in linea di principio, con la Licenza Software Libero, puoi, se necessario, modificare i termini della licenza. Qui entra in gioco l'interpretazione di "altri termini di licenza". Poiché "altri termini di licenza" non è la stessa di "altra licenza".
Nel caso di Fedora, più o meno lo stesso, solo che Fedora - Red Hat non si impegna a concedere in licenza o sublicenziare sotto alcuna licenza. Puoi farlo dove, quando e come vuoi. Anche, a differenza di Canonical, Fedora-Red Hat menziona espressamente che, in un contenzioso in conseguenza del codice assegnato, "ti aggiusti da solo e l'incarico cade". Canonical, l'unico riferimento a questo è quello di "vietare il trasferimento di lavoro senza diritti o che è il prodotto del contratto o contratto di lavoro con terzi". Qualcosa di logico in entrambi i casi è qualcosa di simile ai diritti reali e ai "vizi nascosti della cosa". Quando compri qualcosa e poi scopri che aveva vizi, difetti, tali che, se li avessi conosciuti in anticipo, non avresti comprato, puoi rigettare la vendita e altro se il venditore fosse in malafede. Ebbene, queste clausole pongono qualcosa di simile.
Il vantaggio principale che ottiene chi utilizza il CLA è, prendendo come esempio Canonical: se sviluppi, modifichi o sviluppi software incluso nel catalogo allegato al CLA, cedi il copyright garantendo di non violare il brevetto e puoi farlo. Accetti inoltre di non intraprendere alcuna azione contro Canonical, chiunque riceva il software Canonical o chiunque riceva il Software in base alla Licenza software gratuita. Inoltre, Canonical non impone nulla contro di te, incluso il caso in cui Canonical abbia cambiato le licenze. C'è una sorta di protezione reciproca, è chiaramente un Titolare, niente di più. Tant'è che tu sviluppatore, pur avendo trasferito il copyright, puoi continuare a fare quello che ti pare con il codice, ma devi avvisare Canonical e rispettare il framework CLA, che non è molto rigido e finisce per avvantaggiare entrambi. Cioè, gli scopi 1 e 2 del post.
Il Fedora - Red Hat CLA continua a girare nella mia testa, non per "sublicenza", ma perché è autorizzato a offrire e / o vendere direttamente il codice.
In questi giorni torno ad altri CLA, di quelli citati.
Ottimo articolo, molto ben documentato, scritto e ben studiato. Cose del genere sono così difficili da vedere in questi giorni! Non solo su internet, ma anche nel presunto "giornalismo investigativo" degli altri media.
Per quanto riguarda l'argomento, non avevo idea dell'esistenza di queste licenze e francamente la loro esistenza non mi sembra così logica. Tranne nei casi in cui il codice canonico viene modificato, ma la GPL prevede qualcosa di simile, senza dover cedere il copyright? Non capisco la differenza tra trasferire i diritti all'azienda o semplicemente prendere il progetto e seguirlo da solo, dato ad esempio che il software è concesso in licenza sotto GPL, sotto altre licenze che consentono la ri-licenza sarebbe un'altra storia.
Là fuori quello che dico è stupido, le leggi non sono il mio forte.