fsfe-france
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Fsfe-france] Re: "Multi-licensing" wiki, documentation - comp atibilité


From: Alexandre Dulaunoy
Subject: [Fsfe-france] Re: "Multi-licensing" wiki, documentation - comp atibilité - une approche possible ?
Date: Mon, 17 Apr 2006 15:43:55 +0200
User-agent: mutt-ng/devel-r655 (Linux)

On 17/Apr/06 14:46 +0200, Antoine wrote:
> Le lundi 17 avril 2006 à 14:06 +0200, Alexandre Dulaunoy a écrit :
> > Salut à tous,
> > 
> > Depuis  quelques  temps, je  cherche  un  moyen  simple de  rendre  du
> > ""contenu""  (Wiki,  site web,  documentation)  libre  en évitant  une
> > majorité des problèmes de compatibilité.
> > 
> > Dans  toutes les  approches  utilisées, j'étais  tomber  sur celle  de
> > Emacswiki[1]  (le wiki  d'Alex Schroeder)  qui ne  semble pas  la plus
> > mauvaise :
> > 
> > """
> > This work is licensed to you under version 2 of the GNU General Public
> > License. Alternatively, you may choose  to receive this work under any
> > other  license that  grants the  right  to use,  copy, modify,  and/or
> > distribute the work,  as long as that license  imposes the restriction
> > that derivative  works have  to grant the  same rights and  impose the
> > same restriction.  For example,  you may choose  to receive  this work
> > under  the   GNU  Free  Documentation   License,  the  CreativeCommons
> > ShareAlike License, the XEmacs manual license, or similar licenses.
> > """
> 
> "Similar licenses" est assez spécieux sur le principe. Il faut lister
> exhaustivement les licences jugées compatibles, AMA. Je suggère d'y
> rajouter la licence Art Libre. Il peut être utile également de spécifier
> que  la  mise  sous  GFDL  ne doit  pas  s'accompagner  de  sections
> invariantes.

Bons  points  concernant   la  LAL  et  la  GFDL   sans  les  sections
invariantes.

une idée: "Similar licenses" par "Licenses sharing the same objectives
of freedom" ?
 
> Une précision en passant : la GPL et la GFDL requièrent la mise à
> disposition des sources sur demande, ce n'est pas le cas de la CC-BY-SA
> ni de la LAL. Je ne sais pas ce qu'il en est de la "XEmacs manual
> license".

En  effet mais j'ai  ce gros  problème avec  les CC[1]  concernant les
modifications puisque la licence ne requière pas la mise à disposition
des sources.  Pourtant pour  pouvoir réaliser des modifications, c'est
clairement plus commode. (Imaginons le texte en format PNG, on préfère
avoir la source ASCII du texte)

J'aurais tendance  à supprimer la XEmacs manual  license parce qu'elle
est peu utilisée...

Pour la CC-SA  (or CC-BY-SA), je ne  sais pas trop, je ne  suis pas un
grand   fan   du   modèle   mais   il   y   a   un   certain   "groupe
d'utilisateurs/auteurs".

[1] Pour  l'instant l'inclusion d'une  CC dans cette notice  génère un
paquet de problème mais c'est difficile d'éviter le "marketing" CC ;-)

> 
> Autre précision en passant : la CC-SA (CreativeCommons ShareAlike)
> semble avoir été abandonnée par Creative Commons après le constat que
> les versions "BY" (avec Attribution) étaient très majoritairement
> utilisées.

Je ne  comprends pas trop.   CC-SA possède par défaut  l'attribution ?
puisque  la  licence  est  présente  et ne  peut  être  modifiée  donc
l'attribution  de l'auteur  (ou  son  pseudo) est  tjs  présente ?  En
comparant les  licences CC,  la différence CC-SA  / CC-BY-SA  est fort
subtile. Je n'ai  pas creuser le problème mais je  n'ai pas fort envie
;-)

Il  me semblait  par défaut  que  toutes les  licences libres  inclues
l'attribution  par  le   fait  même  de  la  licence   et  du  nom  de
l'auteur. (la GNU GPL est clairement 'BY')

Je dois avouer  que le modèle CC  est sujet à ce genre  de problème de
compréhension... Que faire ?

 
> > * Quelle est la validité et la portée d'une telle notice ?
> > ** Existe-il  des possibilités  pratiques pour ne  pas la  respecter ?
> >    (sur la forme ou le fond de la notice)
> 
> Je ne suis pas juriste mais il me semble que toute possibilité de flou
> doit profiter à l'auteur, donc dans un sens restrictif. En effet la
> licence ne sert qu'à exprimer la volonté de l'auteur. Si cette volonté
> est mal exprimée il faut en revenir au droit d'auteur traditionnel.
> 
> Ceci dit, si tu veux garder la formulation "ouverte", étant donné la
> vogue actuelle des licences non-commerciales, je suggère d'ajouter
> explicitement que les droits offerts doivent inclure toute utilisation
> commerciale. Histoire d'éviter les malentendus.

Oui,  c'est un  autre bon  point.   Un truc  du genre  : "sans  aucune
restriction du cadre d'utilisation".

> Une autre possibilité est de pointer vers la liste des licences libres
> selon la FSF et de restreindre la compatibilité à celles de ces licences
> qui obligent les oeuvres dérivées à conserver les droits et les devoirs
> spécifiés par la licence.
> 
> Mais personnellement j'abandonnerais cette clause "ouverte" et listerais
> explicitement toutes les licences autorisées. C'est plus lisible et plus
> simple à la fois pour le destinataire et l'originataire (l'auteur).

Cela a  du sens mais  comme la liste  FSF n'est pas exhaustive  (et ne
semble pas  vouloir l'être à court  terme), on risque  de se retrouver
avec un nombre  incalculable de licence hors de la  liste. Il est vrai
que garder la clause ouverte donne deux risques importants :

* Aider à la prolifération des  licences (c'est pas vraiment une bonne
idée mais c'est difficile de l'éviter pour l'instant),

* On laisse ouvert à des licences semblant respecter les libertés mais
ayant des astuces pour éviter de les respecter.

Mais la liste restreinte me semble bien, je vais essayer de venir avec
une proposition dans ce sens.

Merci pour le feedback,

Bonne journée,

adulau


-- 
--                   Alexandre Dulaunoy (adulau) -- http://www.foo.be/
--                          http://www.gnu.org/philosophy/free-sw.html
--         "Knowledge can create problems, it is not through ignorance
--                                that we can solve them" Isaac Asimov




reply via email to

[Prev in Thread] Current Thread [Next in Thread]