Il est courant de faire quelques ajustements ou correctifs dans du code tiers (que ce soit un simple résumé ou une bibliothèque entière). Mais il est également courant que beaucoup de ces codes aient leurs propres règles de licence et éventuellement un en-tête sur chaque fichier avec des informations de copyright.
Après avoir fait ces modifications, quelle est la bonne chose à faire ensuite? Gardez les informations de licence intouchables ou essayez de les mettre à jour, y compris vous-même avec quelque chose comme @authorou des @revisionbalises?
Un autre problème courant consiste à modifier l'espace de noms / package tiers pour l'adapter aux conventions de votre projet. Certains types de licences incluent ce type d'informations dans leur bloc de licence, puis-je les modifier librement?
Je sais que la réponse à ces questions dépend de chaque type de licence, alors pour rendre ma question plus précise ...
Compte tenu des règles générales de licence (généralement elles sont différentes sur des aspects mineurs, n'est-ce pas?), Il est éthique (ou du moins autorisé) que j'ajoute librement des informations au bloc de licence sur mes modifications et peut-être aussi de modifier la façon de m'en référer à mon code (par exemple utiliser YACorp.YALibcomme Utils.YALib)?
Réponses:
Je pense que vous confondez la licence du logiciel et tout prologue qui pourrait faire partie du logiciel.
La licence est l'endroit où les propriétaires des droits d'auteur du programme spécifient les conditions d'utilisation (la licence) pour d'autres personnes. Certaines licences sont très permissives, d'autres sont beaucoup plus restrictives.
Le prologue est l'endroit où les auteurs insèrent
@authoret@revisionbalises pour fournir un moyen de suivre les modifications apportées au code source. Dans certains cas, devenir l'auteur d'un ajout non trivial au code peut vous valoir le droit d'auteur sur cette section du code. Le démêlage des problèmes de droits d'auteur peut être épineux et est mieux géré par les avocats. Cependant, vous avez spécifiquement déclaré que vous ne vous préoccupiez pas de cet aspect, je vais donc poursuivre.Cela dépend vraiment des conventions du projet.
Si vous bifurquez le projet, vous pouvez faire ce que vous voulez.
Si vous prévoyez d'apporter vos modifications au projet, vous devez vous en tenir à la convention établie. S'il existe une raison impérieuse de modifier l'espace de noms, vous devez le présenter à la communauté de l'application.
Ne changez pas la licence!
Tout d'abord, vous n'avez probablement pas les droits légaux pour modifier la licence. Deuxièmement, toutes les modifications que vous apportez vont probablement gâcher la licence. Laissez les modifications de licence aux avocats.
En ce qui concerne la mise à jour du prologue, cela dépend des normes du projet. Certains projets ne veulent pas de prologue car ils utilisent le contrôle de code source pour le suivre. D'autres projets le font. Suivez les conventions du projet.
Si vous gardez vos changements pour vous, pourquoi vous souciez-vous de ce que les autres pensent? Quelque chose que vous n'utilisez que pour vous-même et que vous ne distribuez jamais à d'autres n'a aucun impact sur le projet d'origine. Donc, ils se moquent de ce que vous faites.
Si vous prévoyez de distribuer vos modifications ou de les réinjecter dans le projet, vous devez évaluer les conventions de ce projet. Certains projets ne veulent pas être bifurqués et auront une licence en place empêchant cela. D'autres vont jusqu'à dire "faites ce que vous voulez" et vous avez carte blanche pour faire comme bon vous semble. En fin de compte, la réponse ici dépend du projet particulier que vous regardez.
la source
J'ajouterais un commentaire, en partie pour signaler à un lecteur que le fichier n'est pas "vanille", avec des liens vers toute documentation pertinente ou un système de suivi des problèmes.
Edit: Donc, cette situation me rappelle quand une distribution Linux packages par exemple une bibliothèque. Debian a des directives et des normes sur la façon dont les paquets doivent être construits et nommés, ce qui pourrait bien différer de la façon dont la bibliothèque est généralement distribuée pré-construite.
Je ne pense pas que vous devriez hésiter à nommer / construire / modifier une bibliothèque, car je suppose que vous ne distribuerez pas le résultat au reste du monde? Dans ce cas, j'inclurais un fichier README avec la source qui décrit les modifications que vous avez apportées et pourquoi. Par exemple, README. $ {CompanyName} .changes
la source
Vous devrez consulter la règle de licence du code.
En général, de nombreuses applications frontales open source (par exemple Firefox, OpenOffice) considèrent leur nom et logo d'application comme une marque; Donc, si vous deviez publier une version modifiée de l'application, vous ne pourrez pas utiliser les marques / habillages commerciaux d'origine (donc IceWeasel, Torbrowser, LibreOffice).
Cependant, la plupart des bibliothèques de programmation sont souvent moins concernées par les marques tant qu'il est assez clair qui fait quoi (généralement cela peut être trouvé dans les métadonnées de contrôle de version).
Les informations sur l'auteur ont deux objectifs:
Ces derniers deviennent plus importants à mesure que vos modifications deviennent plus importantes. Les informations réelles sur la paternité peuvent généralement être trouvées dans le contrôle de version, mais certains projets créditent officiellement un ensemble d'auteurs dans un fichier séparé. Le point de coupure où les gens seraient officiellement crédités varie pour chaque projet, contactez les auteurs originaux en cas de doute.
la source