Re: Bacula and OpenSSL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 RE: The FSF position regarding OpenSSL as a system library in Debian. > === > > We do not believe that OpenSSL qualifies as a System Library in Debian. > The System Library definition is meant to be read narrowly, including > only code that accompanies genuinely fundamental components of the > system. I don't see anything to suggest that that's the case for > OpenSSL in Debian: the package only has important priority (as opposed > to glibc's required), there are only about 350 packages depending on it > (as opposed to glibc's 8500), and it isn't installed on a base system. > To put it plainly, if OpenSSL actually were a System Library, I would > expect it to look more like one. > > -- Brett Smith Licensing Compliance Engineer, Free Software Foundation > > === Steve, Kern and Anthony all made comments regarding the statement above. I just wanted to let you know that I've forwarded these comments to Brett Smith. :) Best regards Shane - -- Shane Coughlan FTF Coordinator Free Software Foundation Europe Office: +41435000366 ext 408 / Mobile: +41792633406 [EMAIL PROTECTED] Support Free Software > http://fsfe.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iQCVAwUBRqWzwdGa7CzA5hXyAQJqEwQApMLgHexbnbETjga1Vj3MJN8qMHnWX3uw mpo/8O73LHoBSgUTll+G9pidyy+xe8o39F7l3m4QbmN5u5IN6XcHI1nwynMyVcT1 FKL9cMf7woDYxBhKQv9kUK29Hq73SiFF5DMd2yPm0pO1tNHrS/XBvzeYetgB6YSm VuPARJ+FuC4= =Xk30 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear all Following comments on FSF's position regarding OpenSSL as a System Library in Debian, Brett Smith at FSF sent the following message: === I apologize for my misunderstandings about OpenSSL's status in Debian, and appreciate the corrections. However, even given all this information, I still don't see how OpenSSL meets part (a) of the System Library definition. What is the Major Component that OpenSSL accompanies? Kernels always come with C libraries, and GCC always comes with libgcc. What package comes with OpenSSL? I understand that there are some pretty important applications that require OpenSSL, such as apt, but that's not the same thing as accompanying apt. Moreover, "pretty important" isn't the same thing as "essential" in the very narrow sense the license aims to define it in. === I hope this helps clarify things. :) Regards Shane - -- Shane Coughlan FTF Coordinator Free Software Foundation Europe Office: +41435000366 ext 408 / Mobile: +41792633406 [EMAIL PROTECTED] Support Free Software > http://fsfe.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iQCVAwUBRqYWZdGa7CzA5hXyAQJm9wP/eHCZAkZFQNR1+aliIzJqQ8o4CA2CMU87 MQ98NQubX/fd0Cai34Ue9hu4m8nqS2Eo0zbw9+1TYpHZ29N6HvQW5IwAv32FkBPI ah/aLgmjnlFlcBJAjTfQo2jswHyxUwmRI0CFnAK8J6E1AB2sriBceHgGZdrVs770 ux0SMFlnsqk= =kl+r -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
Shane M. Coughlan writes: > Dear all > > Following comments on FSF's position regarding OpenSSL as a System > Library in Debian, Brett Smith at FSF sent the following message: > > === > > I apologize for my misunderstandings about OpenSSL's status in Debian, > and appreciate the corrections. However, even given all this > information, I still don't see how OpenSSL meets part (a) of the System > Library definition. What is the Major Component that OpenSSL > accompanies? Kernels always come with C libraries, and GCC always comes > with libgcc. What package comes with OpenSSL? I understand that there > are some pretty important applications that require OpenSSL, such as > apt, but that's not the same thing as accompanying apt. Moreover, > "pretty important" isn't the same thing as "essential" in the very > narrow sense the license aims to define it in. > > === > > I hope this helps clarify things. :) I (as neither Debian Developer nor lawyer) think it makes things more arbitrary, in particular the distinction between "come with" and "require". Which kernels come with C libraries in a different sense than they come with a large set of other binaries? When I download the Linux kernel, it does not include any C library; when I download or update the various free BSDs, they include the kernel, a C library, all of gcc, and a variety of other GPLed works that are not System Libraries. On the other hand, libgcc is distributed (by the FSF) with the rest of GCC -- but is that not because it is part of GCC? To pick an example, libgcc includes crtstuff.c from the main gcc directory. The copyright comment at the start of that file says "This file is part of GCC." The libgcc directory includes a variety of linker scripts and build directives, but no separate source code. Distributors usually sever libgcc from the gcc binary, so that libgcc is distributed separately from the packages containing the gcc compilers. (Also: If, for a modern packaging system, a compiler is "essential" but the packaging system is not, the FSF needs to have its head re-examined.) Michael Poole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
On Tuesday 24 July 2007 10:09, Shane M. Coughlan wrote: > RE: The FSF position regarding OpenSSL as a system library in Debian. > > > === > > > > We do not believe that OpenSSL qualifies as a System Library in Debian. > > The System Library definition is meant to be read narrowly, including > > only code that accompanies genuinely fundamental components of the > > system. I don't see anything to suggest that that's the case for > > OpenSSL in Debian: the package only has important priority (as opposed > > to glibc's required), there are only about 350 packages depending on it > > (as opposed to glibc's 8500), and it isn't installed on a base system. > > To put it plainly, if OpenSSL actually were a System Library, I would > > expect it to look more like one. > > > > -- Brett Smith Licensing Compliance Engineer, Free Software Foundation > > > > === > > Steve, Kern and Anthony all made comments regarding the statement above. > I just wanted to let you know that I've forwarded these comments to > Brett Smith. :) OK, thanks. Concerning Brett's most recent answer: I have to agree that OpenSSL is not a System Library in the very strict sense of the word. Regards, Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
License and copyright in generated code from wsdl2h in gsoap package
I recently started looking at gsoap package for potential use and noticed that wsdl2h tool in this package places following in the header of generated C code: /* junk.h deleted... Copyright (C) 2001-2005 Robert van Engelen, Genivia Inc. All Rights Reserved. This part of the software is released under one of the following licenses: GPL or Genivia's license for commercial use. */ So the generated code not only automatically gets placed under GPL, it also gets its copyright assigned to someone else. This makes me uncomfortable that I not only do not get to control the license for software I will be creating, but also I give the copyright up to someone else. This to me will be similar to gcc insisting that any assembly code generated using gcc be under GPL and copyright assigned to someone other than me. What do others think? -- Khalid === [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: License and copyright in generated code from wsdl2h in gsoap package
Khalid Aziz wrote: > So the generated code not only automatically gets placed under GPL, it > also gets its copyright assigned to someone else. In many jurisdictions, an assignment of copyright requires a piece of paper signed by the copyright holder (and usually by the recipient as well). The piece of paper can often be replaced by a digitally signed electronic document, but I do not believe for one second that such an automatically generated notice qualifies as an assignment document. I don't know this tool at all. Does it only transform your input into code, or is some code written by this Robert van Engelen also inserted? For example, startup code or some standard library? If there's code by Van Engelen, he can set whateverlicense he wants on this code. If that license is GPL, that means any combination of that code with your work can only be distributed under the GPL as well. This is indeed similar to gcc, which adds code from libgcc (or libstdc++) to your program. But gcc has an exception that permits you to use whatever license you want to the output. http://www.mingw.org/MinGWiki/index.php/SharedLibgccLegal 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: License and copyright in generated code from wsdl2h in gsoap package
On Tue, 2007-07-24 at 21:03 +0200, Arnoud Engelfriet wrote: > Khalid Aziz wrote: > > So the generated code not only automatically gets placed under GPL, it > > also gets its copyright assigned to someone else. > I don't know this tool at all. Does it only transform your input > into code, or is some code written by this Robert van Engelen also > inserted? For example, startup code or some standard library? This tool generates C code from XML file. So in a way, this tool is generating all of the code in its output which can be considered to have been written by Robert van Engelen since he wrote the tool. > This is indeed similar to gcc, which adds code from libgcc (or > libstdc++) to your program. But gcc has an exception that permits > you to use whatever license you want to the output. > http://www.mingw.org/MinGWiki/index.php/SharedLibgccLegal This refers to linking one's final binary with gcc libraries and the startup code. If one were to use gcc to generate assembly code from C code without linking it with libgcc or libstdc++, gcc does not require the resulting assembly language code to be licensed under GPL. -- Khalid === [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
On Tue, Jul 24, 2007 at 05:10:32PM +0200, Shane M. Coughlan wrote: > Following comments on FSF's position regarding OpenSSL as a System > Library in Debian, Brett Smith at FSF sent the following message: > > === > I apologize for my misunderstandings about OpenSSL's status in Debian, > and appreciate the corrections. However, even given all this > information, I still don't see how OpenSSL meets part (a) of the System > Library definition. What is the Major Component that OpenSSL > accompanies? Kernels always come with C libraries, [...] I don't think it's accurate to say that glibc is any more tightly bound to the Linux kernel than OpenSSL is -- you can certainly use different libc implementations to access the kernel, just as you could use different SSL implementations such as gnutls. In particular, going by the GPLv3: ] 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. then libc can't treat the kernel as its Major Component because it's not "included in the normal form of packaging [that] Major Component". That's somewhat fundamental technically, in so far as the kernel provides the hardware abstraction to a fairly static userspace/kernel ABI, and libc provides an implementation of the C (or POSIX or GNU) API based on the kernel's ABI. Up to that point you can just call it "enabling use of the kernel (by people who can only speak C and POSIX)", but the problem then comes if, say, you choose to implement some C or POSIX API (such as POSIX threads) entirely in userspace rather than using the kernel's features, and to take things a step further, perhaps decide to package that separately. Your cases are then: - libc implements pthreads as a thin layer over the kernel - libc implements pthreads in userspace, with all pthreads looking like a single thread/process to the kernel - libpthreads implements pthreads in userspace, with all pthreads looking like a single thread/process to the kernel, with libpthreads being a standard component of the operating system - libpthreads implements pthreads in userspace, with all pthreads looking like a single thread/process to the kernel, with libpthreads being a optional and rarely installed component of the operating system - libpkthreads implements pthreads as a thin layer over the kernel threads, but is an experimental implementation looking to replace libpthreads, that's optional and (currently) rarely installed To me, the most natural line to draw when considering whether the pthreads implementation is a system library in the above is between the two libpthreads -- in the first three cases, how it's implemented is irrelevant, it's a standard library, implementing a standard API, that doesn't contaminate the GPLed software any more or less in any case, and is available to everyone who's going to use the GPLed software on the operating system in question. For the latter two cases, there's no reason to consider the pthreads implementations particularly important parts of the operating system, so they shouldn't be considered system libraries no matter how thin or heavy-weight they are compared to the kernel. If you're arguing that libc is only relevant in that it provides access to the kernel, I think you end up with the wrong answer in a few levels: - libc doesn't provide access to the kernel; it uses the kernel to provide a C API; printf() isn't a kernel call, eg, it's something native to libc - the clause becomes implementation dependent: if you implement something in the kernel, and provide it via libc it's can be used by GPLv3 programs, but if you implement it in libc, it's only accessible if it's an "official standard" - it becomes packaging dependent: if you implement an official standard in libc, that's okay, but if you implement it in a package of its own, that's not To take a more direct situation: under that interpretation, if you take glibc, implement a new, non-standard feature along the lines of obstacks, say, in glibc -- perhaps a rewrite of talloc -- and only make your new version of glibc available under the GPLv2. Then, even if that's included as a standard part of all Debian or Hurd or OpenSolaris installs, it's no longer possible to compile GPLv3 apps against that library, because the argument becomes: myglibc (prospective System Library) is included in the normal form of packaging the kernel (a Major Component), but is not part of t
