Re: (DRAFT 3) FAQ on documentation licensing
O Mércores, 20 de Abril de 2005 ás 08:40:21 +0200, Jacobo Tarrio escribía: Yes, in places it is too verbose, being that I'm not used to writing in English :-) (I think that I've been reading too many American laws, lately. The provision hereunder, therefore, applies to all persons not under 17 and born not after 1950, unless they never wear pants. 'Pants' means...). -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
I begin undestand debian community (comments to FAQ)
Hi, all. I am newbie and begin undestand debian community only now. Excuse me for previous questions. The matter looked simle. Exists several documentation of standarts in format plain/text with license like Permission is granted to distribute verbatim copies. Documents are useful and some people want to see they in main section. The license mostly conform DFSG section Integrity of The Author's Source Code except paragraph The license must explicitly permit distribution of software built from modified source code.. DFSG primary was developed for software and not adequate to text documents, which not needed to be builded. Simplest way is make obvious change If software must be builded to be used, then the license must explicitly permit distribution of software built from modified source code.. Thats all, almost happy. But what do debian community? Debate what is freedom? and what is not freedom?. Write faq, guidelines, howto and other bureaucratic documents about freedom. Yes, you are free to do this. But. You must undestand and keep in mind. For normal people (not specialized in freedom) things, such as putting gnu-standarts to non-free, always looked very strange (said softly). Good luck -- Olleg Samoylov smime.p7s Description: S/MIME Cryptographic Signature
Re: I begin undestand debian community (comments to FAQ)
Olleg Samoylov [EMAIL PROTECTED] writes: DFSG primary was developed for software and not adequate to text documents, which not needed to be builded. That's wrong, Bruce Perens intended the DFSG to apply to software and documentation alike when he designed them. See his clarification here: http://lists.debian.org/debian-legal/2003/08/msg00690.html Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: I begin undestand debian community (comments to FAQ)
On Wed, Apr 20, 2005 at 01:44:04PM +0400, Olleg Samoylov wrote: DFSG primary was developed for software and not adequate to text documents, which not needed to be builded. The DFSG was developed to be a standard of freedom. It's just as applicable to documentation as it is for programs (and fonts, and graphics, and sounds). Permission to modify is critical for free documentation. Nothing that can't be modified, adapted, and reused is free. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
(DRAFT 4) FAQ on documentation licensing
After suggestions by Glenn Maynard, I rewrote most of the document to make it simpler and remove redundancies that were repeated over and over ;- I repeat my point: repeated exposure to American legal texts is bad for non-native speakers ;-))) The first two questions were merged into a single one. The question about credits was deleted as it is probably too hard to answer in a FAQ (and it is not frequent at all, anyway). The end-result is two questions shorter than the original, and much easier to read (I hope). I'm still unhappy with the length of the second question (the question itself, not the answer). The current text: http://jacobo.tarrio.org/Documentation_licensing_FAQ Full document history is available by clicking on the historial tab, in case you want to compare or recover something. If you do not understand Spanish, you can use the Wikipedia page as a reference (the software I use is Wikimedia). You cannot edit any pages; direct your comments here. Q: Why does Debian apply the DFSG to documents? A: Debian applies the same standards of freedom to all works it distributes; some of these standards are written down in the DFSG. No good reasons have been provided to use a different standard with documents than with programs. Even if we were to treat software and documentation differently, first we would need to have a clear way to tell documentation apart from software. Many works, like source code annotated with Javadoc comments or Postscript files, are software and documentation at the same time, so it is easy to see that there is no such clear division. Q: Some documents need to have some parts which must not be modified. For example, RFC or other standards documents should not be modifiable at all. Or a piece may contain the author's opinion on something, and nobody should be allowed to misrepresent the author's position by modifying that piece. Isn't this a restriction that should be allowed in documents and not in programs? A: Mainly, for three reasons: such a restriction is unnecessary, it is useless and it is not true that it would be less appropriate for software than for documentation. First, misrepresentation can be prevented without forbidding anyone to modify the work, by requiring all modified works to not claim that they are the original work or that they were written by the original work. Furthermore, a clause in a copyright license would not stop anyone from misrepresenting the work or its authors. For example, I might create a new, original document titled RFC 2821, Simple Mail Transfer Protocol with a distorted description of SMTP, and with this action I would not be contravening the license of the IETF's RFC 2821. The proper defense against this are the various laws dealing with libel, fraud and impersonation. Finally, if there were any reasons to allow such a restriction in documents, these reasons would allow it in programs too. For example, qmail's license forbids distributing modified versions of it, since its author believes that his reputation might suffer if someone distributed a version of qmail with bugs not introduced by him. If restrictions on modification of documents were allowed to save an author's reputation, they would be allowed on programs; this would make qmail free, but due to the DFSG it isn't, so these restrictions cannot be allowed. Q: I think that some Debian Free Documentation Guidelines should be created as an alternative to the DFSG for documentation. What should I do to have them adopted? A: First, you must write them; most people never manage this part. Next, for every license restriction permitted by your new guidelines that isn't allowed by the DFSG, you must give satisfactory answers to these three questions: 1. How do we distinguish between packages where this restriction should and should not be allowed? 2. Why should the restriction be allowed in for these packages? 3. Why shouldn't the restriction be allowed in for every other package? Note that the answers to (2) and (3) should not involve special pleading or otherwise be contradictory. Because it's documentation is not a valid answer, and the answer to (3) should not apply to the packages in question. You'll need to discuss your proposal on debian-legal and debian-project to work out any problems with your proposal and to gather support for it. Finally, you'll have to propose a General Resolution to amend the Social Contract, and convince a 3:1 supermajority of your fellow Debian developers to vote for it. Q: If the DFSG are to be applied to documents as well as to programs, why is the text of the GPL included in Debian, if it says that it cannot be modified at all? A: Because the verbatim text of the license must be distributed with any work licensed under its terms. This is not specific to the GPL; almost all free licenses require that their text be included verbatim with the work. As a compromise, Debian distributes copies of the GPL and
Re: [Fwd: Re: Bug#304316: section non-free/doc]
Michael K. Edwards [EMAIL PROTECTED] wrote: For the record, so long as implementations of software freedom are copyright-based, documents from which fragments cannot legally be cut and pasted into the software they accompany do not belong in main. This applies most emphatically to the GFDL and to RFCs, inconvenient as that may be. When did license incompatibility become a freeness issue? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: (DRAFT 4) FAQ on documentation licensing
O Mércores, 20 de Abril de 2005 ás 11:20:36 -0300, Humberto Massa escribía: s/software/programs and\/or libraries/g Darn, I had managed to avoid it in the previous version :-) -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: (DRAFT 4) FAQ on documentation licensing
O Mércores, 20 de Abril de 2005 ás 14:53:18 +, MJ Ray escribía: Q: Shouldn't we allow documents which describe standards or personal opinions to be non-modifiable? Why should we need the same freedoms as for programs? That's a good one (although I don't like the last question very much, I'm putting it in anyway). I think a better example would be the demonstration implementation of a protocol included with a standards document. (I know it's popular (maybe even deserved) to kick qmail, but why do it here?) I suggest: Well, I wrote about qmail because it was the example I knew best. Hey, I even understood his reasons! ;-) Ok, ok, I'm leaving DJB alone... the Q now reads: Q: Shouldn't we allow documents which describe standards or personal opinions to be non-modifiable? Why should we need the same freedoms as for programs? A: Mainly, for three reasons: such a restriction is unnecessary, it is useless and it is not true that it would be less appropriate for programs than for documentation. First, misrepresentation can be prevented without forbidding anyone to modify the work, by requiring all modified works to not claim that they are the original work or that they were written by the original authors; so, the restriction is unnecessary. Furthermore, a clause in a copyright license would not stop anyone from misrepresenting the work or its authors. For example, I might create a new, original document titled RFC 2821, Simple Mail Transfer Protocol with a distorted description of SMTP, and with this action I would not be contravening the license of the IETF's RFC 2821. The proper defense against this are the various laws dealing with libel, fraud and impersonation. So, such a restriction would be useless. Finally, if there were any reasons to allow such a restriction in documents, these reasons would allow it in programs too. For example, a standards document might be accompanied by a demonstration program. One could say that the reputations of the authors of the document and the program may suffer if someone breaks either one of them. If Debian allowed any restriction on modification of the document, Debian should also allow the same restriction on modification on the program, so this kind of restrictions would not be more appropriate for documentation than for programs. -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: (DRAFT 3) FAQ on documentation licensing
On Tue, Apr 19, 2005 at 11:43:33PM -0400, Glenn Maynard wrote: [2] I'm not sure if slander or libel are the relevant laws, here. It depends on the specifics of what you claimed they said. It could also be fraud, or a variety of other jurisdiction-specific things. Not desperately interesting for our purposes. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: (DRAFT 4) FAQ on documentation licensing
On Wed, Apr 20, 2005 at 02:53:18PM +, MJ Ray wrote: Finally, if there were any reasons to allow such a restriction in documents, these reasons would allow it in programs too. For example, qmail's license forbids distributing modified versions of it, since its author believes that his reputation might suffer if someone distributed a version of qmail with bugs not introduced by him. If restrictions on modification of documents were allowed to save an author's reputation, they would be allowed on programs; this would make qmail free, but due to the DFSG it isn't, so these restrictions cannot be allowed. I think a better example would be the demonstration implementation of a protocol included with a standards document. Java. It's precisely the reason Sun use. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Draft Debian and mplayer FAQ
There have been some comments about mplayer, compared to ffmpeg and other packages. The discussion here seems to have cooled, so I have written a summary of the situation as I understand it. Is it accurate? Please send me comments and/or improvements (as plain text or patches, please). I'd also like to hear what next steps readers would suggest about the mplayer package, even if I'm not going to take them myself. The Debian and mplayer FAQ This is just my attempt to explain the current situation. Please contact [1]Andrea Mennucci directly with package questions. The latest version of this FAQ (or a pointer to it) should be at [2]http://people.debian.org/~mjr/mplayer.html Is mplayer in debian? No. Why not? There were problems with copyright and patents (according to [3]this summary of the history). What were the problems and how have they been resolved? 1. code without copyright notices: mplayer team did a licence audit and noted which files have what copyright 2. DeCSS code: removed and mplayer-debian uses [4]libdvdread3 instead 3. libfaad2 code: this is almost identical to libfaad code in xine-lib (from [5]Apr 2005) 4. remaining questionable-licence code in the upstream tarball is removed to make the debian orig tarball by debian/rules (from [6]debian-legal Feb 2005 threads unless marked) What is the current situation? A fresh copy has been uploaded and awaits ftpmaster review in the NEW queue. What is ftpmaster review and how long does it take? See [7]Matthew Garrett's description of ftpmastering. [8]The NEW queue summary suggests it could take up to 3 months. If mplayer is so free, so why is it so darn difficult to have it in Debian??? One theory: mplayer.deb seems to be a tinderbox - Anyone who has prolongued exposure to it gets frustrated by the legal grey areas and its history, so they start flaming innocent bystanders for being wary. This writes new chapters of bad history and dries the tinder more. Users and other developers are wary of mplayer because of this history, so probably treat it differently to other packages, increasing the frustration of the developer and thereby helping to start the flames. Sometimes they try to be kind while being wary, which makes the flames hurt more. (From [9]this list post) How can I help? For now, please wait, unless the packagers ask you for help. Please review the package if you have time, especially looking for problems like those which stopped it before. Please watch [10]debian-devel-announce or [11]debian-devel-changes for developments. Of course, if you're an ftpmaster, please review and act or comment on the package in the NEW queue. Where can I download the current package for review? Direct from the packager at [12]his sarge download area. Where should I send comments and questions about the package? Ask the packager first, or [13]debian-legal for licensing questions if you prefer. Where should I send improvements for this page? [14]Email me with patches to the bare html, please. 20 Apr 2005, [15]MJR References 1. http://tonelli.sns.it/pub/mennucc1/ 2. http://people.debian.org/~mjr/mplayer.html 3. http://lists.debian.org/debian-legal/2005/02/msg00175.html 4. http://packages.debian.org/libdvdread3 5. http://lists.debian.org/debian-legal/2005/04/ 6. http://lists.debian.org/debian-legal/2005/02/ 7. http://lists.debian.org/debian-project/2005/02/msg00184.html 8. http://ftp-master.debian.org/new.html 9. http://lists.debian.org/debian-legal/2005/02/msg00216.html 10. http://lists.debian.org/debian-devel-announce 11. http://lists.debian.org/debian-devel-changes 12. http://tonelli.sns.it/pub/mplayer/sarge 13. http://lists.debian.org/debian-legal/ 14. http://mjr.towers.org.uk/email.html 15. http://people.debian.org/~mjr/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: I begin undestand debian community (comments to FAQ)
On Wed, Apr 20, 2005 at 01:44:04PM +0400, Olleg Samoylov wrote: But. You must undestand and keep in mind. For normal people (not specialized in freedom) things, such as putting gnu-standarts to non-free, always looked very strange (said softly). Keep in mind that normal people can install and use whatever they want. Why should debian try to maintain a document that debian doesn't have permission to maintain? -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question about freeness of XyMTeX license [2nd try]
Kevin B. McCarty wrote: %% Copying of this file is authorized only if either %% %% (1) you make absolutely no changes to your copy, including name and %% directory name %% (2) if you do make changes, %% (a) you name it something other than the names included in the %% ``chemist'' directory and %% (b) you acknowledge the original name. %% This restriction ensures that all standard styles are identical. You should check the discussion of the LaTeX Project Public License in the list archives. Its a fairly long discussion, ultimately leading to a new version of the LPPL. In particular, it is questionable if requiring the file name to be changed is free: While the DFSG does explicitly allow requiring the name of a program to be changed, this is more. In TeX (well, sort of), the file name is part of the API, which the DFSG does not allow you to require to be changed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
