Quelle est la meilleure pratique pour organiser des «formalités administratives» de 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 en matière de «paperasse». Par exemple, la licence Apache, v2.0 indique:

Si les travaux incluent un fichier texte "NOTICE" dans le cadre de sa distribution, tous les travaux dérivés distribués doivent inclure une copie lisible des avis d'attribution contenus dans ce fichier NOTICE.

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 une notice de copyright et indique:

Les redistributions sous forme binaire doivent reproduire la notice de copyright ci-dessus, cette liste de conditions et la clause de non-responsabilité suivante dans la documentation et / ou dans les autres éléments fournis avec la distribution.

LGPL v.3 dit:

(Vous devriez) avertir chaque copie du travail combiné que la bibliothèque y est utilisée et que la bibliothèque et son utilisation sont couvertes par la présente licence.

Les licences LGPL et CDDL nécessitent également de fournir le code source ainsi qu'une forme binaire de bibliothèque. Par conséquent, les informations sur la manière dont le code source peut être obtenu doivent être fournies quelque part.

Quelle est la meilleure pratique pour organiser toutes ces données? Devrais-je créer un fichier texte et copier le contenu de tous les NOTICEfichiers, licences MIT et BSD, etc. dans ce fichier? ... ou devrais-je créer un répertoire distinct pour chaque bibliothèque et y placer toutes les données relatives à la bibliothèque? … 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 Faut-il inclure un avis de licence avec chaque fichier source? , mais cela ne règle pas mon problème. Ma question concerne les bibliothèques tierces utilisées dans un projet. Cette question concerne les en-têtes du code source du projet.

Premièrement, la clause de non-responsabilité standard: IANAL mais un inconnu au hasard.

Je viens d’empaqueter une application AGPL (*) récemment. Il utilise des bibliothèques tierces distribuées sous des licences jQuery, MIT, BSD (et quelques autres). Voici comment j'ai procédé.

Lorsque j'ai conçu ceci, mes intentions principales étaient les suivantes: être conforme et juste . Alors que le premier devrait être suffisant, le second garantit que quiconque essaiera de me poursuivre en justice pour ne pas l'avoir obtenu à 100% doit admettre que j'ai agi de bonne foi.

1) Fichiers sources: tous mes fichiers ont l’en-tête AGPL. Tous les fichiers tiers sont laissés (pour la plupart) non modifiés, 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 paquet, contient des copies complètes de TOUTES les licences. Pour chaque licence, un en-tête indique de quelle licence il s'agit et à quelle partie il s'applique. J'inclus également le nom des détenteurs de droits d'auteur ici - je les réutilise ailleurs après, donc cela en 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) Le fichier README.txt, également à la racine, explique que le logiciel est AGPL (voir LICENSE.txt) et utilise des bibliothèques tierces distribuées sous leurs propres termes (voir LICENSE-3RD-PARTY.txt).

5) Dans la documentation en ligne, j'ai une page de licence qui répète les informations du fichier readme: mon logiciel est AGPL et utilise des composants tiers qui sont 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 du détenteur des droits d'auteur, ainsi qu'un lien vers son 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) Également dans la documentation en ligne, j'ai une page de 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 accusés de réception requis ou souhaités par les auteurs des outils, bibliothèques, etc. de tierces parties.

7) Dans le logiciel lui-même, la liste des bibliothèques avec les détenteurs de la licence et du copyright est répétée dans la boîte de dialogue À propos de.

Pour répondre à vos questions spécifiques concernant l’inclusion de code source et la structure de fichier:

• il est généralement accepté de ne créer que des liens vers le code source complet des packages tiers. Consultez chaque licence spécifique pour être sûr, mais IMHO fournir le lien devrait être suffisant. 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 exige explicitement que les distributions conservent la présentation du fichier identique, vous pouvez réorganiser les éléments à votre guise. Imaginez que vous utilisiez des bibliothèques Web, ayant chacune un répertoire css / et un répertoire js /, vous pouvez les fusionner dans un seul répertoire lib /, contenant les fichiers css / et js / fusionnés, ou même les disperser tout autour de votre arborescence source - à vous de choisir.

Et comme une note finale, je serais plus que bienvenue commentateurs qui agitent la main en disant : « vous faites ce mal » et / ou « vous devez aussi faire que ».

_{(*) Il ne s'agit pas d'un lien spam, mais simplement d'une réponse à 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.}