Dormir avec la GPL
Publié le 10 Février 2008
Filed under juridique , 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 contraindre une société à l'open source de leur logiciel. Après avoir couru sur cette question à Disney, Sony et plusieurs startups, cet article vise à clarifier ma propre compréhension ainsi que l'espérons aider quelques autres prendre des décisions éclairées. Veuillez noter que je ne suis pas un avocat et cet article ne sauraient être considérées comme un substitut à la lecture de la GPL et d'obtenir des conseils juridiques précis d'un avocat agréé.
Bien qu'il existe de nombreuses licences moins restrictives ( MIT, BSD, MPL, etc ), le GPL est peut-être le moins compris et les plus craints par les entreprises. Dans une certaine mesure cette confusion ne devrait pas être une surprise. Le mouvement FOSS (Free Software et Open Source) est constitué d'un réseau d'activistes qui ont légèrement différents idéaux. Depuis une loi de mesure s'appuie fortement sur l'intention et un traitement uniforme, les incohérences dans cette approche les eaux boueuses. Quand au fil du temps les dirigeants du mouvement font des déclarations contradictoires concernant la portée et l'intention de la GPL, ce injecte peur d'incertitude et de doute (FUD).
Pour rendre les choses encore plus confuses, le droit d'auteur est également en piteux état par rapport aux locataires de base que la GPL s'appuie. Pour les logiciels, ce qui constitue une utilisation équitable et les travaux dérivés sont en désaccord au sein de la jurisprudence. D'un extrême, la jurisprudence en déduit que le produit est dérivé même si vous n'avez pas de code copié à partir du système, il interagit. D'autre part, contradictoires déduit de la jurisprudence qu'il est le Fair Use à désosser un système pour l'utiliser sans se soucier d'être considéré comme dérivé.
Lequel de ces précédents que 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ées par les développeurs, nous devons revenir à l'intention des auteurs de la licence elle-même. Dans ce cas, la Free Software Foundation définit précisément 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 façon (dynamique ou statique).
Il existe plusieurs exceptions reconnues à cette règle telle que votre programme ne peut pas être considérée comme une œuvre dérivée.
- Vous pouvez lier dynamiquement avec une interface standard où d'autres bibliothèques existantes peuvent être substitués.
- Vous pouvez exécuter un programme GPL via fork () ou execute ().
- Vous pouvez communiquer avec un programme via des mécanismes réseau et IPC standard. *
- Vous pouvez distribuer votre programme et un programme sous GPL dans l'ensemble (sur le même support) à condition qu'ils soient encore représentent programmes distincts et les termes de la GPL sont respectées.
Ces exceptions nous donnent assez de corde pour utiliser les programmes et bibliothèques sous licence GPL en collaboration dans un plus grand système de code source fermé. En plus de ces quelques développeurs peuvent ajouter des exceptions explicites supplémentaires comme permettant dynamique ( LGPL ) ou statique lien. Dans certains cas, il peut également être possible de contacter les développeurs et négocier une licence à code source fermé qui supprime les limites de la licence GPL ensemble.
Il ya une autre lacune notable. La GPL ne se déclenche lorsque vous distribuez le programme dérivé. Si vous ne distribuez pas un programme issu de gens en dehors de votre entreprise, vous n'avez pas besoin de distribuer votre code source fermé. Vous pouvez même utiliser le logiciel dérivé du GPL comme un service et une charge d'argent pour cela sans libérer aucun code.
Dans la pratique, cette lacune ne avoir un couple pièges. La première est que vous ne pouvez pas vendre ou donner le programme dérivé à une autre société 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 de fusionner les sociétés et la vente des actifs peut également être considérée comme une distribution.
Bien sûr, comme avec n'importe quel logiciel de votre licence (FOSS ou commerciale), vous devriez être conscient des questions de brevets, l'indemnisation, les restrictions de licence supplémentaires (par exemple GPL3 restreint DRM) et le coût total de possession liés à la maintenance et de soutien. Comme avec tout ce que nous faisons comme les entreprises il ya plus à la ligne du bas de l'étiquette de prix à venir dans la porte.
L'autre chose à considérer est la perception du public et le mouvement FOSS. Vous utilisez les logiciels libres et le contrat implicite est que vous allez participer à la communauté et contribuer améliorations. Il ne suffit pas d'utiliser des logiciels libres, vous devriez adopter une politique qui énonce la façon dont vous utilisez les logiciels libres et comment vous soutenir. En collaboration 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
Filtre Scridb
Commentaires
Comme quelqu'un l'a souligné récemment sur une liste de diffusion, le GPL semble très arbitraire que vous n'avez pas besoin de distribuer votre source si vous fournissez un service, mais vous si vous fournissez un produit. En d'autres termes, le GPL favorise Software-as-services sur Software-as-produits.
Pourquoi quelqu'un création de logiciels avec une interface XML-RPC devrait arriver à garder leurs mods privé alors que quelqu'un distribuer une bibliothèque être obligé de révéler leurs mods?
Rechercher
Archives
Blogroll
Administrateur
 |  |  |  |  |  |  |  |  |  | ||||||||||||||||||||||||||||||||||||||
Salut Chuck,
En regardant cela comme un outsider, je pense qu'il ya un certain nombre de facteurs.
1) Le GPL coutures être conçus pour redéfinir les rôles des programmeurs de producteurs IP en prestataires de services. Avec le logiciel client du service est simplement un modèle différent (conseil, personnalisation, etc.)
2) Il est plus difficile d'appliquer sur le serveur. Il serait simple de cacher l'utilisation de logiciels sous licence GPL.
3) Ne pas permettre aux logiciels d'être monétisé comme un service limite l'adoption des produits.
En un mot limitation de l'utilisation de logiciels sous licence GPL en tant que service limiterait son adoption, l'utilité et le caractère exécutoire. Rappelez-vous aussi que le propriétaire du logiciel sous GPL peut double licence du produit et est effet pas lié par la GPL.
Bien que je ne l'utilisation de certains logiciels sous licence GPL, je préfère licences beaucoup moins restrictives et virales, même en tant que service. Chaque utilisation de logiciels, commerciaux ou FOSS, nécessite une diligence raisonnable pour déterminer l'aptitude et le coût total de possession.
Il ya beaucoup de facteurs qui conduisent à la réussite ou l'échec d'un projet FOSS, 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 de conditions de licence. Il sera intéressant de voir comment chaque licence en concurrence.
-Marty
- Spam
- attaque
- désaccord
- hors sujet
Comme