Je cherchais différentes licences que je pourrais utiliser pour un de mes projets open-source, mais tous les projets que j'ai vus, avec toutes sortes de licences, semblent avoir un géant, odieux (à mon avis) notez dans chaque fichier source qu’il est répertorié sous une licence donnée. Je ne pense pas avoir trouvé un seul projet source n'appartenant pas au domaine public et ne comportant pas d'avis de ce type.

Cela semble être une perte de temps et d'espace. Je prévois mettre @licenseet @authorbalises dans mes projets, mais je ne vois pas pourquoi je dois énumérer un tel avis géant dans chaque fichier si je ne veux pas faire mon code domaine public.

Y a-t-il une raison pour laquelle je voudrais inclure un tel avis dans mes projets ou simplement inclure un avis dans READMEet une @licensebalise suffirait? Cela affecte-t-il la règle "clairement énoncée" de la plupart des licences, ou est-ce simplement excessif pour que les gens ne se disputent pas?

Dans ma compréhension, la GPLv3 suggère fortement (ou même peut-être exige, du moins que je comprenne le texte Comment appliquer ces conditions à vos nouveaux programmes , après sa section 17) un avis de droit d'auteur dans chaque fichier source. Ça dit

Pour ce faire, joignez les avis suivants au programme. Il est plus sûr de les attacher au début de chaque fichier source pour énoncer le plus efficacement l'exclusion de garantie; et chaque fichier doit comporter au moins la ligne «copyright» et un pointeur indiquant où se trouve la notice complète.

<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/>.

Et les projets GNU appartenant à la FSF, comme GCC, ont un tel avis dans chaque fichier.

Je connais également un programme (système CAIA de J.Pitrat) qui a été refusé sur un site Web de la communauté du logiciel libre, car il ne contenait pas cette notification dans chaque fichier.

Je ne suis pas avocat , mais j'estime qu'un tel avis est pratiquement obligatoire dans tous les fichiers source d'un programme GPLv3 .

^{(Si vous utilisez une autre licence, en particulier une licence non-FSF, lisez attentivement la procédure d’application: YMMV; toutefois, la rédaction d’un avis AFAIK dans chaque fichier n’est pas préjudiciable.)}

J'ai vu de nombreux projets ne mentionnant la licence que dans le fichier README ou dans un fichier LICENSE ou COPYING.

Votre logiciel est automatiquement couvert par le droit d'auteur, comme convenu dans le droit international. (Sauf si vous travaillez pour le gouvernement des États-Unis ou une autre organisation pour laquelle le droit d'auteur ne s'applique pas.)

Si quelqu'un utilise votre logiciel, il doit s'assurer de respecter l'accord de licence ou les restrictions d'utilisation équitable de ce qu'il peut faire.

Supposons que cette personne souhaite utiliser l'un des fichiers de votre distribution de code, ce qui nécessite bien sûr une copie et, par conséquent, la loi sur le droit d'auteur s'applique. Par défaut, ils n'ont PAS le droit d'utiliser votre logiciel conformément au droit d'auteur. Ce n'est que lorsqu'ils connaissent et respectent les restrictions de licence qu'ils sont autorisés à l'utiliser.

Donc, s’ils utilisent un fichier sans licence de logiciel, ils enfreignent la loi sur le droit d’auteur. Toutes les licences mentionnant quelque chose comme "L'avis de copyright ci-dessus et cet avis de permission doivent être inclus dans toutes les copies ou parties substantielles du logiciel", ils sont obligés de placer cette licence quelque part.

Cela peut être dans le fichier lui-même, ou lorsque j'ai utilisé le code en tant que bibliothèque, j'ai placé les parties pertinentes dans son propre répertoire et ajouté un "README" ou "LICENSE" dans ce sous-répertoire.

En bref, vous n'avez pas besoin de mettre la licence dans chaque fichier. Je pense que c'est exagéré. Il n'y a pas de protection juridique supplémentaire à cet égard. Cela aide un utilisateur en aval un peu, mais pas beaucoup.

Je pense que la tradition de beaucoup de métadonnées basées sur des commentaires (licence, date de création de chaque fonction, changelog, etc.) est une très vieille tradition qui existe parce qu’elle est facile à faire et qui est plus un talisman qu’utile.

Par exemple, le modèle Eclipse par défaut ajoute ce que je considère comme des métadonnées inutiles avant chaque fonction, ce qui est beaucoup mieux capturé par le contrôle de version. Mais cette pratique est courante dans de nombreux magasins.

Le problème est qu’il est très facile de désagréger un fichier de code source de son projet plus volumineux, par exemple, une personne qui extrait, envoie par courrier électronique, télécharge un fichier sans le reste qui contient le droit d’auteur complet. Et ensuite, ce fichier peut être transmis à l'infini dans le temps, aux Nièmes parties qui n'ont peut-être aucune idée de l'origine du fichier.

La notice de copyright en haut rappelle à tous les utilisateurs de ce fichier qu’il est en réalité protégé par des droits d’auteur et ne relève donc pas du domaine public. Par conséquent, une licence peut être associée ou non à sa distribution ou à son utilisation. Versus laissant le chercheur faire ses propres hypothèses aléatoires.

Il n'y a pas de superpuissance secrète réunie dans un bunker souterrain qui indique ce que vous devez mettre dans chaque fichier source.

Cela indique clairement à l'utilisateur que ce fichier est sous une licence quelconque. En fait, la plupart des logiciels GPL contiennent un préambule court qui dit de lire license.txt. Rappelez-vous que les projets sont scindés et les fichiers réutilisés. Il peut donc être inutile de mettre le message dans un seul fichier.

