L'Assegnazione del Copyright e la Proprietà

Ci sono tre modi per maneggiare la proprietà del copyright per il codice libero e la documentazione che sono stati forniti da molta gente. Il primo è ignorare la questione del copyright completamente (io non lo raccomando). Il secondo è raccogliere un contratto legale di collaborazione (CLA) da ogni persona che lavora al progetto, che garantisce esplicitamente al progetto il diritto di usare quel contributo della persona. Questo e usualmente sufficiente per la maggior parte dei progetti, e la cosa simpatica è che in qualche giurisdizione i CLA possono essere inviati per email. Il terzo è acquisire le vere cessioni dei diritti dai collaboratori, di modo che il progetto (cioè qualche entità legale, nonprofit) sia il possessore legale del copyright per ogni cosa. Questo è il modo legalmente più inattaccabile, ma è anche il più gravoso per i collaboratori; solo pochi progetti insistono su di esso.

Notare che anche anche sotto la proprietà centralizzata del copyright il codice[28] rimane libero, perché le licenze open source non danno al detentore del copyright il diritto di rendere retroattivamente proprietarie tutte le copie del codice. Così anche se il progetto, come entità legale, facesse improvvisamente il dietro front e partisse con il distribuire tutto il codice sotto una licenza restrittiva, ciò non causerebbe un problema per la comunità pubblica. Gli altri sviluppatori partirebbero con una diramazione basata sull'ultima copia libera di codice, e continuerebbe come se nulla fosse successo. Poiché essi sanno che possono farlo, la maggior parte dei collaboratori cooperano quando loro viene chiesto di sottoscrivere un CLA o una assegnazione di copyright.

Non far Nulla

La maggior parte dei progetti non raccolgono CLA o assegnazione di copyright dai loro collaboratori. Invece, accettano codice, ogni qualvolta sembra ragionevolmente chiaro che il collaboratore abbia inteso che esso incorporato nel progetto.

In circostanze normali ciò è regolare. Ma ogni tanto, qualcuno può decidere per la citazione in giudizio per infrazione di copyright, adducendo il fatto che essi sono veri proprietari del codice in questione, e che non hanno mai convenuto che esso fosse distribuito dal progetto sotto una licenza open source. Per esempio il gruppo SCO fece qualcosa di simile per il progetto Linux, vedere http://en.wikipedia.org/wiki/SCO-Linux_controversies per i dettagli. Quando ciò avvenisse, il progetto non avrà la documentazione che mostri che il collaboratore ha formalmente dato il diritto di usare il codice, cosa che potrebbe rendere più difficile una difesa legale.

Gli Accordi di Licenza per i Collaboratori

I CLA probabilmente offrono il miglior compromesso fra sicurezza e convenienza. Un CLA è un modulo elettronico che il collaboratore compila e invia al progetto. In molte giurisdizioni l'invio di una email è sufficiente. Una firma digitale sicura può o non può essere richiesta; consultate un legale per trovare quale metodo sarebbe migliore per il vostro progetto.

La maggior parte dei progetti usano due tipi di CLA leggermente differenti, uno per collaboratori individuali e uno per collaboratori associati. Ma in ambedue i tipi il linguaggio base è lo stesso: il collaboratore concede al progetto "...una licenza di copyright perpetua, per tutto il mondo, non esclusiva, a costo zero, senza l'onere di pagare un compenso al titolare del copyright, l'irrevocabile licenza di copyright a riprodurre, preparare lavori derivati, mostrare pubblicamente, eseguire pubblicamente, creare una sotto licenza, e distribuirne [i] Contributi come lavori derivati." In più, potreste ottenere che un legale ratifichi ogni CLA, ma se voi metteste tutti questi aggettivi in essi, potreste probabilmente far bene.

Quando richiedete i CLA dai collaboratori, assicuratevi di puntualizzare che non state richiedendo una assegnazione di copyright. In effetti, molti CLA partono col ricordare a chi legge questo:

Questo è solo un contratto di licenza; non trasferisce la proprietà del copyright e non cambia i vostri diritti di usare i vostri Contributi per ogni altro proposito.

Qui ci sono alcuni esempi:

Trasferimento del Copyright

Trasferimento del copyright significa che il collaboratore dà al progetto la proprietà del copyright sul suo contributo. Idealmente ciò viene fatto su carta e anche mediante fax o con invio per posta normale al progetto.

Alcuni progetti insistono sulla piena assegnazione, perché avendo una unica entità legale propria il copyright sull'intero codice base può essere utile se i termini della licenza open source hanno bisogno di essere fatti valere in una corte. Se nessuna unica entità ha il diritto di farlo, tutti i collaboratori potrebbero dover collaborare, ma qualcuno potrebbe non aver tempo o essere rintracciabile quando nasca il problema.

Differenti organizzazioni applicano differenti quantità di rigore nel raccogliere le assegnazioni. Alcune si procurano una dichiarazione informale da parte di un collaboratore su una mailing list di liste pubbliche—qualcosa dall'effetto di “Io in tal modo assegno il copyright in questo codice al progetto, di essere rilasciato in licenza sotto gli stessi termini del restante codice” Almeno un legale con cui ho parlato dice che ciò è in effetti sufficiente, presumibilmente perché avviene in un contesto in cui la concessione del copyright è normale prevista comunque, e perché rappresenta un tentativo bona fide da parte del progetto di accertare le vere intenzioni dello sviluppatore. D'altra parte la Free Software Foundation va dalla parte opposta: richiede ai collaboratori di sottoscrivere e mandare per posta un pezzo di carta contenente una formale dichiarazione, a volte per un solo contributo, a volte per il contributo corrente e futuro. Se il collaboratore è un impiegato la FSF richiede che anche il collaboratore lo sottoscriva.

La paranoia dell'FSF è incomprensibile. Se qualcuno viola i termini della GPL incorporando qualcuno del loro software in un programma proprietario, la FSF avrà bisogno di litigare su questo davanti al tribunale, e vuole che i suoi copyrights siano il più inattaccabili possibile quando ciò avviene. Siccome la FSF è la detentrice del copyright di una gran quantità di software popolari, vede ciò come una possibilità reale. Se la vostra organizzazione ha la necessità di essere scrupolosa, è un fatto che solo voi potete decidere, consultandovi con dei legali. In generale, a meno che non ci sia un motivo specifico per cui il vostro progetto abbia bisogno di una piena assegnazione del copyright, andate avanti con i CLA; essi sono più facili per tutti.



[28] Userò “codice” per riferirmi sia al codice che alla documentazione, d'ora in avanti