public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Reid Hekman <reid.hekman@ndsu.nodak.edu>
To: David Lang <david.lang@digitalinsight.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: MODULE_LICENSE and EXPORT_SYMBOL_GPL
Date: Fri, 19 Oct 2001 19:00:56 -0500	[thread overview]
Message-ID: <3BD0BEB8.2020508@ndsu.nodak.edu> (raw)
In-Reply-To: <Pine.LNX.4.40.0110191257070.9276-100000@dlang.diginsite.com>

David Lang wrote:

> I use this example becouse the question came up a week or so ago and I
> don't remember seeing the issue resolved.


I wish it was easy, but legality/copyright/property rights are not 
always easy topics


> the problem posted is that a BSD no adv licence is GPL compatable and
> source may be available and therefor BSD no adv modules should not taint
> the kernel, on the other hand it's possible to have a BSD no adv licensed
> module that the source is not available for and therefor it should taint
> the kernel.
> 
> just knowing the license doesn't tell you if the source is available
> (which is the stated goal of the taint stuff)


Good point. Anybody else want to chime in here? For linux-kernel's 
purposes at least, a BSD licensed piece of code with no source is about 
as useful as ice-cream to an eskimo. Of course creating BSD licensed 
binaries from closed source is kind of silly. Say we see an external 
module (one not distributed with the kernel source) that identifies 
itself as BSD licensed loaded into somebodies' kernel then ask the 
provider for source and he refuses. Rightfully that kernel should have 
been marked tainted. Is their anything in the licensing that would allow 
us to say that specifying a BSD license in the MODULE_LICENSE tag refers 
to source distribution? Or is that implied?


> if instead of MODULE_LICENSE there was a MODULE_SOURCE tag this would not
> be an issue, and the EXPORT_SYMBOL_GPL would obviously be a seperate
> issue. as it is they both use the MODULE_LICENSE tag which confuses the
> intent of both of them.


What's in a name? If it's called MODULE_LICENSE or MODULE_SOURCE if it's 
defined to mean availability and licensing of module source, that's the 
important distinction. Further, EXPORT_SYMBOL_GPL is a separate issue 
regardless, it allows us a definite way to specify "private" interfaces.

 
> if BSD no adv is considered a non-tainting license then what's to stop all
> the binary-module vendors from useing it in their modules? it doesn't
> requrire that they give the source to anyone so it's no risk to their IP
> but it avaids the 'bad press' of the kernel announcing that useing their
> stuff taints the kernel.


If it becomes public knowledge that a binary-module vendor distributes 
modules marked as BSD licensed but the source is unavailable that would 
be bad PR for them. First they would probably be ignored by 
linux-kernel. They should also be branded as liars for disingenuosly 
marking their products.

 
> on the other hand if BSD no adv is considered a taining license then you
> are going against the statement that it's compatable with the GPL and you
> are telling module programmers who release the source that BSD isn't good
> enough they can only work with the linux kernel if they change to the GPL
> (or one of the other approved licenses)


I don't think anybody wants to disallow linking of GPL compatible code 
with Linux. Given that the FSF thinks that BSD-no-adv is compatible, I'd 
tend to agree with them. If MODULE_LICENSE is to be used as your 
"MODULE_SOURCE" idea is (which I think it is), it's not an issue. As far 
as programmers releasing BSD source, they seem to be OK with it, check 
the source yourself: http://lxr.linux.no/search?string=MODULE_LICENSE.

> again my point is that knowing the license is not enough by itself to know
> if the kernel should be considered tainted, so let's not try to do it this
> way.


Making access control mandatory with source code availability is hard. 
Nobody said this was a be-all, end-all solution, it simply helps screen 
those that would take advantage of people's limited time and effort. It 
depends partly on respect and good-will, so if a vendor wants to violate 
that trust and flaunt arrogance to the folks of the linux community, so 
be it.

> or if the intent really is to force everything to be GPL then just say so
> rather then claiming that that's not your intent.
> 
> David Lang

The intent is to more clearly define the gracious exception that has 
been made for binary-only module vendors. If we decide to disallow the 
use of BSD licensed code (when everybody else in the world can use it) 
that's our loss. In the end we want to respect other people's copyrights 
and have our's respected in turn.

Regards,
Reid


  reply	other threads:[~2001-10-20  0:02 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-18 16:43 MODULE_LICENSE and EXPORT_SYMBOL_GPL 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 [this message]
2001-10-20  6:38             ` Keith Owens
2001-10-21 15:06               ` Alan Cox
2001-10-21 15:47 ` Alan Cox
  -- strict thread matches above, loose matches on Subject: below --
2001-10-19 18:03 Roy Murphy
2001-10-18 16:05 Roy Murphy
2001-10-18 15:17 ` Arjan van de Ven
2001-10-19 15:30   ` Taral
2001-10-21 15:22     ` Alan Cox
2001-10-21 20:16       ` Taral
2001-10-19 17:06   ` David Woodhouse
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=3BD0BEB8.2020508@ndsu.nodak.edu \
    --to=reid.hekman@ndsu.nodak.edu \
    --cc=david.lang@digitalinsight.com \
    --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