Re: enabling transport and on storage encryption in bacula on debian build
Josselin Mouette writes: > Le dimanche 11 janvier 2009 à 21:25 +0100, Hendrik Weimer a écrit : >> The only >> case I am aware of where another distro refuses to distribute a >> package found in Debian is Fedora's stance on afio. If you know of >> other cases, I would be interested to learn about them. > > There’s also the case of MP3 decoders in Red hat. That's patents rather than copyright. When it comes to patent issues I agree that Debian has a fairly lax (and informal) policy. Hendrik -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: enabling transport and on storage encryption in bacula on debian build
Josselin Mouette writes: > Le dimanche 11 janvier 2009 �Á� 21:25 +0100, Hendrik Weimer a �Á�crit : >> The only >> case I am aware of where another distro refuses to distribute a >> package found in Debian is Fedora's stance on afio. If you know of >> other cases, I would be interested to learn about them. > > There�’s also the case of MP3 decoders in Red hat. And SRP authentication in GnuTLS, unless that changed recently. There is some discussion on this in: http://fedoraproject.org/wiki/ForbiddenItems /Simon -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: enabling transport and on storage encryption in bacula on debian build
Le dimanche 11 janvier 2009 à 21:25 +0100, Hendrik Weimer a écrit : > The only > case I am aware of where another distro refuses to distribute a > package found in Debian is Fedora's stance on afio. If you know of > other cases, I would be interested to learn about them. There’s also the case of MP3 decoders in Red hat. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: enabling transport and on storage encryption in bacula on debian build
MJ Ray writes: > Hendrik Weimer wrote: >> It is a fact that Debian more often rejects packages present in other >> distros than the other way around. Which I believe is a good sign, >> BTW. > > Is that a fact? Where's the evidence? A quick web search didn't find > a good study, but it might exist. I found some evidence that Debian > rejects packages present in Ubuntu, but that's a special case and only > one related distribution. A list of packages that have or had license issues from the top of my head: gnucash (HBCI support), kmymoney2 (HBCI support), ttf-liberation, bacula (encryption), libapache-mod-security. The only case I am aware of where another distro refuses to distribute a package found in Debian is Fedora's stance on afio. If you know of other cases, I would be interested to learn about them. > Even if so, how does one get from that fact to "Debian's policy on > licensing usually involves taking the high road..."? I would claim that said fact presents evidence that this statement is true. But again, I do not see a problem with this. Hendrik -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: enabling transport and on storage encryption in bacula on debian build
On Sunday 11 January 2009 15:22:25 MJ Ray wrote: > Hendrik Weimer wrote: > > It is a fact that Debian more often rejects packages present in other > > distros than the other way around. Which I believe is a good sign, > > BTW. > > Is that a fact? Where's the evidence? A quick web search didn't find > a good study, but it might exist. I doubt there is such a stufy, but you may want to look at the recently uploaded 'whohas' package, and ask it for some possibly problematic packagenames to see whether any other distro has it. > I found some evidence that Debian > rejects packages present in Ubuntu, but that's a special case and only > one related distribution. ... like codeblocks package for example, which got recently rejected in NEW, but I'm not sure exactly why, though code dups and unfinished debian/copyright might be the reasoning behind that. -- pub 4096R/0E4BD0AB 2003-03-18 -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: enabling transport and on storage encryption in bacula on debian build
Hendrik Weimer wrote: > It is a fact that Debian more often rejects packages present in other > distros than the other way around. Which I believe is a good sign, > BTW. Is that a fact? Where's the evidence? A quick web search didn't find a good study, but it might exist. I found some evidence that Debian rejects packages present in Ubuntu, but that's a special case and only one related distribution. Even if so, how does one get from that fact to "Debian's policy on licensing usually involves taking the high road..."? I am subscribed to debian-legal - no need to cc me. Thanks, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: enabling transport and on storage encryption in bacula on debian build
* MJ Ray: > Everyone is entitled to their opinion, but please don't state it as > fact. I believe that Debian's policy on licensing is generally to try > to do what we think the software and licence authors intended, but to > be fairly cautious because we don't have big money or fast lawyers and > it really sucks if you're a maintainer who gets a complaint from the > copyright holder. Most rejections are based on our own policies, and are not guided by the limits of copyright. The stuff that might interest lawyers usually slips through because our upstream sources misrepresent the copyright status (like in the afio case). -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: enabling transport and on storage encryption in bacula on debian build
* Kern Sibbald: > Problems of mismatched licenses apparently occur when forming and > distributing a "mixed" binary program or when mixing different > licenced source code in the same file and distributing it. As far > as I know Bacula 2.4.x does not mix source code with different > licenses in the same source file (we simply call libraries that when > executed are incompatible), and Debian as well as its derivatives > have decided not to form a Bacula binary using the offending > libraries. Some folks claim that merely referencing a dynamic shared object makes a program a derived work of the dynamic shared object. In my opinion, this is an argument based on an extensionist copyright policy, and I therefore reject it. However, something like this is necessary to preserve the self-enforcing nature of the various GPL versions for dynamic shared objects (and other library code which is only incorporated per reference). As a result, the derived-work-by-reference concept has several prominent followers, including the FSF. The OpenSSL situation is special because it's the only relict of the old BSD-vs-GPL fight which is still relevant. It's a real shame that this was not solved in the GPL renewal process, but this was predictable. But it still hurts that the FSF does not want us to ship software released under the GPL which uses the OpenSSL library, but has no problem with proprietary software vendors shipping compiled third-party programs licensed under the GPL which are linked to proprietary system libraries, perhaps even including a copy of OpenSSL. There is something seriously wrong about this. In short, I share your frustration, but I also think that the John's decision is quite reasonable. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: enabling transport and on storage encryption in bacula on debian build
(Here goes an email with actual content, since I messed up...) > > I suggest you Google up "user does the link". [...] > I suggest you just post the URL(s) you mean. Google results pages are > highly volatile and vary by browser location: what you saw then may > not be what I see now. You don't really need Google, you just need a tiny bit of knowledge about some very famous things the FSF had said in the past. It has turned up for NeXt and GNU Readline, for instance. Asking this is like asking for a reference that Abraham Lincoln was a US President--it's just too well known. If you really want a reference, try this: http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLPluginsInNF # Can I release a program under the GPL which I developed using non-free tools? # # It depends on how the program invokes its plug-ins. For instance, if the # program uses only simple fork and exec to invoke and communicate with # plug-ins, then the plug-ins are separate programs, so the license of the # plug-in makes no requirements about the main program. # # If the program dynamically links plug-ins, and they make function calls to # each other and share data structures, we believe they form a single program, # which must be treated as an extension of both the main program and the # plug-ins. In order to use the GPL-covered plug-ins, the main program must # be released under the GPL or a GPL-compatible free software license, and # that the terms of the GPL must be followed when the main program is # distributed for use with these plug-ins. > It also seems unkind to tell upstream > developers to use non-free software like Google, instead of writing > great free software like they usually do. You are being ridiculous. Google's search engine runs on their own machines. They're not distributing it. Which means that most free licenses wouldn't require Google to release any source code at all. (And the ones that do are highly controversial.) If you like, you can pretend that Google's search engine is under BSD. That would make no difference whatsoever as to your rights to get it (which are nonexistent in either case). -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: enabling transport and on storage encryption in bacula on debian build
On Fri, 9 Jan 2009, MJ Ray wrote: > Date: Fri, 09 Jan 2009 10:04:00 + > From: MJ Ray > To: k...@sibbald.com > Cc: debian-legal@lists.debian.org > Subject: Re: enabling transport and on storage encryption in bacula on > debian build > Resent-Date: Fri, 9 Jan 2009 10:04:17 + (UTC) > Resent-From: debian-legal@lists.debian.org > > Ken Arromdee wrote: > > I suggest you Google up "user does the link". [...] > > I suggest you just post the URL(s) you mean. Google results pages are > highly volatile and vary by browser location: what you saw then may > not be what I see now. It also seems unkind to tell upstream > developers to use non-free software like Google, instead of writing > great free software like they usually do. > > Thanks, > -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: enabling transport and on storage encryption in bacula on debian build
MJ Ray writes: > Everyone is entitled to their opinion, but please don't state it as > fact. I believe that Debian's policy on licensing is generally to try > to do what we think the software and licence authors intended, but to > be fairly cautious because we don't have big money or fast lawyers and > it really sucks if you're a maintainer who gets a complaint from the > copyright holder. It is a fact that Debian more often rejects packages present in other distros than the other way around. Which I believe is a good sign, BTW. Hendrik -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: enabling transport and on storage encryption in bacula on debian build
Hendrik Weimer wrote: > [...]. However, Debian's policy on licensing > usually involves taking the high road rather than doing what you can > get away with. [...] Everyone is entitled to their opinion, but please don't state it as fact. I believe that Debian's policy on licensing is generally to try to do what we think the software and licence authors intended, but to be fairly cautious because we don't have big money or fast lawyers and it really sucks if you're a maintainer who gets a complaint from the copyright holder. 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 debian-legal-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: enabling transport and on storage encryption in bacula on debian build
Ken Arromdee wrote: > I suggest you Google up "user does the link". [...] I suggest you just post the URL(s) you mean. Google results pages are highly volatile and vary by browser location: what you saw then may not be what I see now. It also seems unkind to tell upstream developers to use non-free software like Google, instead of writing great free software like they usually do. Thanks, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: enabling transport and on storage encryption in bacula on debian build
Kern Sibbald writes: > I personally don't believe that such distribution is a problem -- > after all Debian does distribute pure GPLv2 code and OpenSSL source > code on the same ISO image. This should not be a problem anyway as it falls under the "mere aggregation" clause. > Problems of mismatched licenses apparently occur when forming and > distributing a "mixed" binary program or when mixing different > licenced source code in the same file and distributing it. As far > as I know Bacula 2.4.x does not mix source code with different > licenses in the same source file (we simply call libraries that when > executed are incompatible), and Debian as well as its derivatives > have decided not to form a Bacula binary using the offending > libraries. I see what you mean, but I think there is a problem with this reasoning. If you redistribute GPLv2ed sources you must ensure that all recipients of the code enjoy the rights granted to you the license (6.). One such right is the distribution of the software as a binary (3.), which you may not without satisfying OpenSSL's advertizing clause. Which in turn means you may not distribute the software at all (7.). > In any case, there are many other programs that have far worse > problems than the old Bacula code. Most of the Bacula problems > involve code copyrighted by FSF, and the FSF is very well aware of > the Bacula problem all the way up to RMS. They are also very well > aware that I take those problems seriously and fixed them a long > time ago. For these kinds of "technical" problems, I certainly hope > that no one would not want to simply stop supplying the source code > -- that would likely hurt the users far more than helping the Free > Software movement, and so far none of the authors of the pure GPLv2 > code have complained. I fully agree here. I don't think the FSF(E) will go berzerk for someone distributing Bacula. However, Debian's policy on licensing usually involves taking the high road rather than doing what you can get away with. Moreover, the belief that distributing software in source form magically frees you from your obligations under the GPL seems rather mystical to me. Hendrik -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: enabling transport and on storage encryption in bacula on debian build
Ken Arromdee wrote: > On Tue, 6 Jan 2009, Kern Sibbald wrote: > 1. Build it from source yourself (perfectly legal -- only distribution > violates the GPL license). >>> Isn't it the FSF's position that "user does the link" violates GPL? >> No. Please read the GPL. > > I suggest you Google up "user does the link". Unless they changed their > position recently, they *do* think that creating something designed to link > against GPL coder, but not distributing the GPL code and letting the user get > it and link it in, is a violation. That's not the same thing as "building it from source yourself". -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: enabling transport and on storage encryption in bacula on debian build
On Wednesday 07 January 2009 21:59:45 Hendrik Weimer wrote: > Kern Sibbald writes: > > 1. Build it from source yourself (perfectly legal -- only distribution > > violates the GPL license). > > The question is whether it is legal to distribute the Bacula sources > (including parts depending on OpenSSL) to begin with. These are > uncertain legal grounds to say the least. I personally don't believe that such distribution is a problem -- after all Debian does distribute pure GPLv2 code and OpenSSL source code on the same ISO image. Problems of mismatched licenses apparently occur when forming and distributing a "mixed" binary program or when mixing different licenced source code in the same file and distributing it. As far as I know Bacula 2.4.x does not mix source code with different licenses in the same source file (we simply call libraries that when executed are incompatible), and Debian as well as its derivatives have decided not to form a Bacula binary using the offending libraries. In any case, there are many other programs that have far worse problems than the old Bacula code. Most of the Bacula problems involve code copyrighted by FSF, and the FSF is very well aware of the Bacula problem all the way up to RMS. They are also very well aware that I take those problems seriously and fixed them a long time ago. For these kinds of "technical" problems, I certainly hope that no one would not want to simply stop supplying the source code -- that would likely hurt the users far more than helping the Free Software movement, and so far none of the authors of the pure GPLv2 code have complained. I resolved the problem long time ago, so I consider it just a question of ensuring a conservative, smooth transition from the old code the new code. If someone is really concerned by the "legality" of using the old source, then they should feel free to use the new code (beta), which has absolutely no license problems. Regards. Lerm > > > 2. Wait for version 3.0.0 (currently in Beta testing as version > > 2.5.28-b1). This version has no licensing problems (pointer to > > details for version 2.4.x provided by John) and so Debian will be > > able to release it with OpenSSL compiled in. > > Ah, that's good to hear! > > Hendrik -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: enabling transport and on storage encryption in bacula on debian build
Kern Sibbald writes: > 1. Build it from source yourself (perfectly legal -- only distribution > violates the GPL license). The question is whether it is legal to distribute the Bacula sources (including parts depending on OpenSSL) to begin with. These are uncertain legal grounds to say the least. > 2. Wait for version 3.0.0 (currently in Beta testing as version > 2.5.28-b1). This version has no licensing problems (pointer to > details for version 2.4.x provided by John) and so Debian will be > able to release it with OpenSSL compiled in. Ah, that's good to hear! Hendrik -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: enabling transport and on storage encryption in bacula on debian build
On Tue, 6 Jan 2009, Kern Sibbald wrote: > > > > 1. Build it from source yourself (perfectly legal -- only distribution > > > > violates the GPL license). > > > > Isn't it the FSF's position that "user does the link" violates GPL? > > No. Please read the GPL. I suggest you Google up "user does the link". Unless they changed their position recently, they *do* think that creating something designed to link against GPL coder, but not distributing the GPL code and letting the user get it and link it in, is a violation. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: enabling transport and on storage encryption in bacula on debian build
On Monday 05 January 2009 23:08:33 Ken Arromdee wrote: > > > 1. Build it from source yourself (perfectly legal -- only distribution > > > violates the GPL license). > > Isn't it the FSF's position that "user does the link" violates GPL? No. Please read the GPL. > > Of course, even then, that only applies to distribution--which means that > the user can build it from source himself, but the fact that Debian > distributes something the user *can* use to build it from source itself > violates GPL. No. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: enabling transport and on storage encryption in bacula on debian build
> > 1. Build it from source yourself (perfectly legal -- only distribution > > violates the GPL license). Isn't it the FSF's position that "user does the link" violates GPL? Of course, even then, that only applies to distribution--which means that the user can build it from source himself, but the fact that Debian distributes something the user *can* use to build it from source itself violates GPL. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: enabling transport and on storage encryption in bacula on debian build
Hello everybody, thanx for all your answer's. I think Version 3 wont make it into Debian 5.0 Lenny :( so the only solution for me would be to compile the version by my own on each needed machine, what is imho unhappy, but if this is the only solution :( hopefully the licence's of version 3 are compatible with debian's policy and *dreaming* it would make it into debian lenny and a half ;) *end dreaming* greetings thomas Am 04.01.2009 17:48, schrieb Kern Sibbald: > Hello, > > The current released version (2.4.x) series under an interpretation that > OpenSSL is not a system library routine, which is Debian's position, means > that they cannot distribute Bacula with OpenSSL enabled (Bacula > communications and data encryption). > > The source code does exist, but is simply not enabled in the Debian binaries. > > As a consequence, if you want encryption in Bacula, there are two choices: > > 1. Build it from source yourself (perfectly legal -- only distribution > violates the GPL license). > > 2. Wait for version 3.0.0 (currently in Beta testing as version 2.5.28-b1). > This version has no licensing problems (pointer to details for version 2.4.x > provided by John) and so Debian will be able to release it with OpenSSL > compiled in. > > Best regards, > > Kern > > > > On Sunday 04 January 2009 00:59:33 Thomas Stegbauer wrote: > >> hello everybody, >> >> a happy new year to all. >> >> as i figured currently out, bacula on debian is unable to encryption >> the data. >> >> http://lists.debian.org/debian-legal/2007/07/msg00144.html >> >> >> what can be done this get solved within debian 5.0 lenny? >> >> >> greetings >> thomas >> > > > -- # Stegbauer Datawork # Thomas Stegbauer # Oberjulbachring 9, 84387 Julbach # https://keyserver1.pgp.com/vkd/submitsearch.event?searchcriteria=tho...@stegbauer.info # PGP Fingerprint: C5B5 BDBD 6607 A9DF E545 0EC5 9DDF 9749 BD05 808A - Die Nachricht wurde vom Absender mittels S/MIME digital signiert. Bitte die Signatur pruefen! Die Signatur wurde der E-Mail angehaengt. Signierte E-Mail ermoeglicht es, die Authentizitaet der Nachricht zu ueberpruefen, dass die Nachricht von dem angezeigten Absender stammt und nicht waehrend der Uebertragung gefaelscht wurde. - -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: enabling transport and on storage encryption in bacula on debian build
* Kern Sibbald [090104 19:21]: > The current released version (2.4.x) series under an interpretation that > OpenSSL is not a system library routine, which is Debian's position, means > that they cannot distribute Bacula with OpenSSL enabled (Bacula > communications and data encryption). substitute "not a system library" with "cannot be described as 'major component[...] of the operating system on which the executable runs, unless that component itself accompanies the executable'". (and remember that we want to put everything together on a single Bluray disc (or DVD/cdrom set), so everything in Debian accompanies everything else). Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: enabling transport and on storage encryption in bacula on debian build
Hello, The current released version (2.4.x) series under an interpretation that OpenSSL is not a system library routine, which is Debian's position, means that they cannot distribute Bacula with OpenSSL enabled (Bacula communications and data encryption). The source code does exist, but is simply not enabled in the Debian binaries. As a consequence, if you want encryption in Bacula, there are two choices: 1. Build it from source yourself (perfectly legal -- only distribution violates the GPL license). 2. Wait for version 3.0.0 (currently in Beta testing as version 2.5.28-b1). This version has no licensing problems (pointer to details for version 2.4.x provided by John) and so Debian will be able to release it with OpenSSL compiled in. Best regards, Kern On Sunday 04 January 2009 00:59:33 Thomas Stegbauer wrote: > hello everybody, > > a happy new year to all. > > as i figured currently out, bacula on debian is unable to encryption > the data. > > http://lists.debian.org/debian-legal/2007/07/msg00144.html > > > what can be done this get solved within debian 5.0 lenny? > > > greetings > thomas -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: enabling transport and on storage encryption in bacula on debian build
Thomas Stegbauer wrote: > hello everybody, > > a happy new year to all. > > as i figured currently out, bacula on debian is unable to encryption > the data. > > http://lists.debian.org/debian-legal/2007/07/msg00144.html > > > what can be done this get solved within debian 5.0 lenny? Please see README.Debian included with the Bacula package, which includes a lengthy discussion of the topic and reference to various mailing list threads. If you have a new suggestion to propose after reviewing that information and the threads it refers to, I'd be very happy to hear it. -- John > > > greetings > thomas > -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
