linux-kernel - RE: Aggregation in embedded context, is kernel GPL2 prejudiceagainst embedded systems?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 11 Oct 2007 12:06:14 -0400
From:	"Crane, Matthew" <mcrane03@...ris.com>
To:	"Adrian Bunk" <bunk@...nel.org>
Cc:	<linux-kernel@...r.kernel.org>
Subject: RE: Aggregation in embedded context, is kernel GPL2 prejudiceagainst embedded systems?

Hi, 

I wasn't sure how to describe what the people and groups with the
mandate to defend open source software.  There are people and groups
with such a mandate.

I'm asking if in a legal sense the grayness is affected by the
constraints of the hw the kernel is being run on, and some attempt to
quantify how the grayness is affected.  Of course it is not black and
white and ultimately up to a judge. 

I realize similar questions have been asked for more then a decade.
What is generally practiced and accepted does change, and any judge
weighing a case wrt these issues would consider that.

Matt

-----Original Message-----
From: Adrian Bunk [mailto:bunk@...nel.org] 
Sent: Thursday, October 11, 2007 11:16 AM
To: Crane, Matthew
Cc: linux-kernel@...r.kernel.org
Subject: Re: Aggregation in embedded context, is kernel GPL2
prejudiceagainst embedded systems?

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/