Si, dans le cas improbable, il soit jamais allé au tribunal, vous pourriez avoir plus de réclamations si vous aviez clairement marqué chaque fichier comme étant votre travail et quelle licence il était - alors personne ne pourrait prétendre qu'il pensait que ce fichier prticular n'était pas couvert

J'ai presque posté une question remarquablement similaire. Moins de désagréments et plus de détails techniques. TL; DR: Je pense que la réponse est une question de priorités de l'auteur. Peut-être que l'intention serait plus précise que les priorités ...

Je pense qu'il est correct de référencer une licence dans votre source, en fonction de votre définition de "d'accord". Convenons que le terme "non accompagné" désigne un fichier source faisant partie d'un projet qui a été impitoyablement séparé de sa base de code affectueuse. Ce fichier contient une ligne comme ceci:

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

Ou une ligne beaucoup plus froide comme celle-ci:

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

"Mais attendez!" , vous vous exclamez, "vous venez de dire que le fichier a été séparé de son projet! Et goodlics.com redirige vers un squatter de domaine! Arrêtez d’être en trixy!" Vous avez raison, c'est ce que j'ai dit, mais c'est peut- être acceptable et arrêtez de me crier dessus. Voici mon raisonnement non-avocat:

• Presque tous les pays ont souscrit à la Convention de Berne, ce qui signifie, autant que je sache, si vous créez quelque chose que vous créez un droit d'auteur. Vous n'avez pas besoin d'une ligne (c) ou d'une merde comme celle-là, mais cela (plus un VCS tiers comme GitHub) vous permet de prouver plus facilement que vous l'avez créé et à quel moment .
• Par conséquent, si vous publiez du code juteux 1337 en ligne que vous avez créé, vous disposez d'un droit d'auteur. Personne n'est autorisé à le copier (légalement). C'est rare et choquant, je sais, mais j'ai entendu dire que des gens enfreignent la loi de temps en temps. C'est encore possible.
• Ce impressionnant nyancat-bcminer-algo.qbasicfichier que vous avez écrit et affiché sur LiveJournal est, croyez - le ou non, pas du domaine public. Sauf si vous dites que c'est du domaine public. Par défaut, c'est à vous et à vous seul. C'est ... Précieux . (Au moins 25-50 ans ou plus, sauf si vous êtes Disney.)
• Les gens communiquent de manière conventionnelle cette intention (certains ou tous les droits ne sont pas à vous et uniquement les vôtres) via des licences, mais vous devez annoncer cette intention; c'est opt-in opt-out (HAHA GET IT? décochez-vous de désactiver vos droits d'auteur? IMPRESSIONNANT). Sortez vos billets, nous y sommes presque!
• S'il est normal que les fichiers non accompagnés susmentionnés relèvent du domaine privé, c'est-à-dire non légalement copiables, l'utilisation d'une référence potentiellement rompue convient parfaitement. Cependant, si cela ne va pas , alors je pense que vous devez inclure le texte de la licence dans chaque fichier source. De cette façon, les fichiers non accompagnés sont toujours sûrs d'être sous licence la façon dont vous prioriti-- l' intention . Ouais, c'est mieux.

Ce raisonnement fait deux hypothèses épiques et probablement non valides:

• Une référence de licence "cassée" repose sur un comportement par défaut (sous copyright), ce qui peut ne pas être une hypothèse valide.
• Le site sur lequel vous avez posté n'a pas de politique de publication (comme StackExchange) qui rend tout public.

Merci d'avoir conduit les voies respiratoires du singe-cerveau.

Disclaimer: Cela me semble logique, je suis sûr à 90% que je me trompe à 100%.

Il y a une différence entre licence et préambule .

Dans certains de mes projets, j'utilise la licence publique générale GNU, version 3.0 . La GNU GPL impose de disposer d’un préambule sur chaque fichier de code source:

Le préambule et les instructions font partie intégrante de la GNU GPL et ne peuvent pas être omis.

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

Alors voici ce que je fais:

1. Ajouter License.txt

Pour suivre les règles, je mets un LICENSE.txt à la racine du référentiel de mon projet. Ceci est également suggéré par GitHub (voir " Où réside la licence" ).

2. Ajouter le préambule en utilisant le pliage automatique

Ensuite, j'inclus le préambule GPL au-dessus de chaque fichier de code source, MAIS pour le rendre dérangeant, je le cache dans l'EDI. La plupart des IDE ont une fonctionnalité pour plier automatiquement les blocs de code. NetBeans prend en charge le pliage de code personnalisé et WebStorm prend également en charge les commentaires de pliage .

Alors voici à quoi ça ressemble:

//<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.');

Je pense que c'est un très bon compromis entre confort et sécurité juridique.

Si vous avez beaucoup de projets pour lesquels vous devez ajouter une licence, http://www.addalicense.com/ peut vous être utile.

Remarque: mon conseil concerne la GPLv3. D'autres types de licence peuvent ne pas nécessiter de préambule.

Il y a un autre moyen pratique non encore mentionné ici.

SPDX-License-Identifierétiquette. https://spdx.org/using-spdx

En l'utilisant, votre "passe-partout légal" dans chaque en-tête de fichier source se réduit à deux lignes:

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

En outre, les personnes qui automatisent les analyses de la chaîne logistique des logiciels vous remercient de vous en tenir à une norme commune de description de licence lisible par machine.