public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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