On Tue, Jan 08, 2013 at 04:14:11PM +0000, 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 between, is blurry. What would be relevant in case of litigation is whether the applied changes have changed the nature of the product, possibly undermining upstream reputation. Trademarks policies can be used to forbid those kind of changes, but cannot be used to forbid other kind of changes (i.e. those that do not bring user confusion or substantially change the nature of the product). I think we did have consensus on the fact to ignore trademark restrictions that are clearly outside the scope of trademark law. A related question is obviously who, in Debian, should judge which part of specific trademark policies are overstepping the limits of trademark laws. I think we do have a natural, and agreed upon answer for this: FTP Masters (sorry folks :-)). Then, there is the matter of the guarantees that we should offer to our users and downstreams who want to modify Debian packages, who are possibly trademark encumbered. In particular, I disagree with your comment: > ] So personally I think this is a practical question. People who get > ] Debian and want to modify it in the ways one ordinarily would should > ] not have to check trademark conditions. because the only common guarantees that we (try to!) offer for our archive is that the material there is DFSG-free. Given that DFSG do account for trademarks, I think it should be up to our downstreams to verify whether they are allowed to do a specific change without rebranding or, on the contrary, if they have to rebrand. I don't see this as a significant extra burden wrt checks that our users should already do in the realm of copyright: for example, the kind of linking and redistribution people could do with software in the Debian archive is significantly different for GPL-, BSD-, or LGPL-licensed software. My bottom line on this is that: it is acceptable to have restrictions that force rebranding, as long as they do not overstep the purpose of trademarks. And downstream modifying software are responsible for their choices. Clearly, we should document trademark restrictions prominently, in debian/copyright (and too bad for the misnomer). > B. Due to the exigencies of trademark law and the management realities > of most Free Software projects, it is sometimes the case that an > upstream project will publish a restrictive trademark policy (or > indeed simply mention that something is a trademark without writing > a licence at all) but in fact not carry out any enforcement against > bona fide downstreams. […] > C. What about the risk of trademark licences (or informal toleration, > if we accept that) being revoked ? > > Stefano wrote: > > > For trademark encumbered software that could at a given point in > > time be distributed without rebranding, maintainers should > > carefully evaluate the risk of having to rebrand them later on, > > and seek advice from the teams that would be impacted by impromptu > > rebranding (e.g.: security team, release team, ftp-masters). > > ] Personally I agree with Stefano's approach which is to treat this > ] as a practical problem. In fact, I think that B and C are essentially the same problem: evaluating the *risk* of accepting something trademark encumbered in the Debian archive, *without rebranding* it. It is not a risk in the DFSG sense, as via rebranding the material become unencumbered. It is a risk in terms of the efforts that will cost us (and possibly our downstream) to do the rebranding later on. I don't think this part should be regulated in the guidelines: it is very hard to detail actionable criteria for this and we'll likely always find exceptions. So I'm much more inclined to threat *both* at the same practical problem of evaluating the likelihood of having to do rebranding in the future. Once more, we do have gatekeepers of this kind of issues in the archive (FTP Masters) and I'm happy to leave the final decision on this matters to their discretion, of course in consultation with the package maintainers and the other teams that might be affected by impromptu rebranding. On this, I'd also like to note that considerations like "how much is upstream hostile?, how much we risk of being sued by upstream and their cats?" are *already* taken into account when accepting software in the archive. Trademark considerations are both similar and much simpler issues, as we can always rebrand-away. Hope this helps, Cheers. -- Stefano Zacchiroli . . . . . . . zack@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Attachment:
signature.asc
Description: Digital signature