Re: Inbound trademark policy, round 3
On Tue, Jan 08, 2013 at 04:14:11PM +, Ian Jackson wrote: I volunteered to Stefano to try to summarise and synthesise the discussion about our inbound trademark licence policy. Thanks Ian, it's much appreciated and very useful! Rought consensus: 1. DFSG principles should apply. 2. No Debian-specific licences; freedom to make changes. 3. Rebranding to avoid the trademarks makes the package OK. Outstanding questions: A. Is it OK for some changes to need rebranding? If so which? B. What if upstream have restrictive policy but relaxed attitude? C. What about risk or revocation or upstream change of mind? I agree with your interpretation of consensus, but I also had a more optimistic impression that we do have agreements also on the outstanding questions. Clearly, the fact that you got a different impression independently rereading the thread warrants a new discussion. My own feedback is below, inline. ] One thing that seems to be missing from the discussion is a clear ] statement of our objectives in this context. I know that perhaps ] they are obvious but I'd like to set them out. I think the adopted ] policy should explicitly state them. That's fine with me. Stating objectives is generally a useful thing to do. I think I would've put as a goal, possibly supplementing yours, a pragmatic point like: - up to now we've threated in a rather ad-hoc way inbound trademarks, resulting in both unclarity among Debian developers on what is acceptable and what is not, and in a lack of guidelines that we can propose to educate upstreams that care about avoiding downstream distribution problems (in Debian and derivatives) - inbound trademark guidelines is meant to correct that ] I think these are our goals: ] ] I. The primary and overriding objective is to ensure the freedom ]of our users and downstreams. This should be evaluated with ]respect to the DFSG and the FSF's Free Software Definition. I don't see why we should mention FSF's Free Software Definition. I personally care a lot about Debian-FSF collaboration, but I think FSF guidelines or principles should have no direct place in the enumeration of goals for the Debian archive. We could mention other similar guidelines as related work, but at present I'm not aware of anything suitable for that purpose. ] II. Insofar as it doesn't conflict with the primary objective, […] ] III. Insofar as it doesn't conflict with the primary objective, […] I'm unable to grok an important difference among these two. Can't they be subsumed in a single point aimed at defending upstream identity reputation, highlighting that that is *also* useful to users and sysadms? The other goals look fine to me. 0. Firstly we need to be clear that we're primarily discussing trademarks on logos, names, etc., which affect larger programs. Where the whole package embodies one or more trademarks (eg, it's a logo collection or something), different principles apply and the package is probably suitable only for non-free. Absolutely yes. This is something that has only been discussed at the very end of the last round of discussion, but which is indeed very important. Thanks for wording it so effectively. For normal packages, I think we have rough consensus on the following: I agree with your interpretation of consensus on these parts. ] I think it is OK for the trademarked logos etc. still to physically ] exist in the source tree in main if their copyright licenses ] permit, since distributing them in the source tree but not ] presenting them doesn't engage trademark law. This is indeed something we have not discussed in the past. FWIW, I agree with you. I'd like to point out that once separated from the product, marks can have useful uses per se, possibly even for products in different trademark classes (e.g. a foot-shaped logo used for pedicure business). So it is in fact *useful* to distribute those material even in case of rebranding, and I don't see any reason not to as long as its copyright license (and other, non-trademark, restrictions) make the marks DFSG-free. The main big question that remains under discussion is this one: A. Is it acceptable for a trademark to impose any restrictions at all about the changes which might be made to the software. Or to put it in the words of 2b above, how much further than are likely to want to make should we go ? Are there changes prior to which it might be acceptable for the trademark holder to insist on rebranding ? Several people have answered this with no. Others have suggested that the escape hatch of rebranding is sufficient. A first observation on this is that trademark law do restrict its own field of application. For one thing, after rebranding, it's free for all; on the other end, in the absence of rebranding, unmodified versions are allowed to keep original marks thanks to nominative use. Everything in
Re: Inbound trademark policy, round 3
Uoti Urpala writes (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. You made this point at length in the previous discussion. It seemed to me that your point of view was not well supported by other people. As I said, what I wrote in my previous document was what I thought we had a rough consensus on. I'd encourage other members of the project not to get distracted by Uoti's points. I think there is no need to rebut them any more. I'd appreciate input on the questions I asked in my long message. And of course if people feels my understanding of the consensus is flawed, then that's very relevant too. Thanks, Ian. -- 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/20719.5957.642455.205...@chiark.greenend.org.uk
Re: Inbound trademark policy, round 3
Ian Jackson wrote: Uoti Urpala writes (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. You made this point at length in the previous discussion. It seemed to me that your point of view was not well supported by other people. As I said, what I wrote in my previous document was what I thought we had a rough consensus on. Some people objected to what I said, but much of that was based on objectively false views/claims on their part. Looking back at the thread now, I see little consensus on any real policy questions; much of the thread is about trying to get the objective facts right, and there isn't much discussion about possible policies based on those facts. I'd encourage other members of the project not to get distracted by Uoti's points. I think there is no need to rebut them any more. I don't think anyone has managed to write a good rebuttal to them. If you disagree, give a link to a post which in your view does that. -- 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/1357853787.26124.171.camel@glyph.nonexistent.invalid
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
Inbound trademark policy, round 3
I volunteered to Stefano to try to summarise and synthesise the discussion about our inbound trademark licence policy. Here is the previous discussion head article: https://lists.debian.org/debian-project/2012/02/msg00073.html In this message I'm going mostly to write things from the point of view of a more or less neutral summariser/shepherder of the discussion. But I also want to make some points of my own which I will mark with the symbol ] in the LH column. I think we have some areas of agreement but are still lacking in consensus answers to some important questions. I'm afraid I don't think we're quite ready to publish and deploy a concluded policy. Summary: ] We need to be clear about our objectives. Rought consensus: 1. DFSG principles should apply. 2. No Debian-specific licences; freedom to make changes. 3. Rebranding to avoid the trademarks makes the package OK. Outstanding questions: A. Is it OK for some changes to need rebranding? If so which? B. What if upstream have restrictive policy but relaxed attitude? C. What about risk or revocation or upstream change of mind? Detailed discussion: ] One thing that seems to be missing from the discussion is a clear ] statement of our objectives in this context. I know that perhaps ] they are obvious but I'd like to set them out. I think the adopted ] policy should explicitly state them. ] ] I think these are our goals: ] ] I. The primary and overriding objective is to ensure the freedom ]of our users and downstreams. This should be evaluated with ]respect to the DFSG and the FSF's Free Software Definition. ] ] II. Insofar as it doesn't conflict with the primary objective, ]we should honour the reasonable wishes of upstreams and ]respect their concern for their reputation (and their ]legal position). ] ] III. Insofar as it doesn't conflict with the primary objective, ]we would like users to see the software we package under its ]usual name and usual branding. That gives credit to upstream ]where it is due (assisting with objective II), and assists ]users and administrators (assisting with the primary ]objective). ] ] IV. We have a limited amount of effort available. If we have ]insufficient resources to distribute certain software while ]complying with the primary objective and applicable laws, we ]should not distribute that software. Otherwise, we should ]direct our efforts where they will do the most good and not ]undertake unnecessary work. Reading the thread, I come to the following conclusions: 0. Firstly we need to be clear that we're primarily discussing trademarks on logos, names, etc., which affect larger programs. Where the whole package embodies one or more trademarks (eg, it's a logo collection or something), different principles apply and the package is probably suitable only for non-free. For normal packages, I think we have rough consensus on the following: 1. We should try to apply the principles of the DFSG to potential restrictions attached to inbound trademarks. Exactly what that means in practice is subject to some discussion. 2. In particular Debian should not distribute packages affected by trademarks if those trademarks: a. restrict the activities of Debian's downstreams more than they restrict Debian (so no Debian-specific license agreements) b. restrict the ability to make changes we or our downstreams are likely to want make to the software. (This weak form of the criterion has consensus; some people want a stronger test.) 3. If we rename and rebrand a package as needed so that the trademarks no longer apply, there is no objection to the result being in main. (Whether this is an effort worth doing depends on the value of the package, of course; perhaps for some packages it would be better not to bother and simply leave the program out of Debian.) ] I think it is OK for the trademarked logos etc. still to physically ] exist in the source tree in main if their copyright licenses ] permit, since distributing them in the source tree but not ] presenting them doesn't engage trademark law. 4. Trademarks present at least somewhat different problems to copyright because we can escape trademarks by rebranding. So our treatment of trademark licences shouldn't be entirely identical to our treatment of copyright licences (but see below). The main big question that remains under discussion is this one: A. Is it acceptable for a trademark to impose any restrictions at all about the changes which might be made to the software. Or to put it in the words of 2b above, how much further than are likely to want to make should we go ? Are there changes prior to which it might be acceptable for the trademark holder to insist on rebranding ? Several people have answered this with no. Others have suggested
