public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Guillaume Morin <guillaume@morinfr.org>
To: Andre Hedrick <andre@linux-ide.org>
Cc: James Clark <jimwclark@ntlworld.com>, linux-kernel@vger.kernel.org
Subject: Re: Driver Model 2 Proposal - Linux Kernel Performance v Usability
Date: Wed, 3 Sep 2003 14:35:07 -0400	[thread overview]
Message-ID: <20030903183507.GI905@siri.morinfr.org> (raw)
In-Reply-To: <Pine.LNX.4.10.10309031043410.13722-100000@master.linux-ide.org>

Dans un message du 03 Sep à 10:49, Andre Hedrick écrivait :
> The only solution is to created a GPL pre-loading module with all the
> GPL_ONLY needed extentions re-exported or externed as to bypass the
> horse sh*t.

Which would be a violation of the GPL :

What is the difference between "mere aggregation" and "combining two
modules into one program"?  

   Mere aggregation of two programs means putting them side by side on
the same CD-ROM or hard disk. We use this term in the case where they
are separate programs, not parts of a single program. In this case, if
one of the programs is covered by the GPL, it has no effect on the other
program.

    Combining two modules means connecting them together so that they form a
single larger program. If either part is covered by the GPL, the whole
combination must also be released under the GPL--if you can't, or won't, do
that, you may not combine them.

    What constitutes combining two parts into one program? This is a legal
question, which ultimately judges will decide. We believe that a proper
criterion depends both on the mechanism of communication (exec, pipes, rpc,
function calls within a shared address space, etc.) and the semantics of the
communication (what kinds of information are interchanged).

    If the modules are included in the same executable file, they are
definitely combined in one program. If modules are designed to run linked
together in a shared address space, that almost surely means combining them
into one program.

    By contrast, pipes, sockets and command-line arguments are communication
mechanisms normally used between two separate programs. So when they are used
for communication, the modules normally are separate programs. But if the
semantics of the communication are intimate enough, exchanging complex internal
data structures, that too could be a basis to consider the two parts as
combined into a larger program.

-- 
Guillaume Morin <guillaume@morinfr.org>

     Tu veux que les gens réagissent ? Alors commence par réagir (Lofofora)

  parent reply	other threads:[~2003-09-03 18:36 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-03 17:53 Driver Model 2 Proposal - Linux Kernel Performance v Usability James Clark
2003-09-03 17:49 ` Andre Hedrick
2003-09-03 18:23   ` Guillaume Morin
2003-09-04  4:10     ` Andre Hedrick
2003-09-03 18:35   ` Guillaume Morin [this message]
2003-09-03 19:30     ` Andre Hedrick
2003-09-03 18:18 ` Greg KH
2003-09-03 18:23 ` Richard B. Johnson
2003-09-03 18:49 ` Patrick Mochel
2003-09-03 18:58 ` Gábor Lénárt
2003-09-03 20:18 ` Christoph Hellwig
     [not found] <1062637356.846.3471.camel@cube>
2003-09-04 20:14 ` James Clark
2003-09-04 20:27   ` Mike Fedyk
2003-09-04 21:16     ` James Clark
2003-09-04 21:50       ` Mike Fedyk
2003-09-04 22:10       ` insecure
2003-09-04 22:01     ` jdow
2003-09-04 20:29   ` Rik van Riel
2003-09-04 21:12     ` James Clark
2003-09-04 21:40       ` Alan Cox
2003-09-04 21:41       ` Bartlomiej Zolnierkiewicz
2003-09-04 22:19       ` Jamie Lokier
2003-09-04 21:29   ` Richard B. Johnson
2003-09-04 21:51     ` James Clark
2003-09-04 22:06       ` Alan Cox
2003-09-04 22:10       ` Martin Mares
2003-09-04 22:23       ` Gustav Petersson
2003-09-05 17:52       ` Valdis.Kletnieks
2003-09-05 18:31         ` James Clark
2003-09-05 18:59           ` Martin Schlemmer
2003-09-05 19:12           ` Dale P. Smith
2003-09-05 19:45             ` Stan Bubrouski
2003-09-05 19:59           ` Richard B. Johnson
2003-09-05 20:01             ` James Clark
2003-09-05 20:08           ` Mike Fedyk
2003-09-05 21:15           ` Valdis.Kletnieks
2003-09-05 23:19             ` Bernd Eckenfels
2003-09-10 20:50     ` Timothy Miller
2003-09-10 20:48       ` Richard B. Johnson
2003-09-10 23:22         ` James Clark
2003-09-10 23:58           ` Greg KH
2003-09-12 20:51         ` Timothy Miller
2003-09-12 20:55           ` Tim Hockin
2003-09-15 11:39           ` Richard B. Johnson
  -- strict thread matches above, loose matches on Subject: below --
2003-09-04 22:41 Chad Kitching
2003-09-05 20:53 Chad Kitching
2003-09-05 23:30 ` Mike Fedyk

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=20030903183507.GI905@siri.morinfr.org \
    --to=guillaume@morinfr.org \
    --cc=andre@linux-ide.org \
    --cc=jimwclark@ntlworld.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