Lunix Fundation su Comunità Open Source e Marchi: torniamoci su.

Questo articolo è una traduzione di Open Source Communities and Trademarks: A Reprise (link: https://www.linuxfoundation.org/blog/blog/open-source-communities-and-trademarks-a-reprise ).

Articolo utilissimo che non ho trovato in italiano e che mi sono permesso di tradurre. Fate riferimento al testo originario.

Proprietà intellettuale e come viene condivisa sono stati i pilastri dell'open source. Anche se è più comune discutere di "codice" o "copyright", ci sono altre preoccupazioni legate alla proprietà intellettuale, come brevetti e marchi registrati, che devono essere considerate prima di investire tempo e sforzi in un grande progetto open source. Esistono pratiche consolidate che regolano queste questioni. Aziende e avvocati coinvolti nell'open source lavorano da decenni su questioni relative ai marchi dei progetti open source.

Il controllo neutrale dei marchi è un prerequisito chiave per i progetti open source che operano sotto una governance aperta. Quando i marchi di un progetto open source sono di proprietà di una singola azienda all'interno di una comunità, si crea uno squilibrio di controllo. L'uso di qualsiasi marchio deve essere attivamente controllato dal suo proprietario, altrimenti il proprietario perderà il diritto di controllarne l'uso. La riserva di questo diritto esclusivo di esercitare tale controllo mina inevitabilmente il campo di gioco equilibrato che è alla base della governance aperta. Questo è particolarmente vero quando il marchio viene utilizzato in associazione con prodotti o soluzioni commerciali.

Le licenze open source consentono a chiunque di fare un fork del codice, distribuirlo e modificare la propria versione. I marchi, tuttavia, funzionano in modo diverso. I marchi identificano una specifica fonte del codice. Ad esempio, sappiamo tutti che MariaDB non è la stessa cosa di MySQL. Hanno sviluppato ciascuno il proprio brand, sebbene derivino da una base di codice comune. La domanda chiave è: chi decide quando un'azienda dovrebbe essere autorizzata ad associare il proprio prodotto o soluzione al brand della comunità?

Un marchio è una parola, una frase o un design che denota un "brand" e distingue una fonte di prodotto o soluzione da un'altra. L'USPTO (Ufficio Brevetti e Marchi degli Stati Uniti) descrive l'uso dei marchi come "identificare e distinguere i beni/servizi di un venditore o fornitore da quelli di altri, e indicare la fonte dei beni/servizi". Secondo la legge sui marchi degli Stati Uniti, non è possibile separare efficacemente la proprietà di un marchio di progetto dal controllo del progetto open source sottostante. Anche se alcuni possono creare strutture elaborate attorno a questo, alla fine dei conti un principio importante da seguire è che la comunità del progetto dovrebbe avere il controllo di ciò che accade al proprio brand, il marchio che hanno costruito collettivamente come loro identità, parallelamente alla costruzione della funzionalità del loro codice.

Per questo motivo, nelle comunità che considerano il proprio brand importante, depositiamo anche registrazioni per la protezione del marchio, riservando i diritti sul marchio per il progetto, comunemente negli Stati Uniti, Cina, Unione Europea, Giappone e altri paesi in tutto il mondo. I marchi registrati spesso hanno il simbolo ®. Questo è diverso da un marchio di common law, dove spesso si vede il simbolo ™ accanto al marchio. Avere un marchio registrato è spesso importante perché ci permette di proteggere meglio la comunità da false rappresentazioni, abusi e confusione nell'ecosistema tra ciò che è effettivamente il progetto costruito dalla comunità e ciò che non lo è. Questo si basa spesso su benefici specifici derivanti dalla registrazione, che possono variare da paese a paese.

La Linux Foundation ha iniziato a ospitare progetti al di fuori di Linux un decennio fa. Fin dall'inizio, il brand di una comunità di progetto che ospitiamo è stato un asset importante che ci è stato chiesto di proteggere per le nostre comunità. Gli obiettivi e le motivazioni delle comunità sono sempre diversi, ma, in generale, l'organizzazione che contribuisce a un marchio vuole assicurarsi che esso denoti la comunità che stanno aiutando a stabilire presso la LF, e gli altri partecipanti nell'ecosistema vogliono la certezza che un'azienda non possa dire loro cosa possono o non possono fare con un progetto che ospitiamo perché hanno mantenuto la proprietà del marchio.

Questa neutralità è l'essenza stessa di ciò che cerchiamo di stabilire alla Linux Foundation con i nostri progetti. I nostri progetti sono configurati per essere neutrali: la Linux Foundation o le nostre entità di progetto possiedono il marchio. Quindi mettiamo il controllo sulle decisioni relative al marchio nelle mani delle comunità dei progetti, da determinare da loro in modo aperto e trasparente per raggiungere i loro obiettivi collettivi.

Ad esempio, nel marzo 2017, abbiamo partecipato a un incontro ospitato a una KubeCon a Berlino, dove le organizzazioni coinvolte in Kubernetes si sono sedute in una sala affollata per discutere di cosa volessero fare con il brand Kubernetes in relazione alle aziende che utilizzano Kubernetes in congiunzione con i loro prodotti o soluzioni commerciali. Durante la stesura della governance per CNCF, Google aveva insistito sul fatto che era importante che la Linux Foundation possedesse anche il marchio Kubernetes come parte di CNCF, in modo che il controllo del branding andasse di pari passo con una governance neutrale e guidata dalla comunità.

Tuttavia, la LF non era in una posizione per determinare quando un'azienda dovrebbe o non dovrebbe essere in grado di dire che la sua soluzione è un prodotto basato su "Kubernetes". Avevamo bisogno di un programma per consentire alle aziende e ad altre organizzazioni di utilizzare il marchio commercialmente per denotare la loro distribuzione o compatibilità con le release della comunità Kubernetes. Quel gruppo iniziale ha lavorato per mesi per definire cosa significa avere una distribuzione Kubernetes conforme. Questo è anche il motivo per cui la promessa di portabilità tra i provider cloud funziona davvero oggi. Quegli esperti tecnici della comunità nel loro insieme hanno definito esattamente cosa sarebbe servito per mantenere la promessa di portabilità. E poi la definizione di conformità che hanno stabilito è stata supportata dalla proprietà neutrale del marchio Kubernetes, nella Linux Foundation. Ciò che è ancora più importante è che la comunità rimane in controllo del programma. In effetti, la definizione di conformità è controllata dal SIG Architecture di Kubernetes e cambia in un processo attentamente controllato in ogni release man mano che nuove API diventano stabili e quelle obsolete vengono deprecate.

Questa stessa storia si è ripetuta in altre comunità che abbiamo ospitato. Abbiamo avuto molte comunità che hanno costruito un consenso su cosa significa essere compatibili o conformi con le release provenienti dalle nostre comunità di progetto. Così tante che di recente abbiamo scritto un intero blog solo su questo argomento.

Questi esempi mostrano che una comunità può gestire in modo neutrale un marchio all'interno della struttura della LF. Tendiamo a riferirci a questi come programmi di "marchi gestiti dalla comunità". I marchi sono di proprietà dell'entità LF per il progetto, e lavoriamo con le comunità che serviamo per stabilire le regole sull'uso dei nostri marchi.

Di recente c'è stata una nuova ondata di conversazioni sui progetti open source e sulla proprietà dei marchi. Comprensibilmente, c'è stata anche preoccupazione che l'open source non abbia affrontato le questioni relative ai marchi per quanto riguarda i principali progetti OSS. Questo non è il caso. Mentre le motivazioni variano, un aspetto rimane costante: la legge sui marchi.

Ci è stato chiesto: "Possiamo far gestire il nostro marchio anche dalla LF?" La risposta è sì. Fateci sapere quale progetto state gestendo e saremo felici di aiutarvi a capire cosa è coinvolto nella creazione di un programma di marchi gestiti dalla comunità per il vostro progetto. Ad oggi, lo abbiamo fatto con successo per i progetti open source più importanti al mondo e per progetti che sono i più importanti per poche persone. Probabilmente possiamo aiutarvi anche voi.