rust non-free-compatible trademark

rust non-free-compatible trademark

[lkcl]

with the recent announcement that rust is supported by gcc
has it been taken into consideration that the draconian (non-free-compatible)
requirements of the rust Trademark make the distribution of the gcc
compiler Unlawful?

    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013920

if the word "rust" is entirely removed from the gcc source code then
there is no problem whatsoever (recall: "iceweasel").

l.

Re: rust non-free-compatible trademark

[Richard Biener]

> Am 17.07.2022 um 17:29 schrieb lkcl via Gcc <gcc@gcc.gnu.org>:
> 
> with the recent announcement that rust is supported by gcc
> has it been taken into consideration that the draconian (non-free-compatible)
> requirements of the rust Trademark make the distribution of the gcc
> compiler Unlawful?
> 
>    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013920
> 
> if the word "rust" is entirely removed from the gcc source code then
> there is no problem whatsoever (recall: "iceweasel").

We’ll call it gust.

Richard 
> 
> l.

Re: rust non-free-compatible trademark

[Mark Wielaard]

Hi Luke,

On Sun, Jul 17, 2022 at 04:28:10PM +0100, lkcl via Gcc wrote:
> with the recent announcement that rust is supported by gcc

There is just a discussion about whether and how to integrate
(portions) of the gccrs frontend into the main gcc repository. Nobody
claims that means the rust programming language is supported by gcc
yet. There is a lot of work to be done to be able to claim that.

> has it been taken into consideration that the draconian (non-free-compatible)
> requirements of the rust Trademark make the distribution of the gcc
> compiler Unlawful?
>
>     https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013920

That looks to me as an overreaching interpretation of how to interpret
a trademark. I notice you are the bug reporter. It would only apply if
a product based on gcc with the gccrs frontend integrated would claim
to be endorsed by the Rust Foundation by using the Rust wordmark. Just
using the word rust doesn't trigger confusion about that. And
trademarks don't apply when using common words to implement an
interface or command line tool for compatibility with a programming
language.

If you are afraid your usage of gcc with the gccrs frontend integrated
does cause confusion around the Rust word mark then I would suggest
contacting the Rust Foundation to discuss how you can remove such
confusion. Probably adding a README explicitly saying "this product
isn't endorsed by and doesn't claim to be endoresed by the Rust
Foundation" will be enough.

Good luck,

Mark

Re: rust non-free-compatible trademark

[lkcl]

On Sun, Jul 17, 2022 at 5:25 PM Richard Biener
<richard.guenther@gmail.com> wrote:

> > if the word "rust" is entirely removed from the gcc source code then
> > there is no problem whatsoever (recall: "iceweasel").
>
> We’ll call it gust.

love it! the puns i would have recommended would have been based
on "iron oxide".

please bear in mind: under Trademark Law, as developers, you *must* not make
"announcements" saying "we *are* changing the name from rust to gust".
this creates "Confusion" for which you become directly and legally liable
and responsible.

*users* are permitted to go, "oh look, errr there's this thing called gust
and the source code compiles for rust".

just as with the Java Trademark, you as developers can say "gust is
compatible with
the rust language" but you *cannot* say "gust is compatible with rust".

Trademarks are a bitch.  get legal advice.

l.

Re: rust non-free-compatible trademark

[lkcl]

On Sun, Jul 17, 2022 at 5:31 PM Mark Wielaard <mark@klomp.org> wrote:
>
> Hi Luke,
>
> On Sun, Jul 17, 2022 at 04:28:10PM +0100, lkcl via Gcc wrote:
> > with the recent announcement that rust is supported by gcc
>
> There is just a discussion about whether and how to integrate
> (portions) of the gccrs frontend into the main gcc repository. Nobody
> claims that means the rust programming language is supported by gcc
> yet. There is a lot of work to be done to be able to claim that.

as i just replied to Richard, my understanding is that your careful usage
of wording there is Lawful ("the rust programming language is supported by gcc"
rather than "*rust* is supported by gcc").

> > has it been taken into consideration that the draconian (non-free-compatible)
> > requirements of the rust Trademark make the distribution of the gcc
> > compiler Unlawful?
> >
> >     https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013920
>
> That looks to me as an overreaching interpretation of how to interpret
> a trademark.

Trademarks are a bitch.   if no explicit License is given, then "default"
Trademark Law applies, where you must seek permission for all and
any distribution.  if the License *does* exist and does not explicitly
grant a Permission, then, exactly like Copyright Law, you must explicitly
seek it.

you have to be *really* careful here, particularly given that the Mozilla
Foundation is attempting a poor-man's "Certification Mark".

they have defined the Trademark as requiring "language compatibility".
which is perfectly reasonable given that they don't want end-users to
be complaining "i can't compile my program" or worse, "my program
broke, rust is supposed to be secure, whom do i sue".

Uses that require explicit approval #

    Distributing a modified version of the Rust programming language
    [or the Cargo package manager] with modifications other than those
    permitted above and calling it Rust or Cargo requires explicit,
    written permission from the Rust Foundation.

given that gcc is *entirely implementing* the rust programming language
(from scratch) and given that that implementation is not in fact implemented
by the Rust Foundation (the Trademark Holders themselves) but by the
gcc developers, then by definition *every* single line of source code
constitutes
"a patch", and according to the Trademark License they (the Rust Foundation)
require that you seek explicit approval for its distribution.

