All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ihar 'Philips' Filipau" <filia@softhome.net>
To: Guennadi Liakhovetski <gl@dsa-ac.de>
Cc: Linux Kernel ML <linux-kernel@vger.kernel.org>
Subject: Re: [somewhat OT] binary modules agaaaain
Date: Sat, 24 Apr 2004 12:03:46 +0200	[thread overview]
Message-ID: <408A3B82.5020807@softhome.net> (raw)
In-Reply-To: <1MJlZ-4mT-47@gated-at.bofh.it>

Guennadi Liakhovetski wrote:
> Hello all
> 
> I came across an idea, how Linux could allow binary modules, still having
> reasonable control over them.
> 
> I am not advocating for binary modules, nor I am trying to make their life
> harder, this is just an idea how it could be done.
> 
> I'll try to make it short, details may be discussed later, if any interest
> arises.
> 
> A binary module is "considered good" if
> 

   I belive that you forgot to make "The Point."

   And "discussion" (good vs. bad isn't discussion, but flames) went in 
wrong direction.

   Be constructive. For example: Let's aks h/w producers making at least 
glue layer open source (bsd or something), so people eventually might 
help to maintain this glue layer.
   How it can help? - producer with time may move bigger parts of driver 
into open source domains.
   How it can gets screwed? - producer might just start liking when 
someone is doing his work for him. Some license a-la GPL to not let glue 
layer to slip into binary only domain back must be in place.

   This could be a good starting point for h/w producers and linux 
comunity as a whole.

   Saying Good/Bad is just B.S. - helps no-one.
   Building bridges between comunity and producers - might improve and 
deepen relationships. And that's what I hope for.

P.S. nVidia driver might be an example: IIRC nVidia engineers were 
saying that they have four 2/3rd party code parts inside driver, which 
they are not able to open source/GPL. But open source glue layer to 
connect this "tainted" 4 parts with Linux kernel might help everyone: 
nVidia, LK and even those four companies. At least I hope for this.

       reply	other threads:[~2004-04-24 10:03 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1MJlZ-4mT-47@gated-at.bofh.it>
2004-04-24 10:03 ` Ihar 'Philips' Filipau [this message]
2004-04-24 20:00   ` [somewhat OT] binary modules agaaaain Guennadi Liakhovetski
2004-04-19 15:53 Guennadi Liakhovetski
2004-04-20  8:39 ` Geert Uytterhoeven
2004-04-20 10:23   ` Guennadi Liakhovetski
2004-04-20 14:11 ` Bartlomiej Zolnierkiewicz
2004-04-20 15:08   ` Guennadi Liakhovetski
2004-04-21  2:24     ` Horst von Brand
2004-04-22 14:13       ` Grzegorz Kulewski
2004-04-23 11:28     ` Andrew McGregor
2004-04-23 12:29       ` Richard B. Johnson
2004-04-24  2:29         ` Andrew McGregor
2004-04-22 16:19   ` Charles Shannon Hendrix
2004-04-22 18:55     ` Bartlomiej Zolnierkiewicz

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=408A3B82.5020807@softhome.net \
    --to=filia@softhome.net \
    --cc=gl@dsa-ac.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.