Bug#384934: Does not depend on Xen hypervisor as advertised in description
Package: xen-linux-system-2.6.17-2-xen-686 Version: 2.6.17-7 Severity: grave [EMAIL PROTECTED]:~$ apt-cache show xen-linux-system-2.6.17-2-xen-686 | grep-dctrl -sPackage,Description,Depends . Package: xen-linux-system-2.6.17-2-xen-686 Description: XEN system with Linux 2.6.17 image on PPro/Celeron/PII/PIII/P4 This package depends on the binary Linux image and the correct hypervisor. Depends: linux-image-2.6.17-2-xen-686 (= 2.6.17-7) The same problem exists with xen-linux-system-2.6.17-2-xen-k7. - Josh Triplett signature.asc Description: OpenPGP digital signature
Bug#370295: DLJ prevents running jython with sun-java
Steve Langasek wrote: > On Mon, Jun 05, 2006 at 01:46:29AM -0700, Walter Landry wrote: >> Steve Langasek <[EMAIL PROTECTED]> wrote: >>> On Sun, Jun 04, 2006 at 08:16:24AM -0700, Walter Landry wrote: >>>> This can be fixed by making Jython conflict with sun-java, although I >>>> suspect that there may be other packages that also cause problems. > >> Another fix for this particular problem is to make sun-java not >> Provide:java-runtime etc. at all. Good point. That would tend to decrease the utility of sun-java, but it should avoid most of the issues. >>> There have been various clarifications that the intent of this clause is to >>> prohibit distributing sun-java5 in a configuration that mixes and matches >>> parts of Sun's implementation with other Java implementations. I don't think any of the clarifications have limited the clause to that sole purpose, and furthermore I don't think even that much of a clarification addresses the question of what constitutes such a configuration. See my message referenced at the end of this mail for examples that seem to me to fall under such a description. >>> Why are these clarifications not sufficient when we regularly accept >>> clarifications of this nature from other copyright holders? > >> There are a few problems here: > >> 1) Clarifications from other copyright holders do not come with a big >>disclaimer stating that the clarification has no legal weight. >>Debian relies on the clarification having legal weight. > > Well, this seems to have just changed in the case of the DLJ. I agree; the FAQ now seems sufficiently binding to meet the standards of other license clarifications Debian has accepted, in my opinion. I also think the answers in the FAQ address many of the other concerns raised by debian-legal: the issue of whether distributing in non-free (which Debian does not consider part of the distribution) counts as distributing with the OS, the issue of whether users can develop software for non-Debian platforms using the JDK (not a freeness issue but an important question), and the issue of whether removal affects mirrors or stable releases. >> 3) There are only two clarifications I know of. One is in the >>non-binding DLJ FAQ, and the other is from Tom Marble [1]. Neither >>of these clarifications limit the restrictions to Java >>implementations. For example, in Tom's clarification he says [2] > >> In a similar way please don't take bits from the Java platform >> and use them as part of or to complete alternate technologies >> (e.g. plugin.jar). > >> So using Java's plugin mechanism to implement python plugins for >> Jython is not allowed. And this makes sense. Sun would definitely >> be unhappy if the JDK were used to implement J++ or C#, especially >> because they are not Java. > > That's not actually clear to me; "alternate technologies" is very vague. > I'm also not convinced that dropping the java-runtime provide from the Sun > Java packages is the sort of thing Sun intends with this, either. > Basically, it seems to me that the cited clarification from Tom happens to > not clarify much after all... Same with the clarification in the FAQ. It seems to answer some questions (we don't need to worry about non-Java software qualifying as "similar functionality"), but not others; see my message referenced below for examples of what I don't think it addresses. > BTW, if jython is the only package that poses a problem for this clause, I'm > not sure there's much to worry about anyway here: jython is RC-buggy and > likely to be dropped from etch, because it build-depends on (and implements) > python2.1, which is 3 stable releases behind where we expect the main python > implementation to be for etch. Other packages raise similar concerns; please see my message <[EMAIL PROTECTED]>, available at <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=370295;msg=10>, for other examples, as well as suggested fixes for the DLJ (or the FAQ now that it looks like a sufficiently binding clarification) which would address those concerns. The bug probably needs a new title. :) I see no problem with the idea of not letting other Java-related software use pieces of Sun Java. My primary concern lies in avoiding any possibility that a package in main will need to change to satisfy the DLJ. - Josh Triplett signature.asc Description: OpenPGP digital signature
Bug#370295: More direct replacement examples
As more direct examples than Jython:
gjdoc implements javadoc. If a user installs a
non-natively-gcj-compiled gjdoc and the Sun Java packages, and then runs
gjdoc, it will run gjdoc with the Sun Java packages. That looks very
much like a violation of DLJ clause 2 (c).
jikes-sun implements a javac compiler, and uses the Sun JDK.
Any libfoo-java package in Debian will run with the current installed
JDK. Thus, any libfoo-java package in Debian which implements "the same
or similar functionality" as Sun Java causes Debian to violate the
license on Sun Java. Obvious examples include libswingwt-java (which
implements much of the Swing API), libcharva1-java, libcommons-*-java
("similar functionality"), Java XML processing tools that implement the
standard APIs, libgnu-regexp-java (since, if I recall correctly, Sun
Java includes regular expression handling), liboro-java (same reason),
libregexp-java (same reason), libgetenv-java (specifically notes itself
as a replacement for java.lang.System.getenv), and probably others.
Most of these issues would go away if DLJ 2 (c) limited itself to
software which replaces Sun's java.* or javax.* APIs; since Sun Java
prevents non-Sun software from doing so unless you use -bootclasspath,
Debian need only ensure that nothing invokes Sun Java with
-bootclasspath. This does not handle the case of running software like
gjdoc with Sun Java; to handle this, the clause could limit itself to
software which provides binaries with the same names, and then implement
the planned solution of preventing Sun Java from running with any of the
java alternatives set to software from other packages. Software like
jikes-sun which explicitly makes use of Sun Java components may still
violate the DLJ even with these measures in place, but packages in
contrib take their chances about remaining distributable; such packages
may need to declare conflicts, or this package may need to declare
conflicts on them.
Alternatively, this package could conflict with any and all software in
Debian considered objectionable to DLJ clause 2 (c), but this seems like
an unmaintainable option.
- Josh Triplett
signature.asc
Description: OpenPGP digital signature
Bug#339085: tail +n stopped working again
Michael Stone wrote: > On Thu, May 25, 2006 at 05:24:06PM -0700, you wrote: >> $ seq 1 10 | tail +5 >> tail: cannot open `+5' for reading: No such file or directory > > Yeah, it's intentional (see changelog). I don't intend for this version > to enter testing yet, so people reading this please don't be tempted to > close or downgrade the bug. I had already seen the changelog entry. I reopened the bug to request that this syntax continue to work. How often do people tail files named with a plus sign follwed by a number (and can't just use tail ./+NUM or tail -- +NUM), versus how many people have tail +NUM burned into finger memory? The same applies to sort +NUM. Furthermore, third-party software will likely still rely on this for quite some time to come. I do agree that packages should get fixed to avoid this issue by using tail -n +NUM and sort -k NUM+1, and all the packages in Debian may even have these fixes in place already (though it looks like they don't; see 368909 for an example regarding usage of sort +NUM in cvs), but changing tail and sort to no longer support this behavior for interactive use or third-party software violates user expectations in a big way. If you *do* decide to go this route, then at a minimum this change needs: * An entry in debian/NEWS.Debian.gz , including an explanation of the environment variable setting (_POSIX2_VERSION=199209) needed to get the previous behavior, and a pointer to 'info coreutils "Standards conformance"', * A note in the tail and sort manpages, including the same explanation and pointer, * A mail to various appropriate places, including debian-user, debian-devel-announce, and anywhere else that seems appropriate, and * An extremely good justification for why we should break this syntax, and what it gains us to do so. "Precisely conform to POSIX 1003.1-2001" by itself may or may not qualify. This justification should get included in all three of the above. - Josh Triplett signature.asc Description: OpenPGP digital signature
Bug#339085: tail +n stopped working again
reopen 339085 thanks [control BCCed] $ seq 1 10 | tail +5 tail: cannot open `+5' for reading: No such file or directory - Josh Triplett signature.asc Description: OpenPGP digital signature
Bug#368902: underscore.sty non-free as shipped; author relicense available
Package: texlive Version: 2005-1 Severity: serious underscore.sty as shipped in texlive has the following non-free license: % Copyright 1998,2001 Donald Arseneau; Distribute freely if unchanged. However, I wrote to Donald Arseneau and he agreed to relicense this file under the LPPL; including his mail in the debian/copyright file should make underscore.sty distributable in main (and also permit inclusion in tetex as well). I've quoted his mail below. - Josh Triplett Donald Arseneau wrote: > Josh Triplett <[EMAIL PROTECTED]> writes: >> % Copyright 1998,2001 Donald Arseneau; Distribute freely if unchanged. >> >> Would you be willing to license this file under the standard LaTeX >> Project Public License, or another Free Software license? > > Yeah. Following that original short permission, I should use the LPPL. signature.asc Description: OpenPGP digital signature
Bug#323099: License of wget.texi: suggest removal of invariant sections
Hrvoje Niksic wrote: > Don Armstrong <[EMAIL PROTECTED]> writes: > >> On Thu, 18 May 2006, Hrvoje Niksic wrote: >>> Including the text of the GPL in Wget's manual serves the purpose >>> of explaining Wget's copying terms to the user. As such, it seems >>> pertinent regardless of whether Wget is actually distributed along >>> with the manual. >> To reiterate what you said above, our problem is that the GPL can't be >> removed at all,[1] even when it's no longer applicable, not that it's >> being included by wget.texi in the first place. > > What I don't understand is how the GPL can be "no longer applicable", > given that it's not possible to change Wget's license. If the > copyright holder (in this case the FSF) decided to change the license, > surely they could also remove the invariant section? Don't just think in terms of the software the current manual describes (namely Wget), which of course remains GPLed. First, you could distribute the Wget manual without distributing Wget, in which case the GPL itself no longer obligates you to include it since you don't distribute GPLed software, but the Wget manual license notice requires you to continue distributing it. Second, you might modify the manual to make a smaller form, such as a manual page, and want to avoid including more extra text than you need to. Third, someone might want to adapt some part of the Wget manual for their own documentation, which might document an LGPLed library, or a MIT-licensed work, and thus shouldn't have to include a potentially confusing third license. - Josh Triplett signature.asc Description: OpenPGP digital signature
Bug#346354: AW: Bug#346354: Is distribution of the maxdb-doc package a GPL violation?
Steve Langasek wrote: > On Thu, Apr 27, 2006 at 05:35:51AM -0700, Walter Landry wrote: >> [EMAIL PROTECTED] wrote: >>> I have verfified that the actual sources for the generated HTML are >>> Microsoft Word documents and that those will not be >>> distributed. Does the mean that the maxdb-doc package will have to >>> be pulled from the repository? > >> Yes, unless you get a license exemption from the copyright holder >> allowing Debian and its mirrors to distribute the HTML as is. They >> will probably agree. In that case, it goes into non-free. > > It's not obvious to me that either the license exemption or the non-free > categorization are necessary here. GPL requires the "preferred form for > modification", which for most people working on derivative works would > probably *not* be the Word docs? As I understand it, "preferred form for modification" means the preferred form by a person who made modifications (in other words, upstream), not the preferred form of those who would like to make modifications (in other words, downstream). In any case, I'd sooner edit a Word document (using OO.o, Abiword, or similar) than the "HTML" that Word outputs. - Josh Triplett signature.asc Description: OpenPGP digital signature
Bug#363061: Implicit granting of rights?
Frank Küster wrote: > Ralf Stubner <[EMAIL PROTECTED]> wrote: >> On Fri, Apr 14, 2006 at 15:14 +0200, Frank Küster wrote: >>> , >>> | %%% Copyright (C) 1994 Aloysius G. Helminck. All rights reserved. >>> | %%% Permission is granted to to customize the declarations in this >>> | %%% file to serve the needs of your installation. However, no permission >>> | %%% is granted to distribute a modified version of this file under >>> | %%% its original name. >>> ` > > That would be just on the right side of the border set by DFSG #4 (note > that it's a TeX input file, so it is both source and used form), but No, it falls just on the wrong side; licenses can restrict the name of the *work*, as in the human-parsable name, but filenames serve as a functional component of a work. This issue came up with the previous version of the LPPL. For example, would you accept as DFSG-free a license which said you must change the SONAME of a library if you changed the library? That would mean you could not legally create a compatible work. >>> But it doesn't even allow use - don't know whether this is implicitly >>> granted? >> I would vote for implicitly granted usage rights, but IANAL. > > Can we in fact assume such implicit granting of rights? It seems logic > to me, because there are no "needs of your installation" if all I may do > is meditate over the contents of the file. But I'm not sure whether > what seems logic to me is logic in IP law... Generally, I think you can assume the right to *use* something. However, you can't assume the right to modify or distribute, and this license does not grant any permission to distribute. It also seems to restrict which modifications you can make; among other things, you can't modify it to serve the needs of *other* installations, or modify anything other than declarations. It may well *intend* to grant the right to distribute (unmodified or with another filename) and the right to all possible modifications, but it doesn't appear to actually do so. - Josh Triplett signature.asc Description: OpenPGP digital signature
Bug#362882: libxosd-dev Depends: xlibs-static-pic, which no longer exists
Package: libxosd-dev Version: 2.2.14-1.2 Severity: serious libxosd-dev Depends: xlibs-static-pic, which no longer exists in unstable. The corresponding libraries now exist as shared libraries. Also, libxosd-dev depends on the transition packages xlibs-static-dev and x-dev; in the former case, use the same shared library -dev packages as above (only the ones you need), and in the latter case, use x11proto-core-dev. - Josh Triplett signature.asc Description: OpenPGP digital signature
Bug#362877: libdmx-dev: insufficient version in Pre-Depends on x11-common
Package: libdmx-dev Version: 1:1.0.1-2 Severity: serious libdmx-dev Pre-Depends: x11-common (>= 1.0); it needs to include the epoch. - Josh Triplett signature.asc Description: OpenPGP digital signature
Bug#360539: [Pkg-mythtv-maintainers] bugs.debian.org forwarding the pkg-mythtv-maintainers list
Mark Purcell wrote: > On Monday 03 April 2006 18:29, Ian Campbell wrote: >> I also see that I have my first bug >> report :-( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=360539 "Must >> go to contrib: requires non-free (and non-distributable) firmware" >> >> The logs say it was forwarded to the list (it's registered as the >> maintainer address) but I never received it via the list and it isn't in >> the archives. Does the BTS need to be whitelisted or similar? > > You are correct. The list at present is pretty much setup to hold everything > it doesn't know about. I can whitelist bugs.. I did indeed receive an "awaits moderator approval" message after submitting the bugreport. Please do whitelist bugs so that submitters don't receive such a message. (Unfortunately, the BTS itself tends to get spammed, but I don't know any way to avoid that.) >> On the subject of the bug report, I know there is some controversy about >> firmware in main etc but I haven't really been following so I don't know >> if the project has reached a consensus about what is to be done. Does >> anyone know or have any pointers? I don't know that the decision is as >> clear cut as the bug suggests and I don't want move stuff around >> unnecessarily. >> >> (FWIW I don't have an opinion myself on where firmware requiring >> packages should go, I'll follow the project's policies/guidelines). > > Well there are some packages, which have firmware dependencies which are in > main. But generally that is because they have utility without the firmware. Right. As I understand it, some such packages go in main because they drive various hardware, only some of which requires proprietary firmware; other such packages go in main because they form only a small part of the kernel in main, and thus the entire kernel doesn't need the proprietary firmware. I don't think ivtv falls into either of those categories: as far as I can tell, all ivtv-supported cards require firmware images, so the package doesn't serve any function at all without the firmware. - Josh Triplett signature.asc Description: OpenPGP digital signature
Bug#360539: Must go to contrib: requires non-free (and non-distributable) firmware
Package: ivtv-source Version: 0.6.1-1 Severity: serious The ivtv drivers require non-free (and non-distributable) firmware in order to run. See http://ivtvdriver.org/index.php/Firmware . Thus, the ivtv drivers and utilities need to go in contrib, not main. - Josh Triplett signature.asc Description: OpenPGP digital signature
Bug#359184: uninstallable; uses old C++ ABI, Depends on libraries no longer in testing/unstable (last upload in 2004)
Package: showeq Version: 5.0.0.14-1 Severity: grave showeq cannot install in testing or unstable. The last upload of showeq occurred in 2004, built with gcc-3.3, using an old C++ ABI and thus building against libraries that no longer exist in testing or unstable. - Josh Triplett signature.asc Description: OpenPGP digital signature
Bug#254113: New version of ttf-freefont to test
Christian Perrier wrote: > I just built a new upstream version of ttf-freefont. As Konstantinos > is mostly away currently, I wanted to give a try for getting a new > version in as the graphical installer could benefit it. > > I am not at all a font guy...I just took some time to build this new > version. > > Can people who experienced spacing problems with former versions test > that one ? > > http://people.debian.org/~bubulle/ttf-freefont No spacing problems either with this version or with the current version in Debian. - Josh Triplett signature.asc Description: OpenPGP digital signature
Bug#336983: PATCH: Fix for qemu build on PowerPC
Guillem Jover wrote: > On Thu, Dec 15, 2005 at 07:45:23PM -0800, Daniel Gimpelevich wrote: >>If that release is imminent, there is something that I would >>like to take care of beforehand: I think I have found a bug that causes >>random garbage to be passed to a syscall under certain circumstances, >>and I have yet to determine whether the upstream sources or the Debian >>patches are at fault. > > Josh Triplett fixed the signal related support on ppc, if this is > related you could try the latest svn debian dir. Otherwise we can > upload now and once you get the fix a new version can be uploaded > again. I would definitely recommend trying the latest debian directory from SVN, but I would mention that I've also observed some syscalls failing in the PowerPC emulation for unknown reasons, and I'd be interested in any details you might have about that problem. In particular, I've observed poll() failing with EPERM, which shouldn't be possible. - Josh Triplett signature.asc Description: OpenPGP digital signature
Bug#341228: Direct copyright and trademark infringement
Ignoring the possible issue of "making a similar game" being somehow an infringement independent of actual copying of game data, the far more blatant and relevant issue is that the game data still directly uses material copyrighted and trademarked by Konami. The maintainer mentioned in the changelog that they "Removed non-free original graphics", which is true: they removed the graphics set "alternate" which was simply the original graphics with various improvements, leaving the "naramura" graphics set which appears to be *mostly* an original creation. However, this graphics set still includes several chunks of non-original or trademarked data, including: * The title screen in "start.pcx" which includes the trademark "Konami" and a derived game logo. Compare the layout and font of the words; they look like a near-exact match, with just a color change and an increased size. Creating an original logo design, and avoiding the trademarked company name would solve this issue. For reference, BTW, a quick search on the USPTO website indicates that there are no trademarks on the game name itself, only on "Konami"; on the other hand, choosing an original game name would avoid some extra trouble, and make it easier to claim the logo image is original. * The Konami logo in konami.pcx; trademarked and copyrighted by Konami. This should be removed entirely, as should any and all references to the word "konami" in the entire work. * It is possible, given these issues, that some of the other graphics were not drawn from scratch, and may be modified versions of the original graphics. Most look original to me, but to be certain, it would be a good idea to contact the original author of the graphics set. Any non-original graphics need to be replaced by original graphics. - Josh Triplett signature.asc Description: OpenPGP digital signature
Bug#336227: bumprace uses backgrounds from digitalblasphemy.com
Package: bumprace-data Version: 1.5.1-1 Severity: serious The in-game help for bumprace includes credits for the various components; one of them is "Backgrounds: Unknown (see AUTHORS)". From the AUTHORS file: > Backgounds grabbed from the "eterm-backgrounds_1.0-1.deb" the authors say > about > it: > "NONE of these images are original work by either of the Eterm authors; they > have all been collected from various sites on the web. As far as I know, they > are all freely available for use. > > However, should any person who can provide proof of ownership of any of these > pictures object to their inclusion, they will be IMMEDIATELY withdrawn. No > copyright infringement is intended. Inclusion here should be taken as a > compliment. :-)" The eterm-backgrounds package referred to here has not existed since slink. The actual background used in the package comes from digitalblasphemy.com, with a watermark containing that URL in the lower-right corner of the image. The digitalblasphemy backgrounds are nowhere near free enough even for non-free; see <http://www.digitalblasphemy.com/webmasters.shtml> for the details, but basically only personal use is permitted without permission from the author. The background depicts an earth-like planet with two moons and a partially-eclipsed surface. It should be possible to get a similar image via celestia or xplanet. - Josh Triplett signature.asc Description: OpenPGP digital signature
Bug#306996: Adds maintainer's personal bin directory to $PATH
Package: gcjwebplugin
Version: 0.3.1-2
Severity: grave
>From src/gcjwebplugin.cc:
> static NPError
> start_appletviewer_process(void)
> {
>
> // Add install prefix to PATH.
> char *searchpath = getenv("PATH");
> char *newpath = NULL;
>
> if (searchpath != NULL)
> {
> newpath = strcat(searchpath, ":/home/mkoch/local/gcjwebplugin/bin");
> }
> else
> {
> newpath = "/home/mkoch/local/gcjwebplugin/bin";
> }
>
> setenv("PATH", newpath, 1);
- Josh Triplett
signature.asc
Description: OpenPGP digital signature
Bug#298289: Thread error when starting Mozilla and gcjplugin is installed
package gcjwebplugin tags 298289 + patch thanks I can reproduce this error. It is caused by not initializing the thread support early enough; the call to g_thread_init should be made before creating the mutex, not right before locking the mutex. Replacing debian/patches/thread-init.patch with the attached thread-init.patch fixes this problem. Also, gcjwebplugin needs to link against gthread, not just glib; otherwise a relocation error occurs when loading the plugin. (I don't know why this doesn't already occur with the current binary package in Debian.) Applying the attached link-to-gthread.patch and regenerating the autoconf files will fix this problem. - Josh Triplett --- src/gcjwebplugin.cc.orig 2004-11-28 00:02:14.0 -0800 +++ src/gcjwebplugin.cc 2005-04-29 09:45:06.155640024 -0700 @@ -514,6 +514,10 @@ pluginTable->urlnotify = NewNPP_URLNotifyProc(GCJ_URLNotify); pluginTable->getvalue = NewNPP_GetValueProc(GCJ_GetValue); + // Initialize threads (needed for mutexes). + if (!g_thread_supported ()) +g_thread_init (NULL); + mutex_appletviewer_process = g_mutex_new (); return NPERR_NO_ERROR; --- gcjwebplugin-0.3.1.orig/acinclude.m4 2004-07-20 10:44:09.0 -0700 +++ gcjwebplugin-0.3.1/acinclude.m4 2005-04-29 10:02:08.853166368 -0700 @@ -3,7 +3,7 @@ dnl --- AC_DEFUN([GCJWEBPLUGIN_CHECK_GLIB],[ -PKG_CHECK_MODULES([GLIB],[glib-2.0 >= 2.0]) +PKG_CHECK_MODULES([GLIB],[gthread-2.0 >= 2.0]) AC_SUBST([GLIB_CFLAGS]) AC_SUBST([GLIB_LIBS]) ]) signature.asc Description: OpenPGP digital signature
Bug#303091: fancybox is non-free
Package: tetex-extra Version: 2.0.2c-7 Severity: serious >From the file /usr/share/texmf/tex/latex/misc/fancybox.sty in tetex-extra: > %% COPYING: > %% Copying of part or all of this file is allowed under the following > %% conditions only: > %% (1) You may freely distribute unchanged copies of the file. Please > %% include the documentation when you do so. > %% (2) You may modify a renamed copy of the file, but only for personal > %% use or use within an organization. > %% (3) You may copy fragments from the file, for personal use or for > %% distribution, as long as credit is given where credit is due. > %% > %% You are NOT ALLOWED to take money for the distribution or use of > %% this file or modified versions or fragments thereof, except for > %% a nominal charge for copying etc. This license is non-free; it prohibits charging for distribution, requires renaming for modification, and restricts the use and distribution of modified versions. This license also makes the relatively common mistake of believing it can impose restrictions (such as renaming) in the case of personal use; while unenforceable, such attempted restrictions are non-free. The authors should be contacted and asked to relicense fancybox under the current version of the LPPL (or another Free license). If they do not wish to relicense fancybox, or they cannot be contacted, fancybox must be removed from Debian main. - Josh Triplett signature.asc Description: OpenPGP digital signature
Bug#298600: copyright file refers to LGPL 2.1, but points to LGPL-2 file
Package: bzflag Version: 2.0.0.20050118 Severity: serious >From the copyright file: > It may be redistributed under the terms of the GNU LGPL, Version 2.1 > found on Debian systems in the file /usr/share/common-licenses/LGPL-2. The upstream license is the LGPL 2.1, so the reference to the common-licenses file should refer to /usr/share/common-licenses/LGPL-2.1 . Or if upstream uses "or any later version", it should refer to /usr/share/common-licenses/LGPL, which is a symlink to the latest version. - Josh Triplett signature.asc Description: OpenPGP digital signature
Bug#293210: bluez-bcm203x firmware loader depends on non-free firmware
Package: bluez-bcm203x Version: 2.10-4 Severity: serious [Previously discussed via private mail with maintainer. I'm going ahead and reporting this to have it recorded somewhere.] From the description of bluez-bcm203x: > Firmware loader for Broadcom 203x based Bluetooth devices > This package contains a firmware loader for users of the 2.4 Linux > kernel and Broadcom 203x based Bluetooth devices. From debian/copyright of the non-free bluez-firmware package, which contains the firmware this package can load: > The BlueZ project has permission from Broadcom Corporation to > distribute this firmware in conjunction with the BlueZ GPLd > tools, available in Debian as bluez-utils, as long as the notice > contained in /usr/share/doc/bluez-firmware/BCM-LEGAL.txt accompanies > the firmware. > > This arrangement was made with BlueZ author Max Krasnyansky > <[EMAIL PROTECTED]>. This raises many issues: * Since bluez-bcm203x seems to exist only to load this non-free firmware, it should have a "Depends: bluez-firmware" rather than "Suggests: bluez-firmware". * For the same reason, the bluez-bcm203x package should be moved to contrib. * The indicated grant of permission to distribute requires that the distribution be "in conjunction with the BlueZ GPLd tools, available in Debian as bluez-utils". Given that non-free isn't part of Debian, it seems difficult to argue that the bluez-firmware package in non-free is being distributed "in conjunction with" the blues-utils package in main, or even a bluez-bcm203x package in contrib. - Josh Triplett signature.asc Description: OpenPGP digital signature
Bug#290726: mozilla-enigmail is uninstallable; requires Mozilla 1.7.3 but unstable has 1.7.5
Package: mozilla-enigmail Version: 2:0.89.0.experimental-1 Severity: serious Tags: experimental The mozilla-enigmail package is uninstallable, because it requires Mozilla 1.7.3, but unstable has 1.7.5 . - Josh Triplett signature.asc Description: OpenPGP digital signature
Bug#290242: prozilla: Nonfree
Brian Nelson wrote: > On Thu, Jan 13, 2005 at 12:16:21AM -0800, Josh Triplett wrote: >>Justin Pryzby wrote: >>>ftpparse.c heading: >>> >>> Commercial use is fine, if you let me know what programs >>> you're using this in. >>> >>>Which I believes fails the desert-island test? Legal, can you >>>confirm? >> >>Confirmed; requirements to notify the author are non-free. > > Bullshit. There's no requirement whatsoever that a source file may be > used at all "commercially", assuming the common definition of > "commercial" == "closed source". First of all, that's not a common definition; even if it were, it is not a correct one. "commercial" means "related to commerce"; proprietary/closed-source programs need not be involved in commerce, and commercial programs need not be proprietary/closed-source. Second, there is certainly no requirement that a source file may be used in closed-source software; however, I seriously doubt that that is what this license is referring to. "commercial" (or more commonly "non-commercial") in licenses refers almost exclusively to money-making purposes; I have never seen a license that used "commercial" to mean "proprietary". Finally, even if we were to assume that it is possible the license means what you suggest (that the only type of use for which notification is required is proprietary use), then due to the multiple possible meanings of "commercial", the license is ambiguous at best, and therefore we need clarification. - Josh Triplett signature.asc Description: OpenPGP digital signature
Bug#289750: widelands-data contains non-free font Knights.ttf
Package: widelands-data Version: build8-2 Severity: serious widelands-data contains the font file Knights.ttf, containing the font KnightsTemplar. "strings Knights.ttf" reveals that the font is by Iconian Fonts, for which Googling leads to http://www.iconian.com/ . The front page of that site says: > All fonts are e-mailware, meaning the fonts are distributed for free > personal use and for use by charities or non-profit organizations (as > these are generally, to me, noncommercial uses). Feel free to contact > me if you would like to use any of the fonts for commercial purposes. > I do ask that if you like any of my fonts, you please let me know by > e-mailing me at [EMAIL PROTECTED], hence the name "e-mailware". These > fonts may be freely distributed and may be included on any free font > archive site so long as the "readme" text file is not removed from > the ZIP file. If you have more questions, try the FAQ. This does not satisfy the DFSG, as it requires contacting the author, and restricts types of use. This font should be removed from the widelands-data package as soon as possible, and replaced with some Free font. In the meantime, I'll try contacting the font designer, and see if they would be willing to permit use of that font under the GPL. - Josh Triplett signature.asc Description: OpenPGP digital signature
