Ah ! J’allais justement réagir sur ce point un peu au-dessus. Les licences libres ne demandent à priori que les sources, qui ne sont pas les seuls documents qui permettent de produire un programme (entre un cahier des charges, la description de l’architecture, la documentation interne, le détail des algorithmes avant implémentation, l’API des librairies écrites pour l’occasion, y’a de quoi faire).
À mon avis la fourniture des documents qui vient avec la plupart des projets libres n’est pas une obligation stricte imposée par les licences : des entreprises qui libèrent dans la nature leurs modifications sous la forme d’un patch monstrueux, ça arrive. Ça a même fait des vagues ici et là. Que je sache Redhat n’a pas été inquiétée de distribuer les patch sous cette forme. C’est uniquement une question de bonne pratique, et de réputation envers la communauté.
...
Bon je viens de retrouver, pour la GPL, je suppose que tu parles de ce bout là :
The "source code" for a work means the preferred form of the work for making modifications to it. "Object code" means any non-source form of a work.
The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.
The Corresponding Source need not include anything that users can regenerate automatically from other parts of the Corresponding Source.
Donc je suppose que ça dépend : le makefile doit être distribué. La suite de test j’en doute. Pour les gestionnaires : si tu parles des programmes, je caserais ça dans des « general-purpose tools », si tu parles des données que ces programmes manipulent... ben je vois pas où il en est fait mention.
[^] # Re: Blabla
Posté par BB . En réponse au journal Jamendo, les creative commons et l'hypocrisie de la "culture libre". Évalué à 1.
Ah ! J’allais justement réagir sur ce point un peu au-dessus. Les licences libres ne demandent à priori que les sources, qui ne sont pas les seuls documents qui permettent de produire un programme (entre un cahier des charges, la description de l’architecture, la documentation interne, le détail des algorithmes avant implémentation, l’API des librairies écrites pour l’occasion, y’a de quoi faire).
À mon avis la fourniture des documents qui vient avec la plupart des projets libres n’est pas une obligation stricte imposée par les licences : des entreprises qui libèrent dans la nature leurs modifications sous la forme d’un patch monstrueux, ça arrive. Ça a même fait des vagues ici et là. Que je sache Redhat n’a pas été inquiétée de distribuer les patch sous cette forme. C’est uniquement une question de bonne pratique, et de réputation envers la communauté.
...
Bon je viens de retrouver, pour la GPL, je suppose que tu parles de ce bout là :
Donc je suppose que ça dépend : le makefile doit être distribué. La suite de test j’en doute. Pour les gestionnaires : si tu parles des programmes, je caserais ça dans des « general-purpose tools », si tu parles des données que ces programmes manipulent... ben je vois pas où il en est fait mention.