Quelle est la meilleure pratique pour organiser la «paperasserie» des licences de bibliothèque tierces?
Je développe un petit projet open source. L'application utilise de nombreuses bibliothèques tierces publiées avec une gamme de licences: Apache, MIT, BSD, LGPL et CDDL.
Chacune de ces licences a ses propres exigences de "paperasse". Par exemple, la licence Apache, v2.0 dit:
Si l'Œuvre comprend un fichier texte "AVIS" dans le cadre de sa distribution, alors tout Œuvre dérivée que vous distribuez doit inclure une copie lisible des avis d'attribution contenus dans ce fichier AVIS.
La licence MIT contient une notice de copyright et indique:
L'avis de droit d'auteur ci-dessus et cet avis d'autorisation doivent être inclus dans toutes les copies ou parties substantielles du logiciel.
La licence BSD contient également un avis de copyright et indique:
Les redistributions sous forme binaire doivent reproduire l'avis de droit d'auteur ci-dessus, cette liste de conditions et la clause de non-responsabilité suivante dans la documentation et/ou d'autres documents fournis avec la distribution.
LGPL v.3 dit:
(Vous devez) indiquer clairement à chaque copie de l'œuvre combinée que la bibliothèque y est utilisée et que la bibliothèque et son utilisation sont couvertes par cette licence.
Les licences LGPL et CDDL nécessitent également de fournir le code source ainsi qu'une forme binaire de bibliothèque, de sorte que les informations sur la façon dont le code source peut être obtenu doivent être fournies quelque part.
Quelle est la meilleure pratique pour organiser toutes ces données? Dois-je créer un fichier texte et copier le contenu de tous les fichiers NOTICE, MIT et licences BSD, etc. dans ce fichier? ... ou dois-je créer un répertoire séparé pour chaque bibliothèque et mettre toutes les données relatives à la bibliothèque dans ce répertoire?… ou autre chose?
Il serait également intéressant de voir des exemples de cette "paperasse" dans les projets publiés.
MISE À JOUR:
J'ai lu Devez-vous inclure un avis de licence avec chaque fichier source? , mais cela ne résout pas mon problème. Ma question concerne les bibliothèques tierces qui sont utilisées dans un projet, et cette question concerne les en-têtes dans le propre code source du projet.
Tout d'abord, la clause de non-responsabilité standard: IANAL mais un inconnu au hasard.
J'ai emballé un AGPL application (*) récemment. Il utilise des bibliothèques tierces distribuées sous jQuery, MIT, BSD (et quelques autres) licences. Voici comment j'ai procédé.
Mes intentions principales lorsque j'ai conçu ceci étaient: être conforme et être juste . Alors que le premier devrait être suffisant, le second garantit que quiconque essaie de me poursuivre pour ne pas avoir 100% raison doit admettre que j'ai fait les choses de bonne foi.
1) Fichiers source: tous mes fichiers ont l'en-tête AGPL. Tous les fichiers tiers ne sont pas modifiés (pour la plupart) et incluent donc leur propre en-tête de licence.
2) LICENSE.txt, à la racine du package, contient le texte de la licence AGPL (comme expliqué dans la section "Comment appliquer ces conditions à vos nouveaux programmes").
3) Un fichier de licence secondaire, que j'ai nommé LICENSE-3RD-PARTY.txt, également situé à la racine du package, contient des copies textuelles de TOUTES les licences. Pour chaque licence, un en-tête indique à quelle licence il s'agit et à quelle partie elle s'applique. J'inclus également le nom des titulaires des droits d'auteur ici - je les réutilise ailleurs par la suite, donc ça vaut la peine.
-----------------------------------------------------------------------------
The MIT License (MIT)
applies to:
- AJAX Upload, Copyright (c) Andrew Valums
- jQuery hashchange event, Copyright (c) 2010 "Cowboy" Ben Alman
- jquery.hotkeys, Copyright (c) 2010 John Resig
-----------------------------------------------------------------------------
Permission is hereby granted, free of charge [...]
4) README.txt, également à la racine, explique que le logiciel est AGPL (voir LICENSE.txt) et utilise des bibliothèques tierces qui sont distribuées selon leurs propres termes (voir LICENSE-3RD-PARTY.txt)
5) Dans la documentation en ligne, j'ai une page Licence qui répète les informations du fichier Lisezmoi: mon logiciel est AGPL, et il utilise une tierce partie composants BSD/MIT/[...]. J'ai décidé de garder cette page plus propre et plus lisible, par conséquent, seul le nom de la licence est fourni, avec un lien vers le texte intégral, et le nom des titulaires des droits d'auteur avec un lien vers leur propre site Web.
jQuery
Copyright 2013 jQuery Foundation and other contributors
http://jquery.com
MIT License
Data Driven Documents (D3)
Copyright (c) 2013, Michael Bostock <-- link to personal website, if any
http://d3js.org <-- link to software website
BSD-like license <-- link to license full text
[...]
6) Toujours dans la documentation en ligne, j'ai une page Crédits , où je liste les principaux contributeurs directs et indirects. J'ai par exemple cité le groupe PostgreSQL, bien que PostgreSQL ne soit pas inclus dans le téléchargement, mais vous en avez besoin pour exécuter le logiciel. Ce serait un bon endroit pour placer tous les remerciements requis ou souhaités par les auteurs d'outils/bibliothèques/etc.
7) Dans le logiciel lui-même, la liste des bibliothèques ainsi que les détenteurs de licence et de copyright, est répétée dans la boîte de dialogue À propos .
Pour répondre à vos questions spécifiques concernant l'inclusion de code source et la disposition des fichiers:
il est généralement accepté de ne lier que le code source complet des packages tiers. Consultez chaque licence spécifique pour en être sûr, mais à mon humble avis, le lien devrait suffire. Par exemple, si vous utilisez une version réduite d'une bibliothèque, vous pouvez fournir le lien vers le téléchargement standard et tout va bien.
à moins que le composant tiers n'exige explicitement que les distributions gardent la disposition des fichiers identique, vous pouvez réorganiser les choses comme vous le souhaitez. Imaginez que vous utilisez des bibliothèques Web, ayant chacune un répertoire css/et js /, vous pouvez les fusionner ensemble dans un seul répertoire lib /, contenant les css/et js/fusionnés, ou même les disperser tout autour de votre arbre source - votre choix.
Et comme note finale, je serais plus que ravi d'accueillir les commentateurs qui agitent la main en disant "vous faites ceci mal" et/ou "vous devriez aussi faire ça = ".
(*) Il ne s'agit pas d'un lien de spam, mais simplement de répondre à la partie "veuillez fournir des exemples" de la question. N'hésitez pas, chers mods, à effacer ce lien si cela est contraire aux règles.