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

Re: [PHP-QA] Debian and the PHP license



MJ Ray writes ("Re: [PHP-QA] Debian and the PHP license"):
> On 4 August 2014 13:26:11 GMT+01:00, Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:
> >Can you please confirm that the question I put in my draft questions
> >for SFLC, on this subject, addresses this point ?  If I haven't
> >fully captured your understanding of the problem then my draft needs
> >to be updated.
> 
> I'm not sure it does. The question to me should be more like "does
> putting a name restriction in the copyright licence rather than
> using a trademark licence mean we lose any ability to package this
> software under its own name and if so, how?" but worded more slickly
> like you do.

I think that's exactly what my question (Q5) is asking:

  Q5. Does the fact that the PHP licence conditions about the use of the
     PHP name are contained in the actual copyright licence, rather than
     in a separate trademark licence, significantly increase the risks
     we would face if we had a disagreement with upstream about our
     modifications (or our failure to seek approval) ?

> At best, the earlier paragraph suggesting we rely on assurances from
> trademark holders rather than usual rights in law, just for
> packaging, seems beside the point. At worst, it could mislead about
> the question.

I think it is an important point.  Many of the projects whose software
we use have trademarks.  Those trademarks often come with a
restrictive trademark licence which says that we have to submit
changes for approval, or some other unacceptable conditions.

We often ignore those trademarks because the upstream community
doesn't appear to actually mean what the project's laywers have
written.  We can afford to do this because, if we are wrong, the
result is that we must rename the software.  Renaming it is annoying
but it doesn't leave us high and dry.

So the real concern about the name restriction being in the copyright
licence is not that it might be used, at some point in the future, to
force us to rename.  We already tolerate exactly that situation with
trademarks.

It is also not that we might be in technical break of the condition
(eg, to seek written approval) right now.  We already take exactly
that risk with trademarks.

The concern is this: should upstream have a problem with some of our
changes, or our failure to formally get approval, they may seek to
apply legal pressure based on the name restriction clause.  In that
case if it were a trademark problem we would rename the software and
carry on.  We need to know that this is a sufficient response when the
name restriction is in a copyright clause.


Or to put it another way, addressing your first paragraph again:

> I'm not sure it does. The question to me should be more like "does
> putting a name restriction in the copyright licence rather than
> using a trademark licence mean we lose any ability to package this
> software under its own name and if so, how?" but worded more slickly
> like you do.

The question is not about some kind of abstract `ability', as if law
was always hard-edged and clear.

The question is our _practical_ ability.  What can we (by which I
include Debian and all of our downstreams) do without incurring
significant risk ?

If you disagree with me on this point then you probably disagree with
the Debian project's existing approach to troublesome trademarks.  For
example, when there is a trademark whose licence requires us to seek
approval, but where the trademark holder and their community don't
appear to want to enforce this rule.

If you think that in that situation we should decline to package the
software, or rename it right away, then that is a coherent position.

But that is not our current practice.  If you want to change that you
will need a GR, I think.


But perhaps I have misunderstood.  If my reply doesn't seem to make
sense perhaps you would like to suggest an alternative wording for
this part of the question email.


Thanks,
Ian.


Reply to: