non-free firmware: driver in main or contrib?
Hi all! I have just packaged a driver for wifi cards. The driver is licensed under GPL, but the cards needs a non-free firmware to be uploaded in order to work. I don't know in which section the driver should go? main or contrib. I have been told that the driver does not need any firmware, but the card does. Cheers, Aurelien -- .''`. Aurelien Jarno GPG: 1024D/F1BCDB73 : :' : Debian GNU/Linux developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net
Re: non-free firmware: driver in main or contrib?
On Sun, 10 Oct 2004 19:08:25 +0200 Aurelien Jarno wrote: I don't know in which section the driver should go? main or contrib. I have been told that the driver does not need any firmware, but the card does. Probably the right question to ask is: is there any chance to use the driver without touching the non-free firmware (nor any other non-free stuff, for that matters)? IIUC, the free driver can go in main, as long as it provides a significant amount of functionality without depending on non-free stuff. Otherwise, it belongs in contrib. -- Today is the tomorrow you worried about yesterday. .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpMbXRHL4xpu.pgp Description: PGP signature
Re: Web application licenses
Brian Thomas Sniffen wrote: Josh Triplett [EMAIL PROTECTED] writes: Brian Thomas Sniffen wrote: Josh Triplett [EMAIL PROTECTED] writes: Glenn Maynard wrote: Here's a case that I'd remembered vaguely but havn't been able to find again until now: http://lists.debian.org/debian-legal/2003/03/msg00369.html In this case, the only realistic way to fulfill this type of source to network users requirement is by some other channel than the actual network. Costs aside, spamming the source at the SMS receiver is useless; it needs to be sent to a computer. Agreed. This isn't a matter of resources; the very medium itself is not designed for the transmission of source code, and a make the source available on the same medium could make use in this context not onerous, but impossible, and I think that's a clear non-free boundary. I don't think that's a non-free boundary at all. The GPL has the same make available on the same medium clause, so the No, it doesn't -- for two reasons. First, the referrerents are diffent. same medium as the binary and same medium as the interface are different. What if this is a kiosk? Must I provide source by scrolling it up the screen? Second, the GPL talks about a medium customarily used for software exchange. It specifically *doesn't* require the same medium, party to avoid this bug. You're taking one part of my message out of context, and analyzing it without considering the rest. I'm saying that the GPL has the same clause as the hypothetical license would, which is true by definition, since in the hypothetical license, I incorporated the GPL clause in question (3) by reference; I did not intend to suggest that on the same medium was the *only* option. There would be a full set of clauses that would parallel GPL clauses 3 a-c, so one could either accompany the binary with source, or distribute an offer. But the GPL doesn't *have* a same medium clause at all. There's nothing like that in the GPL. Some poster back there -- I can't tell through the quotes -- wrote that on the same medium is non-free. You countered that it isn't, because it's the same as the GPL. But the GPL doesn't have that at all. My apologies for the sloppy phrasing. s/same medium/same act of distribution/g. The point I was making was that by definition, the same wording for methods of distribution was used in both the hypothetical license and the GPL, because the hypothetical license referenced GPL clause 3 for its methods of distribution. I was simply drawing a similarity between the free path of the GPL and the hypothetical license, for the purposes of showing below that both can cause severe inconvenience. Please highlight the section of the GPL which you believe is similar to this, including the text which talks about source being distributed on the same medium. As I said above, same medium was sloppy phrasing; same act of distribution is more accurate. Providing the full source to this Wikipedia-like encyclopedia via SMS would be nearly impossible and prohibitively expensive, and as you said above, quite useless to the recipient. (And I don't think providing only the source for each page would be acceptable, nor would it really be feasible or useful either.) You would again need to provide the source via a separate medium. Why wouldn't providing the source for the page be acceptable? It's the work which is being copied to you. And Wikipedia is a great example of this: the source for a page is roughly the same order of magnitude as the page, and there's a link *right there* on every page to get the source. So you could GPL the content of Wikipedia and it would work fine as is, even over WAP for cellphones. (You seem to have switched from SMS to WAP. I'm going to stick with the SMS example for now.) First, it is quite a stretch to say that one page of a heavily-hyperlinked and interwoven encyclopedia is an independent work. To do so, I believe you would be implying that Wikipedia is merely an aggregation of a number of separate and independent works, which I do not believe is accurate. No, I'm not implying that at all. You're providing one part of a larger work, but when you separate it out by itself, sure, that's a work too. Articles in a normal encyclopedia are often credited to individual authors. It's not a mere aggregation of separate and independent works. It's a combination of integrated and dependent works. Sets of articles are interesting on their own; often, a singleton set is interesting. If you had truly taken Wikipedia and abridged it, creating a new work, which you then distributed, then it would be acceptable to distribute only the source for your new work. However, that is not what you are doing here. Instead, you are taking a larger work and serving pieces of it at a time. Perhaps you'd be more convincing with a different example, like a normal book. But an enclopedia is so clearly composed of many works precisely because it is
Re: firmware status for eagle-usb-*: non-distributable
posted mailed
Martin Braure de Calignon wrote:
I wanted to know if the binary files in the
eagle-usb-{utils,data,source} package are free.
No.
When I get the source of the package (apt-get source), there is a
LICENSE file in the root directory which says that the package is GPL.
But in the eagle-usb-1.9.9/driver/firmware/sagem/* directories, the
files seems to be binary files, and there's no sources for them. Are
they considered as data files only ? (like a picture ?)
No. But the situation is worse; see below.
Can you give me some information about this ? Does this package need
to be in non-free ?
This package is undistributable, for several reasons.
--
(1) From the GPL: This License applies to any program or other work which
contains a notice placed by the copyright holder saying it may be
distributed under the terms of this General Public License
Most of the upstream program does *not* contain such notices, so it doesn't
have a proper license and isn't technically distributable at all. Contact
the copyright holders and get them to fix this by adding the standard
notice:
one line to give the program's name and a brief idea of what it does.
Copyright (C) year name of author
...
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
Ideally the notice would be on *each file*. (Alternately, a single notice
in a toplevel file like LICENSE or README, which mentions that it covers
all the files in the tarball, would be fine, as long as it was accurate.)
Note that this must be done and approved, by all copyright holders:
- Copyright (c) 2001,2002 Analog Devices Inc.
- Copyright (c) 2002,2003 Christian Casteyde [EMAIL PROTECTED]
- Copyright (c) 2003,2004 Fred Sleeper Ros [EMAIL PROTECTED]
- Copyright (c) 2003 R. Guerin [EMAIL PROTECTED]
- Copyright (c) 2003,2004 Olivier Tux Borowski [EMAIL PROTECTED]
- Copyright (c) 2003,2004 Benoit Audouard [EMAIL PROTECTED]
(You can't license on behalf of a different copyright holder.)
--
(2) driver/eu_firmware.h is binary code without source code. It is
therefore non-free.
But more importantly, we don't have a license to distribute it.
It is licensed under the GPL according to the file. Unfortunately,to
distribute under the GPL, we'd need to distribute source in order to
distribute them, and we don't have source.
To put this in non-free, we need explicit permission from the copyright
holder (Analog Devices) to distribute *without* source. This means an
MIT/X11 license or a 2-clause BSD license, for instance.
Alternatively, Analog Devices could release the source code. It doesn't
need to be compilable with free tools to satisfy the GPL; it just has to be
the source code. Then we could put this in contrib.
(2) driver/firmware/sagem/* are binary code without source code. They are
therefore non-free. Worse, we have no license to distribute them at all.
Again, to put this in non-free, we need the copyright holder to issue them
under a license which allows them to be distributed. (Licensing under GPL
and including source would work. Licensing under 2-clause BSD and not
including source would also work.)
--
This package should be removed from Debian before Debian gets sued for
copyright infringement.
--
This space intentionally left blank.
Re: non-free firmware: driver in main or contrib?
Aurelien Jarno wrote: Hi all! I have just packaged a driver for wifi cards. The driver is licensed under GPL, but the cards needs a non-free firmware to be uploaded in order to work. I don't know in which section the driver should go? main or contrib. I have been told that the driver does not need any firmware, but the card does. If the driver does not provide any significant functionality without the firmware, it belongs in contrib. If there are some cards which the driver drives which work without the firmware, it can go in main. -- This space intentionally left blank.
Re: Bug#265352: grub: Debian splash images for Grub
Brian Thomas Sniffen wrote: Josh Triplett [EMAIL PROTECTED] writes: The trademark rights are entirely separate, and there's no reason for Debian to license them in any way other than Free for use if there's no confusion with Debian, either because they refer to Debian or because they're in a domain where Debian does no business. If you believe that to be the case, then I assume you would argue that we should not include any of the Debian logos within the Debian main distribution. That would be unfortunate. Or are you arguing that such a restriction would be DFSG-free? It seems to blatantly fail DFSG6. It doesn't fail DFSG 6 because it is explicitly protected by DFSG 4: the logo is a name. I strongly disagree with that, as I do with anything other than a set of words being called a name. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: non-free firmware: driver in main or contrib?
Nathanael Nerode [EMAIL PROTECTED] wrote: If the driver does not provide any significant functionality without the firmware, it belongs in contrib. If there are some cards which the driver drives which work without the firmware, it can go in main. Nowadays very few drivers will work without the presence of non-free software. This may be located in flash, or it may be loaded from the operating system. Why should a hardware implementation detail affect whether or not we include the drivers on a Debian CD? (Whether or not we should ship firmware is an entirely separate argument that I'm not massively interested in here) -- Matthew Garrett | [EMAIL PROTECTED]
Re: Bug#265352: grub: Debian splash images for Grub
Edmund GRIMLEY EVANS wrote: Josh Triplett [EMAIL PROTECTED]: Please note that I did not say that a work is non-free if it can be transformed to contain a trademarked item, any more than a work is non-free if it can be transformed to contain a copyrighted work to which we don't have a Free license, such as the source code to Microsoft(TM) Windows(TM). :) This doesn't really make sense. The only way you can transform a work to contain a different copyrighted work is by including parts of the other copyrighted work, which means you're transforming that other work, not just the first work. The comparison between trademarks and patents makes some sense; this comparison with copyright doesn't. My point is that I'm only concerned with trademarks that already cover the work, just as I'm only concerned with copyrighted works already included in the work. Whether you can transform the work to be covered by another trademark, just as whether you can transform the work by including another copyrighted work, depends on the license of that other trademark or other copyrighted work, and is irrelevant to the freeness of the existing work as it stands. I am only concerned with whether a given work, and all derived works of that work, have permission to use the trademark. Which trademark? Trademarkedness isn't a property of the work; trademarks exist independently of the work. Any trademark that already covers the work in question. I have no problem with Debian holding and licensing rights under both trademarks and copyrights that apply to Debian's works. The whole point of a trademark restriction is that it doesn't just apply to one's own works. But the only works to which it is relevant that the trademark license be DFSG-free are those works that are shipped in Debian main, and all derivatives of those works. Therefore, if we want to ship the logo in main, we need to grant a DFSG-Free license to the logo itself and to derived works of the logo. Why the if clause? Debian owning a trademark is a restriction on all works whether or not they include a representation of the trademark and whether or not Debian ships them, so surely what you are really saying is that Debian should not restrict the world's freedom by owning a trademark, which seems to me like a reasonable, if extreme, point of view. Do not put words in my mouth; I am most certainly not saying or advocating that. I am only stating that in order to ship the logo in main, it must be DFSG-free, and a necessary condition for the logo to be DFSG-free is that the trademark license must be DFSG-free. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: I have just packaged a driver for wifi cards. The driver is licensed under GPL, but the cards needs a non-free firmware to be uploaded in order to work. I will quote from policy 2.2.2: Examples of packages which would be included in _contrib_ or _non-US/contrib_ are: * free packages which require _contrib_, _non-free_ packages or packages which are not in our archive at all for compilation or execution, and * wrapper packages or other sorts of free accessories for non-free programs. Your driver can be compiled and successfully executed without the firmware, so it should go in main because it's free software. As you correctly stated, the card needs a firmware, not the device driver. The hardware device may not perform useful work until its firmware has been loaded, but we distribute the driver and not the device. A similar issue was raised for clients for proprietary instant messaging protocols like AIM and MSN: long ago it was decided that as long as they are DFSG-free they can be part of Debian, even if they are obviously useless without the proprietary servers they connect to. Considering that every complex device needs a firmware to work (of which usually we lack the source code), I cannot see why it should be relevant for our policy or detrimental to the cause of free software if this firmware is distributed by the hardware producer on a CD or in a flash EEPROM. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: Probably the right question to ask is: is there any chance to use the driver without touching the non-free firmware (nor any other non-free stuff, for that matters)? Can you quote which part of the policy describes this criteria? -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: If the driver does not provide any significant functionality without the firmware, it belongs in contrib. The driver provides all of its functionality without the firmware, the firmware never becomes part of the driver. The hardware device may or may not provide useful functionality, but debian is not in the business of distributing hardware. If there are some cards which the driver drives which work without the firmware, it can go in main. I can affirm with reasonable certainty that there is a very tiny number of devices in your computer which works without a firmware. -- ciao, Marco
Re: Bug#265352: grub: Debian splash images for Grub
Josh Triplett wrote: Similarly, the logo/logo image is used to identify Debian as Debian; it could be argued (and is currently being argued by many) that we need a license which prohibits those uses we find undesirable, such as use by competing (or even friendly) distributions. Again, this is non-free. No, the trademark prevents the use of the logo in misleading ways. In the same way I can't go and make a new distro called Debian, I can't use Debian's logo either. There is no requirement that misrepresentation be allowed in the DFSG.
Re: Bug#265352: grub: Debian splash images for Grub
Josh Triplett wrote: That's a huge leap, and I seriously doubt it was intended by the drafters of DFSG4. I would argue very strongly against that interpretation. A name is just that, a name: some text moniker that identifies a project. GCC, grub, Linux, and Apache are all names. A logo is not a name. How is Τεχ, a name, any different from the swirl? Both serve the same purpose, to uniquely identify; both do so in the same manner. What is the difference between a name and a logo? m-w.com gives a name as a word or phrase that constitutes the distinctive designation of a person or thing. Is the only real difference if you can find the identifier in the Unicode table? If so, that'd make --- IMO --- a very silly distinction. Especially since I can find ⌚, ⌛, ☝, ♕, etc. there. Or even 怂, which looks like it'd make a neat logo.
Re: non-free firmware: driver in main or contrib?
On Mon, 2004-11-10 at 01:50 +0200, Marco d'Itri wrote: Probably the right question to ask is: is there any chance to use the driver without touching the non-free firmware (nor any other non-free stuff, for that matters)? Can you quote which part of the policy describes this criteria? I think it's a question of what dependence means for contrib. If the driver absolutely _depends_ on using the non-free firmware, it should be in contrib. If the non-free firmware is optional, it should go into main. Of course, there's shades of gray, here. If all the driver does is emit a message CAN'T FIND NON-FREE FIRMWARE, ABORTING without the firmware, it's hard to say that it doesn't depend on the firmware. But if the mainline functionality works without the non-free part, and the firmware's just needed for extra stuff, then it might be a candidate for main. ~ESP -- Evan Prodromou [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
[Fwd: Re: firmware status for eagle-usb-*: non-distributable]
---BeginMessage--- Thanks for your answer, I have a mail from one of the developper of this software : QUOTE There's a wiki url to see about that : http://dev.eagle-usb.org/wakka.php?wiki=DeveloppementGPL It seems to me (Benoit Audouard) that you incorrectly inferred that we want to change licence - which is not the case - as this driver has been identified as GPL from the start by Analog Digital. All upstreams contributors have worked with GPL in fact and added headers whenever necessary and possible, we may have forgot some though ? You may review the URL given and provide precisions about missing points. I'll do my best to provide them, and I think that we'll have Sagem and ADI contacts that are willing to work on these points, as soon /QUOTE sorry for playing an intermediate role, the developper of the software will subscribe to debian-legal soon. Thanks -- Martin Braure de Calignon as they are provided with suficient information. ---End Message---
Re: Bug#265352: grub: Debian splash images for Grub
Anthony DeRobertis wrote: Josh Triplett wrote: That's a huge leap, and I seriously doubt it was intended by the drafters of DFSG4. I would argue very strongly against that interpretation. A name is just that, a name: some text moniker that identifies a project. GCC, grub, Linux, and Apache are all names. A logo is not a name. How is Τεχ, a name, any different from the swirl? Both serve the same purpose, to uniquely identify; both do so in the same manner. What is the difference between a name and a logo? m-w.com gives a name as a word or phrase that constitutes the distinctive designation of a person or thing. That's precisely the difference. A logo is not a word or phrase. I didn't really want to use a dictionary to support my point, but since you provided the definition... :) Is the only real difference if you can find the identifier in the Unicode table? If so, that'd make --- IMO --- a very silly distinction. Especially since I can find ⌚, ⌛, ☝, ♕, etc. there. Or even 怂, which looks like it'd make a neat logo. No, that's not the distinction. Those characters are not a word or phrase, they are symbols. (With the exception of the last, which according to gucharmap is some sort of ideograph.) There are symbols in Unicode that are not in words or phrases, and I think there are still words and phrases that use symbols not in Unicode. Regardless, in the face of an apparent ambiguity (though I would not consider it one), you seem to be advocating that we permit more restrictions, while I'm advocating that we permit less restrictions. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: Bug#265352: grub: Debian splash images for Grub
On Sun, Oct 10, 2004 at 03:51:11PM -0700, Josh Triplett wrote: I strongly disagree with that, as I do with anything other than a set of words being called a name. Why should this be an issue? It's clear that trademarks serve an identification role. We interpret the DFSG according to its spirit, rather than trying to interpret it as some kind of legal document, Anyways, it's my understanding that someone in the U.S. had his name legally changed to this, at one point: http://www.extractando.com/entretenimiento/image/PrinceSymbol.jpg But why should that even be an issue? Thanks, -- Raul
