La presentazione di una richiesta pull potrebbe mai costituire l'accettazione di un contratto di licenza per collaboratori? [chiuso]

Alcuni progetti software hanno un Accordo di licenza di Contributor . L'accordo potrebbe, ad esempio, assegnare il copyright dei contributi di terzi al creatore del progetto originale. Inviare una richiesta pull su github potrebbe mai costituire un accordo del genere?

Gli accordi di licenza di contribuzione sono, per la maggior parte, contratti. Un contratto è vincolante solo se una parte acconsente (cioè accetta) come indicato con qualsiasi mezzo ragionevole. Tali mezzi possono includere approcci tradizionali come la firma di un accordo cartaceo, ma anche meccanismi di "clic per accettare", l'invio di un'e-mail che dice "Accetto" o, come menzionato qui, di inoltrare una richiesta pull - ma solo se lo è ragionevole nelle circostanze per concludere che hai effettivamente accettato. Se l'avviso che accetti inviando una richiesta pull è sepolto da qualche parte e non dovresti aspettarti di averlo visto, o non hai l'opportunità di vederlo prima di effettuare la richiesta, potresti essere in grado di evitare di essere vincolato al contratto. Ma se tu fossi informato (come ad esempio da una nota preminente sul sito) che l'invio di una richiesta pull costituiva un accordo, ed è ragionevole aspettarti che tu capisca che l'accordo è stato applicato, quindi sì, sarai vincolato. Questa è una domanda di buon senso: non c'è molta magia.

Sono un avvocato che esercita le licenze IP, ma se hai domande sul tuo caso specifico dovresti parlare con un avvocato che ti rappresenta - sto solo parlando del caso generale.

Sarei interessato a sapere - supponendo che questa stringa non sia troppo vecchia a questo punto - gli esempi a cui ti riferisci. Ho trovato questa stringa mentre cercavo un esempio di un sito che dice che una richiesta pull costituisce un accordo con un CLA.

Noto che la questione di cosa sia un "lavoro a noleggio" o un trasferimento di diritti di proprietà intellettuale è una domanda diversa. La maggior parte dei CLA non lo sono.

Non sono un avvocato, e se vuoi una risposta su cui fare affidamento, consulta un avvocato specializzato in diritto d'autore, idealmente con un focus sull'Open Source / Software libero.

Detto questo, il copyright viene raramente trasferito implicitamente: un'eccezione notevole è il lavoro a noleggio, che è il default in alcuni paesi e una clausola standard nei contratti di lavoro in altri. Con il software Open Source, di solito si considera la responsabilità del responsabile del progetto garantire che la distribuzione del progetto sia conforme alla legge e che distribuirlo in base a una determinata licenza non violi alcun copyright né accordi e licenze esistenti. Esistono due modi standard per farlo:

a) accettare solo i contributi che sono stati rilasciati sotto una licenza compatibile dai rispettivi autori; questo approccio non richiede scartoffie, ma una certa diligenza, perché il responsabile del progetto può essere ritenuto responsabile se qualcosa viene incluso e ripubblicato in un modo che viola la licenza originale (ad esempio, incluso il codice GPL in un progetto rilasciato sotto una licenza MIT). b) Fai firmare al collaboratore un accordo esplicito di trasferimento del copyright, di solito in cambio di una promessa di rilasciarlo con una licenza gratuita. A volte, il copyright non viene trasferito, ma viene invece concessa una licenza irrevocabile che conferisce al manutentore del progetto gli stessi diritti di un trasferimento del copyright; tuttavia, consente all'autore originale di rilasciare il proprio codice (ma solo quello!) con una licenza diversa dal progetto principale.

Questo mi porta a credere che se non si accetta esplicitamente un trasferimento di copyright, si mantiene comunque il pieno copyright. Mi aspetto anche che l'invio di una richiesta pull possa essere interpretato come un accordo implicito affinché il tuo contributo venga distribuito agli stessi termini del progetto principale, vale a dire, se invii patch a un progetto GPL, si può presumere che tu lo faccia così con l'intento di averli inclusi e distribuiti come parte del progetto.

Tuttavia, ogni volta che ricevo un contributo per uno qualsiasi dei miei progetti, chiedo esplicitamente se sono d'accordo con me includendo e ridistribuendo il loro lavoro.

Alcune alternative che potrebbero essere più sicure:

• fai in modo che i committenti per la prima volta scrivano una riga "Accetto il CLA" su un CLA.mdfile. Il messaggio di commit identifica quindi la persona.
• https://github.com/clahub/clahub

Se hai bisogno di una risposta effettiva, come in "questo potrebbe avere conseguenze legali reali", devi chiedere a un vero avvocato, non ad alcune persone che non hai mai incontrato dall'altra parte di Internet.

Le licenze di Shrinkwrap (dove ti danno una mazzetta di testo al momento dell'installazione e ti fanno premere "Accetto la licenza" per l'installazione) sono state ritenute legalmente valide, ma credo che una parte del motivo sia che si assicurano che tu veda (e premi) il pulsante "accetta". A meno che non ci sia un'azione simile richiesta dalla persona che presenta la richiesta pull, sospetto che potrebbe non essere giuridicamente vincolante, dal momento che il contributore potrebbe alzarsi in tribunale e dire: "Non avevo idea che stessero usando la licenza" o qualcosa di simile.

Se fossi io a gestire un piccolo progetto che necessitasse di qualcosa di legale da parte dei collaboratori, mi assicurerei che abbiano inviato un'e-mail di accettazione formale della cosa legale prima di accettare il loro contributo.

Secondo la legge del Regno Unito, esiste un contratto in cui una parte fa un'offerta e l'altra parte accetta tale offerta. Quindi, per rispondere alla tua domanda, sì, ci sono situazioni in cui un giudice dovrebbe decidere che, rendendo disponibili i loro software a cui le persone hanno accesso e pubblicando i termini della licenza, stanno facendo un'offerta contrattuale. Quindi, quando si sceglie di accedere al codice sorgente, è stata dimostrata la propria accettazione del contratto che garantisce l'accesso legale al codice sorgente.

Tuttavia, le circostanze esatte contano considerevolmente. È difficile stipulare un accordo legalmente vincolante con un bambino di 12 anni, allo stesso modo, è difficile sostenere che uno sviluppatore di software professionale non si aspetterebbe che il codice sorgente venga concesso in licenza.