(i.e. the *entire* gccrs source code is "a modified version of the rust
 programming language")

distribution in this particular case would be:

* all tarballs under the gcc.org domain name
* all git repositories under the same
* all git repositories created by all gcc developers

so, yes, you've enacted distribution, and enabled and empowered
others to engage in distribution - sorry to have to inform you of this
(i trust you won't engage in "Shooting-Messenger-Syndrome") but,
how can i put this... if you check with a good - and i do mean good -
Trademark Lawyer, you'll likely be advised that you're legally liable,
here.  checking that is of course your responsibility, not mine.

> If you are afraid your usage of gcc with the gccrs frontend integrated
> does cause confusion around the Rust word mark then I would suggest
> contacting the Rust Foundation to discuss how you can remove such
> confusion.

that would not be my responsibility, but yours [i'm assuming you're
a gcc developer?]

only if *i* were to engage in *distribution* of gcc with gccrs frontend
integration would *i* become concerned, and i appreciate the reminder/prompting
from you that, at some point in the near future, this will actually occur.
sigh.

to that end i would strongly recommend and advocate that the
gccrs frontend be a dynamic-loadable plugin into gcc, so that it
can be optionally excluded.

or, as Richard suggested, begin calling it "gust".  gccgust frontend.
(but don't for goodness sake put anywhere "we ARE renaming
all uses of rust to gust in gcc".)

l.

Re: rust non-free-compatible trademark

[Mark Wielaard]

Hi Luke,

On Sun, Jul 17, 2022 at 06:06:45PM +0100, lkcl via Gcc wrote:
> given that gcc is *entirely implementing* the rust programming
> language (from scratch) and given that that implementation is not in
> fact implemented by the Rust Foundation (the Trademark Holders
> themselves) but by the gcc developers, then by definition *every*
> single line of source code constitutes "a patch", and according to
> the Trademark License they (the Rust Foundation) require that you
> seek explicit approval for its distribution.

I think you are misinterpreting when you need a trademark license for
usage a word mark in an implementation of a compiler for a programming
language. Note that gcc used to come with a full implementation of the
Java programming language, compiler, runtime and core library
implementation (for which I was the GNU maintainer). None of that
required a trademark license because the usage of the word java was
just for compatibility with the java programming language. And since
there was no claim of being or distributing Java(tm). The same is true
for Rust(tm) and the gccrs frontend.

Also note that the Rust Foundation is aware of the work and has
already integraeted parts of gcc through another alternative
implementation (based on libgccjit). As far as we know thy have no
problem with either alternative implementation of the Rust programming
language.

Cheers,

Mark

Re: rust non-free-compatible trademark

[lkcl]

On Sun, Jul 17, 2022 at 6:41 PM Mark Wielaard <mark@klomp.org> wrote:

> I think you are misinterpreting when you need a trademark license for
> usage a word mark in an implementation of a compiler for a programming
> language.

i'm aware of the difference.  i mentioned this in my first reply to Richard
(and covered it briefly in my reply to you as well)

> Note that gcc used to come with a full implementation of the
> Java programming language, compiler, runtime and core library
> implementation (for which I was the GNU maintainer). None of that
> required a trademark license because the usage of the word java was
> just for compatibility with the java programming language.

yes. i mentioned that example in my reply to you and in my separate
reply to Richard: you may have missed it.

that would likely be down to the difference in the Java Trademark License
and the Rust Trademark License.

with the wording the Rust Trademark License has attempted to create a poor-man's
Certification Mark.

Certification Mark Law is an advanced variant of Trademark Law covering
Standards Compliance.

> And since
> there was no claim of being or distributing Java(tm). The same is true
> for Rust(tm) and the gccrs frontend.

this would be perfectly fine if the Rust Foundation had not explicitly
worded the Trademark License in terms of a poor-man's Certification
Mark.

i gave the relevant section that you can pass over to appropriate Legal
Counsel.

i leave it with you as i am just a "reasonably well-informed
non-lawyer messenger"
here.

> Also note that the Rust Foundation is aware of the work and has
> already integraeted parts of gcc through another alternative
> implementation (based on libgccjit). As far as we know thy have no
> problem with either alternative implementation of the Rust programming
> language.

then that needs to be put into writing and made public.  only the Trademark
Holder may do that - not you. otherwise if you claim something and it turns
out not to be true, you can be sued for misrepresentation.

did i say Trademarks are a pig already?

l.

Re: rust non-free-compatible trademark

[Richard Kenner]

> just as with the Java Trademark, you as developers can say "gust is
> compatible with the rust language" but you *cannot* say "gust is
> compatible with rust".

Note that trademarks are adjectives, not nouns (and only apply to specific
nouns, so I'm not sure what you mean here.

Re: rust non-free-compatible trademark

[Richard Kenner]

> I think you are misinterpreting when you need a trademark license for
> usage a word mark in an implementation of a compiler for a programming
> language. Note that gcc used to come with a full implementation of the
> Java programming language, compiler, runtime and core library
> implementation (for which I was the GNU maintainer). None of that
> required a trademark license because the usage of the word java was
> just for compatibility with the java programming language. 

Was "Java" a trademark for both the language and compiler or just the
language?  What about "rust"?  That would seem to make a difference.

If the trademark is just for the language, then when you say you have
a "compiler for the XYZ language", you're refering to the trademarked
entity (the language) and you can always use a trademark to refer to
the trademark owner's product.

But if the trademark is also for the compiler and you have a different
compiler (even if it differs just by patches), you need the permission
of the trademark owner to call you compiler by the trademarked name.

Re: rust non-free-compatible trademark

[lkcl]

ah. right. sorry Mark i missed something.

whilst you *as developers* have been in contact with the Rust Foundation
and presumably have private assurances that your use of the Trademarked
word "rust" is Authorised under License (through either implication or by
actual explicit approval) absolutely nobody else does.

all *new* gcc developers for example who have *not* been party to
those private conversations may not safely assume that they are part
of any such explicit or implicit consent.

and given that literally anyone in the world may pick up the gcc source
code and consider themselves to become a developer (as permitted
by the GPL) that's a serious concern.

in addition to that, even if you as developers have indeed been
explicitly or implicitly granted a Trademark License that does *not*
extend to *Distributors* of gcc and i again refer you to the wording that i
copied here, and to the debian bugreport.

i appreciate that this is a bloody nuisance.  i do however expect the
Rust Foundation to get their act together and act Reasonably and
Fairly to sort out the mess they've accidentally created.

after all, Trademarks do have value in FOSS Projects, to protect
them from harm in ways that Copyright Licenses cannot touch.
it's just rather unfortunate that they're really not well-understood,
not even by Lawyers!

l.

Re: rust non-free-compatible trademark

[Alexandre Oliva]

On Jul 17, 2022, Mark Wielaard <mark@klomp.org> wrote:

> None of that required a trademark license because the usage of the
> word java was just for compatibility with the java programming
> language.

"just for compatibility" is an defense that applies to copyrights, but
AFAIK it doesn't apply to trademarks.

indeed, one can probably still find records suggesting that gcj got its
name, "GNU Compiler for Java", that way rather than the more natural
phrasing "Java Compiler", because the Java trademark was liberally
licensed for use in the form "for Java", whereas other uses were not.

-- 
Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
   Free Software Activist                       GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>

Re: rust non-free-compatible trademark

[Alexandre Oliva]

On Jul 17, 2022, Richard Biener via Gcc <gcc@gcc.gnu.org> wrote:

> We’ll call it gust.

How about "giust"?  (GNU Implementation of...)

so that it sounds like https://just-lang.org/

-- 
Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
   Free Software Activist                       GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>

Re: rust non-free-compatible trademark

[Mark Wielaard]

Hi Luke,

On Sun, Jul 17, 2022 at 07:29:22PM +0100, lkcl wrote:
> whilst you *as developers* have been in contact with the Rust Foundation
> and presumably have private assurances that your use of the Trademarked
> word "rust" is Authorised under License (through either implication or by
> actual explicit approval) absolutely nobody else does.

As far as I know all discussions have been in public. The Rust
Foundation is aware of the gccrs frontend and other "unofficial"
implementations.

Using the word "rust" in the implementation of the gccrs frontend
doesn't need any "Authorization under License". Normal use of a word
isn't something that Trademarks prevent.

> i appreciate that this is a bloody nuisance.  i do however expect the
> Rust Foundation to get their act together and act Reasonably and
> Fairly to sort out the mess they've accidentally created.

I believe the Rust Foundation is reasonable. We aren't using the word
mark "Rust" in a way that needs any trademark license. And even if we
did the Rust Foundation allows all usage of the word mark as long as
you don't deliberately try to confuse about (commercially) shipping a
product called "Rust" that is officially endorsed by the Rust
Foundation.

If the Rust Foundation really believed that some of the marketing we
do around the gccrs frontend is confusing they would contact us and if
they are reasonable we can adjust the messaging (we can be reasonable
too).

The best advice I can give you is to listen to what the Rust
Foundation itself says about their trademark:

  Please do not approach users of the trademarks with a
  complaint. That should be left to the Rust Foundation and its
  representatives. Thanks!

  If you have a specific question or concern about promoting Rust or
  using its trademarks, please contact the Rust Foundation:
  contact@rustfoundation.org.

Cheers,

Mark

Re: rust non-free-compatible trademark

[lkcl]

sorry, Mark, you're still misunderstanding, on multiple levels
and in so many ways i am having a hard time tracking them
all.

i don't feel that i've been heard, and consequently do not
feel comfortable continuing the conversation, especially
given that i have other priorities.

if you had asked questions "so let me make sure that
i understand you correctly" i would feel much more
comfortable to continue the conversation.

i have raised the topic: it is your responsibility and duty to
consider.

l.

Re: rust non-free-compatible trademark

[Richard Kenner]

> Normal use of a word isn't something that Trademarks prevent.

In general, no, but what it prevents is using the word in a way that
would produce confusion with an "official" use of that mark.  If the
word that constitutes the mark is too general, then the trademark
shouldn't have been granted.  But let's assume that somebody has
trademarked a common adjective, which we'll call "adjective", when
applied to noun "noun".

If I write "I have an adjective noun", that's supposed to refer to the
trademarked it.  If it instead refers to some other item (e.g., in our
case a compiler with patches), that's a trademark violatio.

Re: rust non-free-compatible trademark

[David Brown]

On 17/07/2022 18:31, Mark Wielaard wrote:
> Hi Luke,
> 
> On Sun, Jul 17, 2022 at 04:28:10PM +0100, lkcl via Gcc wrote:
>> with the recent announcement that rust is supported by gcc
> 
> There is just a discussion about whether and how to integrate
> (portions) of the gccrs frontend into the main gcc repository. Nobody
> claims that means the rust programming language is supported by gcc
> yet. There is a lot of work to be done to be able to claim that.
> 
>> has it been taken into consideration that the draconian (non-free-compatible)
>> requirements of the rust Trademark make the distribution of the gcc
>> compiler Unlawful?
>>
>>      https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013920
> 
> That looks to me as an overreaching interpretation of how to interpret
> a trademark. I notice you are the bug reporter. It would only apply if
> a product based on gcc with the gccrs frontend integrated would claim
> to be endorsed by the Rust Foundation by using the Rust wordmark. Just
> using the word rust doesn't trigger confusion about that. And
> trademarks don't apply when using common words to implement an
> interface or command line tool for compatibility with a programming
> language.
> 
> If you are afraid your usage of gcc with the gccrs frontend integrated
> does cause confusion around the Rust word mark then I would suggest
> contacting the Rust Foundation to discuss how you can remove such
> confusion. Probably adding a README explicitly saying "this product
> isn't endorsed by and doesn't claim to be endoresed by the Rust
> Foundation" will be enough.
> 
> Good luck,
> 
> Mark
> 

Speaking as someone who is neither a lawyer, nor a GCC developer, nor 
even (as yet) a Rust user, it seems to me that step 1 would be to hear 
what the Rust Foundation has to say on the matter:

<https://foundation.rust-lang.org/policies/logo-policy-and-media-guide/>

As far as I can tell, if they have been happy with the current gccrs 
project, they should in principle be happy with its integration in gcc 
mainline.  And they are also happy to talk to people, happy to promote 
rust, and happy to work with all kinds of free and open source projects. 
  The key thing they want to avoid would be for GCC to produce a 
compiler that is mostly like rust, but different - leading to 
fragmentation, incompatibilities, confusion, bugs in user code.  /No 
one/ wants that.

I am sure that if the Rust Foundation foresaw a big problem here, they'd 
already have contacted the gccrs and/or GCC folks - the project is not a 
secret.

I would think that the long term aim here is that the gcc implementation 
of rust (may I suggest "grust" as a name, rather than "gust"?) be 
considered "official" by the Rust Foundation - with links and 
information on their website, their logo on the GCC website, and 
coordination between GCC and the Rust Foundation on future changes. 
That may be ambitious, or far off, but it should be the goal.

In the meantime, as far as I can see it is just a matter of writing 
"rust" without capital letters, and a documentation disclaimer that 
grust is not (yet) endorsed by the Rust Foundation.

David

Re: rust non-free-compatible trademark

[lkcl]

On Mon, Jul 18, 2022 at 8:09 AM David Brown <david.brown@hesbynett.no> wrote:

> Speaking as someone who is neither a lawyer, nor a GCC developer, nor
> even (as yet) a Rust user, it seems to me that step 1 would be to hear
> what the Rust Foundation has to say on the matter:
>
> <https://foundation.rust-lang.org/policies/logo-policy-and-media-guide/>

this is their Trademark License.  like a Patent License or a Copyright
License it comprises *additional* terms and conditions with which
You *must* Comply.

[you *can* attempt to ignore it but exactly like ignoring a Copyright License
 you risk operating Unlawfully and place yourself at risk of being sued
 at best in a Civil Court, and there are some circumstances in Trademark
 Law where you can end up in a Criminal Court as well].

the objectionable section of that Trademark License is:

    Uses that do not require explicit approval #

    Distributing a modified version of the Rust programming language or the
   Cargo package manager, provided that the modifications are limited to:
   - porting the software to a different architecture
   - fixing local paths
   - adding patches that have been released upstream
   - adding patches that have been reported upstream, provided that the
     patch is removed if it is not accepted upstream

    Uses that require explicit approval #

    Distributing a modified version of the Rust programming language
    [or the Cargo package manager] with modifications other than those
    permitted above and calling it Rust or Cargo requires explicit,
    written permission from the Rust Foundation.

so any optimisations made by anyone are Unlawful.

any additional documentation is Unlawful.

any addition of Copyright notice files (debian/copyright) is Unlawful.

why?

because none of those "patches" are "permitted" by the Rust Foundation
under their Trademark License.


> As far as I can tell, if they have been happy with the current gccrs
> project, they should in principle be happy with its integration in gcc
> mainline.  And they are also happy to talk to people, happy to promote
> rust, and happy to work with all kinds of free and open source projects.
>   The key thing they want to avoid would be for GCC to produce a
> compiler that is mostly like rust, but different - leading to
> fragmentation, incompatibilities, confusion, bugs in user code.  /No
> one/ wants that.

yes, absolutely.  it's quite obvious that that was the intent of the
clause that they added, which explicitly prohibits patching without
consent [and still having the right to use the word "rust'].

however that prohibition is - as i have said many times and been ignored
as many times - is in *direct* violation of the GPL, and of Debian's DFSG
(on multiple counts), and is also completely Un-Reason-Able.

in addition - and this was not acknowledged either - any developer
*not* considered to be "part of the gcc team" - i.e. anyone who wants
to modify and then further distribute - patched versions of gcc containing
gccrs - also does so at the risk of violating the Rust Trademark.

> I would think that the long term aim here is that the gcc implementation
> of rust (may I suggest "grust" as a name, rather than "gust"?) be
> considered "official" by the Rust Foundation - with links and
> information on their website, their logo on the GCC website, and
> coordination between GCC and the Rust Foundation on future changes.
> That may be ambitious, or far off, but it should be the goal.

at which point although the gcc team is fine, the ongoing distribution
of gcc by anyone and everyone still is not.

actually, it occurs to me that under the terms and conditions of the GPL,
even the gcc developers may not be able to comply with the GPL *and*
those above Trademark Conditions, because the restriction on
what can and cannot be patched is in direct conflict with *granting
the right to modify*.

if this is in fact the case then the only choice left for the gcc developers
would be to cease and desist distribution of gcc, because they cannot
comply with both Licenses simultaneously.

which is why i said - and have been ignored - that the gcc developers
need rather urgently to seek proper legal counsel and get a proper
legal opinion.

l.

Re: rust non-free-compatible trademark

[Jonathan Wakely]

On Mon, 18 Jul 2022 at 09:07, lkcl via Gcc <gcc@gcc.gnu.org> wrote:
> which is why i said - and have been ignored - that the gcc developers
> need rather urgently to seek proper legal counsel and get a proper
> legal opinion.

You haven't been ignored. People have expressed reasonable
disagreements with your interpretation.

Just because every line of your email hasn't been explicitly responded
to with positive acknowledgement of receipt doesn't mean you've been
ignored.To keep insisting that sounds silly, and IMHO will increase
the chance of being ignored in future.

Re: rust non-free-compatible trademark

[lkcl]

On Mon, Jul 18, 2022 at 9:50 AM Jonathan Wakely <jwakely.gcc@gmail.com> wrote:

> You haven't been ignored. People have expressed reasonable
> disagreements with your interpretation.
>
> Just because every line of your email hasn't been explicitly responded
> to with positive acknowledgement of receipt doesn't mean you've been
> ignored.

if i feel that i've been ignored, and it makes me upset and frustrated
i have every right to say so, and whilst i know that you are trying to
help you are unfortunately at risk from telling me that my feelings
are invalid, which is a line that i trust you understand is completely
and utterly inappropriate that you cannot cross.

bottom line is that you're giving a perfectly reasonable justification
for Mark's lack of empathy.

[sadly this is extremely common in Technical discussions]

i know exactly what Mark's doing: he's only superficially skim-reading
reading (citing the Java case without even acknowledging that i'd
raised it already - twice), wants to take control of the conversation and
wants it shut down as quickly as possible (telling me to "go contact the
Rust Foundation directly").

i'd very much like to see Mark read - and follow - this
https://www.crnhq.org/cr-kit/#empathy

i'm already at this:
https://www.crnhq.org/cr-kit/#assertiveness

l.

Re: rust non-free-compatible trademark

[lkcl]

a (private) discussion has, fascinatingly, uncovered this, from 1987:
http://archive.adaic.com/pol-hist/policy/trademrk.txt

    In order to be a validated Ada compiler, a compiler must pass
    an extensive suite of programs called the Ada Compiler Validation
    Capability (ACVC).  The AJPO has adopted a certification mark to show
    that a compiler has passed the ACVC and is a validated compiler or
    a compiler derived from a validated base compiler as defined in the
    Ada Compiler Validations Procedures and Guidelines (version 1.1 of
    which was issued in January 1987).  The certification mark may also
    be used on certain literature accompanying or documenting a validated
    compiler.  Information concerning the proper use of the certification
    mark was distributed to interested parties during the summer of 1987.

what that tells us is that there is precedent for a Computer Language
to apply for and be granted a *Certification Mark* which was enforced
through the extremely simple process of running an Authorised
Certification Suite.

the modern name for such is "test suite".

if the Rust Foundation were to add an extremely simple phrase

   "to be able to use the word rust in a distributed compiler your
    modifications must 100% pass the test suite without modifying
    the test suite"

then all the problems and pain goes away.

as i said: the Rust Foundation is the world's first FOSS Project
attempting to create a Certification Mark (and doing a poor-man's
job of it).

a thorough investigation of how it was done for ADA should reveal
how it can be properly done for gccrs and rustc.

i feel reasonably confident in saying that if i had the time to look
up discussions on this topic, there would almost certainly be requests
from the Rust Foundation that gccrs pass the exact same test suites
as provided with rustc.

A Certification Mark is the proper way to formally and legally enforce such
requirements.  telling people they cannot patch the source code without
permission is a troublesome and tiresome and non-trusting way to attempt
the same objective.

l.

Re: rust non-free-compatible trademark

[Richard Kenner]

>     In order to be a validated Ada compiler, a compiler must pass
>     an extensive suite of programs called the Ada Compiler Validation
>     Capability (ACVC).

FYI: the current name for this is ACATS: Ada Conformity Assessment Test
Suite.

>    "to be able to use the word rust in a distributed compiler your
>     modifications must 100% pass the test suite without modifying
>     the test suite"

What does "in" mean here?  Is "rust" modifying "language" or "compiler"
in this case?  As was stated, that's a significant difference.

> a thorough investigation of how it was done for ADA should reveal
> how it can be properly done for gccrs and rustc.

It's a very different situation.  Ada was a standardized language via
a very formal process.  And it was a very different time.

Re: rust non-free-compatible trademark

[Richard Kenner]

> A Certification Mark is the proper way to formally and legally enforce such
> requirements. 

BTW, nobody is or was at all confident that the Ada mark was legally
enforcable.  I'm in the camp that it isn't.

> telling people they cannot patch the source code without permission

Nobody is telling people that.  What they're saying is the same thing as
the GPL does: it you distribute modified code, you need to be clear that
what you're distributing is a modification.

Re: rust non-free-compatible trademark

[Florian Weimer]

* lkcl via Gcc:

> if the Rust Foundation were to add an extremely simple phrase
>
>    "to be able to use the word rust in a distributed compiler your
>     modifications must 100% pass the test suite without modifying
>     the test suite"
>
> then all the problems and pain goes away.

No.  It would actually make matters worse for GCC in this case because
the stated intent is to ship without a borrow checker (“There are no
immediate plans for a borrow checker as this is not required to compile
rust code”, <https://rust-gcc.github.io/>, retrieved 2022-07-18).  There
are of course tests for the borrow checker in the Rust test suite, and
those that check for expected compiler errors will fail with GCC.

Thanks,
Florian

Re: rust non-free-compatible trademark

[Arthur Cohen]

Hi Florian,

On Mon, Jul 18, 2022, 20:33 Florian Weimer via Gcc <gcc@gcc.gnu.org> wrote:

> * lkcl via Gcc:
>
> > if the Rust Foundation were to add an extremely simple phrase
> >
> >    "to be able to use the word rust in a distributed compiler your
> >     modifications must 100% pass the test suite without modifying
> >     the test suite"
> >
> > then all the problems and pain goes away.
>
> No.  It would actually make matters worse for GCC in this case because
> the stated intent is to ship without a borrow checker (“There are no
> immediate plans for a borrow checker as this is not required to compile
> rust code”, <https://rust-gcc.github.io/>, retrieved 2022-07-18).


The website is not up to date and we do have to change that. We do have
plans for borrow-checking, which revolve around using and contributing to
the Polonius project.

There
> are of course tests for the borrow checker in the Rust test suite, and
> those that check for expected compiler errors will fail with GCC.
>
> Thanks,
> Florian


Thanks,

-- 
Arthur Cohen

Re: rust non-free-compatible trademark

[lkcl]

(apologies top-posting, strange mobile mailer). i would expect in that case that the Rust Foundation to work closely with Certification Mark Licensees, and to come to an accommodation, defining a subset if necessary.

if the gcc developers can clearly enunciate why shipping a "borrow checker" (whatever that is) is unreasonable, the Certification Mark Holder has to take that into consideration.  without knowing full details i would expect it to be a third party library of some kind (rather than libgcc.a)

Certification Mark Holders *have* to act FRAND otherwise they lose the Certification Mark

aside: it is reasonable for a Certification Mark Holder to require full compliance, they are after all the Custodians of the Language, and one would not expect a broken (non-compliant) compiler to actually be distributed, regardless of a Certification Mark.

thus i think you'll find that the usual "pre-alpha alpha beta" release cycles which would and would not naturally be released for distribution fit directly and one-to-one with what a Certification Mark Holder would and would not authorise.

regarding missing tests: well, tough titty on the Certification Mark Holder.  if they cannot define the Compliance Test Suite they cannot tell people they are non-compliant, can they!

thus although quirky it all works out.

(whereas telling people what patches they can and cannot apply just pisses them off).

l.



On July 18, 2022 7:32:25 PM GMT+01:00, Florian Weimer <fweimer@redhat.com> wrote:
>* lkcl via Gcc:
>
>> if the Rust Foundation were to add an extremely simple phrase
>>
>>    "to be able to use the word rust in a distributed compiler your
>>     modifications must 100% pass the test suite without modifying
>>     the test suite"
>>
>> then all the problems and pain goes away.
>
>No.  It would actually make matters worse for GCC in this case because
>the stated intent is to ship without a borrow checker (“There are no
>immediate plans for a borrow checker as this is not required to compile
>rust code”, <https://rust-gcc.github.io/>, retrieved 2022-07-18). 
>There
>are of course tests for the borrow checker in the Rust test suite, and
>those that check for expected compiler errors will fail with GCC.
>
>Thanks,
>Florian

Re: rust non-free-compatible trademark

[David Malcolm]

On Mon, 2022-07-18 at 20:35 +0100, lkcl via Gcc wrote:
> (apologies top-posting, strange mobile mailer). i would expect in that
> case that the Rust Foundation to work closely with Certification Mark
> Licensees, and to come to an accommodation, defining a subset if
> necessary.
> 
> if the gcc developers can clearly enunciate why shipping a "borrow
> checker" (whatever that is) is unreasonable, the Certification Mark
> Holder has to take that into consideration.  without knowing full
> details i would expect it to be a third party library of some kind
> (rather than libgcc.a)
> 
> Certification Mark Holders *have* to act FRAND otherwise they lose the
> Certification Mark
> 
> aside: it is reasonable for a Certification Mark Holder to require full
> compliance, they are after all the Custodians of the Language, and one
> would not expect a broken (non-compliant) compiler to actually be
> distributed, regardless of a Certification Mark.
> 
> thus i think you'll find that the usual "pre-alpha alpha beta" release
> cycles which would and would not naturally be released for distribution
> fit directly and one-to-one with what a Certification Mark Holder would
> and would not authorise.
> 
> regarding missing tests: well, tough titty on the Certification Mark
> Holder.  if they cannot define the Compliance Test Suite they cannot
> tell people they are non-compliant, can they!
> 
> thus although quirky it all works out.
> 
> (whereas telling people what patches they can and cannot apply just
> pisses them off).

I've been trying to ignore this thread, but unfortunately it seems to
still be going on.

Luke: you appear to me to be the one who is telling people what patches
they can and cannot apply, and it's pissing me off.  You seem to me to
be constructing elaborate arguments for why there's some kind of legal
problem here, and elaborate purported workarounds, when it isn't at all
clear to me that there are any problems.

Are you a lawyer?  If so please consider volunteering your time to the
GCC Steering Committee *privately*.  If not, it seems to me to be a
terrible idea to try to get the developers to pontificate in public
about alleged legal issues with the project, their implications, and
supposed workarounds.

The GCC Steering Committee has approved merging the rust frontend into
GCC.  It's a big project, so I fully expect that the frontend that we
ship in GCC 13.1 will have bugs, missing functionality, and slight
differences compared to rustc.  I'm guessing we'll need to have some
kind of in the release notes for GCC 13 to set people's expectations -
perhaps the GCC 13 release of the rust frontend will be considered just
of "alpha" quality, for people to "kick the tyres" - but I leave that
judgement call to Philip and the other gcc rust developers.  There are
no doubt "unknown unknowns" (to misquote Donald Rumsfeld), and shaking
these out will make help both the GCC and Rust communities - but please
can we leave the technical issues to the developers doing the work (I'm
a gcc developer, but merely a rust "fanboy").

The gcc rust frontend is an ambitious one with lots of technical
challenges, but which has the potential to make the GCC and Rust
development communities stronger; this discussion seems to me to be a
pointless attempt to pick a fight between the two.


These opinions are my own, and not those of my employer, etc etc
Dave

> 
> l.
> 
> 
> 
> On July 18, 2022 7:32:25 PM GMT+01:00, Florian Weimer <
> fweimer@redhat.com> wrote:
> > * lkcl via Gcc:
> > 
> > > if the Rust Foundation were to add an extremely simple phrase
> > > 
> > >    "to be able to use the word rust in a distributed compiler your
> > >     modifications must 100% pass the test suite without modifying
> > >     the test suite"
> > > 
> > > then all the problems and pain goes away.
> > 
> > No.  It would actually make matters worse for GCC in this case
> > because
> > the stated intent is to ship without a borrow checker (“There are no
> > immediate plans for a borrow checker as this is not required to
> > compile
> > rust code”, <https://rust-gcc.github.io/>, retrieved 2022-07-18). 
> > There
> > are of course tests for the borrow checker in the Rust test suite,
> > and
> > those that check for expected compiler errors will fail with GCC.
> > 
> > Thanks,
> > Florian
> 

Re: rust non-free-compatible trademark

[lkcl]

On Mon, Jul 18, 2022 at 10:01 PM David Malcolm <dmalcolm@redhat.com> wrote:

> Luke: you appear to me to be the one who is telling people what patches
> they can and cannot apply, and it's pissing me off.

1) please don't you dare put words into my mouth that i did not state.
    first and only warning.
2) i'm sorry you're annoyed. Asperger's interactions with neuro-typical
    individuals who are not used to the same typically do not go well:
    this conversation has all the hallmarks i'm used to being subjected
    to (and, frankly, shouldn't have to put up with).
    as you can probably imagine in 25 years it's pretty tiresome
    for me to be constantly subjected to abuse based solely on
    misunderstandings that, with the tiniest bit of tolerance, could
    easily have been avoided.
  3) as you work for redhat, you should be able to speak to HR and
      request Diversity training for how to interact with people with
      Asperger's.  [or, at least, how to recognise them and not get
      pissed off by how they speak].  given that it was "neurodiversity month"
      only a few weeks ago you should be able to find references on linkedin.

> Are you a lawyer?  If so please consider volunteering your time to the
> GCC Steering Committee *privately*.  If not, it seems to me to be a
> terrible idea to try to get the developers to pontificate in public
> about alleged legal issues with the project, their implications, and
> supposed workarounds.

i'm a Libre Ethical Technology Specialist.  i expect a project such as
gcc to be held accountable publicly for its decisions and actions,
and to act responsibly.  this conversation will be watched by a hell
of a lot of people and if there are private conversations on this topic
being held behind closed doors then how the hell can anyone have
any confidence and trust in gcc?

i'm publicly and fully accountable in the FOSS projects that *i* manage,
including the full financial records, and given how massively high-profile
gcc is, i expect it to be held publicly accountable to a far greater degree.


> The gcc rust frontend is an ambitious one with lots of technical
> challenges, but which has the potential to make the GCC and Rust
> development communities stronger;

or, if done incorrectly, screw absolutely everyone who ever tries
to distribute gcc or attempt to contribute to it.

> this discussion seems to me to be a
> pointless attempt to pick a fight between the two.

wrong, sorry.  read again the parts where i recommend a workable
solution that is based on a past real-world case: the ADA Certification
Mark.  here is the link again:

    http://archive.adaic.com/pol-hist/policy/trademrk.txt

what you *might* be referring to is that i have absolutely no qualms
at all about calling out the Mozilla Foundation's Rust Trademark as,
frankly, "bloody stupid".  given their past handling of iceweasel this
should be no surprise to anyone familiar with that fiasco.

i have absolutely no problem with the Python Software Foundation
Trademark because the PSF Trademark does not attempt such a
kak-handed, heavy-handed and draconian imposition.

i mean, for god's sake, the attempt to hide the efforts to demand
that people contact them if they perform any kind of "unauthorised"
patches is hidden in a document entitled "Logo and Media Policy Guide".
this in no way should inspire confidence!

please understand: if they *actually* did a decent job and *actually*
listened by converting the Trademark to a proper Certification Mark
(just as ADA did in 1987), i would be the first person to very loudly
praise them for such an astoundingly forward-thinking strategic
move to protect the Rust Language from harm in a very natural
and logical way.

from me you will always get the blunt truth as i see it.  no gloves,
no sugar-coating.  no diplomacy, no lying by omission.  it's... not
popular, but serves an extremely valuable purpose: cuts through
a lot of crap on topics that people were either not aware of or
were deeply uncomfortable bringing up, often for years.

you might not feel comfortable *admitting* that (certainly not publicly)
but after some [considerable] time and calm and considered
investigation, and once your feathers have de-ruffled, you'll
appreciate what i've done.

l.

Re: rust non-free-compatible trademark

[Gabriel Ravier]

On 7/19/22 01:09, lkcl via Gcc wrote:
> On Mon, Jul 18, 2022 at 10:01 PM David Malcolm <dmalcolm@redhat.com> wrote:
>
>> Luke: you appear to me to be the one who is telling people what patches
>> they can and cannot apply, and it's pissing me off.
> 1) please don't you dare put words into my mouth that i did not state.
>      first and only warning.
> 2) i'm sorry you're annoyed. Asperger's interactions with neuro-typical
>      individuals who are not used to the same typically do not go well:
>      this conversation has all the hallmarks i'm used to being subjected
>      to (and, frankly, shouldn't have to put up with).
>      as you can probably imagine in 25 years it's pretty tiresome
>      for me to be constantly subjected to abuse based solely on
>      misunderstandings that, with the tiniest bit of tolerance, could
>      easily have been avoided.
>    3) as you work for redhat, you should be able to speak to HR and
>        request Diversity training for how to interact with people with
>        Asperger's.  [or, at least, how to recognise them and not get
>        pissed off by how they speak].  given that it was "neurodiversity month"
>        only a few weeks ago you should be able to find references on linkedin.

Hello there. For a while I've been watching this conversation and seeing 
how
inflammatory it has become, and this seems like the right place to 
intervene,
as I myself have Asperger. I would like to say that from my perspective 
it is
you, not everyone else, who is subjecting people to abuse based on a
misunderstanding with what seems to me like a constant stream of "OMGWTF
THE RUST TRADEMARK WILL DESTROY ALL GCC DEVELOPERS, REMOVE RUST
NOW" (note: this is hyperbole, and I am not claiming it is literally 
what you
have said, it is simply the general feeling that I have been left off 
with after
reading your messages throughout this thread).

David is simply telling you one of the most basic implications of what you
have been claiming, i.e. that if the GCC Rust frontend was to be added to
GCC then it would apparently expose everyone involved in distribution of
GCC (which as we know is a very wide definition) to trademark infringement
lawsuits and even potential criminal liability as you have claimed in a 
previous
message. The hopefully obvious implication is that the patches to add 
the Rust
frontend should thus not be applied. You have answered to this by 
telling him
that this simple statement is somehow abuse, which seems ridiculously
confrontational to me and almost like you are accusing him of deliberately
acting in bad faith, even though I have been doing my best to assume the
assumption of good faith so far. Just as you have cited the Conflict 
Resolution
Kit in one of your previous messages, I too know of similar sources. 
Here is one
that might help you with this: 
https://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith

>> Are you a lawyer?  If so please consider volunteering your time to the
>> GCC Steering Committee *privately*.  If not, it seems to me to be a
>> terrible idea to try to get the developers to pontificate in public
>> about alleged legal issues with the project, their implications, and
>> supposed workarounds.
> i'm a Libre Ethical Technology Specialist.  i expect a project such as
> gcc to be held accountable publicly for its decisions and actions,
> and to act responsibly.  this conversation will be watched by a hell
> of a lot of people and if there are private conversations on this topic
> being held behind closed doors then how the hell can anyone have
> any confidence and trust in gcc?
>
> i'm publicly and fully accountable in the FOSS projects that *i* manage,
> including the full financial records, and given how massively high-profile
> gcc is, i expect it to be held publicly accountable to a far greater degree.

While public accountability is a very good thing, I would hope you 
understand
that some topics are best kept private to some degree, at least for a short
duration so as to discourage impulsive or defensive reactions. Security
vulnerabilities should be a rather obvious example of this, but sensible 
issues
such as legal ones (as the one you are raising here) are also the kind 
of things
that seem to me like they should be kept private in the very short term.

Coming on the GCC mailing list, which hundreds of people regularly read,
and making such a statement as "has it been taken into consideration 
that the
draconian (non-free-compatible) requirements of the rust Trademark make the
distribution of the gcc compiler Unlawful?" will instinctively put 
essentially
everyone directly involved with the project on the defensive for hopefully
obvious reasons. By being publicly confrontational on this issue, you 
make it
much, much more likely, regardless of the accuracy of your statements, 
that the
people involved will not want to admit any potential mistake they might 
have
made, and will encourage them to be equally confrontational in 
responding to
you.

Making private contact instead is very useful for establishing good 
faith and
makes it easy for those that have been contacted to talk honestly about the
matter, and in my view, public confrontation on things like this is only 
useful
if those involved are using the privacy of the initial contact to cover 
up inaction.

Note that this is also essentially the policy of the FSF on GPL violations
(see the "Confidentiality can increase receptiveness and responsiveness"
section in https://www.fsf.org/licensing/enforcement-principles), which
seems quite reasonable to me.


>> The gcc rust frontend is an ambitious one with lots of technical
>> challenges, but which has the potential to make the GCC and Rust
>> development communities stronger;
> or, if done incorrectly, screw absolutely everyone who ever tries
> to distribute gcc or attempt to contribute to it.

Yes, because the Mozilla Foundation is obviously an evil cabal aiming to
destroy all that dare to touch GCC. Well, I suppose saying this will 
probably
get me accusations of putting words into your mouth, but I can't really
see any other way to get to this conclusion other than this kind of
conspiratorial thinking, unless you're assuming egregriously bad faith
on their part.



>> this discussion seems to me to be a
>> pointless attempt to pick a fight between the two.
> wrong, sorry.  read again the parts where i recommend a workable
> solution that is based on a past real-world case: the ADA Certification
> Mark.  here is the link again:
>
>      http://archive.adaic.com/pol-hist/policy/trademrk.txt
>
> what you *might* be referring to is that i have absolutely no qualms
> at all about calling out the Mozilla Foundation's Rust Trademark as,
> frankly, "bloody stupid".  given their past handling of iceweasel this
> should be no surprise to anyone familiar with that fiasco.
>
> i have absolutely no problem with the Python Software Foundation
> Trademark because the PSF Trademark does not attempt such a
> kak-handed, heavy-handed and draconian imposition.
>
> i mean, for god's sake, the attempt to hide the efforts to demand
> that people contact them if they perform any kind of "unauthorised"
> patches is hidden in a document entitled "Logo and Media Policy Guide".
> this in no way should inspire confidence!
>
> please understand: if they *actually* did a decent job and *actually*
> listened by converting the Trademark to a proper Certification Mark
> (just as ADA did in 1987), i would be the first person to very loudly
> praise them for such an astoundingly forward-thinking strategic
> move to protect the Rust Language from harm in a very natural
> and logical way.
>
> from me you will always get the blunt truth as i see it.  no gloves,
> no sugar-coating.  no diplomacy, no lying by omission.  it's... not
> popular, but serves an extremely valuable purpose: cuts through
> a lot of crap on topics that people were either not aware of or
> were deeply uncomfortable bringing up, often for years.
>
> you might not feel comfortable *admitting* that (certainly not publicly)
> but after some [considerable] time and calm and considered
> investigation, and once your feathers have de-ruffled, you'll
> appreciate what i've done.

It also encourages them to actively do nothing about it, as any related
action could easily be tied back to this conversation without explicit
admission, and could itself be seen as a public admission of guilt,
regardless of how guilty of anything they actually are.

> l.

Re: rust non-free-compatible trademark

[Florian Weimer]

* Arthur Cohen:

> Hi Florian,
>
> On Mon, Jul 18, 2022, 20:33 Florian Weimer via Gcc <gcc@gcc.gnu.org> wrote:

>  No.  It would actually make matters worse for GCC in this case because
>  the stated intent is to ship without a borrow checker (“There are no
>  immediate plans for a borrow checker as this is not required to compile
>  rust code”, <https://rust-gcc.github.io/>, retrieved 2022-07-18). 
>
> The website is not up to date and we do have to change that. We do
> have plans for borrow-checking, which revolve around using and
> contributing to the Polonius project.

Ahh, I was wondering about that, but I couldn't find a clear indicator
that Polonius is still being developed in upstream Rust.

Thanks,
Florian

Re: rust non-free-compatible trademark

[lkcl]

On Tue, Jul 19, 2022 at 12:41 AM David Edelsohn <dje.gcc@gmail.com> wrote:
>
> Luke,
>
> The GCC Community will give the issues that you raised due
> consideration and resolve any problems through appropriate channels.

David: although this was a private reply I am assuming that is in
error, and i feel it is appropriate to make public, and wrap up this
thread.

thank you for being literally the first person to very kindly give an explicit
indication that i've been heard.  that's all that any of you had to do, and
now that i feel i've been heard i am no longer deeply frustrated and angry.

    https://www.crnhq.org/cr-kit/#empathy

Gabriel i very much appreciate your efforts to tell me that "i am
the problem" (see #empathy above) and i acknowledge those efforts.
let's not reduce the S/N ratio any further, eh?

perhaps everyone can learn from this experience, and some point
down the line appreciate that, as an outsider with no vested interest,
i was the only member in this community that could safely raise that
"The Rust Foundation Emperor has no Clothes" without damage to
their tenure, client base, or career, in what is one of the highest-paying
most strategically critical FOSS Projects in the world.

in summary i look forward to seeing the public results of the consideration of
conversion of the Rust Trademark to a Certification Mark and the clear benefits
and natural fit with existing FOSS development practices that entails.

    http://archive.adaic.com/pol-hist/policy/trademrk.txt

l.


l.

Re: rust non-free-compatible trademark

[Jonathan Wakely]

On Tue, 19 Jul 2022 at 11:27, lkcl via Gcc <gcc@gcc.gnu.org> wrote:
>
> On Tue, Jul 19, 2022 at 12:41 AM David Edelsohn <dje.gcc@gmail.com> wrote:
> >
> > Luke,
> >
> > The GCC Community will give the issues that you raised due
> > consideration and resolve any problems through appropriate channels.
>
> David: although this was a private reply I am assuming that is in
> error, and i feel it is appropriate to make public, and wrap up this
> thread.
>
> thank you for being literally the first person to very kindly give an explicit
> indication that i've been heard.  that's all that any of you had to do, and
> now that i feel i've been heard i am no longer deeply frustrated and angry.

I already said you were not being ignored, but you chose to interpret
it as a dismissal of your feelings. Telling people to have more
empathy and then reacting negatively when people have responses you
don't like comes across as hypocritical. Your communication affects
others too.

>
>     https://www.crnhq.org/cr-kit/#empathy

This should apply to all parties, not just the ones that aren't you.

"Empathy is about building rapport, openness and trust between people.
When it is absent, people are less likely to consider your needs and
feelings."

You started this thread with strong words like "draconian", "Unlawful"
and immediately insisted on absolutes like "completely removed". No
attempt to build rapport, or consider the feelings of the gccrs
developers. It's no wonder it went downhill!

>
> Gabriel i very much appreciate your efforts to tell me that "i am
> the problem" (see #empathy above) and i acknowledge those efforts.
> let's not reduce the S/N ratio any further, eh?
>
> perhaps everyone can learn from this experience, and some point
> down the line appreciate that, as an outsider with no vested interest,
> i was the only member in this community that could safely raise that
> "The Rust Foundation Emperor has no Clothes" without damage to
> their tenure, client base, or career, in what is one of the highest-paying
> most strategically critical FOSS Projects in the world.

Nobody who has replied to you was trying to preserve their career or
tenure, they just didn't agree with you. That's allowed.

> in summary i look forward to seeing the public results of the consideration of
> conversion of the Rust Trademark to a Certification Mark and the clear benefits
> and natural fit with existing FOSS development practices that entails.
>
>     http://archive.adaic.com/pol-hist/policy/trademrk.txt
>
> l.
>
>
> l.