This discussion has been moved here (svn-org@subversion.tigris.org)
from users@ and dev@. See this post for the original thread:
http://subversion.tigris.org/servlets/ReadMsg?list=users&msgNo=66571
From: Karl Fogel <kfogel@red-bean.com>
To: users@subversion.tigris.org, dev@subversion.tigris.org
Subject: RFC: Subversion trademark policy
Date: Wed, 30 May 2007 15:21:48 -0700
Message-Id: <87646ac5qb.fsf@red-bean.com>
Several people responded in the old thread. I'll try to answer all
the issues here. First I'll quote a lot of people, responding to each
with a short answer, then at the end of this mail is a longer proposal.
Stefan Langer <mailtolanger@googlemail.com> writes:
> I have a slight irritation when reading 3c) I understand that you are
> not allowed to refer to a fork or somesort of extension (like for
> e.g. SVK) as a successor of subversion but the example you are giving
> confuses me. The example does not designate a successor but simply
> states the fact that the software is kind of like a Subversion
> 2.0. This does not mean that it claims to be the designated
> successor. It might be better to leaf off the example in order not to
> confuse anybody or state a different example.
Good point. I've changed the example to be less confusing.
Stefan Küng <tortoisesvn@gmail.com> writes:
> I may be missing this, but when/how/if is it allowed to refer to a
> client tool/app linked with the Subversion lib as a "Subversion
> client"?
> From how I understand the policy, that isn't allowed because that
> wouldn't be "substantially unmodified"?
>
> Maybe another section (2d) for client tools would help to clarify this.
You're right, we've got a big open question there... I'll propose a
solution later in this mail.
Marc Strapetz <marc.strapetz@syntevo.com> writes:
> [responding to Stefan Küng]
> +1, but mandatory usage of the Subversion lib is very restrictive. I
> think an "SVN" client must have its primary purpose being a client to
> Subversion and it must be compatible with SVN protocols and working
> copies. This should be sufficient to deserve "SVN" within its name.
Yup, same issue. Again, see proposed solution later in this mail.
Peter Samuelson <peter@p12n.org> writes:
> [Stefan Küng]
> > I may be missing this, but when/how/if is it allowed to refer to a
> > client tool/app linked with the Subversion lib as a "Subversion client"?
>
> More generally, I think there should be a section about the related
> term "Subversion protocol" or "Subversion protocols", allowing
> arbitrary software to advertise support for Subversion protocols if
> they aim to be compatible with Subversion clients or servers across a
> network. This grant should extend to software which does not use the
> official libraries; trademark policy isn't an appropriate place to
> force that issue, IMO. I also don't think the grant should require a
> regression test or other proof of rigorous compatibility.
>
> Alternatively you could say explicitly that you do not intend for
> "Subversion protocol" to be protected by your trademarks at all.
*nod* This ties into the questions above; see proposal later on.
"Justin Erenkrantz" <justin@erenkrantz.com> writes:
> My personal opinion is that apps with reverse engineered protocols
> have no right to the Subversion trademark - only apps that directly
> use our libraries can use our name. -- justin
Not sure where the "reverse engineering" would come in -- our
protocols are fully documented :-). But I get the larger point you're
making: that if it's not our code, it shouldn't use the Subversion
name.
I think I don't agree, though. Such a restriction would hurt the
Subversion project more than it would help. Suppose Stefan had
implemented TortoiseSVN using some other library, but it behaved
exactly the same way? I think it would hurt the Subversion project
more to not have the "SVN" in that name, than whatever abstract harm
might come from it not using our code.
See below for a proposal that might be acceptable to both sides of
that debate, though.
Peter Samuelson <peter@p12n.org> writes:
> [Justin Erenkrantz]
> > My personal opinion is that apps with reverse engineered protocols
> > have no right to the Subversion trademark - only apps that directly
> > use our libraries can use our name. -- justin
>
> This also does not address the issue of talking about the protocol
> commonly found on TCP 3690 or tunneled over ssh running a server-side
> binary named 'svnserve'. What do you think people should call this
> protocol? Does it bother you if people call it "the Subversion
> protocol", as they do today?
That wouldn't bother me. Whatever else we do, we should allow people
to describe implementations of that protocol as "Subversion protocol".
See below for a solution.
Okay. I've left out a few quotes that are redundant with things
already said, but the above is pretty representative. Now for the
proposed adjustments.
PROPOSALS:
----------
I suggest we modify 2(c), and add a new clause 2(d):
2. You may use the Subversion Marks without prior written permission
for the following purposes (subject to the other sections):
a. [...]
b. [...]
c. To refer to the Subversion project itself, its products, or its
protocols.
d. As part of the name of a product designed to work with
Subversion, so long as the name as a whole (via its other
components) clearly and unambiguously distinguishes the product
from Subversion itself, and the general presentation of the
product does not imply any official association or identity with
Subversion.
Because it would be awkward to attach a trademark symbol to a
portion of a larger name whose other portions might themselves
be trademarked, the requirement to display the symbol is waived
for this specific circumstance, but this waiver implies no
relaxation of the Subversion Corporation's right to enforce its
trademark in general (see section 4).
The reasons for the updated 2(c) are self-evident, I won't spend space
on them here. Probably we're all okay with it.
The motivation for 2(d) is that our main goal is to prevent identity
confusion. Yes, sometimes users will see "FooSVN" and assume it must
be from the Subversion project, but in general we've been able to set
them straight about that pretty easily -- it just hasn't been a big
problem in practice. If it ever *did* become a big problem, why, then
we'd have the evidence we'd need to say "This name isn't
distinguishing enough, please change it."
The point is make it possible to solve problems when they arise, not
prevent every possible problem in advance.
Thoughts? (Note that 2(d) hasn't had legal review yet; when we're
ready, the Subversion Corporation can run it by our lawyers.)
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: svn-org-unsubscribe@subversion.tigris.org
For additional commands, e-mail: svn-org-help@subversion.tigris.org
Received on Mon Jun 4 14:48:07 2007