From: Taral <taral@taral.net>
To: linux-kernel@vger.kernel.org
Subject: Re: MODULE_LICENSE and EXPORT_SYMBOL_GPL
Date: Fri, 19 Oct 2001 10:30:41 -0500 [thread overview]
Message-ID: <20011019103041.D30774@taral.net> (raw)
In-Reply-To: <3bceefa6.3cf6.0@panix.com> <3BCEF26E.12D69882@redhat.com>
On Thu, Oct 18, 2001 at 04:17:02PM +0100, Arjan van de Ven wrote:
>
> > Exported interfaces are "methods of operation" in the sense of US
> > Copyright Law. Copyright Law affords no protection to "methods of
> > operation". The GPL, which gains its strength from Copyright Law, also
> > has no rights in this area. If a GPLed module does not want other code
> > using its interfaces, they should not be exported.
>
> I think you're missing one thing: binary only modules are only allowed
> because of an exception license grant Linus made for functions that are
> marked EXPORT_SYMBOL(). EXPORT_SYMBOL_GPL() just says "not part of this
> exception grant"....
Fine. I (the hypothetical binary driver maker) will just make two
modules -- one which is MODULE_LICENCEd GPL, and the other which is not.
The first will re-export your interfaces as unrestricted ones which the
second can use. Are we going to start insisting on a transitivity of
this restriction? If so, then it's possible that a large number of
interfaces might go...
I also think this is somewhat ridiculous. If I (the binary module maker)
distribute a program which effectively replicates the functionality of
insmod without the licence checking, and distribute that program with my
module, am I violating any restrictions? I don't think so, since it's
the end-user that ends up linking the kernel to the module. No linked
products are actually distributed...
--
Taral <taral@taral.net>
This message is digitally signed. Please PGP encrypt mail to me.
"Any technology, no matter how primitive, is magic to those who don't
understand it." -- Florence Ambrose
next prev parent reply other threads:[~2001-10-19 15:29 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-18 16:05 MODULE_LICENSE and EXPORT_SYMBOL_GPL Roy Murphy
2001-10-18 15:17 ` Arjan van de Ven
2001-10-19 15:30 ` Taral [this message]
2001-10-21 15:22 ` Alan Cox
2001-10-21 20:16 ` Taral
2001-10-19 17:06 ` David Woodhouse
-- strict thread matches above, loose matches on Subject: below --
2001-10-19 18:03 Roy Murphy
2001-10-18 16:43 Roy Murphy
2001-10-18 15:49 ` Arjan van de Ven
2001-10-18 18:42 ` Tim Bird
2001-10-19 15:38 ` Taral
2001-10-18 16:07 ` Jan-Benedict Glaw
2001-10-18 22:38 ` David Lang
2001-10-19 0:46 ` John Alvord
2001-10-18 23:57 ` David Lang
2001-10-19 12:44 ` Reid Hekman
2001-10-19 20:07 ` David Lang
2001-10-20 0:00 ` Reid Hekman
2001-10-20 6:38 ` Keith Owens
2001-10-21 15:06 ` Alan Cox
2001-10-21 15:47 ` Alan Cox
2001-10-18 3:23 Keith Owens
2001-10-18 4:03 ` Alexander Viro
2001-10-19 7:16 ` Kai Henningsen
2001-10-19 8:26 ` Nils Philippsen
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=20011019103041.D30774@taral.net \
--to=taral@taral.net \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.