Devi includere un avviso di licenza con ogni file sorgente?


111

Ho cercato varie licenze che posso usare per un mio progetto open source, ma tutti i progetti che ho visto, con tutti i tipi di licenze, sembrano avere un gigantesco, odioso (secondo me) notare in ogni file sorgente che indica che il file è elencato sotto una determinata licenza. Non penso di aver trovato un singolo progetto di origine che non sia di dominio pubblico e che non abbia un avviso del genere.

Sembra solo una perdita di tempo e spazio per i file. Ho intenzione di mettere @licensee @authortaggare i miei progetti, ma non vedo perché devo elencare un avviso così grande in ogni singolo file se non voglio rendere il mio codice pubblico.

C'è qualche motivo per cui vorrei includere un simile avviso nei miei progetti, o semplicemente includere un avviso nel tag READMEe un @licensetag sarebbe abbastanza buono? Ciò influisce sulla regola "chiaramente dichiarata" della maggior parte delle licenze o è eccessiva per evitare che le persone discutano?


10
Il tuo editor dovrebbe permetterti di piegare / nascondere la licenza in 1 riga.
Pubby

1
Realisticamente, se qualcuno accelera il tuo codice, rinomina una variabile e rimuove il copyright un tribunale considererebbe identici questi 2 file?
NoChance,

5
@Emmad: No, un tribunale non direbbe che sono identici. (Ma potrebbero essere "sostanzialmente identici".) Sì, un tribunale direbbe che è una violazione del copyright.
Andrew Dalke,


Risposte:


39

Secondo la mia comprensione, GPLv3 suggerisce fortemente (o forse richiede, almeno, come comprendo il testo Come applicare questi termini ai vostri nuovi programmi , dopo la sua sezione 17) un avviso di copyright in ogni file sorgente. Dice

Per fare ciò, allegare le seguenti comunicazioni al programma. È più sicuro collegarli all'inizio di ciascun file sorgente per dichiarare in modo più efficace l'esclusione della garanzia; e ogni file dovrebbe avere almeno la riga "copyright" e un puntatore al punto in cui si trova la notifica completa.

<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year>  <name of author>

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program.  If not, see <http://www.gnu.org/licenses/>.

E i progetti GNU di proprietà di FSF, come GCC, hanno un tale avviso in ogni file.

Conosco anche un programma (il sistema CAIA di J.Pitrat) che è stato rifiutato su un sito Web della comunità di software libero perché non aveva tale avviso in ogni file.

Non sono un avvocato , ma credo che tale avviso sia praticamente obbligatorio in ogni file sorgente di un programma GPLv3 .

