3. If they charge a fee for the CD-ROM or other media on which
they deliver the Mugshot™ code, they warranty the media on
which the Mugshot™ code is delivered, thus ensuring that the
recipient receives a usable copy.

Paragraph 3 may be the first problem. It basically prevents "cheap CD"
vendors from selling copies of Debian on an "as is" basis.

I'm not sure this is a real concern. are they really selling the media
as-is?

So If the cd comes scratched so bad it does not work, or is warped,
the buyer has no recourse?
I can see no warrenty on data being useable for anything, but

I'm not aware of anybody who sells Disc's who does not have at least a
limited
warrenty covering manufactiong defects on the media. (As opposed to data
defects)

[Snip, following quote is in regard to the FTP part of the license]
If Red Hat consider a README in the same download directory to be good
enough then that should be fine, however.

Presumably it would be fine in general. However, it may be a problem for
Debian,

as I'm not sure our arcitecture is properly set up for this.
Including that notice in the package long description would certainly cover
the packages.debian.org and downloading via aptitude/synaptic.

But I don't think out ftp architecture is set up such as to allow us to
include a README file

in the same directory.

My guess is that including the statement in the package's long description
is would
be considered by RedHat as sufficient, but we should really get
clarification.

Modified Mugshot Client Code – Limited Trademark Permission
Red Hat and the Mugshot Project support the extension of Mugshot™ to
new platforms and languages. Red Hat grants a limited permission to
use the Mugshot™ mark on these modified versions of the Mugshot™
client code

Note that is only covers extending Mugshot to other platforms and
languages, not distributing modified versions for the same platform or
language. But packaging it for Debian probably counts as "extension
... to a new platform", especially given the stated purpose of this
"limited permission" being to make Mugshot as widely available as
possible (while preserving Red Hat's trade mark rights).

Indeed. I would consider Debian a seperate platform, in so far as it has a
seperate package managment system.
Clarification by RedHat on this point would be nice, but I'm fairly
convinced this is not a problem.

provided the following conditions are met:
1. You identify your version of the client code as an adapted
version of Mugshot™ in the “About” dialog associated with
the Mugshot icon. The attribution statement should be
similar to: “Mugshot™ client code adapted for ____.”

I'm guessing that's OK.

I agree. There is no special freeness problem here because we (or the end
user)

could always change the program name if they wanted to remove that message.

2. You do not prefix the named product with "Red Hat" (e.g.
"Red Hat Mugshot" is not allowed.).

3. The changes you make do not alter the fundamental user
experience from that provided by Mugshot™ as made available
by Red Hat. That is, you can: 1. localize the client code;
2. provide patches or bug fixes to the client code; 3.
provide extensions or plug-ins to the client code; or 4.
adapt the client code to run on another platform; but 5. you
cannot substantively modify or remove basic components of
the client code such that the user experience is altered. 4.
You do not redirect the client code to operate with a server
other than the server found at mugshot.org

Again, that's probably OK too. From a free software POV, it's always
open to people to do any of the unpermitted acts under a different
name.

Yeah. That sounds fine, and sounds like it includes all we really would need
to

make a Debian package using the Mugshot name.

It is very important that any modified version of Mugshot™ meet (or
exceed) the quality level people have come to associate with
Mugshot™. Red Hat reserves the right to require persons to cease use
of the Mugshot™ mark if they are redistributing software with low
quality and efforts to remedy the situation have not succeeded.

This is probably a key point in practice. It would be worth getting
Red Hat to confirm that they are happy with the Debian package. IIRC
the issue over Firefox/Iceweasel arose (at least in part) because
Mozilla were unhappy with some of the changes being made in order to
Debianize the software (e.g. disabling the built-in update system).

That was a small part. They had a policy of not letting patched versions be
called
Firefox, unless the patches were approved. That is fair enough, and I
suspect that most changes could have gotten approval.
If our patches were not approved and they made Firefox unstable, it would
reflect badly on Mozilla Corp. However, it seems likely
that some comrpomise could have been reached. (A closely related issue was
backporting security fixes to old versions in Stable, because of the policy
not to indroduce new upstream versions in Stable.)

However, the real killer was the logo. The Firefox Logo has a non-free
copyright license, that attempts to basically enforce tradmark rights using
copyright. This is a problem. Debian has no problem with the fact that the
logo is trademarked, but the non-free copyright prevents us prem
distributing Firefox in main. The problem is that by attempting to enforce
the trademark on the logo via copyrights prevents users from making
dervitive works, even those that could not possibly be confused with the
Firefox logo. Mozilla Corp was not willing to chane the copyright license on
the logo, nor to allow us to distribute the Firefox branded browser without
the logo. They even rejected the potential compromise of using a re-created
version of the logo, that has a free license (obviously trademark
restrictions would still apply).

Back on topic:

Here however, there is no such logo problem. Further we are allowed to make
any nessiary patches without pre-approval as long they do not alter the user
experience or reduce the quality of the code. This is perfectly reasonable.

So in conclusion:
1. The specific requirements on how the mark can be used on
versions that are maintain the "fundamental user experience"
can probably be lived with, assuming Red Hat don't have any
objections to any changes necessary to make Mugshot play
nicely with the Debian way of doing things.

Agreed. I also doubt Red Hat would raise any such objections.

2. The problems are (i) requiring a warranty of the distribution
media, and (possibly) (ii) the notices required to be
displayed where the software is downloaded.

Yes. The distribution media thing is likely something the ftpmasters would
need to decide. It not really so much
a freeness problem, as potential practical problem should an organization
unwilling to place a limited warrenty on the

physical media exist and desire to destribute Debian.

The notice requirement can be solved, if Red Hat agrees that including the
notice in the package's long description is
sufficient. (Which I expect they will, but we really need offical
clarification on.)