Re: License concerns regarding package lft
Terry Hancock [EMAIL PROTECTED] wrote: [...] A court is going to consider what the apparent intent was -- not try to stretch the meaning beyond the obvious. Intent is not written on the paper. It seemed obvious to me that this clause hinders binaries. It seemed obvious to Florian Weimer that it rules out private changes. So, I don't think it's obvious what the intent was. [...] You can do that, because the license is POORLY WRITTEN. Which I have already said. Miraculously, you and I appear to AGREE on that point. One consequence of this is that some lawyer might try to play the same games with the language that you are doing here. In other words, this is an obvious lawyerbomb and we need further data. [...] I'm trying to understand how it is possible to claim that compilers don't fit the meaning of materials there That would be by using the *normal*, *first* definition of materials and not some alternate meaning that has come about by association. Normal? First? Those imaginary English Language Meaning Norms don't exist. On the shelf behind me, I have ten dictionaries, and there's more in the office across the landing and in my living room at home. It doesn't matter whether one can support a view with a dictionary - I've made that mistake in the past. Is it ambiguous? Yes. Is it clarified by licensor statements or case law? I haven't found any. There is also the point that it wouldn't make any sense to require the meaning you are attempting to press: is there even a compiler which can be released in source format under conditions of this license? If not, then it stands to reason that the author, knowing this, cannot have intended to limit compilation to such a hypothetical compiler. [...] It wouldn't be the first source-only-distribution licence I've seen, or the first licence to rely on US-style Fair Use. [...] Intent is a matter of pragmatics[1] -- the study of situated utterances as evidence for meaning, not semantics[2] -- the study of isolated utterances for potential meaning. [...] I repeat my pragmatic questions ignored so far: can we tell how this is interpreted by the licensor? Can we claim binaries are GPL by clause 6 or does the 'no permission is granted...' style of clause 7 overrule it? Any more comments? Please stop getting so personal and flamey. 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]
Bacula: GPL and OpenSSL
Hi legal folks, Kern Sibbald, author of Bacula, contacted me today regarding its license. Some years ago, Jose Luis Tallon -- then the maintainer of Bacula -- asked Kern to add a clause to the Bacula license that would explicitly permit linking with OpenSSL. Kern did. Kern also subsequently assigned copyright to FSF Europe (FSFE). Recently, Fedora developers noticed that there were a few files in the Bacula source tree that were not copyrighted by Kern or FSFE. Since Kern did not have written permission from these developers to relicense Bacula with the OpenSSL exemption, Fedora believed the license as written was problematic. Kern approached me about this situation (see full correspondence below, forwarded with his permission). He added that Bacula does not statically link with OpenSSL, that OpenSSL support can be disabled at build time, and that FSFE does not believe that an exception clause to the GPL is necessary to legally link to OpenSSL in the manner that Bacula is (dynamic linking). Further, could we not consider OpenSSL to be a major component of the OS on which the executable runs, and thus fall under that exemption in the GPL anyway? I have not been able to pull up a succinct statement of why Debian believes this is a problem when FSFE doesn't, or what we ought to do. Can somebody please comment on the OpenSSL linking issue when OpenSSL is only dynamically linked? Kern believes that he must remove the explicit OpenSSL exemption from the license in order to be fully GPL-compliant, and it appears that FSFE agrees. Thanks, -- John - Forwarded message from Kern Sibbald [EMAIL PROTECTED] - From: Kern Sibbald [EMAIL PROTECTED] Date: Thu, 7 Jun 2007 16:05:37 +0200 To: John Goerzen [EMAIL PROTECTED] Subject: Bacula license Hello John, I hope things are going well for you. There is an interesting issue that has come up with the Bacula license mainly because of a request by Debian for me to add a specific clause that reads: Linking: Bacula may be linked with any libraries permitted under the GPL, or with any non-GPLed libraries, including OpenSSL, that are required for its proper functioning, providing the source code of those non-GPLed libraries is non-proprietary and freely available to the public. Now, this was added because Debian asked me to add it because of the fact that Bacula uses OpenSSL. However, in researching the issue a bit further, I realize that Bacula does not link OpenSSL into the Bacula binary because the OpenSSL (like glibc) is a shared object. Thus, no non-GPLed code is being mixed with GPLed code, and hence there is no need for the above clause. My question to you is: will there be any problems with Bacula in the Debian distribution if I remove this clause and make the Bacula code simply pure GPL v2? Best regards, Kern PS: Here is an email that I sent to the Bacula list a while ago, that explains in more detail the licensing problem. == FYI An annoying GPL catch-22 concerning Bacula Date: Today 11:38:01 From: Kern Sibbald [EMAIL PROTECTED] To: bacula-users [EMAIL PROTECTED] CC: bacula-devel [EMAIL PROTECTED] Hello, For non-English speakers, a catch-22 in English means a situation in which there is no way out. The following annoying and frustrating issue has come up with regard to the Bacula source code: As you probably know, Bacula is released with a modified GNU GPL licence. The Bacula license modifies the GPL to permit Bacula to link to OpenSSL. This was necessary because using MySQL libraries requires OpenSSL. This modification was suggested by Debian to bring Bacula in compliance with their procedures. The problem comes from including pure GNU GPL code, which is not compatible with the OpenSSL license, inside Bacula itself (there are something like 8 such files). This works in the same way that Debian would not allow Bacula as pure GNU GPL to link with OpenSSL. If Bacula uses any pure GNU GPL code then that code cannot be subject to the GNU GPL modifications, and that code technically cannot linked and distributed with Bacula because of OpenSSL. I suspect that a lot of GPL projects are in a similar situation, but they do not explicitly point out the exception as Bacula does. The real bummer here is that this issue was flagged by someone involved in the Fedora packaging process. From what I understand (I may be wrong here), Fedora and hence Red Hat will not use Bacula because it uses some pure GPL code and OpenSSL together raising potential license problems -- after the problems with SCO and threats from Microsoft, their license concerns are quite understandable. This is not a show-stopping issue because at least for the moment, no author of pure GNU GPL code is lodging a complaint. In addition as I mentioned in a previous email, this issue could potentially be resolved by GPL v3 (due at the end of the month, if I remember right) because it is compatible
Re: Bacula: GPL and OpenSSL
John Goerzen writes: Kern approached me about this situation (see full correspondence below, forwarded with his permission). He added that Bacula does not statically link with OpenSSL, that OpenSSL support can be disabled at build time, and that FSFE does not believe that an exception clause to the GPL is necessary to legally link to OpenSSL in the manner that Bacula is (dynamic linking). Further, could we not consider OpenSSL to be a major component of the OS on which the executable runs, and thus fall under that exemption in the GPL anyway? I have not been able to pull up a succinct statement of why Debian believes this is a problem when FSFE doesn't, or what we ought to do. Can somebody please comment on the OpenSSL linking issue when OpenSSL is only dynamically linked? Debian generally distributes OpenSSL logically near the packages that dynamically link against it, so the major system component option is not available to Debian (... unless that component itself accompanies the executable). GPL section 3(a) also uses accompany in a way that Debian and others interpret to include distribution in the same directory tree on a particular server, so -- the usual line of reasoning goes -- it would be inconsistent to interpret accompany one way at the start of section 3 and a different way at the end of section 3. Michael Poole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula: GPL and OpenSSL
John Goerzen [EMAIL PROTECTED] wrote: Kern believes that he must remove the explicit OpenSSL exemption from the license in order to be fully GPL-compliant, and it appears that FSFE agrees. I just read the contents of /usr/share/doc/bacula-director-sqlite/copyright I have reproduced it below for debian-legal. The Linking section, which is needed for linking with OpenSSL, is not a problem for GPL-compatibility. The other parts may or may not be a problem, and indeed seem superfluous, but all that is needed is the Linking section. Cheers, Walter Landry [EMAIL PROTECTED] This package was debianized by Jose Luis Tallon [EMAIL PROTECTED] on Sun, 19 Oct 2003 14:36:45 +0200 and is now maintained by John Goerzen [EMAIL PROTECTED]. It was downloaded from http://www.bacula.org Upstream Authors: Kern Sibbald [EMAIL PROTECTED] and John Walker. Trademark: The name Bacula is a registered trademark. === License: For the most part, Bacula is licensed under the GPL version 2 and any code that is Copyright Kern Sibbald and John Walker or Copyright Kern Sibbald (after November 2004) with the GPL indication is so licensed, but with the following four additions: Linking: Bacula may be linked with any libraries permitted under the GPL, or with any non-GPLed libraries, including OpenSSL, that are required for its proper functioning, providing the source code of those non-GPLed libraries is non-proprietary and freely available to the public. IP rights: Recipient understands that although each Contributor grants the licenses to its Contributions set forth herein, no assurances are provided by any Contributor that the Program does not infringe the patent or other intellectual property rights of any other entity. Each Contributor disclaims any liability to Recipient for claims brought by any other entity based on infringement of intellectual property rights or otherwise. As a condition to exercising the rights and licenses granted hereunder, each Recipient hereby assumes sole responsibility to secure any other intellectual property rights needed, if any. For example, if a third party patent license is required to allow Recipient to distribute the Program, it is Recipient's responsibility to acquire that license before distributing the Program. Copyrights: Each Contributor represents that to its knowledge it has sufficient copyright rights in its Contribution, if any, to grant the copyright license set forth in this Agreement. Code falling under the above conditions will be marked as follows: Copyright (C) 2000-2006 Kern Sibbald This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License version 2 as amended with additional clauses defined in the file LICENSE in the main source directory. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the the file LICENSE for additional details. Windows: Certain source code used to build the Windows version of the Bacula File daemon is copyrighted and or trademarked by Microsoft and may contain Microsoft intellectual property (examples: Microsoft VC++, the source to the VSS libraries, the Microsoft C runtime libraries). As such we cannot and do not distribute that software. We are permitted however to distribute Bacula in binary form with the necessary Microsoft libraries linked in. You may obtain the parts that we cannot distribute as follows. The Microsoft compiler available for purchase, and Microsoft provides a free version of the compiler. The source code and libraries are available for download from Microsoft public Web servers. We have documented in the src/win32 directory the URLs from which we obtained the library source, and how we build the Windows File daemon and many users have succeeded in doing so themselves. Our intention is to respect as closely as possible Open Source practices while maintaining full respect for proprietary and copyrighted code. On Debian systems, the complete text of the GNU General Public License and the GNU Lesser General Public License can be found in /usr/share/common-licenses/.
Re: Bacula: GPL and OpenSSL
On Thu, Jun 07, 2007 at 10:50:39AM -0700, Walter Landry wrote: John Goerzen [EMAIL PROTECTED] wrote: Kern believes that he must remove the explicit OpenSSL exemption from the license in order to be fully GPL-compliant, and it appears that FSFE agrees. I just read the contents of /usr/share/doc/bacula-director-sqlite/copyright I have reproduced it below for debian-legal. The Linking section, which is needed for linking with OpenSSL, is not a problem for GPL-compatibility. The other parts may or may not be a problem, and indeed seem superfluous, but all that is needed is the Linking section. But the problem is that parts of Bacula's code are copyrighted by third parties, and licensed under plain GPL (or Kern's license before he added this exception), and may be unreachable for obtaining permission to relicense with this exception. (Kern, have you tried contacting them?) So the question really is: how can we have Bacula in Debian, with SSL support, but without that clause? And why does FSFE disagree with our interpretation? -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
In message [EMAIL PROTECTED], Wesley J. Landaker [EMAIL PROTECTED] writes On Sunday 03 June 2007 14:46:12 Anthony W. Youngman wrote: In message [EMAIL PROTECTED], Wouter Verhelst [EMAIL PROTECTED] writes That's wishful thinking, at best. Common knowledge defines fee as something involving the transfer of money. If it isn't, then the GPL is also non-free, by the very same rationale: the fact that you are required to produce source when so asked if you do distribute binaries from source under the GPL means that you are giving up a right (the right not to distribute any source) which you might otherwise have, which could be considered to be a fee. And what about societies without money? fee does NOT equal money. Your common knowledge is not my understanding ... Okay, now I'm really curious. Exactly which societies without money are you talking about? There's groups of friends who do each other favours. There's people who are so poor they have to barter - you're aware, of course, that in Eastern Europe that was quite normal - cash was worthless. Even between businesses and governments - there was a thriving barter market worth millions of pounds without any money changing hands at all... There's plenty of societies where I live (England) who have a system (yes I know it's like money) where you earn points and trade them. And one only has to look close to home at the world of Free Software, where code and respect are the items of currency, not money :-) Cheers, Wol -- Anthony W. Youngman - [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
In message [EMAIL PROTECTED], Steve Langasek [EMAIL PROTECTED] writes On Sun, Jun 03, 2007 at 09:33:12PM +0100, Anthony W. Youngman wrote: I'm in the UK, and if I wasn't but the choice of venue specified England and Wales, I'd probably have a very nice holiday at the copyright holder's expense :-) Look at SCOG and how they got dealt with in Germany ... What license did SCOG have that specified Germany as a choice of venue? They didn't. But they made loads of noise about how linux infringed their copyrights. One complaint to a court by an infuriated linux developer, and one injunction and fine later, they shut up shop. I think that took less than six months. Look at where we are now in the US - four or five years later and still going strong ... Cheers, Wol -- Anthony W. Youngman - [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
Anthony W. Youngman writes: In message [EMAIL PROTECTED], Steve Langasek [EMAIL PROTECTED] writes On Sun, Jun 03, 2007 at 09:33:12PM +0100, Anthony W. Youngman wrote: I'm in the UK, and if I wasn't but the choice of venue specified England and Wales, I'd probably have a very nice holiday at the copyright holder's expense :-) Look at SCOG and how they got dealt with in Germany ... What license did SCOG have that specified Germany as a choice of venue? They didn't. But they made loads of noise about how linux infringed their copyrights. One complaint to a court by an infuriated linux developer, and one injunction and fine later, they shut up shop. I think that took less than six months. Look at where we are now in the US - four or five years later and still going strong ... There are several points that can be made here: (1) If I recall correctly, SCO's speaker was from the US and probably did not get advice from German legal counsel on what to say. Such an injunction is almost impossible to get in the US due to differences in free speech laws. Copyright laws tend to be more uniform thanks to the Berne Convention and UCC. Because SCO's questionable behavior in Germany was commercial speech rather than anything related to copyright, the contrasts or similarities may not give that much insight into how free software licenses should work. (2) This is an example of how normal rules on venue can reach results preferable to those under unilaterally selected or convenient venue (since SCO would love to have all its lawsuits venued in Utah). Michael Poole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request for suggestions of DFSG-free documentation licences
On 05/06/07, MJ Ray [EMAIL PROTECTED] wrote: Small excerpts (e.g. an Emacs reference card from the Emacs info docs) are probably covered under Fair Use. [...] This is England calling. Would the FSF have to sue under US law or UK law an offender in the UK? I'm genuinely ignorant about this issue. poison pill invariant sections Huh? Poison pill? and inability to fix some sections. What do you want to fix? The reasons for why free software needs free documentation or would you like to fix the suggestions on how to give funds to the FSF? You think you know better than the FSF what funds the FSF needs? Since invariant sections can't be about technical matters, I really fail to see what non-technical aspects could possibly need to be fixed. [...] Debian really is the odd distro out here by considering GFDL docs non-free. Not even RMS or the FSF calls the FDL a Free Software licence. Of course the FSF doesn't consider the GFDL a free software licence. That's why it recommends releasing any substantial amount of code from a GFDLed doc under the GPL. I wouldn't call the GFDL a free software licence; it isn't a software licence at all. But it's Debian who insists on calling Wikipedia a software distributor (and I'm not referring to Wikimedia, I'm referring to Wikipedia's content). Since Debian wants to call every bitstream software, then it feels like it can apply the DFSG to every bitstream. Software simply doesn't need the same freedoms as documentation, but Debian disagrees. Perhaps it wants to modify the results of the MOTIVATION article in the Emacs distribution in hopes of altering reality by altering the findings of the article (yes, I'm trolling, sorry, but the whole GFDL thing and Debian really gets my knickers in a twist). non-free-software aspects of FDL and was just yanking our chain. Debian calling the GFDL non-free reminds me so much of the BSD zealots calling the GPL non-free. This really is the stuff of flamewars (such as this one). - Jordi G. H. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula: GPL and OpenSSL
On Thu, Jun 07, 2007 at 12:17:28PM -0700, Walter Landry wrote: GnuTLS + libgcrypt + libtasn1 implements everything unless you need ECC. And why does FSFE disagree with our interpretation? Michael Poole gave a good answer. He didn't address the FSFE -- where are they taking a different analysis than us on this? Kern, is it possible to remove the OpenSSL exception from the license of only those third-party sources, and keep it in the master license? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula: GPL and OpenSSL
On Thursday 07 June 2007 19:00, Michael Poole wrote: John Goerzen writes: Kern approached me about this situation (see full correspondence below, forwarded with his permission). He added that Bacula does not statically link with OpenSSL, that OpenSSL support can be disabled at build time, and that FSFE does not believe that an exception clause to the GPL is necessary to legally link to OpenSSL in the manner that Bacula is (dynamic linking). Further, could we not consider OpenSSL to be a major component of the OS on which the executable runs, and thus fall under that exemption in the GPL anyway? I have not been able to pull up a succinct statement of why Debian believes this is a problem when FSFE doesn't, or what we ought to do. Can somebody please comment on the OpenSSL linking issue when OpenSSL is only dynamically linked? Debian generally distributes OpenSSL logically near the packages that dynamically link against it, so the major system component option is not available to Debian (... unless that component itself accompanies the executable). GPL section 3(a) also uses accompany in a way that Debian and others interpret to include distribution in the same directory tree on a particular server, so -- the usual line of reasoning goes -- it would be inconsistent to interpret accompany one way at the start of section 3 and a different way at the end of section 3. Well, the above is total Greek to me. However, I must say that there is absolutely no reason why Bacula would every accompany OpenSSL in any sense of the the English meaning of accompany that I am aware of, nor is Bacula in the same directory tree as any OpenSSL shared object unless you consider everything is under root thus everything on the server is in the same directory tree. By the way, just to be clear, I consider all this (not you guys but these license difficulties) to be a real pain. As long as the code is Open Source (i.e. I can get it, see it and modify it), I have no problem with it being linked with Bacula. I modified the Bacula GPL license at Debian's request to remove the issue you find with OpenSSL, however, that created a much bigger problem for me -- it made Bacula in violation of other peoples GPLed code that is used in Bacula. As a consequence, I removed all Bacula modifications to the GPL making Bacula clean -- it violates no one's license. Each person, distributor, packager can decide for himself whether or not to enable Bacula to use encryption. At the current time if encryption is turned on, Bacula expects an OpenSSL interface. I much appreciate that Debian has for a long time packaged Bacula as part of the Debian system. If it were only a simple matter of keeping that clause rather than a question of violating other people's copyright, I would keep the clause despite what Fedora/Red Hat think/want. So, sorry if this causes you problems, but I prefer to be in compliance. Best regards, Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
In message [EMAIL PROTECTED], Michael Poole [EMAIL PROTECTED] writes Anthony W. Youngman writes: In message [EMAIL PROTECTED], Steve Langasek [EMAIL PROTECTED] writes On Sun, Jun 03, 2007 at 09:33:12PM +0100, Anthony W. Youngman wrote: I'm in the UK, and if I wasn't but the choice of venue specified England and Wales, I'd probably have a very nice holiday at the copyright holder's expense :-) Look at SCOG and how they got dealt with in Germany ... What license did SCOG have that specified Germany as a choice of venue? They didn't. But they made loads of noise about how linux infringed their copyrights. One complaint to a court by an infuriated linux developer, and one injunction and fine later, they shut up shop. I think that took less than six months. Look at where we are now in the US - four or five years later and still going strong ... There are several points that can be made here: (1) If I recall correctly, SCO's speaker was from the US and probably did not get advice from German legal counsel on what to say. Such an injunction is almost impossible to get in the US due to differences in free speech laws. Copyright laws tend to be more uniform thanks to the Berne Convention and UCC. Because SCO's questionable behavior in Germany was commercial speech rather than anything related to copyright, the contrasts or similarities may not give that much insight into how free software licenses should work. iirc, you recall wrong. This was stuff posted on the www.sco.de website, iirc. (2) This is an example of how normal rules on venue can reach results preferable to those under unilaterally selected or convenient venue (since SCO would love to have all its lawsuits venued in Utah). And why, under English law, it is pretty automatic for a private defendant to have the right to choose venue ... Cheers, Wol -- Anthony W. Youngman - [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula: GPL and OpenSSL
On Thursday 07 June 2007 19:50, Walter Landry wrote: John Goerzen [EMAIL PROTECTED] wrote: Kern believes that he must remove the explicit OpenSSL exemption from the license in order to be fully GPL-compliant, and it appears that FSFE agrees. I just read the contents of /usr/share/doc/bacula-director-sqlite/copyright I have reproduced it below for debian-legal. The Linking section, which is needed for linking with OpenSSL, is not a problem for GPL-compatibility. The other parts may or may not be a problem, and indeed seem superfluous, but all that is needed is the Linking section. What you included is the old LICENSE, which unfortunately violated other people's copyrights due to the linking clause. The other modifications were not causing any problem. However, I have now removed *all* modifications, so that the current Bacula code as of a few hours ago has no modifications to GPL v2. I am attaching a copy of the current LICENSE file as it is at this moment in the SVN Best regards, Kern History: The original Bacula code was Copyright Kern Sibbald and John Walker. After November 2004, it became Copyright Kern Sibbald, and finally, the copyright was transferred to the Free Software Foundation Europe on 15 November 2006. Trademark: The name Bacula is a registered trademark. === License: For the most part, Bacula is licensed under the GPL version 2 this code is listed under Copyright Free Software Foundation Europe e.V. A small part of the code (less than 20 files) is copyrighted under the GPL by other people (FSF, Sun, ...). What follows is information from the authors of the code: Linking: Bacula may be linked with any libraries permitted under the GPL. However, if configured with encryption Bacula does use the OpenSSL libraries which are, unfortunately, not compatible with GPL v2. To the best of our knowledge these libaries are not distributed with Bacula code because they are shared objects, and as such there is no conflict with the GPL according what I (Kern) understand in talking to FSFE. If you take a more severe stance on this issue, and you are going to distribute Bacula, then simply do not use the --with-openssl when building your package, and no use of OpenSSL even through dynamic linking will be included. IP rights: Recipient understands that although each Contributor grants the licenses to its Contributions set forth herein, no assurances are provided by any Contributor that the Program does not infringe the patent or other intellectual property rights of any other entity. Each Contributor disclaims any liability to Recipient for claims brought by any other entity based on infringement of intellectual property rights or otherwise. As a condition to exercising the rights and licenses granted hereunder, each Recipient hereby assumes sole responsibility to secure any other intellectual property rights needed, if any. For example, if a third party patent license is required to allow Recipient to distribute the Program, it is Recipient's responsibility to acquire that license before distributing the Program. Copyrights: Each Contributor represents that to its knowledge it has sufficient copyright rights in its Contribution, if any, to grant the copyright license set forth in this Agreement. Code falling under the above conditions will be marked as follows: Bacula® - The Network Backup Solution Copyright (C) 2000-2006 Free Software Foundation Europe e.V. The main author of Bacula is Kern Sibbald, with contributions from many others, a complete list can be found in the file AUTHORS. This program is Free Software; you can redistribute it and/or modify it under the terms of version two of the GNU General Public License as published by the Free Software Foundation, a copy of which is in the LICENSE file This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. Bacula® is a registered trademark of John Walker. The licensor of Bacula is the Free Software Foundation Europe (FSFE), Fiduciary Program, Sumatrastrasse 25, 8006 ZÌrich, Switzerland, email:[EMAIL PROTECTED] Windows: Certain source code used to build the Windows version of the Bacula File daemon is copyrighted and or trademarked by Microsoft and may contain Microsoft intellectual property (examples: Microsoft VC++, the source to the VSS libraries, the Microsoft C runtime libraries). As such we cannot and do not distribute that software. We are permitted however to distribut Bacula with the necessary Microsoft
Re: Bacula: GPL and OpenSSL
John Goerzen [EMAIL PROTECTED] writes: On Thu, Jun 07, 2007 at 12:17:28PM -0700, Walter Landry wrote: GnuTLS + libgcrypt + libtasn1 implements everything unless you need ECC. And why does FSFE disagree with our interpretation? Michael Poole gave a good answer. He didn't address the FSFE -- where are they taking a different analysis than us on this? I have not seen a specific statement from FSFE on the question, so I do not know and I had preferred not to guess. I suspect that their analysis was more liberal on -- or overlooked -- the angle of Debian as distributor of OpenSSL in accompaniment with GPLed works that are linked against it. Perhaps the FSF's intent for the GPL is to allow a more LGPL-like option with regards to system libraries; that would make sense and I think not sacrifice software freedoms. However, I have not seen a defensible way to construe the actual wording other than the one that classifies Debian's method of distribution as each work accompanied by the other(s). [As a side note, I think that resolving this in favor of allowing works under the plain GPL to dynamically link against OpenSSL would allow the aggregation of binary firmware blobs into a package of the Linux kernel. The lack of source for those blobs would still bar them from main, but it would not be a license issue. This is meant simply as an observation, not a judgment of whether that would be a good or bad result.] I am not a lawyer, but I belive that most lawyers urge clients to err on the side of caution when straying from a strict interpretation of license -- or even when interpreting ambiguous clauses. I try to follow that guide when making suggestions on what a license permits. In this case, the wording is consistent and clear, although in an unfortunate direction, and I would not want to rely on extrinsic evidence[1] about the GPL's meaning if I were in court. [1]- http://en.wikipedia.org/wiki/Parol_evidence_rule Michael Poole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula: GPL and OpenSSL
On Thursday 07 June 2007 20:15, John Goerzen wrote: On Thu, Jun 07, 2007 at 10:50:39AM -0700, Walter Landry wrote: John Goerzen [EMAIL PROTECTED] wrote: Kern believes that he must remove the explicit OpenSSL exemption from the license in order to be fully GPL-compliant, and it appears that FSFE agrees. I just read the contents of /usr/share/doc/bacula-director-sqlite/copyright I have reproduced it below for debian-legal. The Linking section, which is needed for linking with OpenSSL, is not a problem for GPL-compatibility. The other parts may or may not be a problem, and indeed seem superfluous, but all that is needed is the Linking section. But the problem is that parts of Bacula's code are copyrighted by third parties, and licensed under plain GPL (or Kern's license before he added this exception), and may be unreachable for obtaining permission to relicense with this exception. (Kern, have you tried contacting them?) Well, most of the other files are FSF copyrighted, and FSFE told me that FSF always sticks to the letter of the license (logical) so I haven't tried to contact the other users. I could have gone on with the current situation because no one has filed a formal complaint. However, I *much* prefer to be in compliance and not to violate anyone's copyright. So the question really is: how can we have Bacula in Debian, with SSL support, but without that clause? This is apparently possible because GNUTLS seems to have an OpenSSL compatiblity layer. However, this is not something that I can personally look at in the very near future. In addition, over time, I will remove *all* code that is not copyrighted with the Bacula license, but that will probably take even longer to fix. And why does FSFE disagree with our interpretation? I don't know. One possibility is that I misunderstood them. My understanding is that it all has to do with distribution. If one does not distribute GPLed binaries mixed with non-GPLed code and one's distributed binaries use only shared objects that are on the user's system, there is no problem. This is in fact what happens with glibc and many other libraries, which are not *required* to run a system, but are on the system. That is my understanding. In any case, that is how I am going to interprete it until someone threatens me, and if that happens, which I doubt, the project will simply stop releasing binaries that can run with OpenSSL, and hopefully by then everyone will have switchted to GPL v3 where this stupid problem does not exist. I don't imagine that is a solution for Debian though. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula: GPL and OpenSSL
On Thursday 07 June 2007 23:51, John Goerzen wrote: On Thu, Jun 07, 2007 at 12:17:28PM -0700, Walter Landry wrote: GnuTLS + libgcrypt + libtasn1 implements everything unless you need ECC. And why does FSFE disagree with our interpretation? Michael Poole gave a good answer. He didn't address the FSFE -- where are they taking a different analysis than us on this? Kern, is it possible to remove the OpenSSL exception from the license of only those third-party sources, and keep it in the master license? The problem is that those third-party sources are linked into the Bacula binaries, and since they are licensed as GPL with no modifications, I cannot include them in a binary that has code that is licensed in a way that is incompatible with the GPL. Adding the OpenSSL exception to my license makes my code incompatible with the non-modified GPL, and hence I was violating the license on those 3rd party files (copyrighted by FSF, ATT, Sun, and a few others ...). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula: GPL and OpenSSL
Kern Sibbald writes: On Thursday 07 June 2007 19:00, Michael Poole wrote: Debian generally distributes OpenSSL logically near the packages that dynamically link against it, so the major system component option is not available to Debian (... unless that component itself accompanies the executable). GPL section 3(a) also uses accompany in a way that Debian and others interpret to include distribution in the same directory tree on a particular server, so -- the usual line of reasoning goes -- it would be inconsistent to interpret accompany one way at the start of section 3 and a different way at the end of section 3. Well, the above is total Greek to me. However, I must say that there is absolutely no reason why Bacula would every accompany OpenSSL in any sense of the the English meaning of accompany that I am aware of, nor is Bacula in the same directory tree as any OpenSSL shared object unless you consider everything is under root thus everything on the server is in the same directory tree. Bacula and OpenSSL packages are both found on Debian install media and on mirrors. I am not sure how to define accompany in a way that excludes that. In addition, Debian Bacula packages are marked to work with the specific OpenSSL package at the same place (although others are compatible). GPL section 3 provides three options to someone who wishes to distribute executable binary versions of GPLed works: 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.) 3(c) is not available to Debian. 3(b) is prohibitively expensive. That leaves 3(a), with this clarification at the end of section 3: If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code. This seems to say that offering equivalent access to copy [] from the same place is one way to accompany, at least in the sense used by section 3 of the GPL. By the way, just to be clear, I consider all this (not you guys but these license difficulties) to be a real pain. As long as the code is Open Source (i.e. I can get it, see it and modify it), I have no problem with it being linked with Bacula. I think most of the Debian community that has dealt with this shares the sentiment. I certainly do; it has pushed me to make sure that my (small amount of) encryption-using code can use either OpenSSL or GnuTLS's OpenSSL compatibility mode. Michael Poole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request for suggestions of DFSG-free documentation licences
Jordi Gutierrez Hermoso writes: On 05/06/07, MJ Ray [EMAIL PROTECTED] wrote: Small excerpts (e.g. an Emacs reference card from the Emacs info docs) are probably covered under Fair Use. [...] This is England calling. Would the FSF have to sue under US law or UK law an offender in the UK? I'm genuinely ignorant about this issue. The usual rule on personal jurisdiction in civil suits is that a suit must be filed where (a) the defendant(s) reside, (b) where the alleged tort took place or (c) in some place that the parties agreed would have jurisdiction. Neither the GPL nor GFDL have a choice-of-venue clause, so (c) would not apply. If the courts in (a) decline to enforce judgments made by the courts in (b), then for practical reasons a plaintiff would be advised to file in (a). Similarly, the applicable law would be (a) the law of the court hearing the case or (b) a set of law that the parties agreed to use. Neither the GPL nor GFDL have a choice-of-law clause, so (b) does not apply. So, under the usual rules, a prospective plaintiff would have to sue a UK resident in UK courts under UK law. (IANAL, TINLA, and usual rules have seldom stopped sufficiently determined plaintiffs in the past.) poison pill invariant sections Huh? Poison pill? Poison pills are clauses or sections that make it impractical to do certain things. The GFDL's definition of Secondary Section permit a variety of poison pills, as other potential publishers or distributors might see them. and inability to fix some sections. What do you want to fix? The reasons for why free software needs free documentation or would you like to fix the suggestions on how to give funds to the FSF? You think you know better than the FSF what funds the FSF needs? Since invariant sections can't be about technical matters, I really fail to see what non-technical aspects could possibly need to be fixed. Invariant sections could have factual references that are inaccurate or become outdated. The FSF's mailing address is one example of GPL boilerplate that has changed several times; I have no idea if people include that or any similar information in invariant sections. I looked at the Emacs manual[1] to check, but -- contrary to the usage recommendation contained in the FDL itself -- could not find a statement as to whether it contains any invariant sections. [1]- http://www.gnu.org/software/emacs/manual/emacs.html Michael Poole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula: GPL and OpenSSL
In message [EMAIL PROTECTED], John Goerzen [EMAIL PROTECTED] writes On Thu, Jun 07, 2007 at 10:50:39AM -0700, Walter Landry wrote: John Goerzen [EMAIL PROTECTED] wrote: Kern believes that he must remove the explicit OpenSSL exemption from the license in order to be fully GPL-compliant, and it appears that FSFE agrees. I just read the contents of /usr/share/doc/bacula-director-sqlite/copyright I have reproduced it below for debian-legal. The Linking section, which is needed for linking with OpenSSL, is not a problem for GPL-compatibility. The other parts may or may not be a problem, and indeed seem superfluous, but all that is needed is the Linking section. But the problem is that parts of Bacula's code are copyrighted by third parties, and licensed under plain GPL (or Kern's license before he added this exception), and may be unreachable for obtaining permission to relicense with this exception. (Kern, have you tried contacting them?) The Kern's licence thingy isn't a problem. If I, for example, release a load of code under the GPL, and then later say I'm releasing all my code - *including stuff already out there* - under the GPL, the fact that there may be loads of stuff of mine out there saying GPL is irrelevant. Anybody can now either add a copy of my statement about the LGPL to the licencing file, or add a pointer to my statement, and then they can take any of my code that claims to be GPL'd and use it under the LGPL. So if Kern has said that the addition of this extra freedom applies to all his code in Bacula, then anybody can add a copy of this statement to COPYING.TXT and be covered. Cheers, Wol -- Anthony W. Youngman - [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request for suggestions of DFSG-free documentation licences
In message [EMAIL PROTECTED], Jordi Gutierrez Hermoso [EMAIL PROTECTED] writes On 05/06/07, MJ Ray [EMAIL PROTECTED] wrote: Small excerpts (e.g. an Emacs reference card from the Emacs info docs) are probably covered under Fair Use. [...] This is England calling. Would the FSF have to sue under US law or UK law an offender in the UK? I'm genuinely ignorant about this issue. English law. The UK is not England. The UK does *not* *have* a legal system, as legally it is two kingdoms, each with their constitutionally guaranteed separate legal systems (think of it as if the US congress could pass state laws that applied in one or other state, but could not pass laws which applied to the entire US as a whole. Weird, I know, but it's the system we have). The UK (yes I know I said we don't have a legal system) is a signatory to Berne, which merely guarantees that a foreigner has the same rights as the locals. So, as a USian, you can sue in the UK with exactly the same rights as a UK subject would have. Which is why, if as a UKian I want to sue in the US, I have to register my copyright with the Library of Congress just like you have to do. Cheers, Wol -- Anthony W. Youngman - [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula: GPL and OpenSSL
Hi Kern, On Thu, Jun 07, 2007 at 11:53:19PM +0200, Kern Sibbald wrote: Well, the above is total Greek to me. However, I must say that there is absolutely no reason why Bacula would every accompany OpenSSL in any sense of the the English meaning of accompany that I am aware of Bacula doesn't accompany OpenSSL when you distribute it, but they certainly do accompany one another when we distribute them both as part of the Debian OS. This is a plain English meaning of accompany. I have seen various FSF FAQs over the years that have claimed that distributing binaries linked against OpenSSL is ok, but these FAQs have been mute on the matter of distribution as part of an OS. In recent times, it appears that some Unix vendors such as Sun and Apple have also begun distributing GNU software as part of systems whose cores are not licensed compatibly with the GPL, with the FSF's tacit consent; that seems ill-advised to me, but in any case the FSF's interpretations of the GPL aren't binding on other copyright holders where those interpretations don't follow logically from the text of the license. By the way, just to be clear, I consider all this (not you guys but these license difficulties) to be a real pain. As long as the code is Open Source (i.e. I can get it, see it and modify it), I have no problem with it being linked with Bacula. Ah, well, that right there is sufficient for us to use as a license exception grant. :) But of course it's not binding on other copyright holders. So the question really is: how can we have Bacula in Debian, with SSL support, but without that clause? This is apparently possible because GNUTLS seems to have an OpenSSL compatiblity layer. Not much of one, I fear... The problem is that those third-party sources are linked into the Bacula binaries, and since they are licensed as GPL with no modifications, I cannot include them in a binary that has code that is licensed in a way that is incompatible with the GPL. Adding the OpenSSL exception to my license makes my code incompatible with the non-modified GPL, and hence I was violating the license on those 3rd party files (copyrighted by FSF, ATT, Sun, and a few others ...). To be clear here, it's not incompatible with the GPL for you to grant additional linking permissions, which is what is being done. The only real issue is that you can't grant such permission on behalf of other copyright holders. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
New Private Message from Sussan Kamara on TrustedOpinion
Hey Marco-belo, Sussan Kamara just posted a new private message to you on TrustedOpinion. Click below to view your message: http://www.trustedopinion.com/in/tropbox/LoadMessage.do?method=loadMessagemessageId=1247144recipientId=13928 To view Sussan Kamara's profile click here: http://www.trustedopinion.com/in/usr.do?id=77816 (If the link doesn't work just copy and paste it into your browser's address bar) Don't forget to review the latest movies you've seen on TrustedOpinion. TrustedOpinion - Critically Better Recommendations. Period. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ This is an automatically generated email, please do not reply to it. If you wish to opt out of these friendly updates, change your account settings to Don't allow my friends to send me recommendations and messages by email in your profile. Trusted Opinion Inc, 228 Hamilton Avenue, Palo Alto, California 94301. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
