Re: Inbound trademark policy, round 3
Ian Jackson wrote: 1. DFSG principles should apply. IMO taking this as a starting point is completely wrong. DFSG guarantees that incompetent and malicious people may freely modify the software. For trademarks to have any meaning at all, distributing those modified versions under the original trademark must not be allowed. DFSG principles should not be applied to trademarks; if you insist on applying them, then the only consistent position is to completely reject any use of trademarks whatsoever. Trademarks can be viewed as a legally (rather than technically) enforced form of authentication. Allowing any downstream to freely use trademarks makes about as much sense as allowing any downstream to freely sign their modified packages with Debian archive signing keys. 2. No Debian-specific licences; freedom to make changes. While I can see the rationale for wishing to avoid Debian-specific licenses, I doubt adding such a restriction would ultimately be beneficial. In practice, trying to codify software quality requirements is just too hard. Trusting (and occasionally verifying) the competence of a known team is a lot more practical. The alternative to distro-specific licenses wouldn't be more downstream freedom but no distro-level freedom for anyone; and I don't think Debian preemptively renaming everything would be in the interest of most downstreams either. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1357738759.26124.50.camel@glyph.nonexistent.invalid
Re: Inbound trademark policy, round 3
On Wed, 09 Jan 2013, Uoti Urpala wrote: Ian Jackson wrote: 1. DFSG principles should apply. IMO taking this as a starting point is completely wrong. DFSG guarantees that incompetent and malicious people may freely modify the software. For trademarks to have any meaning at all, distributing those modified versions under the original trademark must not be allowed. This problem and the compromise which allows escape from it is already present in the DFSG. (Require renaming upon modification.) We must start from the principles in the DFSG. If we decide that specific principles in the DFSG need to be altered to account for the realities and/or necessities of trademark(s), we should examine those differences and then alter the DFSG accordingly. While I can see the rationale for wishing to avoid Debian-specific licenses, I doubt adding such a restriction would ultimately be beneficial. The reason why this restriction is beneficial is because it allows the hundreds of distributions which are based on Debian to modify software, etc. [But feel free to argue that this benefit is not worth the cost to Debian in rebranding affected software.] Don Armstrong -- CNN/Reuters: News reports have filtered out early this morning that US forces have swooped on an Iraqi Primary School and detained 6th Grade teacher Mohammed Al-Hazar. Sources indicate that, when arrested, Al-Hazar was in possession of a ruler, a protractor, a set square and a calculator. US President George W Bush argued that this was clear and overwhelming evidence that Iraq indeed possessed weapons of math instruction. http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130109190202.ga26...@rzlab.ucr.edu
Re: Inbound trademark policy, round 3
Uoti Urpala uoti.urp...@pp1.inet.fi writes: DFSG allow a rename requirement; this means any trademark policy whatsoever cannot violate DFSG as long as it allows distributing unmodified sources and binaries, as you can always rename and then ignore the trademark policy. DFSG #4 is narrower than the possible actions that could be required by a trademark policy, at least in the way that we've normally interpreted it, since we've not interpreted it as allowing the renaming to affect functional elements of the program. In other words, our historic interpretation of DFSG #4 is that saying that you have to rename The Foo Library to something else if you modify it is okay (if not preferred), but requiring that you also rename all the functions in the public API from foo_* to something else is a violation of the DFSG. This is not spelled out explicitly in DFSG #4. If we ever did revise the DFSG, it would be nice to make this clearer, since it's come up in some difficult cases (such as with various drafts of the LaTeX license due to the way that LaTeX components work). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bocxy97g@windlord.stanford.edu
Re: Inbound trademark policy, round 3
Russ Allbery wrote: Uoti Urpala uoti.urp...@pp1.inet.fi writes: DFSG allow a rename requirement; this means any trademark policy whatsoever cannot violate DFSG as long as it allows distributing unmodified sources and binaries, as you can always rename and then ignore the trademark policy. DFSG #4 is narrower than the possible actions that could be required by a trademark policy, at least in the way that we've normally interpreted it, since we've not interpreted it as allowing the renaming to affect functional elements of the program. In other words, our historic interpretation of DFSG #4 is that saying that you have to rename The Foo Library to something else if you modify it is okay (if not preferred), but requiring that you also rename all the functions in the public API from foo_* to something else is a violation of the DFSG. Does the naming of library functions really fall under trademarks? I wouldn't expect the use of a trademarked name as part of a function name to require permission (so even if a trademark policy had a clause trying to forbid that, it'd have no effect on an otherwise renamed program). -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1357794096.26124.159.camel@glyph.nonexistent.invalid
Re: Inbound trademark policy, round 3
Uoti Urpala uoti.urp...@pp1.inet.fi writes: Russ Allbery wrote: DFSG #4 is narrower than the possible actions that could be required by a trademark policy, at least in the way that we've normally interpreted it, since we've not interpreted it as allowing the renaming to affect functional elements of the program. In other words, our historic interpretation of DFSG #4 is that saying that you have to rename The Foo Library to something else if you modify it is okay (if not preferred), but requiring that you also rename all the functions in the public API from foo_* to something else is a violation of the DFSG. Does the naming of library functions really fall under trademarks? I wouldn't expect the use of a trademarked name as part of a function name to require permission (so even if a trademark policy had a clause trying to forbid that, it'd have no effect on an otherwise renamed program). I don't know. I'm not a trademark lawyer. It's not obvious to me that they don't, though, given that the purpose of trademarks is to avoid causing confusion in the general public, and having a modified library not eligible for the trademark providing an identical API seems like it would pass a prima facie test for possibly causing confusion. (Please note: that doesn't imply that I think such a case would win in court necessarily, only that it's not obvious to me that trademarks don't apply.) There was extensive discussion over whether the Firefox trademark applied to the command-line program, which strikes me as a very similar sort of case. As with the API of a library, the command-line invocation is the interface that's exposed to the user of the product. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ehhtwp12@windlord.stanford.edu
