Re: SURVEY: Is the GNU FDL a DFSG-free license?
On Aug 21, Branden Robinson wrote: === CUT HERE === Part 1. DFSG-freeness of the GNU Free Documentation License 1.2 Please mark with an X the item that most closely approximates your opinion. Mark only one. [ ] The GNU Free Documentation License, version 1.2, as published by the Free Software Foundation, is not a license compatible with the Debian Free Software Guidelines. Works under this license would require significant additional permission statements from the copyright holder(s) for a work under this license to be considered Free Software and thus eligible for inclusion in the Debian OS. [ ] The GNU Free Documentation License, version 1.2, as published by the Free Software Foundation, is a license compatible with the Debian Free Software Guidelines. In general, works under this license would require no additional permission statements from the copyright holder(s) for a work under this license to be considered Free Software and thus eligible for inclusion in the Debian OS. [ X ] The GNU Free Documentation License, version 1.2, as published by the Free Software Foundation, can be a license compatible with the Debian Free Software Guidelines, but only if certain restrictions stated in the license are not exercised by the copyright holder with respect to a given work. Works under this license will have to be scrutinized on a case-by-case basis for us to determine whether the work can be be considered Free Software and thus eligible for inclusion in the Debian OS. [ ] None of the above statements approximates my opinion. Part 2. Status of Respondent Please mark with an X the following item only if it is true. [ X ] I am a Debian Developer as described in the Debian Constitution as of the date on this survey. === CUT HERE === Chris -- Chris Lawrence [EMAIL PROTECTED] - http://blog.lordsutch.com/ pgpxGZT8UL2oQ.pgp Description: PGP signature
Re: Linux kernel complete licence check, Q.15
On Nov 24, J.B. Nicholson-Owens wrote: Giacomo Catenazzi wrote: * All the material in this file is subject to the Gnu license version 2. I think this is ambiguous. Both the GNU GPL or the GNU LGPL have a version 2 revision; the currently in-use and well-known GNU GPL and an older release of the GNU LGPL as the FSF tells us: In the context of the Linux kernel, the GPL/LGPL issue is not important, as the LGPL-GPL conversion clause means both can be treated as the GPL. Of course, with the FDL on the way, that adds some ambiguity; it's best to get a clarification from the original author(s) or copyright holder(s), if possible. Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ Computer Systems Manager, Physics and Astronomy, Univ. of Mississippi 125B Lewis Hall - 662-915-5765
Re: Knuth statement on renaming cm files and Licence violation.
On Sep 04, Russ Allbery wrote: I don't find your argument particularly persuasive; it seems to be very strong on emotion without a lot of logic to back it up, or without any real discussion of what you're trying to defend and why. The Debian Project has a philosophical commitment to protecting the freedoms of the users of software that it calls free. These freedoms are spelled out in the Debian Social Contract and Debian Free Software Guidelines. You can argue whether the freedom to rename some particular file is important or not, but that's largely beside the point as far as Debian is concerned; it is possible for reasonable people to disagree about the relative importance of that (or any other) freedom. However, we believe that irrespective of whether we intend to exercise the particular rights in question, possessing them (and, more importantly, ensuring our users possess them) is important. For example, the DFSG has a paragraph about non-discrimination. Debian has no intention of setting up a nuclear power plant, but a license that restricts people who own nuclear power plants from using our software [licenses like this do, in fact, exist] is unacceptable. Similarly, Debian has no intention of violating Prof. Knuth's request that the Computer Modern fonts not be replaced without renaming them, yet we are unwilling to call them free unless our end users have the freedom to do so. (Leave aside whether Prof. Knuth's request is legally binding; his statement that the fonts are in the public domain suggests that no request of his regarding the fonts is legally binding, although his wishes should not be lightly disregarded.) Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ Computer Systems Manager, Physics and Astronomy, Univ. of Mississippi 125B Lewis Hall - 662-915-5765
Re: GPL-script to be run on a non-free interpreter
On Aug 04, Ralf Treinen wrote: Is it OK to distribute a script, which is - licencend under GPL. - intended to be executed by a non-free interpreter. [..] When I sent my ITP on debian-devel today, Moshe Zadka claimed that even distributing maria-viz would be illegal. http://lists.debian.org/debian-devel/2002/debian-devel-200208/msg00188.html Can please someone advise whether this is really the case? I do not believe the Free Software Foundation interprets the GPL in this manner. After all, some GNU software includes code that is only intended to work with non-free compilers and make implementations. I believe there is GPL'ed software in contrib that requires certain (non-free) Java class libraries as well. The issue in the case of this program is perhaps even more narrowly cast, since there is a free alternative to (at least some of) graphviz (http://www.chaosreigns.com/code/springgraph/), and it is entirely possible to develop a free alternative for the particular interpreter in question. Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ Instructor and Ph.D. Candidate, Political Science, Univ. of Mississippi 208 Deupree Hall - 662-915-5765 pgpLeAT7n8agw.pgp Description: PGP signature
Re: Towards a new LPPL draft
On Jul 22, Boris Veytsman wrote: The question is, who should say yes and no? Sorry for being ignorant about the rules -- but is there a mechanism of voting or other decision taking of the list? How it is formally initiated? The only formal procedures available are: - Action by the Debian project leader. - Action by the technical committee - if this issue is deemed technical as opposed to non-technical. My guess is they would deem it non-technical and pass the buck. - Action by the developers as a whole through the General Resolution procedure. Additional de facto procedures: - Acceptance of or failure to accept an upload of a new package with the given licen[cs]e by the Debian ftp administration team. (Doesn't help in this case anyway, since you're still drafting.) - Consensus on the debian-legal list. In practice, the de facto procedures are always followed. Chris [no cc needed] -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ Instructor and Ph.D. Candidate, Political Science, Univ. of Mississippi 208 Deupree Hall - 662-915-5765 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: forwarded message from Jeff Licquia
On Jul 19, Boris Veytsman wrote:
The problem is, the first paragraph quoted above is not true. There
are precedents when people changed important parts of TeX and LaTeX
and distributed these changed files without clearly labeling them as
such. AFAIK, there were only good intentions on the part of the
perpetrators, but the damage was real. LPPL was crafted to prevent
these things to happen again.
How does the LPPL actually prevent a distributor from FUBARing their
distribution of LaTeX? The fact is people regularly ignore licenses,
copyrights, patents and trademarks (if this weren't the case, there'd
be almost no GIFs or MP3s in the world).
To put it another way: If you don't trust people to do the right
thing, no license will help you.
So, you are defending abstract principles against a very unlikely
danger. LaTeX people see a real danger in changing their way. What is
a pure abstraction for you (most of the people on debian-legal
probably never used LaTeX in their everyday work) is an important
issue for them -- and for us, end users.
I *do* use LaTeX in my every day work. I also recognize that someone
might want to make a derived work of LaTeX (say MyLaTeX) without
having to engage in unreasonable amounts of bookkeeping or bizarre
filename hacks (i.e. without recoding the parser to add my to the
beginning of every package that is \usepackage{}d since they had to
rename every single file in the distribution that they touched) and
without breaking compatibility with their own source files (i.e. so
they can run mylatex blah.tex where blah.tex is valid input to latex).
In fact, pdflatex depends on this very ability, but since the LPPL
only trusts the anointed of the LaTeX3 Project to do this in a trivial
manner, I couldn't make a tifflatex or pcllatex without going through
silly bureaucracy (renaming files, hacking macros to search for my
modified versions of .cls and .sty files with messed up names, etc.)
that Frank doesn't have to engage in.
Having said that, I'd be pissed if typing latex myfile.tex was
arbitrarily different from system to system. But again, if you
require modified versions of LaTeX to not be called LaTeX and not be
invoked by typing latex, this surprise problem goes away. So,
again, the IMHO reasonable thing to say is:
1. latex should always refer to unmodified LaTeX as distributed by LaTeX3
2. If you modify any part of LaTeX, you must either:
a. call the entire derived work something other than LaTeX, and
invoke it with something other than latex, or
b. distribute modified files within LaTeX under different names, and
include unmodified versions of those files.
Note the word or there. If the derived work is bobslatex or
rubberfetish or whatever you want to call it, 2(b) goes away because
the derived work no longer calls itself LaTeX and is not expected to
behave like standard LaTeX. However, if you represent your derived
work as being standard LaTeX (by calling it LaTeX), the behavior
should be consistent with standard LaTeX for all macro packages
defined in standard LaTeX.
Chris
--
Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/
Instructor and Ph.D. Candidate, Political Science, Univ. of Mississippi
208 Deupree Hall - 662-915-5765
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Distributing GPL Software as binary ISO
On Jul 18, Martin Schulze wrote: The current status quo: a) Company A collects .deb files from Debian and builds an ISO file that runs the system (life system). This ISO only contains binary packages, no source. This CD is sold and distributed freely through the internet. When asked about the source of the binary CD, company A points to ftp.debian.org. b) An entity B (could be a company, or a single person, or a project) lects .deb files from Debian and builds an ISO file that runs the system (life system). This ISO only contains binary packages, no source. This ISO image is distributed freely through the internet and is sold on CD at an exhibition. When asked about the source of the binary CD, B points to ftp.debian.org. Questions: 1. Is either a) or b) in complience with the GPL (assuming all software is licensed using the GNU GPL. 2. Is a) or b) in complience with the DFSG aka OSD? 3. Is it a problem if ftp.debian.org removes the source of the same version of a package that is used on the cd and installs a newer version? (i.e. source of a package is available, but not exactly the proper source). 4. What would be the proper way to solve this problem if a) or b) are not in complience with the license terms? In case (4), it would be up to the individual copyright holders of the packages contained on the CDs. My general thought on 1-3 is that they could be construed as violations of the license if someone were to push the issue. If that were the case, the following policies would probably have to be adopted by anyone offering CDs of Debian (including myself): 1. Refuse to sell binaries without source. This makes Debian 100% more expensive to produce, and possibly means that distributors will only distribute a subset of Debian to reduce the logistical nightmare of producing 12 CD-Rs, but the buyer is the one that bears the brunt of that problem. (i.e. if Bob wants Debian, he has to have the source for everything, and I won't sell him anything without that source included. Bob Newbie is now paying for 6 to-him coasters in addition to 6 binary CDs.) 2. Refuse to offer any ISO images on the Internet. (That means ssh relativity.phy.olemiss.edu rm -rf /var/www/debian-cd, in English) This insulates the distributor from liability under the I got binary from you 2 years and 364 days ago, so I demand the source clause of the GPL, because there's no way the purchaser could get binaries without source. It also makes Debian a royal pain in the ass to distribute at low cost, but that's the legalities of it. (However, this is only actionable if a buyer attempts to exercise his rights under the GPL - unless and until that happens, the distributor is not violating the license. He only violates the license if and only if he fails to meet the buyer's demand for the equivalent source at a reasonable price. Furthermore, this has never been tested in court so it is unclear whether providing a later version of the source would be sufficient, or what a reasonable price might be. For example, if A distributes Debian without source, and nobody complains that they didn't get source, A is not violating the GPL per se.) In other words: you have opened a massive can of worms. :-) Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: User's thoughts about LPPL
On Jul 16, Boris Veytsman wrote: To summarize: I think LPPL strikes a necessary balance between standardization and flexibility. This balance was tested by 20+ years of TeX, which is licensed under exactly same conditions. I don't think anyone here has a problem with a license that says If your LaTeX doesn't pass such and such a validation suite, you can't call it LaTeX, but you can do whatever else you want to do with it. I think the real issue is that the LaTeX project is trying to use its license to enforce a norm of good behavior by distributors that would be much better left to certification marks or a Knuthian statement that if you break it, both pieces are yours and you are the one who will get bitched at, not us. I think that's being obfuscated behind Branden's establishment of hypotheticals that can be dealt with through \renewcommand and the like. I think Frank et al's concerns could be addressed fairly easily by requiring distributors of modified versions of the entire LaTeX suite to document the changes and include the location of that documentation in the diagnostic output of latex, and requiring distributors of modified versions of separately-distributed style/class files to do the same, with a waiver of the documentation requirement if the file/suite is renamed (thereby not misrepresenting the modified version as any longer being a substitute for the original). This certainly would pass the DFSG and would clearly inform users of what sort of LaTeX they're getting. For example, if I modify article.dtx, I must either rename it (thereby no longer calling it article.dtx) or include diagnostic output showing where on the local filesystem a file is that clearly documents the differences between article.dtx as distributed by the LaTeX3 project and my article.dtx (for example, corrected typo in line 300 that stopped articles with fewer than 83 pages from having more than 17 footnotes.) Then again, maybe I'm missing the point :-) Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ pgphu9zxJdYdC.pgp Description: PGP signature
Endorsements (was Re: GPL compatibility of DFCL)
Wouldn't the endorsements issue be best resolved by licensing the endorsements separately from the rest of the document? i.e. the core content could be under the DFCL (unambiguously free GPL compatible) while endorsements, odes to pets, etc. would be under a separate license of the original author's choosing. The only other thing I can think of is some sort of author severability clause (kind of like the use of Alan Smithee by film directors): a provision that states any modification to sections A, B, or C of the text requires the removal of the original author's name from the text and/or a clear statement that the text is a modified version of the author's work. IMHO that wouldn't run afoul of the DFSG, as it is similar in spirit to DFSG clause 4. (Admittedly, some people dislike the patch files section of Clause 4, but this wouldn't be a patch files situation - it's analogous to the rename or re-version portion.) That way if someone edits the GNU Manifesto to add RMS likes goats halfway through, RMS can say you can't call that the GNU manifesto any more, even though I do, in fact, like goats, and while you're at it take my damn name off! (*). Don't mind me, I'm not really awake :-) Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: teTeX Documentation Licenses
On Mar 10, C.M. Connelly wrote: There are about 30 documents (and the stuff they document) whose licensing status is less clear, and those are the ones that I have some questions on. I have included some example copyright/distribution statements based on those in this ``unknown'' category, and I would appreciate a quick take from debian-legal habitues on whether they are DFSG-free, and, in particular, whether we can continue to distribute files with copyright/distribution statements similar to the examples. To the best of my knowledge, none of the attached licenses are DFSG-free, with the possible exception of the guy who goes on about GNU-style stuff (who needs to properly license the file). The one that's written in French I can't be certain of, but I suspect it's not DFSG-free either. Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/
Re: Legal status of using a GPL'd LD_PRELOADed with a non-GPL'd app ...
On Mar 07, Timshel Knoll wrote: I've posted an ITP[1] for libtrash, a library that uses LD_PRELOAD to intercept application calls to unlink(), rename(), open(), fopen(), freopen() and other system calls which may delete/truncate files, and moves them to a trash can rather than deleting them. My question is this: libtrash is licensed under the GPL, and the LD_PRELOAD is likely to allow non-GPL'd (including non-free) binary code to use it. The binary code is not actually linked with libtrash, however. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=137108repeatmerged=yes Branden Robinson seems to think that the distribution of this is OK, but suggested that I bring this discussion to the -legal forum. Any ideas on this? The GPL really only applies when you are distributing a GPL'd work linked to a non-GPL'd work. Using LD_PRELOAD is not distribution, so I can't see how this would pose a problem. The only exception I can think of is if someone distributed a script like (lame example): #!/bin/sh LD_PRELOAD=/your/hack/here /usr/bin/nonfree-application That case might be problematic from a legal standpoint, and might be worth mentioning in README.Debian. Even there, the legal issue is somewhat ambiguous, though I think the FSF's position would be that this is infringement (it certainly violates the spirit of the GPL). But the script is incredibly trivial, so it's hard to argue that even it is infringement (especially since an end-user doing this independently wouldn't be infringement, and you could tell an end-user how to do this in documentation). Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/
Re: Latex Project Public License
On Feb 19, Alexei Kaminski wrote: I am the current maintainer for the package revtex, which is a collection of LaTeX style files to be used in manuscripts submitted for publication in the journals published by the American Physical Society. The license of the upstream version 3.1, which makes the current revtex package, prohibits taking money for the distribution or use of the files except for a nominal charge for copying, etc. It makes the upstream version 3.1 inelegible for debian/main. Recently, version 4 of the upstream product has been released, under the Latex Project Public License (http://www.latex-project.org/lppl.html). My question for debian-legal is: Does the Latex Project Public License satisfy the Debian Free Software Guidelines? My understanding is that in general it does not, due to the clause You may not modify in any way a file of The Program that bears a legal notice forbidding modification of that file, but revtex's upstream version 4 can still be considered as free since none of its files bears such a notice. I believe that interpretation is correct; in the same vein, other licenses (the OPL, for example) have optional clauses that, when not invoked, pass the DFSG. Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ Computer Systems Manager, Physics and Astronomy, Univ. of Mississippi 125B Lewis Hall - 662-915-5765
Re: PROPOSED: interpretive guidelines regarding DFSG 3, modifiability, and invariant text
I'm wading into dangerous waters here, methinks... :) I think Branden's proposal is well-intentioned, but ultimately the wrong approach to dealing with this problem. I think the standard that should be applied is not about kilobytes or percentages, but whether or not the licensing restrictions on ancillary materials harm the ability to make derivative works. For example, in the case of GNU Emacs, we have the misc directory full of all sorts of philosophical ramblings on various topics. None of them have anything to do with Emacs; we could completely rewrite Emacs without anything there being affected. So their non-freeness doesn't seem to harm anything. On the other hand, if the GNU Emacs manual had a non-free license on the parts dealing with the operation of the program, then we might have a problem. At least in the case of documentation and other ancillary materials regarding software, the line seems pretty clear-cut: if the materials document something that could change as a result of changing the program, they should be free; otherwise, who cares? I realize the case of 3 pages of documentation with 100 pages of lame novella isn't covered here; in that case, I would expect the maintainer's judgement (is the 100 pages of lame novella worth 3 pages of worthwhile text... my gut feeling says no) to take over. If it isn't associated with software at all, ancillary materials probably don't have a place in Debian. For example, the text of Martin Luther King Jr's Letter from a Birmingham Jail (copyrighted, non-DFSG-free) has no place in Debian, even though it is an incredibly eloquent piece of writing, because it has nothing to do with computer software. I don't know about the edge case of standards documentation, etc (doc-html-w3, for example) that I'm sure most of us would agree isn't in the same category as the acknowledgements in the GNU manuals. There's a case to be made for exceptions for things that are standards (I certainly wouldn't want people promulgating a modified version of the National Electrical Code, for example), but I think my proposed criteria wouldn't address that case, leaving it verboten as before. I realize this leaves the door open for the inclusion of great volumes of perjorative or simply annoying ancillary documentation in Debian; today Linux-and-GNU, tomorrow Geeks-with-Guns, next week my great collection of poetry I wrote in secondary school. On the other hand I can't see a fair way to include all of GNU Emacs, including the (IMHO) crap in misc, without opening the door to rafts of other crap anyway without a if RMS wrote it, it's OK exception that smacks of hypocrisy. And since I don't see either RMS removing that material or us excising it from our package of emacs over his objections, the only way forward is some sort of *gasp* exercise of reasonable judgment by maintainers. Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ pgpPKzWwaqHwv.pgp Description: PGP signature
Re: OpenOffice and Java
On Oct 21, David Starner wrote: On Sun, Oct 21, 2001 at 02:58:22PM +0400, Peter Novodvorsky wrote: With current jdk license it cannot be put in non-free, right? In this case, openoffice cannot be put in main nor in contrib nor in non-free. It can be placed in contrib. free packages which require ... packages which are not in our archive at all for compilation or execution (interesting that it can't require a package in non-us, but it can require one not in the archive.) FWIW, OpenOffice will install and run without Java on the system, at least if you use the binaries at openoffice.org. There's no reason why we can't have a separate openoffice-java in contrib for people that want the Java support. Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ Instructor and Doctoral Student, Political Science, Univ. of Mississippi 208 Deupree Hall - 662-915-5765
Re: DFSG status of DFARS clause?
On Oct 14, Aaron M. Ucko wrote: [Please Cc: me on replies.] For the record, does All Rights Reserved. RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the government is subject to restrictions as set forth in subparagraph (c) (1) (ii) of the Rights in Technical Data and Computer Software Clause at DFARS 252.227-7013 (Oct. 1988) and FAR 52.227-19(c) (June 1987). in a license violate the DFSG? DFARS: http://www.acq.osd.mil/dp/dars/dfars/html/r20011001/252227.htm#252.227-7013 In the current DFARS, this appears to be subparagraph (b). Frankly the whole thing looks like a confusing mess but it appears to obligate the federal government to respect copyright law except in cases where software was developed exclusively with government funds. I recommend finding a lawyer. I really don't see anything in DFARS that would restrict the ability of the U.S. government to use any DFSG-free software, though it's possible DFARS may give them additional rights not granted by license (in which case you could argue that the restricted rights legend actually discriminates against non-government users) in certain cases, particularly if the entire project was government financed. I could only see this as a problem with something that was GPLed or otherwise copylefted (ex: GPLed software that is financed by the govt could be modified by the govt and combined with non-GPL-compatible software); a BSD-style license (which I think Tcl/Tk is under) doesn't restrict derived works anyway. If anything, it seems like a separate license for the government, which may or may not be the same thing as a discriminatory license... though we generally don't argue that dual-licensed software is non-free unless all of the licenses aren't DFSG-free and/or the range of all possible software users isn't covered by a DFSG-free license; e.g. GNU Ghostscript 6.51 is GPLed, but it was also licensed under the AFPL [as Aladdin Ghostscript 6.50] before being freed, and Aladdin licenses copies of Aladdin Ghostscript under other non-free licenses, yet GNU Ghostscript is DFSG-free. (I guess the question is: if I license software under a BSD-like license, but say in the license that people who use it to build nuclear power plants, have bad breath, or hang out with Osama bin Laden have to abide by the terms of the GPL with regards to the software, would that be non-free, even though both groups are covered by DFSG-free licenses?) Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/
Re: Bug#82116: README.why-python2 does not accurately describe licensing issues
On Jan 13, Gregor Hoffleit wrote: thanks for the feedback! You're welcome :) On Sat, Jan 13, 2001 at 12:34:13PM -0600, Chris Lawrence wrote: I would add at least a pointer to the Python community's response to this issue, Which was like what ? Can _you_ give _me_ a pointer to that response ? The only kind of response I noticed was much /.-like noise a la 'RMS is a moron, let's ignore him.', technical discussions on whether that clause would also apply in Germany, or just silence. I really don't know what the Python community thinks about this issue. I think the community doesn't know either ;-/. What I do know is that people at Digital Creations are aware of the fact that there are mixed emotions about that license, and that Guido himself is very much aware of that, too. I can't find any coherent community response either; I see lots of lawyers yelling past one another, but the community doesn't care. It sounds like you think that that license is compatible with the GPL. Would you agree with my conclusion that we should follow the wish of the FSF and not mix their GPL code with Python 2 code ? I'm really open to other opinions here, since I'm no lawyer. I really don't know what to think. I think you can plausibly argue that the GPL is intended to be interpreted under the laws of the state of Massachussetts. The question is whether specifying how to interpret the terms of another license affects how the GPL would be interpreted, no? And more importantly, does it make any difference? i.e. if I have GPLed code imported by a Py2L'ed program, and there is some licensing dispute, does the fact the Py2L'ed program's licenses will be interpreted under California and/or Virginia law make the GPL have to be interpreted under those laws too? My common sense says no, but common sense != the law. I don't know what all of this means. Erring on the side of caution, we probably should not link Python2 stuff against GPLed stuff, not because the FSF says it's bad voodoo, but because the licensing issues are unclear. My only concern is that we (as a project) probably should rely on our own legal counsel in making a final decision, rather than accepting one side's lawyers' viewpoints on faith. To be fair, the KDE licensing issue was (surprisingly) much more clear-cut. I really don't know if this jurisdiction thing passes the laugh test... Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ Computer Systems Manager (Physics Astronomy, 125 Lewis, 662-915-5765) Instructor, POL 101 (Political Science, 208 Deupree, 662-915-5949)
Clarified Artistic License
) rename any non-standard executables so the names do not conflict
with standard executables, which must also be provided, and provide
a separate manual page for each non-standard executable that clearly
documents how it differs from the Standard Version.
d) make other distribution arrangements with the Copyright Holder.
{+e) permit and encourge anyone who receives a copy of the modified Package
permission to make your modifications Freely Available
in some specific way.+}
4. You may distribute the programs of this Package in object code or
executable form, provided that you do at least ONE of the following:
a) distribute a Standard Version of the executables and library files,
together with instructions (in the manual page or equivalent) on where
to get the Standard Version.
b) accompany the distribution with the machine-readable source of
the Package with your modifications.
c) give non-standard executables non-standard names, and clearly
document the differences in manual pages (or equivalent), together
with instructions on where to get the Standard Version.
d) make other distribution arrangements with the Copyright Holder.
{+e) offer the machine-readable source of the Package, with your
modifications, by mail order.+}
5. You may charge a [-reasonable copying-] {+distribution+} fee for any
distribution of this Package. [-You-]
{+If you offer support for this Package, you+} may charge any fee you choose
for [-support of this
Package.-] {+that support.+} You may not charge a {+license+} fee for {+the
right to use+}
this Package itself. [-However,
you-] {+You+} may distribute this Package in aggregate with
other (possibly
[-commercial)-] {+commercial and possibly nonfree)+} programs as part of a
larger (possibly [-commercial)-] {+commercial and possibly nonfree)+} software
[-distribution-] {+distribution,
and charge license fees for other parts of that software distribution,+}
provided that you do not advertise this Package as a product of your own.
{+If the Package includes an interpreter,+} You may embed this Package's
interpreter within an executable of yours (by linking); this shall be
construed as a mere form of aggregation, provided that the complete
Standard Version of the interpreter is so embedded.
6. The scripts and library files supplied as input to or produced as
output from the programs of this Package do not automatically fall
under the copyright of this Package, but belong to whoever generated
them, and may be sold commercially, and may be aggregated with this
Package. If such scripts or library files are aggregated with this
Package via the so-called undump or unexec methods of producing a
binary executable image, then distribution of such an image shall
neither be construed as a distribution of this Package nor shall it
fall under the restrictions of Paragraphs 3 and 4, provided that you do
not represent such an executable image as a Standard Version of this
Package.
7. C subroutines (or comparably compiled subroutines in other
languages) supplied by you and linked into this Package in order to
emulate subroutines and variables of the language defined by this
Package shall not be considered part of this Package, but are the
equivalent of input as in Paragraph 6, provided these subroutines do
not change the language in any way that would cause it to fail the
regression tests for the language.
8. Aggregation of [-this-] {+the Standard Version of the+} Package with a
commercial
distribution is always permitted provided that the use of this Package
is embedded; that is, when no overt attempt is made to make this Package's
interfaces visible to the end user of the commercial distribution.
Such use shall not be construed as a distribution of this Package.
9. The name of the Copyright Holder may not be used to endorse or promote
products derived from this software without specific prior written permission.
10. THIS PACKAGE IS PROVIDED AS IS AND WITHOUT ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
The End
---
Chris
--
Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/
Computer Systems Manager (Physics Astronomy, 125 Lewis, 662-915-5765)
Instructor, POL 101 (Political Science, 208 Deupree, 662-915-5949)
Re: Clarified Artistic License
On Dec 09, Joseph Carter wrote: On Sat, Dec 09, 2000 at 01:00:10PM -0600, Chris Lawrence wrote: ncftp 3.0.2 comes under something called the Clarified Artistic License. It looks DFSG-free, but I'm not certain. Here's the text: [..] I wish people would adopt thie clarified license.. Based on the wdiff, it's a vast improvement. Nothing changed seems non-free, but I didn't give it a good reading to compare it with the GPL if someone else would like to do that. (ncftp can use readline can it not?) The 3.0 series doesn't natively, but there is a patch that allows it. The old Artistic license wasn't GPL-compatible, so I had to disable that patch; I don't know at first glance whether this clarified version is or not. Frankly, the upstream author doesn't seem to understand all of the licensing issues and thus he could easily GPL the 3.0 series as he as done the 2.0 series, but I think he won't be all that educable on that point after the grief he got on the 2.0 series and readline. Chris -- Chris Lawrence [EMAIL PROTECTED] - http://www.lordsutch.com/chris/ Computer Systems Manager (Physics Astronomy, 125 Lewis, 662-915-5765) Instructor, POL 101 (Political Science, 208 Deupree, 662-915-5949)
Re: QT Designer _NOT_ under QPL.
On Aug 11, Peter S Galbraith wrote: This was on the kde-licensing mailing list two days ago. Just FYI. [snip] Well, I guess we know where Troll came up with their name... Chris, who wonders if we ignore Troll maybe they will just go away... ;-)
Re: Bug#68652 acknowledged by developer (dosemu has clickwrap license)
On Aug 06, Brian Ristuccia wrote: If the clickwrap license doesn't go away, dosemu should move to non-free. [...] Show me where the DFSG prohibits software from using clickwrap licenses. (Incidentally, *our boot floppies* display the license and require confirmation to continue... they don't specifically ask that you accept the license, but that's a moot point.) Chris -- = | Chris Lawrence | Your source for almost nothing of value: | | [EMAIL PROTECTED] | http://www.lordsutch.com/ | || | |Open Directory Editor |Visit the Lurker's Guide to Babylon 5:| | http://dmoz.org/ |* http://www.midwinter.com/lurk/ *| =
Re: Licensing Problems with Debian Packages (Was Re: Copyright lawyers analysis of Andreas Pour's Interpretation)
On Feb 17, Andreas Pour wrote: [...] I don't see why, after you've gone to such pains to establish that the on a module license doesn't change when a module is linked with a GPLed program. Why have you decided that this is a necessary step for this case? B/c the LGPL says so. It says you can change the license to GPL, but then it is no longer under the LGPL. Now you want to have it both ways. However, the LGPL prohibits it. Apparently you can't read and/or comprehend English. I mailed this morning that just because something is put under the GPL once, that does not necessarily mean that everyone else has to use it under the GPL too. Your ignorance of this fact (and your not challenging it) imply that all you're doing is trolling. Besides which, this is irrelevant to your example of grep+libc, since in linking grep with libc you don't modify any of libc's code, nor do you patch libc with code that would make it come under the GPL. The LGPL permits you to make derivative works of the library under either the GPL or the LGPL. That does not mean that once you do this (which we haven't anyway), you can never make another derivative work under the LGPL, or even that you have to treat the original under the GPL for ever and in eternity (which is what you seem to imply in this paragraph). Go away. Find something else to do. Build your own damn distribution if you can't find something more constructive. We're tired of your bullshit and your inability to assimilate new ideas (for example, that you're wrong). Chris -- Chris Lawrence [EMAIL PROTECTED] Senior Research Assistant, SSRL Opinions and attitudes expressed herein are rarely shared by my employer.
Re: Compuclick Ltda - Debian Vendor Page
On Feb 09, Branden Robinson wrote: On Wed, Feb 09, 2000 at 01:30:12PM +1100, Craig Small wrote: COMPUCLICK IS AUTHORIZED MANUFACTURER OF THE OFFICIAL CD OF DEBIAN AND BY EACH CD THAT YOU BUY TO US YOU CONTRIBUTE TO AUTOMATICAMENTE A DOLAR TO ALL PROJECTS DEBIAN/GNU BY INTERVAL OF FOUNDATION SPI What kind of crap is this? Who taught this person English? Binding legal terms should be written in clear, unambiguous, grammatic, and spell-checked language. It's a Babelfish translation of a sentence written in Spanish (the word automaticamente sort of gives it away). The original Spanish sentence looked reasonably correct, so I doubt it's Compuclick's fault. (Also, it doesn't seem to discuss legal terms; it's just a statement about the fact they make CDs.) So I guess the person to blame works for Compaq. Chris -- = |Chris Lawrence | Get rid of Roger Wicker this year!| | [EMAIL PROTECTED]| http://www.lordsutch.com/ms-one/ | | | | | Open Directory Editor |Are you tired of politics as usual?| | http://dmoz.org/| http://www.lp.org/| =
Re: Copyright lawyers analysis of Andreas Pour's Interpretation
On Feb 10, Don Sanders wrote: Secondly I showed him Andreas Pour's XFree license comment, which contains a copy of the Xfree license: http://lists.kde.org/?/=kde-licensingm=94950776505271w=2 * He agreed that software licensees have no inherent right to relicense software under a more restrictive license. * He agreed that one could not relicense software under the XFree license+++ under the GPL, as the XFree license prohibits this. [...] +++ The XFree license allows sublicensing under certain conditions. I don't think you would have any right to relicense software you didn't write. I think the issue is whether or not a derived work incorporating part of the XFree86-licensed code can be licensed under the GPL (or any other license that doesn't contradict the terms of the XFree86 license), and I don't see anyone here arguing that it can't. (Having said that, Debian's XFree86 implementation includes code under 6 separate licenses, 3 of which are identical in their substance, varying only in who they indemnify; 5 of these licenses are propogated from upstream.) If this were not the case, then Sun, HP, et al. could not bundle a proprietary X implementation (including closed-source X servers) with their operating systems. Chris -- = | Chris Lawrence | You have a computer. Do you have Linux? | | [EMAIL PROTECTED] | http://www.linux-m68k.org/index.html | || | | Debian Developer |Visit the Lurker's Guide to Babylon 5:| | http://www.debian.org/ |* http://www.midwinter.com/lurk/ *| =
Re: On interpreting licences (was: KDE not in Debian?)
is not licensed under the GPL. To put it another way, the end-user has all the rights provided by the GPL (actually, he has more, since he can incorporate it into proprietary software, provided he only uses my code and not Readline). Where this gets you in trouble is where you don't fulfil the requirements of section 2(b) in your original license. For example, if I distributed the same software under a M$-style EULA, I would be violating section 2(b) because the end-user would not have the same rights as those provided by the GPL. Whether or not the actual components are licensed under the GPL is irrelevant. What is relevant is that no permissions granted by the GPL are abridged by any of the components. The (regex) Qt. licenses abridge those permissions (in the case of the QPL, ever so slightly. Same deal with the BSD Advertising Clause). Chris -- = |Chris Lawrence| The Linux/m68k FAQ | | [EMAIL PROTECTED] | http://www.linux-m68k.org/faq/faq.html | | || | Open Directory Editor| Are you tired of politics as usual?| | http://dmoz.org/ | http://www.lp.org/ | =
Re: Why Debian's webpages aren't DFGS-free ?
On Feb 02, Joey Hess wrote: I brought this up on debian-www some time back, and I thought we agreed to change it to something free. I am rather pissed off that my work on the web pages (DWN) continues to go out under this license. If something isn't done soon, I may move future issues, and keep the copyright, rahter than assigning to SPI as I have done so far. Sigh. The solution seems rather obvious: Don't assign the copyright and use your own license. I can't see a problem with putting pages on the web site that have a less restrictive license than the SPI copyright. As a matter of fact, there can't be a problem, because the web site hosts documents under the GPL and other licenses. Chris -- = |Chris Lawrence| The Linux/m68k FAQ | | [EMAIL PROTECTED] | http://www.linux-m68k.org/faq/faq.html | | || | Open Directory Editor| Visit the Lurker's Guide to Babylon 5: | | http://dmoz.org/ | * http://www.midwinter.com/lurk/ * | =
Re: Double Standard?
On Jan 31, David Johnson wrote: I didn't check for every GPL application that uses Qt, only one example is sufficient. The package licq 0.44-4, in stable, uses the Qt library, along with being licensed under the GPL. It does not have any additional clauses at all. I looked. I didn't find any. Please report these instances as bugs against the packages and ftp.debian.org; if these are actual violations of the license, it will be removed (whether part of KDE or not). That may even include removal from stable in 2.1r5. As someone else pointed out here, licq does have the QPL exception clause. For the hell of it, I examined the copyright of every package in potato I could find that depended on either libqt1g or libqt2 (excluding the trivial cases of the -dev packages). tuxeyes (qt1): contrib. Has a MIT/X-style license, and thus is Qt ok. qweb (qt1): contrib. GPLed w/o Qt exception; this appears to be a violation. I am opening a release critical bug to that effect. qcad (qt2): main. GPLed with Qt exception. licq-plugin-qt2 (qt2): main. GPLed with Qt exception. xexec (qt2): main. GPLed, apparently w/o Qt exception. Bug filed. qps (qt2): main. GPLed, apparently w/o Qt exception. Bug filed. xsidplay (qt2): main. GPLed, with Qt severability clause. xgmod (qt2): main. Minimalistic license, so Qt ok. regexplorer (qt2): main. Appears to be QPLed itself. qbrew (qt2): main. MIT/X style license, thus Qt ok. So, of 10 packages, 7 have the clause (or don't need one, since they have minimal licenses that don't contradict the Qt ones). The other 3 are likely to be removed very soon. I may have missed some (I used apt-cache showpkg on the two library packages; if there is such a thing as a static Qt, it's possible other packages include Qt code). Chris -- = |Chris Lawrence| Get Debian GNU/Linux CDROMs| | [EMAIL PROTECTED] |http://www.lordsutch.com/cds/ | | || | Grad Student, Pol. Sci.| Visit the Lurker's Guide to Babylon 5: | | University of Mississippi | * http://www.midwinter.com/lurk/ * | =
Re: KDE not in Debian?
If you have something to say, say it to the lists. (This will be my last post on this topic, barring egregious factual errors that need correction---mine or those of others.) You haven't required it, AFAIK, from Gnome or other programs that link with X. And under your reading of the GPL (at least if you agree with the others I have been debating this issue with), if Qt is incompatible with the GPL, so is XFree. Oh right, it would really suck if you couldn't distribute XFree, so you can just ignore that transgression. Or am I missing something? (Please respond to my post with Message-ID [EMAIL PROTECTED] so I don't have to drown this list in repeating it). XFree is not distributed under a license more restrictive than the GPL. Qt is. That's it. End of story. From section 2 of the GPL: These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. There are no provisions of the XFree license that stop XFree code from being aggregated with GPLed code (the result being GPLed). By contrast, the QT FREE EDITION LICENSE (which is what Qt 1 is distributed under) specifically forbids the modification of Qt: Your software does not require modifications to Qt Free Edition. Nothing in the X license forbids modification of X by third parties. You are also forbidden from distributing modified versions of Qt1; nothing in the XFree license prohibits distribution of modified versions (see, for example, xfs-xtt, which is based on XFree's xfs implementation). As far as the QPL (Qt2) license goes, I leave the discussion to Joseph Carter, who actually helped Troll write it (with the specific intent of allowing Qt2 applications to be pure GPL) before the lawyers got involved. My belief is that the provisions that might require you to give your source code to Troll, even if the binary code is not distributed to others, were the most egregious (the GPL only obligates you to give source code to people you give binaries to; if you don't give someone binaries, you don't have to give them source either). For example, if I modify Emacs, RMS can't demand that I give him my changes unless I give him a binary of my modified Emacs; however, if I make a modified Qt2 (to create my own whizz-bang desktop that only I use), or even a program based on Qt2, Troll can demand a copy of it. That seems more restrictive than the GPL to me; I'm amazed it even meets the DFSG. Anyway, if you've followed this thread, you know that Debian has also thrown out (or not let in) other software with ambiguous license terms. XForms and Motif-based programs have gotten the same treatment (as have Qt-based programs from people other than KDE). Chris -- = |Chris Lawrence | Get rid of Roger Wicker this year!| | [EMAIL PROTECTED]| http://www.lordsutch.com/ms-one/ | | | | | Debian Developer|Are you tired of politics as usual?| |http://www.debian.org/ | http://www.lp.org/| =
Re: Was Re: KDE not in Debian?
On Jan 29, Andreas Pour wrote: (3) real permission to distribute from the authors. I do not quite know what you mean by this, but if you mean that to conform to your practice noted above of confirming from package authors that packages can be distributed by Debian, I will see if I can get the core KDE developers to send you their approval that you distribute KDE code. Mail me privately please if you think it is worth any effort and I will get started on it. It's a bit more complicated than that with some of the KDE software, because the GPL does not technically permit the linking of software against libraries that have licenses more restrictive than the GPL (like the QPL, which has restrictions on for-profit use on Win32). If all of the code in a particular KDE app is written by KDE members, all we need is something like: KFlarg is (C) 1999 Foo and Bar. You may use and distribute KFlarg under the terms of the GNU General Public License, version 2 (or a later version, at your discretion). As a special exception, you may also link KFlarg against the Qt widget library. (I forget the exact phrasing we decided was appropriate; but, some stuff that uses XForms in contrib uses it. I do know the correct version is longer). However, there are several instances of software in KDE being repackagings of existing software, with some work to integrate it into KDE (I am told KGV fits into this category). In these cases, because not all of the work was done by the KDE group, we also need permission from the author of the original software (GV in this case) to link against the GPL-incompatible software. [Personally, I think if you wrote the software yourself and link it against Qt, it's pretty obvious from a legal standpoint that you accept people linking it against Qt. However, if you take someone else's software and do the same thing, I can't see how we (or anyone else) can interpret that as acceptable. A lot of people have made a possibly erroneous assumption that authors like that of GV won't consider linking against Qt an abuse, and there are plenty of fat targets out there for a lawsuit (Corel, Red Hat, Caldera...).] Chris -- = | Chris Lawrence | Your source for almost nothing of value: | | [EMAIL PROTECTED] | http://www.lordsutch.com/ | || | |Open Directory Editor | Are you tired of politics as usual? | | http://dmoz.org/ | http://www.lp.org/ | =
Re: Was Re: KDE not in Debian?
On Jan 30, Andreas Pour wrote: [Personally, I think if you wrote the software yourself and link it against Qt, it's pretty obvious from a legal standpoint that you accept people linking it against Qt. I think so too. So why not just exclude kgv and kfloppy and distribute the rest? Because I'm not part of the Cabal (TINC). Seriously, it's the contrast between a meritless lawsuit and no lawsuit at all. Meritless lawsuits are expensive; we'll get back to you after we IPO. Ask the css-auth victims... (I guess I'm missing the reason why it's so hard to get people to explicitly say you can link this against Qt; that apparently would satisfy the FTP maintainers and let KDE 1 into contrib [and KDE 2 into main]). Chris -- = |Chris Lawrence| It's 2/3 of a beltway... | | [EMAIL PROTECTED] | http://www.lordsutch.com/tn385/ | | || | Open Directory Editor| Visit the Lurker's Guide to Babylon 5: | | http://dmoz.org/ | * http://www.midwinter.com/lurk/ * | =
Re: Bug#56166: base-files: copyright in motd is outdated (fwd)
On Jan 25, Santiago Vila wrote: Well, my question is more a do we really want to claim ownership of it? than a do we really have the right to copyright Debian as a whole?. I remember that the Simtel archives were reorganized some time ago so that all the free software (including djgpp and the GNU software) was put out of the collection (of which Simtel claimed a compilation copyright). [ Maybe this was done upon RMS request, I don't know ]. Is claming ownership of Debian as a whole within the spirit of the free software world? So long as we use a DFSG-compliant license for the distribution, I can't see a problem. There may be a weakness in that we don't have an explicit license for the distribution, though. In any case, SPI holds the copyright whether or not we announce it to the world or not (per discussion about the Berne Convention)... If we DO need a license for the distribution, something short and to the point (do whatever the hell you want with it, but don't sue us) seems reasonable enough; I like Branden's license for the X packages personally. === Copyright 1996-2000 Software in the Public Interest, Inc. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the Software), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL SOFTWARE IN THE PUBLIC INTEREST, INC. BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Except as contained in this notice, the name of Software in the Public Interest, Inc. shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization from Software in the Public Interest, Inc. === In essence: Don't sue us, don't use SPI's name as an endorsement, but otherwise go forth and multiply. The Python license makes the same basic point, but you have to fiddle with the wording some if you're not CWI ;-) Chris -- = |Chris Lawrence |Get Debian GNU/Linux CDROMs| | [EMAIL PROTECTED]| http://www.lordsutch.com/cds/ | | | | | Open Directory Editor |This address has been spam-proofed.| | http://dmoz.org/| All spam goes to your postmaster. | =
Re: freedomization task list [was: Re: Dangerous precedent being
On Dec 13, Henning Makholm wrote: Tomasz Wegrzanowski [EMAIL PROTECTED] writes: What kind of free licence make such situations possible ??? (for me it is not free even a little bit if author can change his mind and take away your freedom) I'm told that under American law, a promise that is made without getting something tangible (a consideration) in return cannot be legally binding. That would seem to allow any free software license to be revoked as soon as the author wants to. I might be wrong, though. Can one of the American law guys comment? This month's Linux Magazine has an article about this subject (and related concepts). It is possible that the right of future access to source code could be considered consideration, since the software would not have been used in the absence of that right. IANAL, of course, and this has never been litigated. My gut feeling is that a court would never rule the GPL as invalid, though, if only because there are virtually no positive ramifications of such a ruling (because if the GPL is invalid, then NOBODY can use GPLed code... it wouldn't revert to the public domain, which is the only benefit that an overturned GPL might have to proprietary software companies!). Chris -- = |Chris Lawrence| Get Debian GNU/Linux CDROMs| | [EMAIL PROTECTED] |http://www.lordsutch.com/cds/ | | || | Open Directory Editor| Visit the Lurker's Guide to Babylon 5: | | http://dmoz.org/ | * http://www.midwinter.com/lurk/ * | =
Re: Free Download End User License Agreement
On Dec 02, Tomasz Wegrzanowski wrote: On Thu, Dec 02, 1999 at 03:13:14AM -0600, Chris Lawrence wrote: On Dec 02, Anthony Towns wrote: They seem to be put off by liability issues, etc. And no doubt the risk of having their idle comments paraded about on slashdot isn't exactly an incentive. It seems to me, then, that we need a debian-legal-private list. I dunno how we'd handle subscription, etc., since obviously not all developers are interested in -legal issues. Then we can invite selected people from VA (if you want to call their disc with O'Reilly a separate distro), Corel, Stormix, whoever in to discuss these things, without creating slashdot headlines. You are closing development. I understand the need of a few registered-maintainers-only lists, but such Council-Of-Big-And-Important-Persons is completely against the spirit of free software. The next step will be making a corporation and monopolize GNU/Linux. 1: This list has nothing to do with development; it deals with licensing issues of third-party software that we wish to incorporate into Debian. As such, it's not closing development. 2: The Council of Big and Important Persons would actually be more inclusive than a registered maintainers only list, because people proposing licenses, who are not Debian developers, would be allowed to participate as well as existing developers. It seems to me that such a list is a way to have a more inclusive review of licenses than simply having people email (say) Bruce or ESR privately, which is what happens now. Not that Bruce doesn't do a good job, but I think we (the free software community) need more pairs of eyes so he doesn't get fed up with doing the job. And it lets people like Corel or the KDE group float trial balloons that won't get posted to Slashdot. As for your next step, there's no way to monopolize GNU/Linux, because there are virtually zero barriers to entry in the Linux business. Chris -- = |Chris Lawrence| Get Debian GNU/Linux CDROMs| | [EMAIL PROTECTED] |http://www.lordsutch.com/cds/ | | || | Debian Developer | Visit the Lurker's Guide to Babylon 5: | |http://www.debian.org/| * http://www.midwinter.com/lurk/ * | =
Re: Bruce Perens's Slashdot debacle
On Dec 03, Frank Copeland wrote: Robert Merkel wrote: Like it or not, debian is an open project. In the conventional media, if the news doesn't come from a press release it's standard procedure for the person or organisation concerned to have the opportunity to comment before the story is published. Slashdot ain't the media, conventional or otherwise. Nobody published a story. This isn't a story? http://slashdot.org/article.pl?sid=99/11/26/1450245mode=thread Chris -- = |Chris Lawrence |Get Debian GNU/Linux CDROMs| | [EMAIL PROTECTED]| http://www.lordsutch.com/cds/ | | | | | Debian Developer|Join the party that opposed the CDA| |http://www.debian.org/ | http://www.lp.org/| =
Re: Bruce Perens's Slashdot debacle
On Dec 04, Frank Copeland wrote: Chris Lawrence wrote: On Dec 03, Frank Copeland wrote: Robert Merkel wrote: Like it or not, debian is an open project. In the conventional media, if the news doesn't come from a press release it's standard procedure for the person or organisation concerned to have the opportunity to comment before the story is published. Slashdot ain't the media, conventional or otherwise. Nobody published a story. This isn't a story? http://slashdot.org/article.pl?sid=99/11/26/1450245mode=thread Nope. It's someone starting a thread in a discussion group by forwarding a message from another discussion group. It happens all the time in newsgroups and mailing lists. Characterising Slashdot as the media and trying to put the blame on them for not applying irrelevant journalistic standards is an exercise in messenger-assassination. Yes, but the top level of Slashdot isn't a thread; it's an article. And it is moderated, because only certain people can approve stories for the front page. This isn't the first time /. has gone off half-cocked, turning five lines of text into a flamefest. The people there need to start exercising some quality control on what they post, instead of jumping on the first message in a thread in a mailing list. Chris -- = |Chris Lawrence |Visit my home page!| | [EMAIL PROTECTED]| http://www.lordsutch.com/chris/ | | | | | Debian Developer|Are you tired of politics as usual?| |http://www.debian.org/ | http://www.lp.org/| =
Re: Free Download End User License Agreement
On Dec 02, Anthony Towns wrote: They seem to be put off by liability issues, etc. And no doubt the risk of having their idle comments paraded about on slashdot isn't exactly an incentive. It seems to me, then, that we need a debian-legal-private list. I dunno how we'd handle subscription, etc., since obviously not all developers are interested in -legal issues. Then we can invite selected people from VA (if you want to call their disc with O'Reilly a separate distro), Corel, Stormix, whoever in to discuss these things, without creating slashdot headlines. Chris -- = |Chris Lawrence| The Linux/m68k FAQ | | [EMAIL PROTECTED] | http://www.linux-m68k.org/faq/faq.html | | || | Grad Student, Pol. Sci.| Are you tired of politics as usual?| | University of Mississippi | http://www.lp.org/ | =
Re: Dangerous precedent being set - possible serious violation of the GPL
On Dec 02, Caspian wrote: Something-- SOMETHING-- must be done, or in five to ten years the Linux (and I do say Linux here, since it will no longer be GNU/Linux) The GNU/Linux term has relatively little currency outside Debian. It never has been GNU/Linux to more than a few people. I doubt you see it much except self-consciously or in the phrase Debian GNU/Linux (which gets butchered as Debian/GNU Linux half the time anyway...) In any event, my personal opinion is that Corel has the right to decide who to sell or give their software to, and who not to. They may have phrased it badly, but that's what their intent is. In any event, that decision disproves your assertion that all Corel cares about is money, since obviously they'd make more money if they were selling to minors. Under the GPL, they are only obligated not to make the you can't sell to minors restriction viral. It also seems we're venturing into debian-project territory here Chris -- = |Chris Lawrence |Get Debian GNU/Linux CDROMs| | [EMAIL PROTECTED]| http://www.lordsutch.com/cds/ | | | | | Debian Developer|Join the party that opposed the CDA| |http://www.debian.org/ | http://www.lp.org/| =
Re: is this free?
On Nov 22, Raul Miller wrote: it discriminates against people without regular internet access. Also, it effectively requires a fee for use, unless you consider the time of the person who uses it to have no value. [same issue.] It seems to be designed to protect users from being sued by anyone who might have a right to the code (other than ATT of course), since it would be illegal for you to use the code if ATT didn't have a valid right to license it in the first place. It's like me saying: I wrote this code, but there may be people in the universe who think they have rights to it. If there are, and their claims are legitimate, then it may be illegal for me to distribute the code and for you to use it (at least under the current license). I will update the license if this becomes the case. To put it another way: we're not entirely sure the schmuck who wrote this code didn't steal it from Microsoft. So we're covering our butts and yours by reserving the right to revise the license if that is actually the case (however remote the possibility). IANAL, of course. Would be nice if we had one around here ;-) Chris -- = |Chris Lawrence | You have a computer. Do you have Linux? | | [EMAIL PROTECTED] |http://www.linux-m68k.org/index.html | | | | | Grad Student, Pol. Sci. |Visit the Amiga Web Directory| | University of Mississippi | http://www.cucug.org/amiga.html | =
Re: mutt no longer in non-us?
On Nov 18, Joey Hess wrote: I still think mutt belongs in non-US. Why are people so opposed to putting it there? Putting a program like this in non-US just points out that the US government's laws are so brain-dead that they consider a mail reader a munition, thus raising public awareness of the problem. It doesn't inconvenience Debian much at all. It highly inconveniences our users, however. No part of the Social Contract says protesting stupid laws is more important than our users. It also inconveniences the Debian maintainer, who has to maintain two different forks of the same code (source and binary). It wastes space on our mirrors. It creates confusion by having multiple packages that do the exact same thing (less a system() or two). In any event, that function defines an interface. I'll gladly write a program that does not violate the US export laws that takes those parameters and processes text in some non-crypotgraphical way. # BEGIN LAME FILTER #!/usr/bin/python import sys sys.stdout.write(sys.stdin.read()) # END LAME FILTER There. That code interfaces to my stupid little cat emulator. ;-) (OK, so I didn't account for a few little niggling details. That can be fixed...) Chris -- = | Chris Lawrence | Your source for almost nothing of value: | | [EMAIL PROTECTED] | http://www.lordsutch.com/ | || | | Debian Developer |Visit the Lurker's Guide to Babylon 5:| | http://www.debian.org/ |* http://www.midwinter.com/lurk/ *| =
Re: Corel's apt frontend
On Oct 30, Bruce Perens wrote: From: Raul Miller [EMAIL PROTECTED] Sure, but a frontend isn't mere aggregation -- in this case if you take out the GPLed part of the system, the performance of that front end can't happen. Well, I'd like the law to agree with you, actually. The problem is that copyright law does not consider _reference_ a form of derivation. This would give us problem with dynamic libraries, too, except that the headers get copied into the application. I suspect a blanket prohibition on reference by non-GPL'ed software would be incredibly dumb, even if it were permitted by copyright law. It would forbid anything non-free from operating as a shell (and would even prohibit KDE programs from launching GNU software). Not to mention that it'd be impossible to launch GNU software on a non-GNU system, or even boot a GNU system in the first place (as the boot sector is referenced by a non-free BIOS or other boot rom). I really can't even see the point of forbidding non-free programs from calling dpkg... either (a) they'll reimplement dpkg as non-free software (reimplementing dpkg might be a good idea in and of itself, but a non-free dpkg is pretty worthless to everyone, and probably a source of confusion to boot) or (b) adopt another package manager. (In any event, you're talking about double-indirection here; I assume apt's authors don't give a rat's ass who calls their program, and apt is the program that runs dpkg.) Chris -- = |Chris Lawrence |Get Debian GNU/Linux CDROMs| | [EMAIL PROTECTED]| http://www.lordsutch.com/cds/ | | | | | Open Directory Editor |Join the party that opposed the CDA| | http://dmoz.org/| http://www.lp.org/| =
Re: Bug#47845: libdbd-pg-perl nonfree?
On Oct 20, Brian Ristuccia wrote: COPYRIGHT The DBD::Pg module is free software. You may distribute under the terms of either the GNU General Public License or the Artistic License, as specified in the Perl README CD-ROM or similar media for commercial distribution without the prior approval of the author. Um, what part of this copyright looks non-free to you? You can use the module under either the GPL or Artistic license, both of which are DFSG-free licenses. Ergo, it's OK to be in main, unless there's some dependency on a non-free package (which would make it appropriate for contrib). CHris -- = |Chris Lawrence |Get Debian GNU/Linux CDROMs| | [EMAIL PROTECTED]| http://www.lordsutch.com/cds/ | | | | | Debian Developer|Are you tired of politics as usual?| |http://www.debian.org/ | http://www.lp.org/| =
Re: Bug#47845: libdbd-pg-perl nonfree?
On Oct 20, Brian Ristuccia wrote: On Tue, Oct 19, 1999 at 11:24:40PM -0500, Chris Lawrence wrote: On Oct 20, Brian Ristuccia wrote: COPYRIGHT The DBD::Pg module is free software. You may distribute under the terms of either the GNU General Public License or the Artistic License, as specified in the Perl README CD-ROM or similar media for commercial distribution without the prior approval of the author. Um, what part of this copyright looks non-free to you? You can use the module under either the GPL or Artistic license, both of which are DFSG-free licenses. YoW! A bad paste on my part. It's non-free because it prohibits distribution on CD-ROM or similar media for commercial distribution without the prior approval of the author. Here's the except from man DBD::Pg in its entirety: COPYRIGHT The DBD::Pg module is free software. You may distribute under the terms of either the GNU General Public License or the Artistic License, as specified in the Perl README file, with the exception that it cannot be placed on a CD-ROM or similar media for commercial distribution without the prior approval of the author. OK, yeah, now I can see it ;-) (Having said that, I'm not sure that it's legit to make exceptions to the GPL, especially if the author used anyone else's code in the module...) Chris -- = | Chris Lawrence | Get Debian GNU/Linux CDROMs | | [EMAIL PROTECTED]| http://www.lordsutch.com/cds/ | | | | | Grad Student, Pol. Sci. | Visit the Amiga Web Directory | |University of Mississippi| http://www.cucug.org/amiga.html | =
Re: opencontent licence DFSG free?
On Oct 18, Jens Ritter wrote: What about this? Any publication in standard (paper) book form shall require the citation of the original publisher and author. The publisher and author's names shall appear on all outer surfaces of the book. On all outer surfaces of the book the original publisher's name shall be as large as the title of the work and cited as possessive with respect to the title. (from http://www.ora.com/catalog/debian/chapter/appf_01.html) Isn´t this an advertising clause like the BSD license had? This would be bad and make it non-free, doesn`t it? I wonder if it is enforceable, because every book has got 6 outer surfaces and its hard to get the information requested on the side which opens up... *eg* I don't think it's an advertising clause in the sense of the BSD advertising clause. It's more like a reasonable disclosure clause (i.e. telling people what they're buying). I assume all outer surfaces is a publishing term for the covers and spine. (Also, I'd check to see if this clause is in the release OPL at the Open Content website. The book is licensed under ANY version of the OPL, and the latest versions are a lot less strict in terms of attribution and limiting the freedom of derived works.) Chris -- = | Chris Lawrence|Get Debian GNU/Linux CDROMs| |[EMAIL PROTECTED] | http://www.lordsutch.com/cds/ | | | | |Grad Student, Pol. Sci.|Join the party that opposed the CDA| | University of Mississippi | http://www.lp.org/| =
Re: opencontent licence DFSG free?
On Oct 12, Joey Hess wrote: The whole O'Reilly debian book is online now at http://www.ora.com/catalog/debian/chapter/ The copyright is the OpenContent license, http://www.ora.com/catalog/debian/chapter/copyright.html It looks to me on a hurried reading that the opencontent license is DFSG free so long as none of the license options are invoked. Opinions? I tend to agree; my recollection is that the OpenContent License (aka OPL) was specifically designed to be compliant with the Open Source Definition (and thus the DFSG). Furthermore, I think RMS helped them write it or revise it. Chris -- = |Chris Lawrence |Get Debian GNU/Linux CDROMs| | [EMAIL PROTECTED]| http://www.lordsutch.com/cds/ | | | | | Debian Developer|Are you tired of politics as usual?| |http://www.debian.org/ | http://www.lp.org/| =
Re: NcFTP is free again?
On Sep 30, Chris Cheney wrote: I just looked at NcFTP 3.0Beta20 and it appears to have changed its license to free (no license file) and the libncftp requirement of non-use by other programs seems to have been dropped also. Maybe someone more knowledgeable than me can look at this and see if it can be packaged again. Thanks, Chris (Moved to debian-legal; please direct followups there; CC'd to the author so maybe he can shed some light on what's going on here.) I just downloaded the source code and can't find an actual license anywhere. The changelog entry reads: + Change of licensing. Specifically, GPL was shown the door. NcFTP is, has always been, and will continue to be free software. which isn't a license (at best a statement of principles). Furthermore, READLINE-README reads in part: Apparently this special free version of LibNcFTP still cannot co-exist with GPL'd stuff. which indicates that this special free version is probably not DFSG-compliant. But again, I can't see a license anywhere, so maybe it is (advertising clause maybe?). The man page says: Thanks to Red Hat Software for honoring my licensing agreement, but more importantly, thanks for providing a solid and affordable development platform. which seems to indicate that there is a license somewhere on the planet, but it's still not with the source. Or on the website. The only actual license (grep -i licen) I can find is in vis/syshdrs.h, but it's a GPL license. And he claims in the changelog that NcFTP is not GPLed. Hence I'm stumped. Since my suspicion is that libncftp (even in its special free version) is still only licensed for use with ncftp, it would seem to fail the DFSG [and Open Source Definition] on several points. Off the bat, it would fail point 3. Depending on the actual licensing terms for libncftp, I suspect it fails points 5 and/or 6 too (no commercial use of derived works?). See the DFSG at http://www.debian.org/social_contract#guidelines (and note that these guidelines are substantively identical to the OSD). Having said that, the removal of linkage to Readline probably qualifies it for the non-free section (since it is no longer in violation of Readline's license). Of course, all of this is speculative because (yes, I'm harping on this point) there is no license that I can see. So we can't do squat with NcFTP 3 until Mike includes a license. Incidentally, ncftp 2 core dumps after using ncftp 3 (the prefs files apparently confuse it); maybe we should fix that... Chris -- = |Chris Lawrence| The Linux/m68k FAQ | | [EMAIL PROTECTED] | http://www.linux-m68k.org/faq/faq.html | | || | Grad Student, Pol. Sci.|Visit the Amiga Web Directory | | University of Mississippi | http://www.cucug.org/amiga.html | =
[from -devel] Re: all rights reserved
On Sep 09, Itai Zukerman wrote: I've come across the following in one file of an otherwise GPL'ed set of code: /* simple password generator by XXX * copyright 1991, all rights reserved. * You can use this code as long as my name stays with it. */ The file builds into a stand-alone utility which is not crucial to the package (it just takes a command-line argument and invokes crypt(3), displaying the result). I'm worried that this file does not satisfy the DFSG. Would that restrict me from uploading the entire package source? Or only from including the utility in the binary package? If this is a FAQ, then please point me in the right direction. Thanks, -itai, newbie The third line seems to indicate that you can use it, so long as you don't remove XXX's name, so it is DFSG-compliant. I think. [CC'd to debian-legal for their opinions] Chris -- = |Chris Lawrence| The Linux/m68k FAQ | | [EMAIL PROTECTED] | http://www.linux-m68k.org/faq/faq.html | | || |Amiga A4000 604e/233Mhz | Join the party that opposed the CDA| | with Linux/APUS 2.2.8| http://www.lp.org/ | =
Re: License ok? Opinion needed.
On Jul 31, Mike Goldman wrote: Need a legal opinion on the following license. I assume #9 causes this to be classifiable as non-free (pity, though) -- the only other concern I had was whether #8 posed any sort of problem for our including software under this license in Debian. ... 9. GOVERNMENT RESTRICTED RIGHTS. The SOFTWARE and documentation are provided with RESTRICTED RIGHTS. Use duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of The Rights in Technical Data and Computer Software clause in DFARS 252.227-7013, or subparagraphs (c)(i) and (2) of the Commercial Computer Software -- Restricted Rights at 48 CFR 52.227-19, as applicable. Manufacturer is [Company name and address]. I suspect this is boilerplate language that got included by their lawyers' build yourself a software license in 12 easy steps software :-). Having said that, the restrictions referred to are probably provisions of U.S. law rather than ones imposed by the copyright holder. I suspect the legal effect is similar to the export restrictions clauses in licenses, as it simply restates existing law (and is unenforceable outside the U.S.) rather than imposing additional restrictions on the user. Chris -- = | Chris Lawrence | Get your Debian 2.1 CD-ROMs | |[EMAIL PROTECTED] |http://www.lordsutch.com/| | | | | Amiga A4000 604e/233Mhz | Visit the Amiga Web Directory | | with Linux/APUS 2.2.8 | http://www.cucug.org/amiga.html | =
Re: Is it illegal to distribute Linux kernel? KDE precedent.
On Jun 24, Brian Ristuccia wrote: On Thu, Jun 24, 1999 at 09:54:46PM +0200, Anonymous wrote: My intense observation of GNU/Debian Linux Kernel with grep -R All advertising materials * has shown drivers/net/bsd_comp.c, drivers/net/hydra.h include/linux/quota.h The situation with the Linux kernel is different than the situation with KDE because the network compression and quota drivers are modifications to the Linux kernel. KDE is not a modification to Qt. It is my understanding that : 1. Copying and modification of the Linux kernel was governed by the file commonly located at /usr/src/linux/COPYING 2. Contributors who add to or modify the Linux kernel have accepted the terms for modification as indicated by /usr/src/linux/COPYING. Otherwise, they would not have the right to modify the Linux kernel. These these changes could not exist in the first place if their contributors did not accept the license for making changes. 3. The Linux Kernel's license (The GNU General Public License) requires that all modifications be under the same license as the software being modified. so, 4. The files you mention, while they may themselves be covered by other licenses as noted in their respective source files, are covered by the GNU General Public License when distributed with the Linux kernel. The situation with bsd_comp.c is that you can't compile it into the kernel, but it can be used as a module. make config enforces this policy, even though there's no technical reason why it can't be compiled-in. The other two files are header files; all they do is define an interface, which to my understanding isn't code per se. I doubt Linus would have allowed them in otherwise. Chris -- = | Chris Lawrence | Get your Debian 2.1 CD-ROMs| |[EMAIL PROTECTED]|http://www.lordsutch.com/ | || | | Amiga A4000 604e/233Mhz| Do you want your bank to snoop? | | with Linux/APUS 2.2.8 |http://www.defendyourprivacy.com/ | =
Re: Is it illegal to distribute Linux kernel? KDE precedent.
On Jun 25, reject wrote: GNU/Debian can sure bullshit it's way out of a situation when it has to. Debian/GNU Linux Kernel takes BSD 4.3 code and includes it in Debian/GNU Linux Kernel creating a derived work but distributes it under GPL which is in direct contradiction with the original license of the BSD 4.3 code which has an advertising clause that must be respected. Suddenly this is magically made right by the above rhetoric? Please if you call me a skeptic. The rhetoric is incorrect; ask Linus if you don't believe the explanation I posted previously. He's prohibited major blocks of code from entering the kernel tree because of the BSD advertising clause (notably, the original 680x0 FPU emulator which was adapted from NetBSD), and the bsd_comp situation is consistent with other non-GPLed modules (bsd_comp just happens to be in the kernel tree). (I return you to your regularly-scheduled trollfest.) Chris -- = |Chris Lawrence| Visit my home page!| | [EMAIL PROTECTED] | http://www.lordsutch.com/chris/ | | || | Grad Student, Pol. Sci.| Visit the Lurker's Guide to Babylon 5: | | University of Mississippi | * http://www.midwinter.com/lurk/ * | =
Re: DFSG And Trademarks
On Jun 18, Jeff Licquia wrote: On Fri, Jun 18, 1999 at 02:35:02PM -, [EMAIL PROTECTED] wrote: Change the name on your package just enough to avoid all of the trademarks, because we _will_ have to fix bugs before they do, etc. Any recommendations on avoiding the trademark? Do I have to come up with a brand new name, or would something like cups-debian or debcups or dcups work OK? dcups is a double-entendre (at least in .us) and probably should be avoided... cups-debian might work; common-unix-print-sys might also be appropriate (and a bit more descriptive). And it gets around the trademark... (My understanding is that an acronym can't be trademarked under U.S. law, so the CUPS trademark may be invalid in any case.) Chris
Re: DFSG And Trademarks
On Jun 18, Jeff Licquia wrote: The code itself is GPL, so DFSG compliance isn't a problem. However, the vendors have trademarked the words CUPS, Common UNIX Printing System, and possibly a few others I'm forgetting. The license page (http://www.cups.org/LICENSE.html) has this gem: Also, since we have trademarked the Common UNIX Printing System, CUPS, and CUPS logo, you may not release a derivative product using those names without permission from Easy Software Products. I asked for a clarification from them, and got a response that talked about configuration of the source being permitted. On one level, that could mean that they're giving you permission to run './configure'; OTOH, I was talking about the possible need to change CUPS to conform to Debian policy, which could get into some major configuration. They have promised to clarify the license, but they haven't so far. This is also an issue with other things, like AbiWord. The abiword package in unstable is actually AbiWord Personal; AbiSource provides binary Debian packages (via alien, bleech) for Alpha and Intel (which leaves our other three architectures out in the cold). Who does the building determines what the program can be called, which seems rather contrary to the spirit of the DFSG, if nothing else... Of course, I can build an identical CD image to the Official (Debian) CD, but I'm wouldn't be allowed to call it the Official CD. So even within Debian there are issues. Chris -- = | Chris Lawrence | Get your Debian 2.1 CD-ROMs | | [EMAIL PROTECTED]|http://www.lordsutch.com/| | | | | Grad Student, Pol. Sci. | Do you want your bank to snoop? | |University of Mississippi|http://www.defendyourprivacy.com/| =
Re: Editor and sensible-editor
On Jun 15, Brock Rozen wrote: To clear up any confusion, the Pine (as such, pico; I believe) license has changed and that might make it eligible to be taken out of non-free. A number of problems have been discussed on -legal relative to it; most notably, that you can put it on a CD-ROM but not a Jaz disc (for example), and you can't put it with commercial software. That and the local modification business is a bit goofy; perhaps they should consider a you modify it, you change the name policy (i.e. you can't call a modified Pine UW Pine or UW PC/Pine). That would at least edge it closer to DFSG-freeness (and would certainly let binaries into non-free). Chris -- = |Chris Lawrence| Visit my home page!| | [EMAIL PROTECTED] | http://www.lordsutch.com/chris/ | | || |Amiga A4000 604e/233Mhz | Visit the Lurker's Guide to Babylon 5: | | with Linux/APUS 2.2.3| * http://www.midwinter.com/lurk/ * | =
Re: [awansink@ke.com.au: Re: Isn't a kde version of abiword illegal?]
On May 28, Darren O. Benham wrote: From what I read in FSF/GNU documentation, it's only necessary for segnifigant contributions, not a few lines of code. I think all the major contributors to Abi are employees of AbiSource.. Every thing else are seperate libraries. ... which may have their own issues. Is the LGPL (AbiWord uses glib internally) Qt-compatible? Chris -- = | Chris Lawrence | You have a computer. Do you have Linux? | | [EMAIL PROTECTED] | http://www.linux-m68k.org/index.html | || | | Amiga A4000 604e/233Mhz |Do you want your bank to snoop? | |with Linux/APUS 2.2.3 | http://www.defendyourprivacy.com/ | =
