Re: Hypothetical situation to chew on
On Tue, Jan 04, 2005 at 11:01:41PM -0500, Nathanael Nerode wrote: > Yes, this is what SUCKS about current copyright law. The presumption is "All > rights reserved unless you have explicit permission". The fact that it never expires is what sucks about it. The default copyright permissions aren't so bad, by comparison, as long as you're aware of it. :) That's one of the major contributions of debian-legal, in my opinion: making people aware of how copyright affects their projects (giving it at least the force of "sorry, we just can't distribute this safely"), that it can't simply be ignored, and that in many cases, it can be dealt with reasonably by ordinary humans. (In some cases--possibly like this one, where there may be accumulated licensing errors over years--it may be too late, though.) -- Glenn Maynard
Is the LLVM Release License DFSG-compatible?
Please 'reply all' on any replies as I don't normally subscribe to debian-legal, and it will also document the discussion along with the ITP. I've filed an ITP for LLVM -- the Low-Level Virtual Machine, a compiler toolset that provides a C and C++ compiler. More info on LLVM can be found at http://llvm.cs.uiuc.edu. The ITP is #239415. LLVM licensing is a little more complicated than most packages, but I still believe it to be DFSG-compatible and eligible for being in main. Part of LLVM (the C front-end) is borrowed directly from GCC and distribution of the C front-end used by LLVM is covered under the same licensing as GCC. The remainder of LLVM is covered by the LLVM Release License (see http://llvm.cs.uiuc.edu/releases/1.4/LICENSE.TXT) which is actually the University of Illinois/NCSA Open Source License. The University of Illinois/NCSA (UI/NCSA) license is very similar to the MIT or BSD license, and software distributed under the UI/NCSA license is OSI Certified Open Source Software (please see http://www.opensource.org/licenses/UoI-NCSA.php). Being paranoid about this sort of stuff, I also examined a fairly large random sample of the files (there are ~22K files in the source tree and I sampled roughly 500 of them). Those files all either contained the proper licensing text or were covered by by a file containing the proper text. I also used an experimental text comparison tool to examine all files and feel very confident that the source files are all properly covered by the licenses above in some way. So, based on my understanding of the DFSG, and my understanding of the licensing, I believe this package will be fully DFSG- compatible. What say you all? -- Ciao, al -- Al Stone Alter Ego: Linux & Open Source Lab Debian Developer Hewlett-Packard Company http://www.debian.org E-mail: [EMAIL PROTECTED][EMAIL PROTECTED] --
Re: Hypothetical situation to chew on
[EMAIL PROTECTED] wrote: > I'm vaguely aware of a piece of software which contains both GFDL > licensed material, and possibly code which was dropped in without > actually checking the licence for compatibility with the GPL. > > A gargantuan number of people over the years have contributed code to > it, and many have claimed copyright for their contributions. No policy > of copyright-assignment has been used. > > > So here's a hypothetical situation; say the current upstream maintainer > was to announce in a very public place, with Cc's to all known > contributor e-mail addresses, his intent to change the licence of the > code to GPL-2 (including documentation) and give a full list of > everything that would fall under it. And then was to give a period (say > 28 days) for objections to be raised. > > If none were raised, could they then change the licence? No. :-P Yes, this is what SUCKS about current copyright law. The presumption is "All rights reserved unless you have explicit permission". >If not, what procedure would be needed to make the software DFSG-free? >I'm going to guess clean-room rewrite of all of the documentation, and >of any code that could be affected? Not *quite*. But close. (1) Every piece of code must be audited to determine the copyright holders. (I *hope* they kept track of that, but many don't.) The author of any major portion or major collection of changes -- or his/her employer if it was work for hire and the author was in a country with that doctrine -- is a copyright holder for that portion. (Unless that person has explicitly released it to the public domain, or it was published without copyright notices in the US prior to, I believe, 1986 -- in those cases it's in the public domain.) (2) If the author of a piece cannot be identified, and the piece is not clearly in the public domain, it must be clean-room rewritten. (3) If the author can be identified, and agrees explicitly to relicense the code (or the license for the code is already OK), it can be kept. (4) If the author can be identified, but does not agree explicitly to relicense the code (whether this is because he/she can't be reached or because he/she refuses or because he/she is incomprehensible), it must be clean-room rewritten. So, (3) is the exception to your rule; the work of anyone who can actually be tracked down, and who agrees to relicense, can be relicensed. Perhaps surprisingly, many people can be tracked down, and *do* agree to relicense. For large chunks, this may be easier than clean-room rewrites. For small chunks, probably it's harder. I know of several packages which fall into this rather nasty category, and I haven't had the heart to work on most of them. I wish you luck.
Re: mozilla thunderbird trademark restrictions / still dfsg free?
On Tue, Jan 04, 2005 at 05:44:08PM -0800, Michael K. Edwards wrote: > > So the question is: is the right to call a bit of software by a certain > > name an "important freedom"? That's definitely debatable. The name you > > use to refer to a bit of software doesn't affect its function. > > It can, especially in the case of a web browser; consider web servers > that verify that the client claims to be a sufficiently new Mozilla or > IE before sending DHTML. What a client calls itself to servers (eg. in User-Agent headers) isn't an issue. That's a very functional use of the name, telling the server how to handle the client, not telling a user what program he's running. I don't think trademarks can touch that. Note that my copy of Explorer calls itself: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705) and every other browser I have installed either does the same or offers it as an alternative. (Anyone who knows more about trademarks than I do is encouraged to tell me I'm wrong, of course. IANAL.) -- Glenn Maynard
Re: mozilla thunderbird trademark restrictions / still dfsg free ?
"mozilla _wants_ us to make some changes to the thunderbird package in order to not infringe their trademarks." I think plenty of dialog with Mozilla is a good idea. If they don't like the way we package Thunderbird or any of the other packages, I recommend using really generic names for each of the packages, then refer to the Mozilla names in the descriptions, such as: Debian Web browser based on Mozilla Firefox Debian Email client based on Mozilla Thunderbird Debian browser suite based on Mozilla or something similar that makes them happy and still makes things like package searches contain a searchable string that people can recognize. I have a hard time believing that after all this time they want people to get away from their names, but if that's really what they want, let's do it. But let's not make up any new funky names. That just opens up the possibility of other issues elsewhere. If we must change the name at all, let's associate it with our project and a generic term describing the application. Can that get us into any trouble? Hopefully not. -- Brian Masinick mailto:[EMAIL PROTECTED]
Re: mozilla thunderbird trademark restrictions / still dfsg free?
Gervase Markham wrote: So the question is: is the right to call a bit of software by a certain name an "important freedom"? That's definitely debatable. The name you use to refer to a bit of software doesn't affect its function. Yes, that's right, but we don't want to be upstream or another fork. We package free software provided by upstream. That is, we usually distribute the tarballs as they are and build the package with modifications we need to do in order to keep up with some debian standards or to improve the quality. In contrast, the package you want us to distribute is not distributed by upstream. You distribute something that is restricted by active trademark enforcement, which IMHO is non-free, because a trademark policy is just another way to restrict freedom. You referred often to 'we'd have to negotiate'. OK, fine. Let's start with it. Maybe you give up on some off your procedures. e.g. you could give up restrictions you try to enforce on us. I mean, debian (as well as other free software distributors) is (are) should not need to care if there is a trademark for some package or something. There is no problem for thousands of packages we include, so why mozilla? The whole issue arises with your policy document. If no such thing would exist, we (including mozilla) would probably have no problem here. Nevertheless, you could still claim your brand your own IMHO. It is just a problem on how you define "actively enforcing" a trademark. AFAIK, enforcement of trademarks can be of preventive or responsive nature. I think if you treat your trademarks like others do (in a responsive manner), there would be no problem either. (This might be wrong, though, because me != lawyer) AFAICS, other projects use a responsive enforcement for their trademark. I assume this, because they did not come to us. I bet they would go after commercials or other organizations that actually want to harm the brand significantly. On the other hand, going behind the small guys that distribute their super gcc cvs HEAD build of a package is somehow different. Usually those guys are somewhat private and they actually have no intent nor the potential to harm your trademark. Maybe they get 100 downloads of this super unstable package, but that's it. If the quality sucks, people won't come back, but will typically not think: "This piece of software is firefox? What a bad brand!". IHMO, people installing those builds will more or less know what they are doing. Actually, I think there is a much greater probability, that some stupid guy somehow gets your pretty broken HEAD-prealpha-fancy-testings-stuff still-branded-premium-build on his box and wonders why the UI is somehow broken. After installing the right version, he finds his profile is broken and as a stupid user his pop mail inbox is lost too. I bet, the user will find this is _no inbox reclaim_, but rather _an inbox wipe-out_ :). What I am trying to say is that mozilla is far too eager in enforcing their trademarks. I hope this is because you just think this is needed by law. I hope this is not because you really believe it helps the overall purpose or will maximize the value of your brand. Finally, I cannot tell you what to do. But I think it is your turn to break this vicious circle. As Glenn just pointed out, this is completely uncommon. So why do you want to go this way anyway? Try to rethink your attitude, maybe escalate this issue to mozilla management or do what is needed to do, to actually keep things going. I doubt there is a solution unless you do so. -- GPG messages preferred. | .''`. ** Debian GNU/Linux ** Alexander Sack | : :' : The universal [EMAIL PROTECTED] | `. `' Operating System http://www.jwsdot.com/ | `-http://www.debian.org/
Re: mozilla thunderbird trademark restrictions / still dfsg free?
> So the question is: is the right to call a bit of software by a certain > name an "important freedom"? That's definitely debatable. The name you > use to refer to a bit of software doesn't affect its function. It can, especially in the case of a web browser; consider web servers that verify that the client claims to be a sufficiently new Mozilla or IE before sending DHTML. It looks to me like there's a real storm brewing over trademark enforcement in open source space. At least in most US jurisdictions, trademark law applies an "enforce it or lose it" standard, and one of the key criteria in judging whether a company takes its trademark seriously is whether it exercises quality assurance over third parties to which it has (explicitly or implicitly) licensed the right to distribute goods or services marked with its trademark. In a hypothetical situation where Debian is the dominant distribution channel for Software X, performs QA functions, and handles the bulk of bug reports, the upstream for Software X could actually lose ownership of the trademark to Debian. Even when the distributor relationship is non-exclusive, a failure to exercise QA authority over the Debian channel could weaken Mozilla's ability to enforce the trademark on other channels. (Imagine "Mozilla Firefox, MS Authorized Edition" with the crippling limitations of your choice.) The drafters of the classic open source licenses weren't thinking in terms of trademark issues. UC Berkeley probably couldn't enforce trademark constraints on "BSD" now if it tried. The FSF persists in the assertion that the (L)GPL isn't a contract at all, it's some sort of non-contract license (with no legal foundation that I can find) created out of copyright law, and so as a matter of principle the (L)GPL doesn't address trademark questions. (In both cases that I have run across in which GPL software has been discussed in US courts, trademark rights were enforced by the court.) So the Mozilla folks are being responsible in setting out the limits of the license to use their trademarks as part of the MPL, rather than leaving the issue unaddressed and then springing it on people in court. I think it would be a good idea to work out a modus vivendi with them, such that the names of Debian-packaged Mozilla products are unchanged, and designated persons from Mozilla have the right to file RC bugs that the maintainer isn't allowed to downgrade. That at least preserves the forms of trademark defense, at a rather minimal cost in freedom. The only consistent alternative that I can see is to yank packages when the upstream pursues a trademark issue against any infringer -- which means dropping MySQL and RPM for starters, and Mozilla, Apache, and Linux before long. Somehow this doesn't seem wise. Cheers, - Michael
Re: mozilla thunderbird trademark restrictions / still dfsg free?
On Wed, Jan 05, 2005 at 12:06:12AM +, Matthew Garrett wrote: > Francesco Poli <[EMAIL PROTECTED]> wrote: > > > Exactly. > > DFSG #8 seems quite clear to me: we do *not* consider Free > > something that gives all the other important freedoms to Debian only, > > and not to downstream recipients as well. > > There's some contention over this. Based on the discussion on > debian-private that led to the DFSG, I think 8 was effectively shorthand > for ensuring that every freedom enumerated in the DFSG was available to > any further recipients. Others disagree. I asked Bruce about this, but > never got a reply. Just to be clear: except for the "clear" part, you're agreeing with Francesco, right? -- Glenn Maynard
Re: Trademarks: what is the line?
On Wed, Jan 05, 2005 at 12:03:15AM +, Gervase Markham wrote: > >>The Mozilla trademark license seems to be rather harmless > >>at that because they give permission to retain the command names. > > > >Judging from the followups to your message, it seems that this is not > >the case... :-( > > Indeed. If you renamed the product, you'd need to change the command and > package names also. The command (eg. the binary's filename) is a functional element, which can not--to my limited understanding--be restricted by trademark. Debian can always provide a "mozilla" binary (or symlink), that runs "debzilla". (This wouldn't be an unreasonable thing to do, given the "alternatives" paradigm, as long as the program itself was properly renamed--eg. it doesn't say "Mozilla" in the title bar.) Note that copyright licenses which require changing command names are not allowed by the DFSG. DFSG#4 allows requiring the name of the program to be changed, but requiring the command itself to be changed essentially prohibits compatibility, which goes too far. I suspect that while the package name would be changed, a helper "mozilla" package would point people to it. Of course, it'd be nice if the resolution of this doesn't require Debian to rename Mozilla. However, as it's very uncommon for people to brandish trademarks in this way--among free software, at least--there's not much experience with how they interact with Debian's required freedoms. I can't remember the last time a trademark issue was even raised on debian-legal. This is somewhat evidenced by the amount of head-scratching going on--it may take some time to figure out. -- Glenn Maynard
Re: mozilla thunderbird trademark restrictions / still dfsg free?
Francesco Poli <[EMAIL PROTECTED]> wrote: > Exactly. > DFSG #8 seems quite clear to me: we do *not* consider Free > something that gives all the other important freedoms to Debian only, > and not to downstream recipients as well. There's some contention over this. Based on the discussion on debian-private that led to the DFSG, I think 8 was effectively shorthand for ensuring that every freedom enumerated in the DFSG was available to any further recipients. Others disagree. I asked Bruce about this, but never got a reply. Personally, I have no objection to Debian being given freedoms that other users don't, providing that everyone obtains rights that satisfy the DFSG. -- Matthew Garrett | [EMAIL PROTECTED]
Re: mozilla thunderbird trademark restrictions / still dfsg free?
Francesco Poli wrote: Exactly. DFSG #8 seems quite clear to me: we do *not* consider Free something that gives all the other important freedoms to Debian only, and not to downstream recipients as well. So the question is: is the right to call a bit of software by a certain name an "important freedom"? That's definitely debatable. The name you use to refer to a bit of software doesn't affect its function. Gerv
Re: Trademarks: what is the line?
Francesco Poli wrote: Yes, but is requiring a global replacing of trademarked strings and images acceptable? I mean: it seems that Mozilla is requiring us * either to comply with strict modification constraints Not so strict, really. Certainly not to the level of preventing security patches. Exactly how it would work would be something we'd negotiate. * or to replace every and each trademarked reference to the work with something else Which isn't too hard, given that we have centralised branding files. The Mozilla trademark license seems to be rather harmless at that because they give permission to retain the command names. Judging from the followups to your message, it seems that this is not the case... :-( Indeed. If you renamed the product, you'd need to change the command and package names also. Gerv
Re: mozilla thunderbird trademark restrictions / still dfsg free?
On Mon, 3 Jan 2005 23:28:43 -0700 Joel Aelwyn wrote: > If those rights are not available - under the same terms - to our > downstreams (be they users, custom distros... whatever), then by the > spirit of DFSG #8 (at least IMO), we shouldn't be able to make use of > them either. Exactly. DFSG #8 seems quite clear to me: we do *not* consider Free something that gives all the other important freedoms to Debian only, and not to downstream recipients as well. -- 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 pgpwdgBHyUe20.pgp Description: PGP signature
Re: Trademarks: what is the line?
[Since Sylpheed messed up with the GPG signature, I resend this message
(hopefully) correctly signed; I apologize for this]
On Fri, 31 Dec 2004 13:56:45 +0100 Florian Weimer wrote:
> They are not entirely unrelated. The DFSG explicitly mentions
> mandatory renaming clauses in licenses, and deems them to be
> DFSG-free.
Yes, but is requiring a global replacing of trademarked strings and
images acceptable?
I mean: it seems that Mozilla is requiring us
* either to comply with strict modification constraints
* or to replace every and each trademarked reference to the work with
something else
First option seems unacceptable (we couldn't even patch for security
reasons before they decide to release a new version, correct me if I'm
wrong).
Second option would require the Debian package maintainer to dig into
the source and play "seek & destroy" with all cases in which the work is
referenced as "Mozilla {thunderbird|firefox}" or in which the official
logo is used...
This seems a bit more than requiring a name change (per DFSG 4).
> The Mozilla trademark license seems to be rather harmless
> at that because they give permission to retain the command names.
Judging from the followups to your message, it seems that this is not
the case... :-(
--
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
pgp7M8tXO8aSR.pgp
Description: PGP signature
Re: Hypothetical situation to chew on
On Tue, Jan 04, 2005 at 10:37:30PM +, Scott James Remnant wrote: > I'm vaguely aware of a piece of software which contains both GFDL > licensed material, and possibly code which was dropped in without > actually checking the licence for compatibility with the GPL. I'm not quite sure what you mean. Is there one work or two here? The GFDL is GPL-incompatible, so is the "GFDL licensed material" part of "code which was dropped in"? > So here's a hypothetical situation; say the current upstream maintainer > was to announce in a very public place, with Cc's to all known > contributor e-mail addresses, his intent to change the licence of the > code to GPL-2 (including documentation) and give a full list of > everything that would fall under it. And then was to give a period (say > 28 days) for objections to be raised. > > If none were raised, could they then change the licence? No. You can't announce "unless you say otherwise, your copyrighted work is now under this license". I don't know if there are other means to relicense. There's been vague talk of things like "joint works", and also talk of what rights an "editor" can do. These have never been particularly well-explored, though: a means to grant permissions without the original author's consent isn't something most people here want to figure out a way to do, I assume. (If it's possible, it's probably not a good idea to try without asking a lawyer.) -- Glenn Maynard
Re: Hypothetical situation to chew on
On Tue, Jan 04, 2005 at 10:37:30PM +, Scott James Remnant wrote: > So here's a hypothetical situation; say the current upstream maintainer > was to announce in a very public place, with Cc's to all known > contributor e-mail addresses, his intent to change the licence of the > code to GPL-2 (including documentation) and give a full list of > everything that would fall under it. And then was to give a period (say > 28 days) for objections to be raised. > > If none were raised, could they then change the licence? Not with any kind of legitimacy. The copyright holders who have not explicitly agreed to the new license would be fully justified in ignoring it, and treating all licensees as if they were still working to the old one. No private individual can make a declaration of the form "Respond now or forfeit your copyright". > If not, what procedure would be needed to make the software DFSG-free? > I'm going to guess clean-room rewrite of all of the documentation, and > of any code that could be affected? That would work. Alternatively, just cut anything whose author can't be traced or contacted - there's no need to throw away stuff written by somebody who agrees to the new license. That does mean line-by-line verification though, so it might not be practical (depending on whether contributions are concentrated in some areas or uniformly distributed). -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: LCC and blobs
I demand that Glenn Maynard may or may not have written... > On Tue, Jan 04, 2005 at 06:22:20PM +, Darren Salt wrote: >>> On Tue, Jan 04, 2005 at 01:48:12AM +, Darren Salt wrote: >> [fetching firmware on finding hardware which needs it: wget or packaged?] Fetch every time and fetch once. That looks like a difference to me... >>> How could "fetch every time" possibly be acceptable to the SC when "fetch >>> once" is not? Are you saying that the "rancid-installer" package could go >>> in main, if it re-downloaded and reinstalled the program every time it >>> was used? Of course not--there is no difference to the SC. >> I don't believe that I've made any comments about freeness of the firmware >> installer package (though I've definitely said things about kernel modules >> for devices which, to be useful, require firmware uploads). I merely >> consider fetch-every-time to be broken (and you can add "firmware no >> longer available for download" to the list of reasons). > Since this is a discussion of freeness and SC#1, it's differences in > freeness that are relevant here. In response to "no difference: contrib at > best", you said "that looks like a difference", which certainly looks like > a comment on freeness. It looked to me like you were saying that there was no difference between fetching always and fetching once. ISTM (now) that you've removed too much and I've removed not enough. > (Unless you do have something to say about freeness, let's let this > subthread die; [...]) I could say something, but I think that in the general case, it wouldn't add to what has already been said. In the specific cases, well, let's wait for them to be mentioned :-) >> They were relevant to the text which you *didn't* snip. You should have >> summarised them or left them in place. >> And you've not marked where you've removed text :-\ > When I think some indication of removal is useful, I mark it with a blank > line between quotes, instead of ">"; this is clear enough, since the full > text is always available. ... but said full text may not have been received locally, and the reader may be offline - in which case, how is he meant to distinguish between your blank line and a blank line left by the original author and possibly devoid of quote indication due to its having been removed because the line was otherwise blank? > All text in all messages is relevant to other text; not removing text which > is relevant to some other quote would mean never removing anything. [...] Degrees of relevance? (Probably best to let that lie.) -- | Darren Salt | linux (or ds) at | nr. Ashington, | woody, sarge, | youmustbejoking | Northumberland | RISC OS | demon co uk | Toon Army | Let's keep the pound sterling If I send this, does that mean that you'll read it?
Hypothetical situation to chew on
I'm vaguely aware of a piece of software which contains both GFDL licensed material, and possibly code which was dropped in without actually checking the licence for compatibility with the GPL. A gargantuan number of people over the years have contributed code to it, and many have claimed copyright for their contributions. No policy of copyright-assignment has been used. So here's a hypothetical situation; say the current upstream maintainer was to announce in a very public place, with Cc's to all known contributor e-mail addresses, his intent to change the licence of the code to GPL-2 (including documentation) and give a full list of everything that would fall under it. And then was to give a period (say 28 days) for objections to be raised. If none were raised, could they then change the licence? If not, what procedure would be needed to make the software DFSG-free? I'm going to guess clean-room rewrite of all of the documentation, and of any code that could be affected? Thanks in advance, Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: LCC and blobs
On Tue, Jan 04, 2005 at 06:22:20PM +, Darren Salt wrote: > > On Tue, Jan 04, 2005 at 01:48:12AM +, Darren Salt wrote: > [fetching firmware on finding hardware which needs it: wget or packaged?] > >> Fetch every time and fetch once. That looks like a difference to me... > > > How could "fetch every time" possibly be acceptable to the SC when "fetch > > once" is not? Are you saying that the "rancid-installer" package could go > > in main, if it re-downloaded and reinstalled the program every time it was > > used? Of course not--there is no difference to the SC. > > I don't believe that I've made any comments about freeness of the firmware > installer package (though I've definitely said things about kernel modules > for devices which, to be useful, require firmware uploads). I merely consider > fetch-every-time to be broken (and you can add "firmware no longer available > for download" to the list of reasons). Since this is a discussion of freeness and SC#1, it's differences in freeness that are relevant here. In response to "no difference: contrib at best", you said "that looks like a difference", which certainly looks like a comment on freeness. (Unless you do have something to say about freeness, let's let this subthread die; my response said "who cares about implementation details for something which clearly doesn't help the software get out of contrib", and this isn't going anywhere.) > They were relevant to the text which you *didn't* snip. You should have > summarised them or left them in place. > > And you've not marked where you've removed text :-\ When I think some indication of removal is useful, I mark it with a blank line between quotes, instead of ">"; this is clear enough, since the full text is always available. All text in all messages is relevant to other text; not removing text which is relevant to some other quote would mean never removing anything. (As your complaints about my quoting are both frivilous and in a somewhat demanding tone, I doubt I'll respond to them any further.) -- Glenn Maynard
Re: LCC and blobs
I demand that Glenn Maynard may or may not have written... > On Tue, Jan 04, 2005 at 01:48:12AM +, Darren Salt wrote: [fetching firmware on finding hardware which needs it: wget or packaged?] >> Fetch every time and fetch once. That looks like a difference to me... > How could "fetch every time" possibly be acceptable to the SC when "fetch > once" is not? Are you saying that the "rancid-installer" package could go > in main, if it re-downloaded and reinstalled the program every time it was > used? Of course not--there is no difference to the SC. I don't believe that I've made any comments about freeness of the firmware installer package (though I've definitely said things about kernel modules for devices which, to be useful, require firmware uploads). I merely consider fetch-every-time to be broken (and you can add "firmware no longer available for download" to the list of reasons). > This could be as simple as mounting a tmpfs on /lib/firmware, and > wgetting >> [my comments about network availability removed - RELEVANT CONTEXT] > The removed quotes were superfluous to my response, so no, they weren't > relevant. Stop yelling. They were relevant to the text which you *didn't* snip. You should have summarised them or left them in place. And you've not marked where you've removed text :-\ -- | Darren Salt | linux (or ds) at | nr. Ashington, | woody, sarge, | youmustbejoking | Northumberland | RISC OS | demon co uk | Toon Army | http://www.youmustbejoking.demon.co.uk/> (PGP 2.6, GPG keys) Answers on a postcard please to 10 Downing Street, London SW1.
Re: LCC and blobs
Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote: > Hamish Moffatt <[EMAIL PROTECTED]> writes: >> So if EEPROMs contain software, why "don't [you] get to distribute any >> drivers"? I don't understand. > > You can get software out of an firmware-EEPROM on a hardware device. > I don't think it's appropriate to call that software as is, or in > general. This line *could* be drawn in lots of places, but if you say > that the contents of an EEPROM are software, then how about a one-shot > PROM? How about a book with a print-out of the source code? A PROM generally contains software (unless you're going to argue that executable code is not always software, in which case I'm going to ignore you). A book is a representation of software but not software itself, since the book exists outside the digital domain. > The only reasonable place to draw the line, for Debian, is this: can > Debian physically ship it in a useful way? For files on disk, the > answer is yes. We are constrained only by the license. For the book > or the PROM, the answer is no. For an EEPROM, in general, the answer > is no. For any such correctly operating device, the firmware is > already there. Debian can't usefully ship it. It would be > interesting to try supporting an architecture to run on those devices > instead of Wind River or whatever, but there isn't one now. Ignoring license constraints, I can find you any number of cases of eeproms where Debian could ship the contents. I can probably find you several that would run on hardware you currently own. Again, drawing the distinction at this point results in the solution that provides more practical freedom to the user being penalised. This implies very strongly that we're doing something wrong. > When the firmware has to be uploaded, it's a dependency. If it were > just a magic initialization sequence, that would be OK -- such a > sequence is presumably too short to copyright. But this is long and > non-free, clearly software, and clearly a dependency. The dependency is not on the specific firmware in question - the dependency is on code that will cause the general purpose device to behave in the way that the driver expects. In the vast majority of cases, the only code that currently satisfies that constraint is non-free, but there's no intrinsic reason why it has to be so. We can compare this to other hardware. The orinoco wireless driver depends on the hardware acting in a specific way, and does this by communicating with the firmware in the device. In doing so, it is communicating (and hence depending) upon non-free executable code - ie, software. But, again, there's no intrinsic reason why it has to be so. You could write free firmware, or you could reimplement the device in such a way that it doesn't actually have any firmware (for sufficiently simple cases, you might be able to reimplement it in a fairly large quantity of clockwork), and hence remove the dependency. But these are hypotheticals. Drivers that require loaded firmware tend to use non-free code, and drivers that require hardware to respond in certain ways tend to use non-free firmware on that hardware. In both cases, we could reimplement something in order to remove that non-free dependency (either free firmware or hardware that doesn't use firmware), but *nobody has done so*. A hypothetical implementation of something without non-free code doesn't satisfy us. You have argued that drivers don't really depend on firmware, but instead depend on the hardware expressing the correct interface. As an example, we can compare maria-vis, which depends on the graphviz package. maria-vis is in contrib, because it depends on graphviz, which is in non-free. But by your argument, it doesn't actually depend on graphviz - it merely depends on something that presents a correctly functioning graphviz interface. This could be a piece of non-free code, but it could also be a piece of free code, an interface to a remote application server, or a userspace application to drive hardware that kicks intelligent rodents until they draw the correct graph. There's no intrinsic dependency on the non-free code. But since the non-free code is currently the only solution that /does/ express the correct interface, there exists a dependency on non-free code. If you can find me a piece of hardware that can be driven by the kernel's orinoco driver and which contains no non-free executable code, I will agree that the driver does not require the use of non-free executable code. But not until then. -- Matthew Garrett | [EMAIL PROTECTED]
Re: Bug#288429: asterisk: Hold music are not DFSG-free
Dear all, * Jose Carlos Garcia Sogo ([EMAIL PROTECTED]) [050104 13:05]: > tags 288429 -sarge-ignore > El lun, 03-01-2005 a las 20:57 +0100, Kilian Krause escribió: > > tags 288429 +sarge-ignore Please do not add or remove the sarge-ignore tag. The sarge-ignore tag might only be added by the release team, and removing should also not be done without coordination (except that of course the maintainer can always declare any issues as release critical for his package, means: also remove the sarge-ignore tag). Thanks, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Bug#288429: asterisk: Hold music are not DFSG-free
tags 288429 -sarge-ignore thanks El lun, 03-01-2005 a las 20:57 +0100, Kilian Krause escribió: > tags 288429 +sarge-ignore > thanks > > Hi Jerome, > > Am Montag, den 03.01.2005, 19:40 +0100 schrieb Jerome Warnier: > > Subject: asterisk: Hold music are not DFSG-free > > Package: asterisk > > Version: 1:1.0.2-3 > > Severity: serious > > Justification: Policy 2.1 > > > > *** Please type your report below this line *** > > In the README.fpm file, it is stated that the Hold Music is non-free for > > use in anything else than Asterisk. > > that's technically correct, yet i'm very tempted to tag this bug as > wontfix until there's a decent license that's DFSG-free which we then > can propose to the asterisk upstream. I think that Jerome is right, and we have a problem with that file. It is not the same problem than we can have with GFDL docs or the problem of which is "the preferred source form" for images and sounds. Here that sound is licensed only for being used as hold music for Asterisk, nothing else. You couldn't even use it as dialtone for Asterisk, as I interpret the file. The only solution I see is removing that sound from upstream sources. Anyway I am CCing debian-legal for advise on this. Attached is README.fpm file. Cheers, About Hold Music Digium has licensed the music included with the Asterisk distribution From FreePlayMusic for use and distribution with Asterisk. It is licensed ONLY for use as hold music within an Asterisk based PBX.
OleMiss Email Account cnlawren DEACTIVATED
This account is no longer active. Thus, your mail regarding "[PMX:VIRUS] Re:" will not be received.
Re: mozilla thunderbird trademark restrictions / still dfsg free?
On Mon, Jan 03, 2005 at 11:56:24PM -0500, Brian Thomas Sniffen wrote: > Gervase Markham <[EMAIL PROTECTED]> writes: > > > We're happy to say that Debian doesn't tend to ship software that > > sucks - but you want the freedom to do so, and let others do so. And I > > understand that. :-) > > Here's an idea: a source package that builds either Thunderbird for > Debian or Lightningferret, a trademark-free version -- and defaults to > the latter, except on Debian autobuilders. The real source to build > the Thunderbird for Debian version is there, and it's a trivial > switch. But the work of producing a free-to-suck version is already > done. > > For reasons I can't fully articulate, I don't think that's a good > idea: source packages should be the plain and simple source of the > binaries produced. But I'm curious whether it would be accepted as > Free by debian-legal. What the package actually does is orthogonal to what rights are available, other than the former being bounded by the latter (at least we hope it is). If those rights are not available - under the same terms - to our downstreams (be they users, custom distros... whatever), then by the spirit of DFSG #8 (at least IMO), we shouldn't be able to make use of them either. Beyond that, alternate package building paths for reasons other than purely technical (debug libraries and the like) are just a Bad Idea. If it isn't of use to build a Debian package - or to let anyone else build the exact same package and distribute it just as we do - then, as a rule, it shouldn't be in the package; it's cruft. -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
