New bugs filed regarding non-free IETF RFC/I-Ds
Hi all. A few months ago, I went over the package list manually to find IETF I-D's, but I finally wrote a simplistic script to do this for me: #!/bin/sh URL='http://packages.debian.org/cgi-bin/search_contents.pl?word=draftsearchmode=searchwordcase=insensitiveversion=unstablearch=i386page=1number=all' wget --quiet -O - $URL | egrep 'draft[a-z0-9-]+[0-9][0-9]\.' | grep -v ':rednon-free' | grep -v 'usr/share/doc/te.*/latex/draftcopy/draftcopy' This currently generate the output below [1]. Of the packages in the output, only one package had an active bug report about this problem, the libsasl2 package: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=365183 The many packages I filed bugs on before that have been fixed: http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED] The good side is that no regression in a particular package has been made. Of the packages with closed bugs, only the openswan package contains I-D's, but it is a different file than in the earlier bug report. The bad side is that some new packages have introduced more I-Ds with unclear or unmodifiable licenses. I have filed these new bug reports: irc-hybrid: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=390667 libsmi2: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=390666 libtheora-dev: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=390665 uuid-dev: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=390664 libvorbis-dev: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=390660 mobilemesh: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=390657 openswan: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=390656 sidentd: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=390658 As per http://release.debian.org/removing-non-free-documentation#bugs I have marked the bugs as serious. Some of these documents MAY be freely available -- check with the author -- but as far as I could see, in no case was this noted in the copyright file, so I'm assuming they are redistributed based on the IETF license, which I believe we've agreed is DFSG-nonfree. Lobbying individual authors to release their documents under a more free license would be a good thing, but I don't have time to pursue that path. Hopefully some package maintainer will want to pursue it... /Simon [1] Output: [EMAIL PROTECTED]:~$ ~/self/tools/find-debian-ietf-works usr/share/doc/ircd-hybrid/technical/draft-mitchell-irc-capabilities-01.txt.gz a href=http://packages.debian.org/unstable/net/ircd-hybrid;net/ircd-hybrid/a usr/share/doc/libsasl2/draft-burdis-cat-srp-sasl-08.txt.gz a href=http://packages.debian.org/unstable/libs/libsasl2;libs/libsasl2/a usr/share/doc/libsasl2/draft-ietf-sasl-anon-02.txt.gz a href=http://packages.debian.org/unstable/libs/libsasl2;libs/libsasl2/a usr/share/doc/libsasl2/draft-ietf-sasl-crammd5-01.txt.gza href=http://packages.debian.org/unstable/libs/libsasl2;libs/libsasl2/a usr/share/doc/libsasl2/draft-ietf-sasl-gssapi-00.txt.gz a href=http://packages.debian.org/unstable/libs/libsasl2;libs/libsasl2/a usr/share/doc/libsasl2/draft-ietf-sasl-plain-03.txt.gz a href=http://packages.debian.org/unstable/libs/libsasl2;libs/libsasl2/a usr/share/doc/libsasl2/draft-ietf-sasl-rfcbis-03.txt.gz a href=http://packages.debian.org/unstable/libs/libsasl2;libs/libsasl2/a usr/share/doc/libsasl2/draft-ietf-sasl-rfc2831bis-02.txt.gz a href=http://packages.debian.org/unstable/libs/libsasl2;libs/libsasl2/a usr/share/doc/libsasl2/draft-ietf-sasl-saslprep-04.txt.gz a href=http://packages.debian.org/unstable/libs/libsasl2;libs/libsasl2/a usr/share/doc/libsasl2/draft-murchison-sasl-login-00.txt.gz a href=http://packages.debian.org/unstable/libs/libsasl2;libs/libsasl2/a usr/share/doc/libsasl2/draft-newman-sasl-c-api-01.txt.gza href=http://packages.debian.org/unstable/libs/libsasl2;libs/libsasl2/a usr/share/doc/libsident0-dev/draft-morgan-ident-ext-04.txt.gz a href=http://packages.debian.org/unstable/libdevel/libsident0-dev;libdevel/libsident0-dev/a usr/share/doc/libsmi2/draft-irtf-nmrg-sming-02.txt.gz a href=http://packages.debian.org/unstable/libs/libsmi2;libs/libsmi2/a usr/share/doc/libspf-doc/spf-draft-200405.txt.gza href=http://packages.debian.org/unstable/doc/libspf-doc;doc/libspf-doc/a usr/share/doc/libtheora-dev/draft-barbato-avt-rtp-theora-01.txt.gz a href=http://packages.debian.org/unstable/libdevel/libtheora-dev;libdevel/libtheora-dev/a usr/share/doc/libtheora-dev/draft-barbato-avt-rtp-theora-01.xml.gz a href=http://packages.debian.org/unstable/libdevel/libtheora-dev;libdevel/libtheora-dev/a usr/share/doc/libuuid1/draft-leach-uuids-guids-01.txt.gza href=http://packages.debian.org/unstable/libdevel/uuid-dev;libdevel/uuid-dev/a usr/share/doc/libvorbis-dev/html/draft-kerr-avt-vorbis-rtp-03.txt.gz a href=http://packages.debian.org/unstable/libdevel/libvorbis-dev;libdevel/libvorbis-dev/a usr/share/doc/mobilemesh/InternetDrafts/draft-grace-manet-mmbdp-00.txt.gz a
Re: Licence for a file in tstat: is it compatible with Debian?
Hi all, I'm sorry but 'till now I didn't have time to keep up with this problem OTOH you have a different problem: a four clauses BSD-like license is not compatible with GPL-licensed code, and this means that the package is not distributable at all. So, what do I have to do now? Should I get in touch with upstream asking to remove/replace that code? Something else? Thanks for your attention, Sandro -- Sandro Tosi (aka Morpheus, matrixhasu) My (little) site: http://matrixhasu.altervista.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: License review request
Those links are dead for me. I found some other urls in /misc -- are they the same license? (in the future, please include the full text of licenses in the body of email requests -- urls often change, but debian-legal is archived all over the place) http://sparcs.kaist.ac.kr/~tinuviel/misc/lowercased http://sparcs.kaist.ac.kr/~tinuviel/misc/lowercased.html Full Text: The Lowercased License Preamble The licenses for most software include a clause spelled in all uppercase letters. By contrast, the Lowercased License includes a clause spelled in all lowercase letters. For the purpose of interpreting this license, the clause spelled in all lowercase letters should be interpreted in the same way assuming it was spelled in all uppercase letters. This license has two purposes. One is to allow you to use the work, to distribute the work, to modify the work, and to distribute the modifed work. The other is to mock and parody other licenses including a clause spelled in all uppercase letters. The precise terms and conditions for copying, distribution, and modification follow. Terms and conditions for copying, distribution, and modification Permission is hereby granted, free of charge, to any person obtaining a copy of this work, to deal in the work without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the work, and to permit persons to whom the work is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the work. the work is provided as is, without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and noninfringement. in no event shall the authors or copyright holders be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the work or the use or other dealings in the work. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Freeness of current draft of GNU SFDLv1
The folowng is ann analysys of the DFSG freeness of the current draft of the GNU SFDL. I was only looking to see if the problems with the current FDL are resolved by the SFDL. There may be new problems that I did not notice. I used Manoj's draft position statement to identify the problems with the FDL. (I have incluuded a more complete analyis after that first part. This more complete analyis may point out new problems). - ==The DRM problem== The text here is different. It is not clear that it fixes the problem, but it is probably better than what the current FDL has. Quote: You may not apply technical measures to obstruct or control the use or further copying of any copies you make or distribute, by those to whom they may be distributed. The phrasing there makes it sound like intent behind DRM'ing is the key here. If you apply technical measures to obstruct... that is a problem. It looks like it might not be a problem if you apply those technical measures for annother reason, but it just so happens to obstruct... then it is ok. That is a very odd position to take. If that is what the FSF intended then applying the techincal measures for reasons of compatability, etc. is not a problem. However, that clause under this interpretation does not require an unencumbered copy, which seems unlikely to be the intent of the FSF. So this one is still somewhat unclear. The FSF really should rephase that. ==The Transparent and Opaque copies problem== Problem is completely gone, due to an equivalent access clause equivalent to the one in the GPL. ==The Invariant Sections problem== Mostly gone due to no invarient section provision. However, there are still some special restricted sections: History, Acknowlegements, Dedications, and Endorsements. The restrictions on those sections might just be acceptable, but they do come close. - Point by point analysis of the licence. ==Sections 0 and 0a.== These are preamble-style sections, so I will not go into detail on them. They are however not as distinct from the main licence as the GPL premable is from the GPL. ==Sections 1 and 1a.== This all looks fine. (More or less) ==Section 2== This clause looks weird: You need not include a copy of this License in the Work if you have registered the work's license with a national agency that maintains a network server through which the general public can find out its license. It does not seem to have any freeness problems though. There is also the still questionable DRM clause, which is described in more detail above. ==Section 3== That looks fine. ==Section 4== I will list the restrictions here and comment on each of them: A. Use a title distinct from that of the Work, and from those of previous versions of the Work as listed in the History section. This should be acceptable as we allow name changes clauses, but it could be inconvenient if we needed to make a change to a manual. B. List as authors (on the Title Page, if any), one or more persons or entities responsible for authorship of the modifications in the Modified Version. C. Credit (on the Title Page, if any) at least five of the principal authors of the Work (all of them, if it has fewer than five) if the material derived from the Work is more than 1/4 of the total. That means that the author(s) of the modifications must be listed on the Title Page, and 5 (or all if less than five) of the main authors of the previous version. They avoid author list explosion because the maximum number of previous authors that must be credited is 5. So that is all fine, although it seems odd to require the name of the most person(s) who made the most recent changes on the Title Page, even if those changes were insignificant. D. Prominently state the name of the publisher of the Modified Version. E. Preserve all the copyright notices of the Work. F. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices. Fine. G. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below. I have reported the lack of Addendum , and the problem with explosive growth of licence notes to the FSF. But those arenot freeness problems. H. Include an unaltered copy of this License. Reported weird inconsistancy with section 2 to FSF. This is not really a freeness issue. I. Preserve the section Entitled History, Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version. If there is no section Entitled History in the Work, create one stating the title, year, authors, and publisher of the Work, then add an item describing the Modified Version as stated in the previous sentence. Should be fine. J. Preserve the network location, if
Re: Object Management Group redistributable files
Hi Francecsco, On Sun, Oct 01, 2006 at 10:45:32PM +0200, Francesco Poli wrote: The binary portability requirement implies that a user can take the generated stub and associated files (helpers, holders, etc.) that were generated using a particular vendor's IDL compiler, and use them on another vendor's runtime. Hence the above limitations restricting an implementor's freedom to modify the required classes. This is a broken logic reasoning. It seems that upstream think that, *since* modifying functionality could deviate from a standard and break binary compatibility (which is true), *then* the license must absolutely forbid any modification to functionality (which is IMHO wrong). Sorry, I'm not sure I was clear enough in the first email. The OMG writes the CORBA specs, and delivers the bare-minimum files matching those specs as a base for a real implementation. The JacORB team wrote a compliant CORBA stack based on those files. So yes, upstream thinks deviating from the standard they have written should be avoided. Firstoff, forbidding *any* functional modification obstructs useful external contributions that could help to *enhance* compliance with the standard. But, more importantly, who says that deviations from a standard are bad in themselves? Well, the standard authors :) A piece of software that conforms to a standard could usefully be modified into a derivative work that does completely different things and thus obviously does not conform to the above standard anymore! Or the derivative work could even conform to another standard (maybe a more recent version of the same standard!). Indeed. But I don't think this use case is forbidden by the readme.txt. The next to last paragraph reads: `files [...] shall be provided by *conformant* products as is' (emphasis is mine). I believe this does not prevent non-conformant products to alter them. To sum up: modifications should be *not* be disallowed. Upstream could be recommended to release the work in a DFSG-free manner (suggested licenses: GPLv2 http://www.fsf.org/licensing/licenses/gpl.txt or Expat http://www.jclark.com/xml/copying.txt) and, if they feel This has been discussed in [3] and lead to a rewrite of the files in classpath. like, to separately provide a standard-compliance test (itself DFSG-free under the same license, but with the official version GPG-signed by them) that can check any standard-compliant-wannabe implementation in order to see, well, if it can be claimed to be standard-compliant. That way, derivative works would be allowed, even non-conforming ones. Simply, there would be an easy test to tell conforming and non-conforming derivatives apart and users could clearly know what they would be using. Does this make sense to you? The Open Group handles compliance already[1], but not for free, even though this has already happened[2]. A DFSG-free standard-compliance test would be great, but I don't see this happening in a near future :( (Note that if the OMG files do not fulfill the DFSG, I could still patch JacORB so that it only use GNU classpath org.omg files, which are aligned on CORBA 2.3 whereas JacORB is on 2.5. That would mean lowering CORBA compliance but would give us a DFSG-free Java ORB) A DFSG-free non-recent Java ORB is maybe better than a non-free more-recent one. I'm looking into this. Thanks, Thomas [1] http://www.opengroup.org/certification/corba-home.html [2] http://www.opengroup.org/press/7jun99_a.htm [3] http://lists.gnu.org/archive/html/classpath/2005-03/msg00025.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
OSSAL/CC license of xMule parts
Hello, I'm currently preparing an updated xMule package and found a statement, which sounds a bit problematic. But I'm not a lawyer, so I ask you. E.g. xLibs/DynPrefs/DynamicPreferences.cpp states: // This file is dually licensed under the terms of the following licenses: // * Primary License: OSSAL - Open Source Software Alliance License // * See the included License.OSSAL for complete details. // * Key points: // 5.Redistributions of source code in any non-textual form (i.e. // binary or object form, etc.) must not be linked to software that is // released with a license that requires disclosure of source code // (ex: the GPL). // 6.Redistributions of source code must be licensed under more than one // license and must not have the terms of the OSSAL removed. // // * Secondary License: Creative Commons Attribution-NoDerivs License v1.0 // * See the included License.CCANDL for complete details. // * Key Points: // * You are free: // * to copy, distribute, display, and perform the work // * to make non-commercial use of the work in its original form // * Under the following conditions: // * Attribution.You must give the original author credit. // * No Derivative Works.You may not alter, transform, or build upon // this work. // // * Special exceptions: // I, Theodore R.Smith, hereby grant, as the sole author of this library, // exclusive permission to the xMule Project to distribute and link to this // library, specifically voiding clause 5 of the OSSAL for the xMule Project. // As a further exclusive permission, when linked to the xMule Project, // the terms of the GPL concerning binary distribution must be observed. // // For more information on legality, see README.txt. I'm not sure of any of these licenses is DFSG-free. AFAIK the CC licenses are considered non-free and I'm concerned about the OSSAL too (that forbids linking against GPLed libraries). And the exceptions don't seem to allow Debian to link against GPLed libraries. Can you clarify the situation? Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OSSAL/CC license of xMule parts
Daniel Leidert wrote: I'm not sure of any of these licenses is DFSG-free. AFAIK the CC licenses are considered non-free and I'm concerned about the OSSAL too (that forbids linking against GPLed libraries). And the exceptions don't seem to allow Debian to link against GPLed libraries. Can you clarify the situation? The OSSAL, at least as defined here: http://people.freebsd.org/~seanc/ossal/ also has a BSD advertising clause: 3. All advertising materials mentioning features or use of this software should, in good faith, display the following acknowledgment: This product includes software developed by the AUTHOR and its contributors. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Public discussion time for Creative Commons 3.0 license draft coming to a close
Hi, everyone. Pardon the wide distribution, but I wanted to make sure I didn't miss anyone. As some of you know [1], a workgroup within Debian cooperating with Creative Commons [2] to make some of their licenses compatible with the Debian Free Software Guidelines [3] so that CC-licensed works (images, video, sounds, documentation, help text) can be part of the Debian operating system. [4] We reached some good conclusions, which resulted in the current Creative Commons 3.0 license but unfortunately some of the people in the Creative Commons community -- a diverse one, just like Debian's -- have managed to knock the process off track. [5] The license draft now available leaves out some key clauses that the workgroup thought necessary to make the license DFSG-compatible. The draft has been subject to public review for more than a month now, and the discussion period is drawing to a close. Creative Commons general counsel has said that they'll consider public opinion when it comes to making a final decision about this license. So, for those of you who want to see Creative Commons licenses that meet our standard of Freedom, this is the time to act. Please, if you haven't already, take a few minutes to send an email message to the Creative Commons public review mailing list [6] letting CC know that you support a Debian-compatible version of the license. I want a Debian-compatible Creative Commons license, signed John Q. Hacker is probably plenty. Complaining to each other 6 months from now won't do any good; the time to complain is now, when it can make a difference. We've got a narrow window in which to let CC know that the Free Software guidelines matter. Please spread the word to other Debian users and supporters as well as into the rest of the Free Software community. Thanks for your time, ~Evan [1] http://evan.prodromou.name/Debian_Creative_Commons_Workgroup_report [2] http://creativecommons.org/ [3] http://www.debian.org/social_contract#guidelines [4] http://people.debian.org/~evan/ccsummary [5] http://creativecommons.org/weblog/entry/6017 [6] http://lists.ibiblio.org/pipermail/cc-licenses/ -- Evan Prodromou [EMAIL PROTECTED] The Debian Project (http://www.debian.org/) signature.asc Description: This is a digitally signed message part
Re: New bugs filed regarding non-free IETF RFC/I-Ds
On Mon, Oct 02, 2006 at 05:49:16PM +0200, Simon Josefsson wrote: Some of these documents MAY be freely available -- check with the author -- but as far as I could see, in no case was this noted in the copyright file, so I'm assuming they are redistributed based on the IETF license, which I believe we've agreed is DFSG-nonfree. Lobbying individual authors to release their documents under a more free license would be a good thing, but I don't have time to pursue that path. Hopefully some package maintainer will want to pursue it... This would've been a good suggestion to include in the bug reports themselves, which I don't remember seeing to be the case? 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 draft of GFDL and GSFDL
Time to see what we would need to change to make it DFSG-free. On a quick readthrough of the SFDL, it looks like this to me: * Unlike the GFDL, no Invariant Sections or Cover Texts. And they can't be added, so it doesn't break copyleft. * Transparent and Opaque definitions look OK this time. * The anti-DRM clause looks like it's still problematic. It appears to prohibit parallel distribution, because it applies to *any copies*. It should be written to apply to *any recipient*, not any copy. This is the prime point which should be fixed. * The requirement to include the license in the work, rather than making it accompany the work, is made much less obnoxious by the excerpt clause. * The mandatory History section is irritating, but much like a Changelog, so probably DFSG-free. * Acknowledgements and Dedications could be non-free requirements if they were abused, but I'm not sure. I think the requirements are free in this draft, because - only applies to actual acknowledgements and dedications - only applies when the acknowledged/dedicated work is still present - may make modifications which preserve the substance and tone In conclusion, on a first glance, I think the only clause I really want to get changed is the anti-DRM clause. -- Nathanael Nerode [EMAIL PROTECTED] Make sure your vote will count. http://www.verifiedvoting.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
