On Sun, 2011-10-09 at 20:02 +0200, Stefano Zacchiroli wrote: [...] > The reason of the non-DFSG-freeness of the Debian logo is that its > *copyright* license tries to do some sort of trademark protection as > part of its terms. Reifying trademark protection in a copyright license > is a bad thing per se, and I've been working with SPI lawyers to fix > that. The goal is to release the Debian logo under a common DFSG-free > license and have a separate, new, trademark policy [5].
+1 [...] > Proposal > ======== > > We need to decide together what to do about the presence of software > with trademark restrictions in the Debian archive. It would be nice to > reach consensus through simple discussion, but we can of course also > decide to vote on this matter. > > My own proposal, that I submit to your consideration, is as follows: > > - DFSG applies to copyright license; trademark restrictions should not > make a package DFSG non-free (philosophical part) DFSG item 4 states explicitly that we accept licences that require us to rename software that we modify. A requirement to stop using other trademarks, such as logos, seems to be entirely within the spirit of this. However, copyright licences that attempt to extend trademark law by restricting the descriptive or functional use of trademarks (e.g. the requirement that a fork of Ion 3 could not use that name in file or directory paths) should not be accepted. > - however, trademark restrictions that get in the way of "usual Debian > procedures" should not be accepted in the Debian archive (practical > part) > > What I've in mind here is stuff like having to either rebrand or ask > for permission before adding a security patch or other kind of > restrictions on changing code that has nothing to do with the > "identity" of upstreams that trademarks are supposed to protect. The intent of such restrictions is to maintain the quality of products that use the trademark. This is absolutely the purpose of trademarks. New users of free software, particularly certain animal-themed Internet applications, generally aren't very familiar with the ideas that there can legitimately be forks and customised versions sharing a name, and that the distributor (not upstream) should initially be held responsible for defects. While I think that Debian users can generally be trusted to understand this, I can also see why upstream projects may be wary. > Practically, I think the set of unacceptable restrictions should be > proposed by the people who would actually have to deal with this kind > of issues: security team (that might need to apply impromptu patches), > release team (that might be forced to rename packages in past release > upon change), ftp-masters (same reason as before), etc. [...] Given the disruption that would be caused by renaming in a stable update, maintainers should be aware of the possibility of such restrictions and should address them proactively, by renaming or obtaining a licence from upstream that allows us to make any necessary bug fixes. In cases where Debian obtains a licence to use a trademark in a modified package and where this is not generally allowed, this should probably be noted in the copyright file (admittedly a misnomer in this case). Ben -- Ben Hutchings Reality is just a crutch for people who can't handle science fiction.
signature.asc
Description: This is a digitally signed message part
