Re: Bacula and OpenSSL
* Anthony Towns ([EMAIL PROTECTED]) wrote: On Thu, Jul 19, 2007 at 04:22:06PM +0200, Shane M. Coughlan wrote: 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. Wow is that confused. OpenSSL certainly accompanies genuinely fundamental components of the system; it's status in Debian is that it's as fundamental as apt, and significantly more fundamental than any windowing system, which is explicitly listed as an example of a fundamental component in the GPLv3. Agreed, and with the rest of Anthony's analysis. It may not have been true a few releases ago but things change and it's definitely fundamental in etch and will be included in all Debian releases and installations in the foreseeable future. It has to be explicitly *removed* from even a minimal installation and doing so has some serious implications. Thanks, Stephen signature.asc Description: Digital signature
Re: Sun Java available from non-free
* Anthony Towns (aj@azure.humbug.org.au) wrote: On Sun, May 21, 2006 at 06:14:51PM +0200, Michael Meskes wrote: On Sat, May 20, 2006 at 04:18:44PM -0500, Anthony Towns wrote: Anyway, the background is that James Troup, Jeroen van Wolffelaar and myself examined the license before accepting it into non-free (which is three times the usual examination, and was done given the inability to examine the license in public), and both James and Jeroen had extensive contact with Sun to ensure that the tricky clauses were actually okay. Some of this might have been avoided had one or two of the debian-legal regulars been asked to look into it. Changing the license beforehand certainly would have been better than ending up in this situation. You won't expect Sun to say they are not, would you? :-) The questions asked weren't Is this okay for non-free? it's Did you mean or when you wrote ?. The answers to those latter questions are, ttbomk, all included in the FAQ, which is why ignoring it just wastes everyone's time. Unfortunately, neither the FAQ nor emails from Sun are actually legally binding so while this is a nice exercise to help identify places where Sun should change the license to make it more clear it doesn't actually improve the license by itself. I'd like to think that this would have been pointed out by most any debian-legal regular who might have reviewed it. Thanks, Stephen signature.asc Description: Digital signature
Re: Packages containing RFCs
* Simon Josefsson ([EMAIL PROTECTED]) wrote: Stephen Frost [EMAIL PROTECTED] writes: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=199810 That package seem to be in non-free now... I'm arguing the same for RFCs in other packages too. The bug is against libnss-ldap, which is certainly not in non-free. Thanks, Stephen signature.asc Description: Digital signature
Re: Packages containing RFCs
* MJ Ray ([EMAIL PROTECTED]) wrote: Simon Josefsson [EMAIL PROTECTED] Then I looked at what other packages in testing may have the same problem, and the list below is what I found. It is not that large, and better than I would expect. Should we file bug reports for these packages, or is there a better way to handle this? What severity should I use? I think you should file bug reports, but I think you should ask a wider or higher audience (maybe -devel or -release) before mass-filing. Most of those bugs look serious (debian-policy s2.1+2.2) to me. I can't remember if anyone is coordinating [NONFREE-DOC] bugs. There's already been bugs filed about this in the past.. I'm not sure where they ended up but, fe: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=199810 Thanks, Stephen signature.asc Description: Digital signature
Re: Results for Debian's Position on the GFDL
* olive ([EMAIL PROTECTED]) wrote: Of course, the final authority on the meaning of a license would be the Supreme Court (at least in the US). Debian is an international project and not a US project. I don't think that many non US Debian users or developer will be happy with that. Would you agree if a say that the final authority on the meaning of a license is the Belgian court (I am from Belgium)? While Debian is an international project, the servers and developers have to be located somewhere. If there are infrastructure servers or Debian developers working on the appropriate things in Belgium then the opinion of the Belgian court might very well apply. To think Debian, or international organizations in general, are above all local laws/courts is clear folly. Enjoy, Stephen signature.asc Description: Digital signature
Re: Results for Debian's Position on the GFDL
* Anthony DeRobertis ([EMAIL PROTECTED]) wrote: So that leads us right back to my point of trying to figure out what the Project is telling us about interpreting licenses and the DFSG. I wouldn't take this any farther than what the GR explicitly said- GFDL w/o invariant sections are free. Otherwise, 'normal' (ie: prior to the GR) rules apply. If people want to change the DFSG then they'll need to actually do that, this GR didn't, just added an explicit exception. If people want to say that the 'types of clauses as those found in the GFDL are ok' then that would require some analysis like what you're doing. Let's try to avoid having that happen, or at least wait to cross that bridge till we get to it. Thanks, Stephen signature.asc Description: Digital signature
Re: Results for Debian's Position on the GFDL
* Marco d'Itri ([EMAIL PROTECTED]) wrote: On Mar 13, Stephen Frost [EMAIL PROTECTED] wrote: I wouldn't take this any farther than what the GR explicitly said- GFDL w/o invariant sections are free. Otherwise, 'normal' (ie: prior to the GR) rules apply. If people want to change the DFSG then they'll need to actually do that, this GR didn't, just added an explicit exception. If If it wanted to added an exception it would have done so. This GR just established the correct interpretation of the DFSG for this license. Err, so you agree with me? How is it not an exception when it's just for this license? No, I do not. It's obviously not an exception (or it would have said so) but a way to officially state what the DFSG means when applied to this license, since there has been a wide disagreement in the project about this. It's obviously an exception (or it would have said 'licenses like the GFDL'). It doesn't change the DFSG at all. Thanks, Stephen signature.asc Description: Digital signature
Re: Linux mark extortion
* Bruce Perens ([EMAIL PROTECTED]) wrote: Stephen Frost wrote: What's the scenario you're concerned about here? Someone taking Debian and distributing it as MyLinux and Debian not protecting that use somehow? Not even that. The license only applies to (c) on AUTHORIZED GOODS/SERVICES which are (i) produced by or for SUBLICENSEE, and (ii) distributed under SUBLICENSEE?s name. Debian distribution does not work this way. Debian CDs are not produced by or for us, they are made by third parties with whom we have no contract. They are not distributed in our name but in the name of those third parties. In other words, I don't see that the license as currently written works for software that our CD manufacturers duplicate and sell. They clearly did not understand our model and did not bother to ask us about it. Debian is still the #2 Linux distribution worldwide, so this seems to me to be a pretty significant error. Did I miss something here? Does Debian actually have such a license (or SPI)? Have you talked with them and gotten them to agree with your interpretation that we even need a license? Have they contacted Debian or SPI about having us get a license? From what I've seen to date it seems like they've contacted UserLinux (which it appeared you agreed was reasonable in a prior email given that you were saying you'd be willing to pay the license costs) about a license but havn't contacted Debian or SPI about one. Perhaps there's a reason for that- ie: that Debian's use (and therefore the use of the same Debian GNU/Linux text) falls under descriptive use and they've no reason or intent to ask us or our distributors to get a license, which makes the concerns you have about the license go away wrt Debian I'd think... Please let me know if there's something I've misunderstood here. In any case it'd probably make some sense to talk to them before jumping to conclusions and, honestly, if we need to make some minor wording change or something to be able to avoid having a license at all personally I think I'd be fine with that. Thanks, Stephen signature.asc Description: Digital signature
Re: Linux mark extortion
* Bruce Perens ([EMAIL PROTECTED]) wrote: The problem isn't the cost. Even the most expensive tier is only $5K/year. It's the license terms. As usual for agreements drawn up to accomodate the commercial software vendors of the world and not us, they don't take into account sublicensing of our product. I'd be happy to license their mark for Userlinux, a commercial product, if I felt their terms were fair for Debian. Nothing doing until that's the case. What's the scenario you're concerned about here? Someone taking Debian and distributing it as MyLinux and Debian not protecting that use somehow? Stephen signature.asc Description: Digital signature
Re: Font source Re: Social Contract GR's Affect on sarge
* D. Starner ([EMAIL PROTECTED]) wrote: But almost no one, if given a choice of the binary or the assembly language to edit, would choose the binary. At the very least, the assembly would be invaluable to deciphering the details of the firmware, and I suspect many programmers would write a QD assembler to use the assembly if there were no free assemblers for the target. It's not like there's a whole lot of difference between the assembly and the binary in this case. Write a QD disassembler and extract the assembly if you want. Stephen signature.asc Description: Digital signature
Re: Font source Re: Social Contract GR's Affect on sarge
* D. Starner ([EMAIL PROTECTED]) wrote: Stephen Frost [EMAIL PROTECTED] writes: It's not like there's a whole lot of difference between the assembly and the binary in this case. Write a QD disassembler and extract the assembly if you want. Even if we were talking about x86 assembly, there would still be a lot of difference between assembly with mnemonic constants and labels and comments, and assembly from a disassembled binary. But some of these chips are poorly documented or undocumented; if we don't know the instruction length, much less the opcodes, writing a disassembler could be a serious act of reverse engineering. Of course it could. Writing an assembler would probably take some serious effort too without knowing that information. To some extent that's my point- are we going to require hardware specifications for anything that uses firmware? Personally I don't think we need to, or should. If we don't have the hardware specifications though, there's really not much use to having the assembly for the firmware that runs on that hardware. Stephen signature.asc Description: Digital signature
Re: DRAFT for a GR proposal concerning the Sarge release
* Glenn Maynard ([EMAIL PROTECTED]) wrote: On Wed, Apr 28, 2004 at 06:21:27AM +0200, Thiemo Seufer wrote: For possible, that is, unsubstantioned license violation claims, yes. Distributing a GPL binary linked against code whose source is not available is a clear-cut violation of the terms of the GPL. Has anyone asked Linus what his feelings are regarding firmware? If he thinks it's acceptable (or possibly even the 'preferred form of modification') to have in Linux and that it's not violating the GPL then I don't think we have a problem. In these cases of ambiguity it makes sense to me to ask the copyright holder to clarify for us instead of assuming that they're violating their own license. Stephen signature.asc Description: Digital signature
Re: DRAFT for a GR proposal concerning the Sarge release
* Glenn Maynard ([EMAIL PROTECTED]) wrote: I concur with the other responses: Linus is not the sole copyright holder. I'll also reiterate the other problem: even if we believe that the entire Linux kernel developer body agrees (which may be the case, though I doubt it), I'm sure there's a lot of code in the kernel pulled from other GPL projects, whose copyright holders aren't kernel developers at all. Certainly you can develop a case where it's not possible to get clarification on the license. That's not constructive or necessary imv. Clarification from Linus on the kernel's license is sufficient for me, and should be for Debian. Stephen signature.asc Description: Digital signature
Re: DRAFT for a GR proposal concerning the Sarge release
* Glenn Maynard ([EMAIL PROTECTED]) wrote: On Wed, Apr 28, 2004 at 04:42:14PM -0400, Stephen Frost wrote: Certainly you can develop a case where it's not possible to get clarification on the license. That's not constructive or necessary imv. If it's the case, then it's the case. Inconvenient does not imply false, whether we like it or not. I don't like that, so we should ignore it isn't a convincing argument. If we make a reasonable attempt to get clarification on the license the kernel is distributed under from the *source* of the kernel tarballs that we use then that should mitigate the risk. No, it won't remove all risk like getting agreeing clarification from everyone but that's not reasonable to do in this case as you pointed out. Clarification from Linus on the kernel's license is sufficient for me, and should be for Debian. If Linus is not legally capable of making this clarification for all of the code in question, then Debian must not pretend otherwise, and I see no evidence that he is. Linus is where we receive the source from, is the originator of the kernel, originally decided the license it was going to be under, and may very well have the largest percentage of direct copyright in the work. It's clear, to me at least, that his interpretation has some weight. Stephen signature.asc Description: Digital signature
Re: OpenLDAP Licenseing issues
* Kurt D. Zeilenga ([EMAIL PROTECTED]) wrote: There were a number of files in U-Mich LDAP software distribution which contained no notice or a notice with no license statement. The OpenLDAP Foundation considers each of these files to be copyright by U-Mich and subject to the license which U-Mich provided in the U-Mich LDAP distribution. A copy of that license remains in the COPYRIGHT file now distributed with OpenLDAP Software. I have read the U-Mich license which is included in the COPYRIGHT file and it does not appear to grant the right to modify the work and redistribute the modified version. The lack of this right is of concern to us and I would think it would be of concern to the OpenLDAP Foundation as well. An example of where this might come up is shown at http://www.openldap.org/devel/cvsweb.cgi/libraries/liblutil/setproctitle.c?hideattic=1sortbydate=0 where a file under the U-Mich license was modified and then distributed. Can you clarify this apparent discrepancy between the rights grants by the license and the acts of the OpenLDAP Foundation? My general feeling on this is that the right to redistribute modified works was intended to be granted by U-Mich and that they meant to imply it in their license and that is what the OpenLDAP Foundation has been operating under. Having this stated explicitly would benefit anyone looking at the licenseing for OpenLDAP when determining if they can use it or if they can include it in their distribution. Since I would expect this is of concern to the OpenLDAP Foundation I would hope that they might be willing to clarify it or to contact U-Mich to have them clarify it since they likely have a contact at U-Mich. If the OpenLDAP Foundation does not share my view then I would ask if they would be kind enough to point us in the right direction at U-Mich so that we might contact them to resolve this question. And, as stated in the OpenLDAP COPYRIGHT file, some files may be subject to additional restrictions. The OpenLDAP Foundation makes no assertion of compatibility or incompatibility between terms placed upon OpenLDAP Software by its copyright holders and terms placed upon other works by their copyright holders which OpenLDAP Software may be combined with. Our primary concern is to understand the licenseing under which OpenLDAP is distributed so that we may make an informed decision as to how it fits in our distribution. We do not ask the OpenLDAP Foundation to make the determination for us as to how OpenLDAP may fit into our distribution or how the OpenLDAP licenseing interacts with other licenses in our distribution but only to clarify the licenseing terms under which the OpenLDAP Foundation distributes OpenLDAP. Thanks, Stephen pgpQsyhUhaztS.pgp Description: PGP signature
OpenLDAP Licenseing issues
* Kurt D. Zeilenga ([EMAIL PROTECTED]) wrote: s/license/complete copyright notice/ That is, read the whole COPYRIGHT file (and then read some more). Very well, I've done so. The results of my work bring up a number of questions, perhaps opening up a larger can of worms than was expected. I found a total of 15 distinct licenses in the OpenLDAP source tree as of version 2.1.17. I also found some files which had copyright statements alone with 'All Rights Reserved.' which would imply that they are not distributable. These files and their associated copyright statements are at the end of this email. A number of files did not include a Copyright statement at all. For the rest of this discussion I am going to assume that they fall under the OpenLDAP Public License unless you tell me otherwise. Of those 15 licenses there are a few questions when it comes to GPL interaction. In the UoC license (Regents of the University of California Berkley) there is the infamous 'advertising clause'. The Regents have however, from my understanding, retroactively removed that clause from all of their licenses, at the request of the FSF. In the HC (Howard Chu) and PM (Pierangelo Masarati) there is 'should' do this and a 'should' do that. If those are to be interpreted as 'must' then they conflict with the GPL. 'should', however, can also be interpreted as a request, in which case there isn't a conflict. The UoC, JC (Juan C. Gomez) and MA (Mark Adamson) licenses don't grant the right to distributed modified versions, which is in conflict with the GPL. The OL2 (OpenLDAP License 2) license doesn't grant modification either but only covers one file (./contrib/ldapc++/LICENSE). The files below which are Pierangelo Masarati or University of Michigan I expect are unintentional omissions and should really be under the PM or UoM licenses respectively. The TimesTen Performance Software files appear to likely be distributed illegally. The results of my work are located here: http://www.snowman.net/ldap-license-notes.txt The licenses which I found (except the OpenLDAP Public License) are listed here with their 'short' names (which appear on the first file): http://www.snowman.net/ldap_licenses.txt These files themselves are placed in the public domain, as much as they can be considering I copied the licenses texts from copyrighted files. I would encourage their inclusion in the OpenLDAP tree as a quick reference to all of the licenses and what files they cover. As opporunity allows I may look at the differences between 2.1.17 and 2.1.20 to see if any changes need to be made. I am cc'ing debian-legal on this so that they may look at the list and the set of licenses and give their opinion on the subject. My current feeling is that without change OpenLDAP will have to be moved into the 'non-free' section of Debian along with all of its libraries. The numerous LDAP-using applications which are GPL would have to be split into two packages with the LDAP-using portion going into the contrib section of Debian and the rest remaining in main. If packages can not be split they would need to be moved entirely into contrib. I look forward to discussing these issues and hope there can be some resolution here. Perhaps the offending licenses and the files they cover can be changed with permission of the copyright owners or their contents reimplemented under a more reasonable license. Yours truly, Stephen Frost ./servers/slapd/back-sql/rdbms_depend/timesten/dnreverse/Makefile (c) Copyright 1996-1998, TimesTen Performance Software. - All rights reserved. - NOT DISTRIBUTABLE ./servers/slapd/back-sql/rdbms_depend/timesten/dnreverse/dnreverse.cpp (c) Copyright 1996-1998, TimesTen Performance Software. - All rights reserved. - NOT DISTRIBUTABLE ./servers/slapd/back-meta/Changes Pierangelo Masarati - All rights reserved - NOT DISTRIBUTABLE ./servers/slapd/back-ldap/Changes Pierangelo Masarati - All Rights reserved. - NOT DISTRIBUTABLE ./doc/man/man5/slapd-meta.5 OpenLDAP Foundation - OpenLDAP Public License Pierangelo Masarati - All rights reserved - NOT DISTRIBUTABLE ./libraries/libldap/open.c OpenLDAP Foundation - OpenLDAP Public License Regents of the University of Michigan - All rights reserved - NOT DISTRIBUTABLE ./libraries/libldap/abandon.c OpenLDAP Foundation - OpenLDAP Public License Regents of the University of Michigan - All rights reserved - NOT DISTRIBUTABLE ./libraries/libldap/getdn.c OpenLDAP Foundation - OpenLDAP Public License Regents of the University of Michigan - All rights reserved - NOT DISTRIBUTABLE ./libraries/libldap/delete.c OpenLDAP Foundation - OpenLDAP Public License Regents of the University of Michigan - All rights reserved - NOT DISTRIBUTABLE ./libraries/libldap/getattr.c OpenLDAP Foundation - OpenLDAP Public License Regents of the University of Michigan - All rights reserved - NOT DISTRIBUTABLE ./libraries/libldap/addentry.c
(forw) [Kurt@OpenLDAP.org: Re: GNUTLS support?]
Comments? I didn't think the OpenLDAP license had the same restrictions the OpenSSL one did...? - Forwarded message from Kurt D. Zeilenga [EMAIL PROTECTED] - Date: Thu, 22 May 2003 10:15:03 -0700 From: Kurt D. Zeilenga [EMAIL PROTECTED] To: Stephen Frost [EMAIL PROTECTED] Cc: openldap-devel@OpenLDAP.org X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Subject: Re: GNUTLS support? At 09:31 AM 5/22/2003, Stephen Frost wrote: It has come to my attention that OpenSSL has some licensing issues and causes problems (at least for Debian) when being linked with programs like Samba. Due to this, This, by itself, is not a good reason once you come to the realization that the same issues which apply to OpenSSL software likely applies to OpenLDAP Software (and to Cyrus SASL and to ...). I suggest you and your lawyer read the complete OpenLDAP Software copyright notice. and the fact that support for alternatives is good anyway, Feel free to submit a patch with an original code implementing the feature. Kurt - End forwarded message - Stephen pgpRrWGSxTUCE.pgp Description: PGP signature
