Re: LGPL v3 compatibilty
Francesco Poli [EMAIL PROTECTED] wrote: On Sat, 14 Jul 2007 21:56:27 -0700 (PDT) Walter Landry wrote: Francesco Poli [EMAIL PROTECTED] wrote: On Mon, 2 Jul 2007 12:31:13 -0400 Anthony Towns wrote: [...] Note that _if_ we do stick to the view we've taken up until now, when we have a LGPLv3 only glibc in the archive, we'll no longer be able to distribute GPLv2-only compiled executables. Unless the GPLv2-only work copyright holder(s) add(s) a special exception, similar to the one needed to link with the OpenSSL library, right? This scenario is worrying me... :-( Is this going to be a problem for the kernel? It is definitely not going to go to GPLv3. Is the Linux kernel linked with any LGPL'd work? AFAIUI, it is not, so no problem for the kernel. Doesn't the kernel get its implementations for pow(), sqrt(), printf(), and the rest of the C standard library from glibc, which is LGPL'd? Cheers, Walter Landry [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: LGPL v3 compatibilty
Walter Landry [EMAIL PROTECTED] writes: Francesco Poli [EMAIL PROTECTED] wrote: On Sat, 14 Jul 2007 21:56:27 -0700 (PDT) Walter Landry wrote: Francesco Poli [EMAIL PROTECTED] wrote: On Mon, 2 Jul 2007 12:31:13 -0400 Anthony Towns wrote: [...] Note that _if_ we do stick to the view we've taken up until now, when we have a LGPLv3 only glibc in the archive, we'll no longer be able to distribute GPLv2-only compiled executables. Unless the GPLv2-only work copyright holder(s) add(s) a special exception, similar to the one needed to link with the OpenSSL library, right? This scenario is worrying me... :-( Is this going to be a problem for the kernel? It is definitely not going to go to GPLv3. Is the Linux kernel linked with any LGPL'd work? AFAIUI, it is not, so no problem for the kernel. Doesn't the kernel get its implementations for pow(), sqrt(), printf(), and the rest of the C standard library from glibc, which is LGPL'd? No. The kernel is completely self-contained. Some code may of course have been borrowed from glibc at some point, but that's irrelevant. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: LGPL v3 compatibilty
On Mon, Jul 16, 2007 at 08:39:10AM +0100, Måns Rullgård [EMAIL PROTECTED] wrote: Walter Landry [EMAIL PROTECTED] writes: Francesco Poli [EMAIL PROTECTED] wrote: On Sat, 14 Jul 2007 21:56:27 -0700 (PDT) Walter Landry wrote: Francesco Poli [EMAIL PROTECTED] wrote: On Mon, 2 Jul 2007 12:31:13 -0400 Anthony Towns wrote: [...] Note that _if_ we do stick to the view we've taken up until now, when we have a LGPLv3 only glibc in the archive, we'll no longer be able to distribute GPLv2-only compiled executables. Unless the GPLv2-only work copyright holder(s) add(s) a special exception, similar to the one needed to link with the OpenSSL library, right? This scenario is worrying me... :-( Is this going to be a problem for the kernel? It is definitely not going to go to GPLv3. Is the Linux kernel linked with any LGPL'd work? AFAIUI, it is not, so no problem for the kernel. Doesn't the kernel get its implementations for pow(), sqrt(), printf(), and the rest of the C standard library from glibc, which is LGPL'd? No. The kernel is completely self-contained. Some code may of course have been borrowed from glibc at some point, but that's irrelevant. Borrowed code *is* relevant, because you can't borrow code *and* change its license without authorization. What makes it irrelevant is that the borrowed code is LGPL'ed. And LGPL code can happily be relicensed to GPL, as stated in the LGPL text. Thus the kernel code that was borrowed from glibc is GPL. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: LGPL v3 compatibilty
Mike Hommey wrote: On Mon, Jul 16, 2007 at 08:39:10AM +0100, M?ns Rullg?rd [EMAIL PROTECTED] wrote: No. The kernel is completely self-contained. Some code may of course have been borrowed from glibc at some point, but that's irrelevant. Borrowed code *is* relevant, because you can't borrow code *and* change its license without authorization. What makes it irrelevant is that the borrowed code is LGPL'ed. And LGPL code can happily be relicensed to GPL, as stated in the LGPL text. Thus the kernel code that was borrowed from glibc is GPL. What's relevant here is that it was borrowed from an LGPL *v2* library into a GPL *v2* project. If a later version of glibc is licensed solely under GPLv3, that won't affect the borrowed code that is in the kernel. If the GPLv2 kernel somehow used an LGPLv3 library, things would get interesting. Arnoud -- Arnoud Engelfriet, Dutch European patent attorney - Speaking only for myself Patents, copyright and IPR explained for techies: http://www.iusmentis.com/ Arnoud blogt nu ook: http://blog.iusmentis.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: LGPL v3 compatibilty
Måns_Rullgård [EMAIL PROTECTED] wrote: Walter Landry [EMAIL PROTECTED] writes: Francesco Poli [EMAIL PROTECTED] wrote: On Sat, 14 Jul 2007 21:56:27 -0700 (PDT) Walter Landry wrote: Francesco Poli [EMAIL PROTECTED] wrote: On Mon, 2 Jul 2007 12:31:13 -0400 Anthony Towns wrote: [...] Note that _if_ we do stick to the view we've taken up until now, when we have a LGPLv3 only glibc in the archive, we'll no longer be able to distribute GPLv2-only compiled executables. Unless the GPLv2-only work copyright holder(s) add(s) a special exception, similar to the one needed to link with the OpenSSL library, right? This scenario is worrying me... :-( Is this going to be a problem for the kernel? It is definitely not going to go to GPLv3. Is the Linux kernel linked with any LGPL'd work? AFAIUI, it is not, so no problem for the kernel. Doesn't the kernel get its implementations for pow(), sqrt(), printf(), and the rest of the C standard library from glibc, which is LGPL'd? No. The kernel is completely self-contained. Some code may of course have been borrowed from glibc at some point, but that's irrelevant. Are you sure that it is self-contained? Grepping through the sources of 2.6.22.1, I do not see an implementation of stdarg.h or stdio.h. I do see string.h, and math.h is never included. Cheers, Walter Landry [EMAIL PROTECTED]
Re: LGPL v3 compatibilty
Walter Landry [EMAIL PROTECTED] writes: Måns_Rullgård [EMAIL PROTECTED] wrote: Walter Landry [EMAIL PROTECTED] writes: Francesco Poli [EMAIL PROTECTED] wrote: On Sat, 14 Jul 2007 21:56:27 -0700 (PDT) Walter Landry wrote: Francesco Poli [EMAIL PROTECTED] wrote: On Mon, 2 Jul 2007 12:31:13 -0400 Anthony Towns wrote: [...] Note that _if_ we do stick to the view we've taken up until now, when we have a LGPLv3 only glibc in the archive, we'll no longer be able to distribute GPLv2-only compiled executables. Unless the GPLv2-only work copyright holder(s) add(s) a special exception, similar to the one needed to link with the OpenSSL library, right? This scenario is worrying me... :-( Is this going to be a problem for the kernel? It is definitely not going to go to GPLv3. Is the Linux kernel linked with any LGPL'd work? AFAIUI, it is not, so no problem for the kernel. Doesn't the kernel get its implementations for pow(), sqrt(), printf(), and the rest of the C standard library from glibc, which is LGPL'd? No. The kernel is completely self-contained. Some code may of course have been borrowed from glibc at some point, but that's irrelevant. Are you sure that it is self-contained? Grepping through the sources of 2.6.22.1, I do not see an implementation of stdarg.h or stdio.h. I do see string.h, and math.h is never included. Inside the kernel stdio is meaningless, so I'd hardly expect to find that header there. The only places in the kernel source where stdio.h is included are in tools, such as kconfig, only to be used for building the kernel or for testing purposes. This use of standard C header files is of course completely outside the scope of any license. As for stdarg.h, it is provided by the compiler, and generally (including GCC) licensed without restrictions on use. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: LGPL v3 compatibilty
Måns_Rullgård [EMAIL PROTECTED] wrote: Inside the kernel stdio is meaningless, so I'd hardly expect to find that header there. The only places in the kernel source where stdio.h is included are in tools, such as kconfig, only to be used for building the kernel or for testing purposes. This use of standard C header files is of course completely outside the scope of any license. As for stdarg.h, it is provided by the compiler, and generally (including GCC) licensed without restrictions on use. Thanks. That clarifies things. I could see how this might still be a problem if there are third party tools that use some internal kernel structures [1] and link to glibc, but I do not know of any such cases. I would expect such tools to be rare since it would be pretty fragile. Cheers, Walter Landry [EMAIL PROTECTED] [1] If the tools use normal kernel interfaces, then the kernel's license disavows any claims on how they can be distributed.
Re: LGPL v3 compatibilty
On Sat, 14 Jul 2007 21:56:27 -0700 (PDT) Walter Landry wrote: Francesco Poli [EMAIL PROTECTED] wrote: On Mon, 2 Jul 2007 12:31:13 -0400 Anthony Towns wrote: [...] Note that _if_ we do stick to the view we've taken up until now, when we have a LGPLv3 only glibc in the archive, we'll no longer be able to distribute GPLv2-only compiled executables. Unless the GPLv2-only work copyright holder(s) add(s) a special exception, similar to the one needed to link with the OpenSSL library, right? This scenario is worrying me... :-( Is this going to be a problem for the kernel? It is definitely not going to go to GPLv3. Is the Linux kernel linked with any LGPL'd work? AFAIUI, it is not, so no problem for the kernel. The problem arises whenever a work under the GPLv2 (only) is linked with a work under the LGPLv3. -- http://frx.netsons.org/doc/nanodocs/testing_workstation_install.html Need to read a Debian testing installation walk-through? . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpbnw1XaBUUd.pgp Description: PGP signature
Re: LGPL v3 compatibilty
Steve Langasek [EMAIL PROTECTED] wrote: I think you forgot to preface this with the disclaimers I am not a lawyer, [...] Some of those disclaimers, plus I am not a lawyer qualification authority seemed to be missing from yours too. Or maybe He Is Not A * posts should be banned from this list and we can get back to looking at packages, hmm? Regards, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: LGPL v3 compatibilty
In message [EMAIL PROTECTED], Michelle Konzack [EMAIL PROTECTED] writes I have coded some programs which are explicit under GPL v2 since I do not like v3 (I have my reasons) but I am using a LIB which is currently under LGPL v2. Now the new version of this LIB is v3. What should I do? DON'T PANIC (as Douglas Adams said). If your GPLv2 program links to an LGPLv3 library, then you don't need to give a monkeys. The whole point behind LGPL is that the LGPL library must be independently distributable, and independently upgradeable. If your program is GPL (any version), then it is compatible with any LGPL library (any version). Cheers, Wol -- Anthony W. Youngman - [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: LGPL v3 compatibilty
In message [EMAIL PROTECTED], Steve Langasek [EMAIL PROTECTED] writes The whole point behind LGPL is that the LGPL library must be independently distributable, and independently upgradeable. If your program is GPL (any version), then it is compatible with any LGPL library (any version). I think you forgot to preface this with the disclaimers I am not a lawyer, I am not a DD, I don't speak for the FSF, I don't even bother to read the other analyses of GPLv2/LGPLv3 interaction that have been posted to this list, and this *is* legal advice that I have no business dispensing to people on a Debian mailing list. Given my experience of lawyers, I strongly suspect my not a lawyer knowledge of law is quite likely to be better than many of theirs' ... :-) Yes maybe I should have put disclaimers - I just tend to assume that people on mailing lists are ordinary people like me ... And I think Gervase has already corrected me :-) Mind you. I think, if you distribute AS SOURCE, GPL code is compatible with pretty much ANYTHING (I can't remember my analysis, but basically it was along the lines of anything else - even components required for successful compilation - are mere aggregation as far as the source goes :-) Cheers, Wol -- Anthony W. Youngman - [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: LGPL v3 compatibilty
Francesco Poli [EMAIL PROTECTED] wrote: On Mon, 2 Jul 2007 12:31:13 -0400 Anthony Towns wrote: [...] Note that _if_ we do stick to the view we've taken up until now, when we have a LGPLv3 only glibc in the archive, we'll no longer be able to distribute GPLv2-only compiled executables. Unless the GPLv2-only work copyright holder(s) add(s) a special exception, similar to the one needed to link with the OpenSSL library, right? This scenario is worrying me... :-( Is this going to be a problem for the kernel? It is definitely not going to go to GPLv3. Cheers, Walter Landry [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: LGPL v3 compatibilty
# ATTENTION: I am currently NOT in Strasbourg because# # haveing the last 4 weeks of my military # # service and can not reply in short delays. # Hello *, Am 2007-07-01 16:38:56, schrieb Francesco Poli: On Sun, 1 Jul 2007 13:58:08 +0200 Andreas Metzler wrote: [...] LGPLv3 libraries could not be used in GPLv2-only programs. I'm afraid that this incompatibility is still true. AFAIUI, when you redistribute a GPLv2-only program in compiled form, the GPLv2 insists that the libraries the program links with (excluding system libraries...) are available under GPLv2. But an LGPLv3-only or LGPLv3-or-later library is available under GPLv3, not under GPLv2. All this, assuming that the FSF's legal theory of linking is correct: this theory has never been tested in court, AFAIK, hence we do not know if it would hold. However, we have to assume that it's correct, to be on the safe side. Disclaimers: IANAL, TINLA, IANADD. Question: I have coded some programs which are explicit under GPL v2 since I do not like v3 (I have my reasons) but I am using a LIB which is currently under LGPL v2. Now the new version of this LIB is v3. What should I do? Push the source of the LIB v2 into my executable since I can not distribute the same LIB (physical) because namespace conflicts ? It seems that I am using 7 libs which will switch to LGPL v3 and I am already using parts of libc-client (I do not want to use the pop3 part in any case and have some restrictions made to the source). Should I pull out all needed functions and put it into my own source? Two of those 7 LIB's are a WebDAV and a Calendar client library. This stuff is realy confusing... Thanks, Greetings and nice Day Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSN LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: LGPL v3 compatibilty
On Sun, Jul 01, 2007 at 04:38:56PM +0200, Francesco Poli wrote: On Sun, 1 Jul 2007 13:58:08 +0200 Andreas Metzler wrote: LGPLv3 libraries could not be used in GPLv2-only programs. I'm afraid that this incompatibility is still true. AFAIUI, when you redistribute a GPLv2-only program in compiled form, the GPLv2 insists that the libraries the program links with (excluding system libraries...) are available under GPLv2. It excludes system libraries that are shipped with the application though. Since Debian ships everything together in main, we haven't been able to make use of that exception with GPLv2. [0] The GPLv3's system libraries extension is broader, and covers at least libc, which is 95% of the problem. So while there's a problem for us in linking GPLv2 stuff against non-GPLv2 compatible system libraries (like OpenSolaris's libc), there's no problem for us linking GPLv3 stuff against non-GPLv3 compatible system libraries. But for GPLv2 only apps, the same argument that stops us linking them to OpenSolaris/CDDL libc applies to LGPLv3 libc too, which will presumably include GNU libc very soon, if it doesn't already. All this, assuming that the FSF's legal theory of linking is correct: this theory has never been tested in court, AFAIK, hence we do not know if it would hold. However, we have to assume that it's correct, to be on the safe side. We've assumed that for three main reasons, I think: (1) assuming otherwise would seem like disagreeing with the GPL, and even if that's legally supportable, we'd rather support the GPL (2) supporting that interpretation seems legally plausible, and is simpler to deal with than trying to draw a different line between static and dynamic linking (3) the more strongly viral the GPL is treated, the more effective it is as a copyleft license, promoting the freedoms and such that we've stood for By we, I mean Debian, in particular per discussions on debian-legal and other lists that've influenced/decided ftpmaster policy. Eben Moglen's (reportedly) claimed otherwise since at least the start of the GPLv3 drafting [1]: ] During the discussion[1], Eben Moglen took special care to assert ] that he always believed the GPL v2 should be interpreted in the way ] GPL v3 now makes explicit - it was never the intent to prevent ] aggregation of otherwise unrelated code because of the GPL being ] triggered just because a system function or C runtime was invoked. I ] found that clarification especially valuable. which makes sense, and probably does away with the first concern (if the FSF doesn't agree with interpreting the GPLv2 that strongly, there's not a lot of point to us doing so, particularly when GPLv3 can't be interpreted that strongly), and the second as well (it's much less legally plausible if the FSF disavow the interpretation, and the line we'd have to draw is one we need to draw for GPLv3 anyway). The third point might still be an issue, but that's about it. Playing it safe about respecting the wishes of GPLv2 authors is definitely a concern, but I think the three issues above have always decided the matter before that's actually come up. I believe Sam's currently waiting on a response from the FSF licensing folks to get a first hand take on the FSF's position that we've only had third hand via posts paraphrasing Eben up 'til now. Note that _if_ we do stick to the view we've taken up until now, when we have a LGPLv3 only glibc in the archive, we'll no longer be able to distribute GPLv2-only compiled executables. Cheers, aj [0] Other people who've distributed KDE separately to Debian, otoh, have been able to (IMO) fairly reasonably claim that Qt under the QPL was a system library for Debian systems, and thus make use of the exception to distribute GPLed KDE binaries. [1] http://www.opensolaris.org/jive/thread.jspa?messageID=21134#21134 signature.asc Description: Digital signature
Re: LGPL v3 compatibilty
On Mon, 2 Jul 2007 12:31:13 -0400 Anthony Towns wrote: [...] Note that _if_ we do stick to the view we've taken up until now, when we have a LGPLv3 only glibc in the archive, we'll no longer be able to distribute GPLv2-only compiled executables. Unless the GPLv2-only work copyright holder(s) add(s) a special exception, similar to the one needed to link with the OpenSSL library, right? This scenario is worrying me... :-( -- http://frx.netsons.org/doc/nanodocs/testing_workstation_install.html Need to read a Debian testing installation walk-through? . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpJ2ZVy6Xshu.pgp Description: PGP signature
Re: LGPL v3 compatibilty
On Mon, Jul 02, 2007 at 07:52:03PM +0200, Francesco Poli wrote: On Mon, 2 Jul 2007 12:31:13 -0400 Anthony Towns wrote: [...] Note that _if_ we do stick to the view we've taken up until now, when we have a LGPLv3 only glibc in the archive, we'll no longer be able to distribute GPLv2-only compiled executables. Unless the GPLv2-only work copyright holder(s) add(s) a special exception, similar to the one needed to link with the OpenSSL library, right? Well, that's always an option, but where the gpl v2 app can get an exception added, it can also be relicensed under gpl v3 too. Presumably we have a few gpl v2 apps where thast's not going to be an option. On the other hand, supposing we find a different view that allows GPLv2 apps to make use of the system library exception to link to a hypothetical LGPLv3 glibc. Then we'll have decided there's /a/ way of distributing a library in Debian (anything that is normally distributed with the major components of the operating system) and an executable that links to that library in Debian, without that component [the library] itself accompan[ying] the executable. Some possible ways to draw that line might be: - as long as the executable only uses bog standard functions from the library (eg, ANSI C standard functions, but not GNU extensions) it's okay - as long as the lib is priority: standard or higher, and the executable is optional or extra, it's ok - as long as the lib is in main, and the executable isn't in main, it's ok - as long as the lib and the executable is in different .debs, it's ok - that clause doesn't hold any meaning or validity at all anymore, so it's ok in all circumstances, as long as the library is in main I would expect the first interpretation there isn't actually useful, but all the others that I can come up with would not only allow GPLv2 apps to use an LGPLv3 glibc, it'd also allow them to link to a CDDL'ed libc (OpenSolaris), a GPLv3'ed libgnutls, or OpenSSL... If we can avoid the accompanying the executable clause in some way as Nexenta have done, with the FSF's apparent blessing, and interpret normally distributed with the major components of the operating system to cover everything in main, that means we can use the system library exemption in the GPLv2 to link GPLv2 software to _any_ DFSG-free library. [0] For GPLv3, the same argument is easier, in that the accompanying the executable clause disappears, but also harder because the other text changes a bit. We'd need for the random non-GPLv3 compatible library to be a System Library as defined by: ] The System Libraries of an executable work include anything, other than ] the work as a whole, that (a) is included in the normal form of packaging ] a Major Component, but which is not part of that Major Component, and (b) ] serves only to enable use of the work with that Major Component, or to ] implement a Standard Interface for which an implementation is available ] to the public in source code form. A Major Component, in this context, ] means a major essential component (kernel, window system, and so on) of ] the specific operating system (if any) on which the executable work runs, ] or a compiler used to produce the work, or an object code interpreter ] used to run it. So for libssl to be covered in the System Libraries of a GPLv3ed executable work, it needs to: 1) be other than the work as a whole 2) be included in the nromal form of packaging a Major Component 3) not be that Major Component 4a) serve only to enable use of the work with that Major Component; or 4b) implement a Standard Interface for which there is an open source implementation If we define it as openssl.h, and the Major Component as libssl, then (1), (2), (3), and (4b) seem satisfied to me, with (4a) satisfied as well, unless I'm misunderstanding that subclause. For libssl to be a Major Component, then libssl has to be: 1a) as major and essential a component of Debian as a window system; or 1b) a compiler used to produce the work; or 1c) an object code interpreter used to run the work (1b) and (1c) aren't satisfied, but (1a) is, afaics -- libssl is far more major and essential than X on Debian, afaics. I would expect (1a) to be satisfied for a lot of significant libraries in Debian, such as anything of standard priority or higher, but not all libraries in optional or extra. Cheers, aj [0] That would only work for us because we're making a universal operating system. It would be difficult to make quite the same argument for Ubuntu, because libraries in universe are distributed separately from the major components of the operating system (ie, Ubuntu's main component). signature.asc Description: Digital signature
Re: LGPL v3 compatibilty
On Sun, 1 Jul 2007 13:58:08 +0200 Andreas Metzler wrote: [...] LGPLv3 libraries could not be used in GPLv2-only programs. I'm afraid that this incompatibility is still true. AFAIUI, when you redistribute a GPLv2-only program in compiled form, the GPLv2 insists that the libraries the program links with (excluding system libraries...) are available under GPLv2. But an LGPLv3-only or LGPLv3-or-later library is available under GPLv3, not under GPLv2. All this, assuming that the FSF's legal theory of linking is correct: this theory has never been tested in court, AFAIK, hence we do not know if it would hold. However, we have to assume that it's correct, to be on the safe side. Disclaimers: IANAL, TINLA, IANADD. -- http://frx.netsons.org/doc/nanodocs/testing_workstation_install.html Need to read a Debian testing installation walk-through? . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpYa8B9f4EUU.pgp Description: PGP signature
