> * Un passage de la licence tente d'éviter les actions en justice pour des histoires de brevets logiciels en interdisant l'usage des logiciels aux personnes initiant les actions en justice. Problème : c'est de la discrimination => non libre.
Seul point problématique à mon sens, d'autant plus que le paragraphe en question des licences (5. Reciprocity) n'est pas un modèle de clarté.
> * Inclusion d'un fichier "NOTICES" (contenant des données à "informational purposes"). Ce fichier ne doit pas être supprimé dans des travaux dérivés. => Non libre
s/non libre/non conforme aux DSFG/
De plus le template de fichier NOTICE ainsi que l'exemple pour httpd-2.0 donnés en annexe de la première licence indiquent clairement quel est le but poursuivi par l'introdution de ce fichier : avoir une licence dont le texte ne change pas selon les projets qu'elle couvre (contrairement à la licence Apache V1) en transférant les informations de copyright dans ce fichier. Ainsi on peut s'apercevoir que les informations que l'on serait obligé de redistribuer dans tout projet dérivé de httpd ne serait pas vraiment différentes de celles que la licence V1 nous impose de redistribuer également.
(A noter que les deux points suivants ne concernent que les licences "Apache RI License, version 1.0" et "Apache TCK License, version 1.0" et pas la licence "Apache License, version 2.0")
> * Possible inclusion de classes Java de Sun non libres.
Moi je lis : Possible implémentation des classes Java de base définies par les Java Specifications Requests.
> * Pour en faire un travail dérivé, on doit, soit : ...
Précisons encore une fois que ces restrictions ne sont présentes que dans les deux dernières licences qui ne sont destinées qu'aux projets de l'ASF liés à sa participation au Java Community Process ( http://www.jcp.org/en/home/index(...) ), c'est à dire aux projets visant à établir les spécifications techniques de la plateforme Java.
De par ce fait, il ne me semble pas scandaleux de demander à ce que les travaux dérivé implémentent également ces spécifications, ou bien qu'ils indiquent de façon claire et non équivoque qu'ils ne le font pas.
# Re: Nouvelles licences Apache non libres ?
Posté par Mus . En réponse à la dépêche Nouvelles licences Apache non libres ?. Évalué à 2.
Seul point problématique à mon sens, d'autant plus que le paragraphe en question des licences (5. Reciprocity) n'est pas un modèle de clarté.
> * Inclusion d'un fichier "NOTICES" (contenant des données à "informational purposes"). Ce fichier ne doit pas être supprimé dans des travaux dérivés. => Non libre
s/non libre/non conforme aux DSFG/
De plus le template de fichier NOTICE ainsi que l'exemple pour httpd-2.0 donnés en annexe de la première licence indiquent clairement quel est le but poursuivi par l'introdution de ce fichier : avoir une licence dont le texte ne change pas selon les projets qu'elle couvre (contrairement à la licence Apache V1) en transférant les informations de copyright dans ce fichier. Ainsi on peut s'apercevoir que les informations que l'on serait obligé de redistribuer dans tout projet dérivé de httpd ne serait pas vraiment différentes de celles que la licence V1 nous impose de redistribuer également.
(A noter que les deux points suivants ne concernent que les licences "Apache RI License, version 1.0" et "Apache TCK License, version 1.0" et pas la licence "Apache License, version 2.0")
> * Possible inclusion de classes Java de Sun non libres.
Moi je lis : Possible implémentation des classes Java de base définies par les Java Specifications Requests.
> * Pour en faire un travail dérivé, on doit, soit : ...
Précisons encore une fois que ces restrictions ne sont présentes que dans les deux dernières licences qui ne sont destinées qu'aux projets de l'ASF liés à sa participation au Java Community Process ( http://www.jcp.org/en/home/index(...) ), c'est à dire aux projets visant à établir les spécifications techniques de la plateforme Java.
De par ce fait, il ne me semble pas scandaleux de demander à ce que les travaux dérivé implémentent également ces spécifications, ou bien qu'ils indiquent de façon claire et non équivoque qu'ils ne le font pas.