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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox