public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Adrian Bunk <bunk@kernel.org>
To: "Crane, Matthew" <mcrane03@harris.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Aggregation in embedded context, is kernel GPL2 prejudice against embedded systems?
Date: Thu, 11 Oct 2007 17:15:43 +0200	[thread overview]
Message-ID: <20071011151543.GX16424@stusta.de> (raw)
In-Reply-To: <E496871456016F4CA8959BE4105D2A890E8D76@troe2k1.cs.myharris.net>

On Thu, Oct 11, 2007 at 10:33:28AM -0400, Crane, Matthew wrote:
> Hi,

Hi Matthew,

>... 
> If that is what is normal for embedded systems, wouldn't the expectation
> of what is reasonable for "mere aggregation" be similarly different?
> I've read much FUD about how anything linked statically is instantly a
> derived work.   I do not think it is so black and white.  To me this
> seems to pre-suppose that the option to load modules dynamically always
> exists.   I do believe that if it does exist, it should be taken, and
> that the interface boundaries always need to be respected regardless, to
> the point of not using kernel headers and limiting the number of calls
> to EXPORT_SYMBOL functions to the absolute minimum.

even for dynamically linking including non-GPL code is not white but 
already dark grey.

> So would the persons responsible for defending the kernel GPL make
> allowance for the minimal options for separation in a system so resource
> constrained that it makes sense only to link statically?  I am trying to
> make a case that this is ok because that is what systems similar in hw
> specs generally due to save resources, and that many examples of an
> "embedded" style of aggregation exist.
>...

There are no "persons responsible for defending the kernel GPL", there 
are just a few hundreds or thousands copyright holders of the kernel,
and each of them has the right to sue you if he thinks you distribute 
something that violates his copyright. Jurisdiction and applicable 
copyright law depends on things like where the copyright holder lives 
and where you distribute it.

> Matt

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


  reply	other threads:[~2007-10-11 15:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-11 14:33 Aggregation in embedded context, is kernel GPL2 prejudice against embedded systems? Crane, Matthew
2007-10-11 15:15 ` Adrian Bunk [this message]
2007-10-11 16:06   ` Aggregation in embedded context, is kernel GPL2 prejudiceagainst " Crane, Matthew
2007-10-11 16:22     ` Theodore Tso
2007-10-11 16:49       ` Aggregation in embedded context, is kernel GPL2prejudiceagainst " Crane, Matthew
2007-10-11 19:51         ` Alan Cox
2007-10-11 19:54     ` Aggregation in embedded context, is kernel GPL2 prejudiceagainst " Alan Cox
2007-10-11 20:49   ` David Schwartz
2007-10-11 21:20     ` Theodore Tso

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=20071011151543.GX16424@stusta.de \
    --to=bunk@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcrane03@harris.com \
    /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