Latest LPPL
After the last round of discussions, the LaTeX Project has asked me to review and present a new revision of the LPPL, which is attached below. It is unlikely that I will be able to participate in the discussion this time around due to time constraints, but the LaTeX people should be around to hear your feedback. The parts of the license that have caused the most friction in the past are now fully contained within clause 6. I doubt that any other part of the license will be seen as objectionable (except, possibly, in their invokation of clause 6). It is my opinion that clause 6 does not violate the Debian Free Software Guidelines. - PREAMBLE The LaTeX Project Public License (LPPL) is the license under which the the LaTeX kernel and the base LaTeX packages are distributed. You may use this license for any work that you have written and wish to distribute. This license may be particularly suitable if your work is TeX-related (such as a LaTeX package), but you may use it with small modifications even if your work is unrelated to TeX. The section `WHETHER AND HOW TO DISTRIBUTE WORKS UNDER THIS LICENSE', below, gives instructions, examples, and recommendations for authors who are considering distributing their works under this license. This license gives conditions under which The Work may be distributed and modified, as well as conditions under which modified versions of The Work may be distributed. We, the LaTeX3 Project, believe that the conditions below give you the freedom to make and distribute modified versions of The Work that conform with whatever technical specifications you wish while maintaining the availability, integrity, and reliability of The Work. If you do not see how to achieve your goal while meeting these conditions, then read the document `cfgguide.tex' and `modguide.tex' in the base LaTeX distribution for suggestions. DEFINITIONS === In this license document the following terms are used: `The Work' Any work being distributed under this License. `Derived Work' Any work that under any applicable law is derived from The Work. `Modification' Any procedure that produces a Derived Work under any applicable law -- for example, the production of a file containing an original file associated with The Work or a significant portion of such a file, either verbatim or with modifications and/or translated into another language. `Modify' Apply any procedure that produces a Derived Work under any applicable law. `Distribution' Making copies of The Work available from one machine to another, in whole or in part. Distribution includes (but is not limited to) making any files associated with The Work accessible by file transfer protocols such as FTP or HTTP or by sharing file systems such as Sun's Network File System (NFS). `Compiled Work' A version of The Work that has been processed into a form where it is directly usable on a computer system. This processing may include using installation facilities provided by The Work, transformations of The Work, copying of files in The Work, or other activities. Note that modification of any installation facilities provided by The Work constitutes modification of The Work. `Current Maintainer' A person or persons nominated as such within The Work's sources. If there is no such explicit nomination then it is the Copyright Holder. `Base Interpreter' A program or process that is normally needed for running or interpreting a part or the whole of The Work. A Base Interpreter may depend on external components but these are not considered part of the Base Interpreter provided that external component clearly identifies itself whenever it is used interactively. Unless explicitly specified when applying the license to The Work the only applicable Base Interpreter is a LaTeX-Format. CONDITIONS ON DISTRIBUTION AND MODIFICATION === 1. Activities other than distribution and/or modification of The Work are not covered by this license; they are outside its scope. In particular, the act of running The Work is not restricted and no requirements are made concerning any offers of support for The Work. 2. You may distribute a complete, unmodified copy of The Work as you received it. Distribution of only part of The Work is considered modification of The Work, and no right to distribute such a Derived Work may be assumed under the terms of this clause. 3. You may distribute a Compiled Work that has been generated from a complete, unmodified copy of The Work as distributed under Clause 2 above, as long as that Compiled Work is distributed in such a way that the recipients may install the Compiled Work on their system exactly as it would have been installed if they generated a Compiled Work directly from The Work. 4. If you
Re: [RFC] Modification history as a source code
On Tue, Jun 17, 2003 at 10:49:46PM +0100, Edmund GRIMLEY EVANS wrote: Dmitry Borodaenko [EMAIL PROTECTED]: even to its creator, 'form preferred for modification' should be chosen from forms remaining in existence. You shouldn't be choosing at all. You should provide everything that is likely to be useful. Where a minimum standard for free software is concerned, this is asking a bit much. The requirements, as I understand them, are that 1) the provided source corresponds directly to the binaries being distributed, and 2) it is the form of source code most suitable for editing (as judged by whether it's the form the creator has actually used for editing). Everything that is likely to be useful imposes an undue burden on the author to provide lots of things that, because they don't meet the above two criteria, are non-essential. There are plenty of things that are likely to be useful in one context or another that we shouldn't require the distribution of. For example, if you automatically converted a Pascal program to C, then made small changes to the C, then you should provide both the Pascal and the C as both are likely to be useful to at least some people who want to make changes. No, you should only provide the C source, because the binaries being distributed are those of the modified C program. Once I've started editing the C program, I've made it unambiguously clear that this is the preferred form for modifications; just because the Pascal source exists doesn't mean I should have to distribute it. On the other hand, if the C has been worked on a lot and nobody has used the Pascal for a few years, then there is probably no need to continue distributing the Pascal. In any case, you have to draw the line somewhere or old versions of the code will pile up like invariant sections in an FDL document ... Exactly. So draw the line where it needs drawing -- don't impose a requirement to distribute files that the programmer isn't in fact using to create the binaries. -- Steve Langasek postmodern programmer pgppIUPksehSQ.pgp Description: PGP signature
Re: Proposed: Debian's Five Freedoms for Free Works
Scripsit Adam Warner [EMAIL PROTECTED] On Tue, 2003-06-17 at 02:54, Henning Makholm wrote: It must be possible for me to enjoy the freedoms without communicating with anybody else but those whom I voluntarily decide to distribute the software to. Why should I have to communicate with anyone, even in a situation of copyleft code distribution? Well, distribution is a form of communication. It would be too much to require that I should be able to distribute software to someone without sending them data (i.e. communication). And how does your proposal proscribe the limits of information disclosure when one does voluntarily decide to distribute the software? It says that the only party I can be required to disclose anything (such as the source) to is the one to whom I distribute. So communication isn't the root issue. The root issue is the extent of one's information disclosure obligation (at the point of distribution). No. If that were the root issue, we wouldn't have problems with you must send patches upstream licenses - they do not require me to disclose anything to upstream that I don't have to disclose to the recipient I choose. On the contrary the root issue is exactly that such a license tries to dictate *whom* I must disclose this information to. -- Henning Makholm I didn't even know you *could* kill chocolate ice-cream!
Re: [RFC] Modification history as a source code
Steve Langasek [EMAIL PROTECTED] writes: No, you should only provide the C source, because the binaries being distributed are those of the modified C program. Once I've started editing the C program, I've made it unambiguously clear that this is the preferred form for modifications; just because the Pascal source exists doesn't mean I should have to distribute it. So if I take a compiled C program -- say, something I got from Debian but for which I do not have the source -- and run 'strip' on it, is it the case that the unstripped binary is the source, and the stripped binary the object? The compiled binary is clearly the only possible form for the modification I've just performed. -Brian -- Brian T. Sniffen[EMAIL PROTECTED] http://www.evenmere.org/~bts/
Re: [RFC] Modification history as a source code
On Wed, Jun 18, 2003 at 11:25:42AM -0400, Brian T. Sniffen wrote: Steve Langasek [EMAIL PROTECTED] writes: No, you should only provide the C source, because the binaries being distributed are those of the modified C program. Once I've started editing the C program, I've made it unambiguously clear that this is the preferred form for modifications; just because the Pascal source exists doesn't mean I should have to distribute it. So if I take a compiled C program -- say, something I got from Debian but for which I do not have the source -- and run 'strip' on it, is it the case that the unstripped binary is the source, and the stripped binary the object? Two things: * The preferred form for modification must include the past modifications that went into the source for the work in question: at best, this means that the stripped binary would be both the source and the binary in this case. There is plenty of precedence among interpreted languages for these being one and the same; however, * my sloppy wording notwithstanding, being the preferred form for modification also means it's suitable as input for the process of *further* modification. Are there other modifications you would perform on a stripped binary? Would you perform *arbitrary* modifications on a stripped binary? The compiled binary is clearly the only possible form for the modification I've just performed. It's the only possible form in your possession; if you had source, such a modification could be completed as part of the build process (which is lossy in general) by adding a 'strip' command to the makefile. So just because you don't have source code available doesn't make it free. -- Steve Langasek postmodern programmer pgpKdxazAhkIP.pgp Description: PGP signature
Re: [RFC] Modification history as a source code
On Tuesday, Jun 17, 2003, at 07:03 US/Eastern, Dmitry Borodaenko wrote: The issue of storage is more controversial, all I can give is my personal opinion that it is fair to expect that creators keep track of at least their own work, I don't think its reasonable to expect me to keep track of every single change I've ever made; to store that indefinitely; etc. In order for this scheme to work, authors of works would have to keep copies of their work, in the same network-accessible location, for eternity[0]. That, especially for large works, is a significant expense. I don't think a free license can require much more than if you distribute this, give source under the same terms. It certainly can't require me to spend an indefinite amount of money keeping stuff around years after I'm dead. (Just imagine that every time you patched XFree, you had to keep the entire XFree tree around. Ouch.) [0] OK, for the duration of the copyright, which is currently what, life+75 years, with Congress routinely increasing it?
Re: How to license a php modules?
W liście z wto, 17-06-2003, godz. 02:09, Artur R. Czechowski pisze: Hi! As apparently nobody replied to this (at least - not to me) I'd try to say how *I* understood the situation and what would I propose. III. Questions. 1. Are those licenses not conflicting with each other? I think no. You have some pieces of auto* tools under GPL. Many projects use them. You and they - don't link to this GPL code, just *USE* these tools. People usually don't even mention GPL in ./debian/copyright because of these pieces. Second thing - the PHP-license. FWICS there's no PHP license under /usr/share/common-licenses - so you should put PHP license in ./debian/copyright and say more-less which files are covered by this license. Thrid thing - the main software which is under BSD license - just give a link to /usr/share/common-licenses/BSD in ./debian/copyright and be done with it. I am not aware of any possible conflict between PHP and BSD licenses (but I *might* be wrong - IANAL) so that's OK. 2. What should I put into debian/copyright? Upstream license only? All mentioned licenses? If you wanto to be 110% correct do this in ./debina/copyright 1. Mention BSD license as the main license for this software 2. Copy PHP license and say which pieces are covered by it 3. Mention GPL license and that auto* pieces are covered by it By mention I mean giving a link to /usr/share/common-licenses/$LIC no. 3. is optional or even unneeded IMO (given current practise) Don't forget to mention authors of 1. and 2. pieces. 3. What should upstream put as a license for a software in tarball? If it hasn't done already - a copy of /usr/share/common-licenses/BSD. HTH Grzegorz B. Prokopski -- Grzegorz B. Prokopski [EMAIL PROTECTED] Debian http://www.debian.org/ signature.asc Description: To jest część listu podpisana cyfrowo
Re: Latest LPPL
Jeff Licquia [EMAIL PROTECTED] writes: After the last round of discussions, the LaTeX Project has asked me to review and present a new revision of the LPPL, which is attached below. It is unlikely that I will be able to participate in the discussion this time around due to time constraints, but the LaTeX people should be around to hear your feedback. The parts of the license that have caused the most friction in the past are now fully contained within clause 6. I doubt that any other part of the license will be seen as objectionable (except, possibly, in their invokation of clause 6). It is my opinion that clause 6 does not violate the Debian Free Software Guidelines. It is my opinion, on first read-through, that this version would satisfy the DFSG. I hope others will agree. Many many thanks Jeff for your persistence in getting this issue settled! Thomas
Re: Defining 'preferred form for making modifications'
Mark Rafn [EMAIL PROTECTED] writes: There are a number of icons and images in products whose original creator preferred to edit in photoshop, with crazy psd files that contain layering, gamma, and other useful information. I made further modifications to the resulting GIF file. My preferred form is gif, hers is psd. I don't even have the psd anymore. On Wed, 18 Jun 2003, Thomas Bushnell, BSG wrote: The .psd is the source. Some people prefer to hack on binary code too, but this is really the same case as that one, except that more people hack .gif than binary code. So I cannot release the GIF freely, given that the PSD no longer exists? But the fact that there are people who prefer to hack binary code (indeed, the fact that it's sometimes useful and valuable) doesn't at all mean that the binary code is therefore source in the context of the copyleft. Can my gif file ever be free? Can her psd file be free if it's in an undocumented format which is only editable in a proprietary tool? Once again, I'm only talking about GPL concerns. It's clear to me that she cannot add the gif to a GPL'd program and refuse to distribute the .psd file. Interesting. I suspect we have some things currently in debian that violate the GPL if this is the common consensus. Additionally, consider that the work was for hire, so I'm the copyright holder, and I didn't keep the psd. Is this gif file forever proprietary because I cannot provide source? Otherwise, consider the disaster: Someone creates a programmatic font, making use of GPL'd code. But they want to keep their program seekrit. So they compile font images, and then tweak a few bits on the bitmaps, claiming now that the bitmaps are the preferred form for modifications, and then refuse to distribute the program. This cannot be permitted! Is intent the deciding factor here? Intentional obfuscation is evil and should be disallowed. Loss of information due to actual edits IMO should be allowed. So we must judge the bitmaps alone to *not* meet the source code requirement (whether or not they have in fact been modified from what the source first produced), and this must be true not just for the person who did the tweaking, but for everyone who got the bitmaps from them. In the case of actual edits, though (I take bitmaps produced algorithmically and make significant bitmap updates), this leads to the strange requirement to provide some bizarre source files that don't produce anything near what you're distributing. -- Mark Rafn[EMAIL PROTECTED]http://www.dagon.net/
Re: Latest LPPL
On Wed, Jun 18, 2003 at 01:24:09AM -0500, Jeff Licquia wrote: After the last round of discussions, the LaTeX Project has asked me to review and present a new revision of the LPPL, which is attached below. It is unlikely that I will be able to participate in the discussion this time around due to time constraints, but the LaTeX people should be around to hear your feedback. The parts of the license that have caused the most friction in the past are now fully contained within clause 6. I doubt that any other part of the license will be seen as objectionable (except, possibly, in their invokation of clause 6). It is my opinion that clause 6 does not violate the Debian Free Software Guidelines. At first glance this looks really good, and probably satisfies the DFSG. While reading over it I noticed some places where the wording could be tweaked or tightened up (I even found a possible loophole the LaTeX folks might want to close), but I'll defer that for a much closer reading. Thanks a lot; I greatly appreciate your patience and that of Frank Mittelbach and numerous others in the LaTeX Project. -- G. Branden Robinson| The noble soul has reverence for Debian GNU/Linux | itself. [EMAIL PROTECTED] | -- Friedrich Nietzsche http://people.debian.org/~branden/ | pgpOD5rQ8qZ2o.pgp Description: PGP signature
