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:
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.
] We need to be clear about our objectives.
1. DFSG principles should apply.
2. No Debian-specific licences; freedom to make changes.
3. Rebranding to avoid the trademarks makes the package OK.
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?
] 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
] 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
that the escape hatch of rebranding is sufficient.
] I think the answer is clearly "yes" at least in some kind of extreme
] cases. For example if a Debian downstream were to take 1% of the
] program's code and replace the other 99% with something entirely
] different, we wouldn't be surprised or indeed offended if the
] trademark holder of the 1%'s name and logo objected.
] 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. Those who do substantial
] violence to the package should be expected to consider whether it
] needs to be renamed or rebranded.
] I'd like to propose the following rule of thumb:
] It is OK for a change to require rebranding, iff a conscientious
] and polite downstream should in any case rebrand (as a matter of
] ethics rather than law) in that case.
There is one other point which has not been considered in detail:
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.
What should our approach be ?
] Certainly IMO there are some situations where such a trademark
] would be unacceptable. For example:
] - there have been trademark-related threats (or hints of threats)
] from upstream (made either towards Debian or towards any
] downstream who isn't behaving unreasonably);
] - upstream seem to think they have a moral right to control the
] changes we make to the software and so don't engage with us on
] a Free Software basis (eg flames and bluster even if trademarks
] aren't specifically mentioned);
] - any process involving approving specific changes or specific
] versions of the Debian package.
The potential grey area seems to be when upstream clearly intend to
tolerate (and perhaps have historically tolerated), the activities
of Debian and its downstreams.
C. What about the risk of trademark licences (or informal toleration,
if we accept that) being revoked ?
> 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).
Views on this question seem mixed.
] Personally I agree with Stefano's approach which is to treat this
] as a practical problem.
Until we have rough consensus answers to the questions in A,B,C I
don't think we can write up and publish a policy. So please weigh in
with your analysis and opinions.