Dormir avec la GPL
Posté le 10 Février, 2008
Filed Under juridiques , Open Source , Web2.0 | 2 Commentaires
Aujourd'hui il ya beaucoup de malentendus et de confusion sur ce qui utilise des logiciels sous GPL peut forcer une compagnie à l'open source de leurs logiciels. Après avoir couru sur cette question à Disney, Sony et plusieurs startups, cet article vise à clarifier ma propre compréhension ainsi que nous espérons aider quelques autres prendre des décisions éclairées. S'il vous plaît noter que je ne suis pas un avocat et cet article ne doivent pas être considérées comme un substitut à la lecture de la GPL et obtenir des conseils juridiques précis à partir d'un brevet d'avocat.
Bien qu'il existe de nombreuses licences moins restrictives ( MIT, BSD, MPL, etc ), le GPL est peut-être le moins compris et le plus redouté par les entreprises. Dans une certaine mesure cette confusion ne doit pas être une surprise. Les logiciels libres (Logiciel Libre et Open Source) Le mouvement est constitué d'un ensemble de militants qui ont des idéaux un peu différente. Depuis une loi étendue s'appuie fortement sur l'intention et le traitement uniforme, les incohérences dans cette démarche dans les eaux boueuses. Lorsque le temps les dirigeants du mouvement de faire des déclarations contradictoires concernant la portée et l'intention de la GPL, cette peur injecte incertitude et doute (FUD).
Pour rendre les choses encore plus confuses, le droit d'auteur est également en mauvais état par rapport aux locataires de base que la GPL s'appuie. Pour les logiciels, ce qui constitue une utilisation équitable et œuvres dérivées sont en désaccord au sein de la jurisprudence. À un extrême, la jurisprudence en déduit que le produit est dérivée, même si vous avez copié aucun code à partir du système, il interagit avec. D'autre part, contradictoires déduit de la jurisprudence qu'il est le Fair Use de désosser un système pour l'utiliser sans se soucier d'être considérés comme produits dérivés.
Lequel de ces précédents, nous pensons va se jouer est potentiellement aléatoire et dépend beaucoup de la façon dont nous utilisons le code. Sans exclusions explicites fixés par les développeurs, nous devons revenir à l'intention des auteurs de la licence proprement dite. Dans ce cas, la Free Software Foundation sorts spécifiquement ses croyances. Dans leur interprétation de la GPL votre programme est dérivé si vous incluez du code GPL ou un lien vers le code GPL en aucune manière (dynamique ou statique).
Il ya plusieurs exceptions à cette règle reconnue telle que votre programme ne peut pas être considéré comme une œuvre dérivée.
- Vous pouvez lier dynamiquement l'encontre d'une interface standard où d'autres bibliothèques existantes peuvent être substitués.
- Vous pouvez exécuter un programme sous GPL avec fork () ou execute ().
- Vous pouvez communiquer avec un programme via le standard du réseau et des mécanismes IPC. *
- Vous pouvez distribuer votre programme et un programme sous GPL dans leur ensemble (sur le même support) à condition qu'ils restent représentent des programmes distincts et les termes de la GPL sont observées.
Ces exceptions nous donner assez de corde pour utiliser des programmes sous licence GPL et les bibliothèques en collaboration au sein d'un système plus large des sources fermées. En plus de ces développeurs peuvent ajouter des supplémentaires exceptions explicites, comme dynamique (permettant LGPL liaison) ou statique. Dans certains cas, il peut également être possible de contacter les développeurs et de négocier une licence de code source fermé qui supprime les limitations de la licence GPL tous ensemble.
Il ya un échappatoire d'autres notables. La GPL ne démarre lorsque vous distribuez le programme dérivé. Si vous ne distribuez pas un programme dérivé à des gens en dehors de votre entreprise, vous n'avez pas à distribuer votre code source fermé. Vous pouvez même utiliser la GPL logiciel dérivé comme un service et responsable de l'argent pour elle, sans relâcher n'importe quel code.
Dans la pratique, cette échappatoire a une pièges couple. La première est que vous ne pouvez pas vendre ou donner le programme proviennent d'une autre compagnie ou personne. La seconde que beaucoup ne considèrent pas, c'est que pendant certaines transactions M & A de la société est la vente des actifs plutôt que la fusion des sociétés et la vente des actifs peut également être considéré comme une distribution.
Bien sûr, comme avec n'importe quel logiciel de votre licence (FOSS ou commercial), vous devriez être conscient des questions de brevets, l'indemnisation, les restrictions de licence supplémentaire (par exemple GPL3 restreint DRM) et le coût total de propriété liés à la maintenance et de soutien. Comme avec n'importe quoi que nous faisons comme les entreprises il ya plus à la ligne de fond que l'étiquette de prix à venir dans la porte.
L'autre chose à considérer est la perception du public et du mouvement des logiciels libres. Vous utilisez les logiciels libres et le contrat implicite est que vous allez participer à la communauté et de contribuer à des améliorations. Il ne suffit pas d'utiliser les logiciels libres, vous devriez adopter une politique qui stipule la manière dont vous utilisez les logiciels libres et comment vous soutenir. Travailler avec les développeurs de logiciels libres et d'être un bon citoyen va un long chemin.
Références:
http://www.gnu.org/copyleft/gpl.html
http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html
http://www.fsf.org/licensing/licenses/gpl-faq.html
http://www.bu.edu/law/lawreview/v85n5/Stoltz.pdf
http://www.linuxinsider.com/story/38089.html?welcome=1202601329&welcome=1202602307
http://en.wikipedia.org/wiki/Free_software_licenses
http://en.wikibooks.org/wiki/FOSS_Licensing/Scenarios
Scridb filtre
Commentaires
Comme quelqu'un a récemment souligné sur une liste de diffusion, la GPL semble très arbitraire en ce que vous n'avez pas à distribuer votre source si vous fournissez un service, mais vous si vous fournissez un produit. En d'autres termes, la GPL favorise Software-as-services sur logiciel en tant que sous-produits.
Pourquoi quelqu'un devrait créer un logiciel avec une interface XML-RPC arriver à garder leurs mods privés tandis que quelqu'un distribuer une bibliothèque être forcé de révéler leurs mods?
Rechercher
Archives
Blogroll
Admin
 |  |  |  |  |  |  |  |  |  | ||||||||||||||||||||||||||||||||||||||
Salut Chuck,
En regardant cela comme un outsider, je pense qu'il ya un certain nombre de facteurs.
1) La GPL coutures doivent être conçus pour redéfinir les rôles des programmeurs de producteurs IP en prestataires de services. Avec un logiciel client le service est tout simplement un modèle différent (personnalisation, etc consultation,).
2) Il est plus difficile à appliquer sur le serveur. Il serait simple de cacher l'utilisation de logiciels sous GPL.
3) Ne pas permettre aux logiciels d'être monétisé comme un service limites de l'adoption des produits.
En un mot limitant logiciels sous licence GPL utilisé comme un service qui limiterait son adoption, l'utilité et le caractère exécutoire. Rappelez-vous également que le propriétaire du logiciel sous licence GPL peut dual licence du produit et est donc pas lié par la licence GPL.
Bien que je ne utiliser certains logiciels sous GPL, je préfère licences beaucoup moins restrictives et virales, même en tant que service. Chaque utilisation de logiciels, commerciaux ou logiciels libres, nécessite une certaine diligence raisonnable pour déterminer l'aptitude et le coût total de possession.
Il ya plusieurs facteurs qui conduisent à la réussite ou l'échec d'un projet de logiciels libres, la licence est l'un des éléments qui peuvent ajouter de friction pour adoption. Nous constatons déjà une division et la duplication des efforts en raison des exigences de licence. Il sera intéressant de voir comment chaque licence compétition.
-Marty
- le spam
- offensif
- en désaccord
- hors sujet
Comme