[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Inbound trademark policy, round 3



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


Reply to: