From: Alex Bligh - linux-kernel <linux-kernel@alex.org.uk>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Alex Bligh - linux-kernel <linux-kernel@alex.org.uk>,
linux-kernel@vger.kernel.org
Subject: Re: Devlinks. Code. (Dcache abuse?)
Date: Mon, 19 Nov 2001 22:06:38 -0000 [thread overview]
Message-ID: <1925755060.1006207598@[195.224.237.69]> (raw)
In-Reply-To: <E165w5m-0007mR-00@the-village.bc.nu>
In-Reply-To: <E165w5m-0007mR-00@the-village.bc.nu>
Alan,
>> Which trademark law are you violating by having that in a directory
>> name path, which you are not also violating by having it in the
>> kernel source, make config, name of the module and its printk()
>> on load, etc. etc.
>
> You can change all the other names with almost zero impact
Ah - OK; dname/dt didn't occur to me, but still this is
a consequence of a violation, not the violation itself; what
aspect of trademark law is a problem?
There are a few other examples of this. /proc/cpuinfo has
shed[amb].121$ cat /proc/cpuinfo
...
vendor_id : GenuineIntel
...
model name : Pentium III (Coppermine)
That's 2, if not 3 trademarks without acknowledgement that
might be searched for by userspace programs.
The solution is presumably that lanana doesn't accept /registered/
trademarks without a GPL compatible license from the trademark
holder. I don't believe you would have too much of a problem
with unregistered trademarks.
In any case, most trademark law has some concept of 'fair use'.
See the difficulty many trademark holders have in suing
registrants of [trademark]sucks.[registrysuffix]. I think
the use in terms of supporting hardware is pretty
fair. Cloning competing OS functionality is closer to
the wind I admit.
(Only tangentially relevant but for amusement value and a
beautifully argued case read
http://arbiter.wipo.int/domains/decisions/html/2001/d2001-0918.html
enjoyment almost guaranteed
)
--
Alex Bligh
next prev parent reply other threads:[~2001-11-19 22:07 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-16 10:08 Neil Brown
2001-11-16 10:26 ` Alan Cox
2001-11-19 3:47 ` Neil Brown
2001-11-19 8:52 ` Andreas Dilger
2001-11-19 10:30 ` Neil Brown
2001-11-19 10:17 ` Alan Cox
2001-11-19 10:40 ` Neil Brown
2001-11-19 11:14 ` Alan Cox
2001-11-19 11:21 ` Neil Brown
2001-11-19 11:27 ` Alexander Viro
2001-11-20 1:06 ` Neil Brown
2001-11-24 20:44 ` Rob Landley
2001-11-19 20:41 ` Alex Bligh - linux-kernel
2001-11-19 21:36 ` Alan Cox
2001-11-19 22:06 ` Alex Bligh - linux-kernel [this message]
2001-11-19 11:05 ` Erik Andersen
2001-11-16 10:33 ` Alexander Viro
2001-11-19 4:02 ` Neil Brown
2001-11-16 19:14 ` Andrew Pimlott
2001-11-16 20:42 ` Neil Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='1925755060.1006207598@[195.224.237.69]' \
--to=linux-kernel@alex.org.uk \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®