(se usi un'altra licenza, in particolare una non-FSF, leggi attentamente su come applicarla; YMMV; tuttavia AFAIK scrivere un avviso in ogni file non danneggerà.)


16
Non può essere obbligatorio perché ci sono sistemi, come le immagini Smalltalk, che non esprimono il codice sorgente come file. Dicono "più sicuro" e "dovrebbe", non "deve". Quello che raccomandano è una linea guida facilmente comprensibile con poche possibilità che qualcuno commetta un errore, ma sicuramente non è "praticamente obbligatorio".
Andrew Dalke,

Sono d'accordo e ho detto "file sorgente" apposta. In realtà, il sistema di CAIA è un po 'come Smalltalk: l'immagine è in file di dati e i "file di origine" di CAIA che ho menzionato sono generati file C. Tuttavia, anche il mio GCC MELT (un ramo di GCC, sotto copyright FSF) è meta-programmato, e mi occupo di generare commenti di avviso sul copyright nei file C generati (e li inserisco nel codice C & MELT scritto a mano).
Basile Starynkevitch,

Punto preso. Conosco ora un paragrafo su MELT. In generale, è meglio che i file generati includano l'avviso sul copyright in quanto è molto difficile "allegare" la licenza altrimenti. Ad esempio, "yacc" e "lex" sono limitati in ciò che possono fare.
Andrew Dalke,

1
Per esperienza personale: per avere un progetto accettato su Savannah devi avere una licenza in ogni file.
Mael,

1
Solo per chiarire, secondo le FAQ di GPL, #LicenseCopyOnly e #NoticeInSourceFile al momento della stesura di questo documento, non è necessario includere il testo Come applicare ... ad ogni file sorgente; nota che la lingua usa "dovrebbe" e non "deve". Tuttavia, raccomandano vivamente di seguire questa pratica.
ZeroKnight il

37

Ho visto molti progetti che menzionano solo la licenza nel file README o in un file LICENZA o COPIA.

Il tuo software è automaticamente coperto da copyright, come concordato nel diritto internazionale. (A meno che tu non stia lavorando per il governo degli Stati Uniti o per qualche altra organizzazione per la quale non si applica il copyright.)

Se qualcuno utilizza il tuo software, deve assicurarsi di seguire l'accordo di licenza o di seguire le restrizioni del fair use su ciò che può fare.

Supponiamo che la persona desideri utilizzare uno dei file nella distribuzione del codice, che ovviamente richiede una copia e quindi si applica la legge sul copyright. Per impostazione predefinita NON hanno il diritto di utilizzare il software in base alla legge sul copyright. È solo quando conoscono e seguono le restrizioni di licenza che sono autorizzati a usarlo.

Quindi, se usano un file senza una licenza software, infrangono la legge sul copyright. Dal momento che tutte le licenze dicono qualcosa come "La suddetta nota sul copyright e questa nota di autorizzazione devono essere incluse in tutte le copie o parti sostanziali del Software", sono obbligate a mettere quella licenza da qualche parte.

Questo può essere nel file stesso, o quando ho usato il codice come libreria ho inserito le parti pertinenti nella sua directory e ho aggiunto un "README" o "LICENSE" in quella sottodirectory.

In breve, non è necessario inserire la licenza in ciascun file. Penso che sia eccessivo. Non esiste alcuna protezione legale aggiuntiva nel farlo. Aiuta un utente a valle in qualche modo, ma non di molto.

Penso che la tradizione di molti metadati basati su commenti (licenza, data di creazione di ciascuna funzione, registro delle modifiche, ecc.) Siano tradizioni molto antiche che esistono perché sono facili da fare e che sono più un talismano che utili.

Ad esempio, il modello predefinito di Eclipse aggiunge ciò che penso come metadati inutili prima di ogni funzione, che ritengo sia molto meglio catturata dal controllo della versione. Ma questa pratica è comune in molti negozi.


2
Ad esempio, non vedo nulla di correlato alla licenza nei file sorgente di Rails.
Anton Barkovsky,

3
E dei 200 file nella libreria standard Python di livello superiore, solo 34 contengono la parola "copyright" e solo 4 di questi sono per Python Software Foundation, che controlla il copyright di Python.
Andrew Dalke,

sì, non credo che le notifiche sul copyright per file stiano per durare ... è semplicemente troppo ... non può essere la strada per il futuro .. pensate a SECCO ... LICENZA a livello di root e andiamo chiamalo un giorno .. penso che quasi tutto su npm lo stia già facendo in questo modo
ChaseMoskal,

13

Il problema è che è molto facile disaggregare un singolo file di codice sorgente dal suo progetto più grande, come qualcuno che sta semplicemente effettuando il checkout, inviando un'e-mail, scaricando un file, senza il resto che contiene il copyright completo. E poi quel file può essere passato nel tempo fino all'infinito, alle parti dell'Nth che potrebbero non avere idea delle origini dei file.

L'avviso sul copyright in alto ricorda a chiunque attraversi quel file solitario che in realtà è protetto da copyright, non di dominio pubblico, e quindi una licenza può o meno essere coinvolta nella sua distribuzione o utilizzo. Contro il lasciare che il cercatore faccia le proprie ipotesi casuali.


21
Non è altrettanto facile disaggregare tramite copia-incolla anche vari frammenti di un file sorgente? Cosa poi? Questa tesi mi sembra incoerente.
Travis Griggs,

10
Supporre che il problema sia di dominio pubblico per un'opera senza avviso di copyright. Se trovi un file senza un avviso sul copyright, non dovresti copiarlo e inviarlo ad altri.
Rich Remer,

ovviamente c'è poi il problema che è legale "clonare e possedere" un file, abbiamo messo direttamente open source nel repository del nostro progetto perché a volte è difficile correggere un bug al di fuori del progetto a monte, ma non puoi aspettare per rilasciarli entrambi. Non dire che è una buona idea, ma l'abbiamo fatto.
xenoterracide,

8

Non vi è alcuna riunione segreta delle superpotenze in un bunker sotterraneo che dice cosa devi inserire in ogni file sorgente.

Ciò chiarisce all'utente che questo file è sotto qualsiasi licenza e in effetti la maggior parte del software GPL contiene un breve preambolo che dice di leggere license.txt. Ricorda che i progetti vengono suddivisi e i file vengono riutilizzati, quindi solo inserire il messaggio in un singolo file potrebbe non essere una buona idea.

Se nell'improbabile caso in cui fosse mai andato in tribunale, potresti avere maggiori pretese se avessi contrassegnato chiaramente ogni file come opera e quale licenza fosse - quindi nessuno poteva affermare di aver pensato che questo file pratico non fosse coperto


6

Ho quasi pubblicato una domanda molto simile. Meno fastidi e più tecnicismi. TL; DR: credo che la risposta sia una questione di priorità dell'autore. Forse l'intento sarebbe più preciso delle priorità ...

Credo che sia giusto fare riferimento a una licenza nella tua fonte, a seconda della tua definizione di "ok". Concordiamo sul fatto che il termine "non accompagnato" indica un file sorgente che fa parte di un progetto che è stato spietatamente separato dalla sua base di codice amorevole. Detto file contiene una riga come questa:

# This file is covered by the LICENSING file in the root of this project.

O una linea molto più bella come questa:

* @license OMGBBQ <http://goodlics.com/bbq>

"Ma aspetta!" , escludi, "hai appena detto che il file è stato separato dal suo progetto! E goodlics.com reindirizza a uno squatter di dominio! Smetti di essere un trixy!" Hai ragione, l'ho detto, ma potrebbe andare bene, e smettila di urlarmi. Ecco il mio ragionamento da non avvocato:

  • Quasi tutti i paesi hanno concordato di [sentire la] Convenzione di Berna, che AFAIK significa che se crei qualcosa, ne hai il copyright, punto. Non hai bisogno di una linea (c) o di una merda del genere, ma quella roba (oltre a un VCS di terze parti come GitHub) rende più facile dimostrare che l'hai creata e quando l' hai creata.
  • Pertanto, se pubblichi online un succoso codice 1337 che hai creato, hai il copyright su di esso. A nessuno è permesso (legalmente) copiarlo. È raro e scioccante, lo so, ma ho sentito che le persone infrangono la legge a volte. Questo è ancora possibile.
  • Quel fantastico nyancat-bcminer-algo.qbasicfile che hai scritto e pubblicato su LiveJournal è, che ci crediate o no, non di dominio pubblico. A meno che tu non dica che è di dominio pubblico. Di default è tuo e solo tuo. È ... prezioso . (Almeno per 25-50 anni, a meno che tu non sia Disney.)
  • Le persone comunicano convenzionalmente questo intento (rendendo alcuni o tutti i diritti non solo tuoi e tuoi) tramite licencingses, ma è necessario annunciare tale intento; è opt-in opt-out (HAHA OTTIENI? optare per la rinuncia al tuo copyright? FANTASTICO). Prendi i biglietti, siamo quasi arrivati!
  • Se è giusto che i file non accompagnati sopra menzionati siano di dominio privato, vale a dire non legalmente copiabili, l'utilizzo di un riferimento potenzialmente non funzionante va benissimo. Tuttavia, se non va bene , penso che sia necessario includere il testo della licenza in ogni file sorgente. In questo modo, i file non accompagnati continueranno sicuramente a essere concessi in licenza come previsto dalle priorità . Sì, va meglio.

Questo ragionamento fa due ipotesi epiche e probabilmente non valide:

  • Un riferimento di licenza "non funzionante" ricade sul comportamento predefinito (protetto da copyright), che potrebbe non essere un presupposto valido.
  • Quel sito su cui hai pubblicato non ha una sorta di politica di pubblicazione (come StackExchange) che rende tutto di dominio pubblico.

Grazie per aver cavalcato le vie respiratorie scimmia-cervello.

Disclaimer: questo mi sembra logico, sono sicuro al 90% di sbagliarmi al 100%.


6

C'è una differenza tra licenza e preambolo .

In alcuni dei miei progetti sto usando la GNU General Public License, Versione 3.0 . La GNU GPL rende necessario avere un preambolo su ogni file di codice sorgente:

Il preambolo e le istruzioni sono parti integranti della GNU GPL e non possono essere omessi.

Fonte: http://www.gnu.org/licenses/gpl-faq.html#GPLOmitPreamble

Quindi ecco cosa faccio:

1. Aggiungi License.txt

Per seguire le regole ho inserito un LICENSE.txt nella radice del repository del mio progetto. Questo è anche suggerito da GitHub (vedi " Dove vive la licenza" ).

2. Aggiungi il preambolo usando la piega automatica

Quindi includo il preambolo GPL sopra ogni file di codice sorgente MA per renderlo difficilmente inquietante lo nascondo nell'IDE. La maggior parte degli IDE ha una funzione per piegare automaticamente i blocchi di codice. NetBeans supporta anche la piegatura del codice personalizzata e WebStorm supporta anche i commenti sulla piegatura .

Quindi ecco come appare:

//<editor-fold desc="Preamble">
/*
 * Company Name
 * Copyright (C) 2016 Company Name
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 *
 * ...
 */
//</editor-fold>

console.log('Here is my licensed JavaScript code.');

Penso che questo sia un ottimo compromesso tra comodità e sicurezza legale.

Se hai molti progetti in cui è necessario aggiungere una licenza, http://www.addalicense.com/ potrebbe essere di aiuto.

Nota: il mio consiglio si riferisce a GPLv3. Altri tipi di licenza potrebbero non richiedere un preambolo.


7
«La GNU GPL rende necessario avere un preambolo su ogni file di codice sorgente:» Non lo è. La parte che hai citato ti impedisce semplicemente di rimuovere il preambolo dal LICENSEfile, cioè non puoi modificare il testo della GPL facendolo cadere.
Andrea Lazzarotto,

6

C'è un altro modo pratico non ancora menzionato qui.

SPDX-License-Identifieretichetta. https://spdx.org/using-spdx

Usandolo, il tuo "bollettino legale" in ogni intestazione del file sorgente si riduce a solo due righe:

/* SPDX-License-Identifier: (GPLv3-or-later AND LGPL-2.0-only) WITH bison-exception */
/* Copyright © 1234 Project Author */

Inoltre, le persone che automatizzeranno le analisi della catena di approvvigionamento del software saranno grate per aver rispettato uno standard comune di descrizione della licenza leggibile dalla macchina.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.