LCDproc development and user support list

Text archives Help


[Lcdproc] Re: GPL and loadable module


Chronological Thread 
  • From: David GLAUDE Mailing" <dglaudemailing AT gmx.net (David GLAUDE Mailing)
  • Subject: [Lcdproc] Re: GPL and loadable module
  • Date: Fri Dec 7 10:12:02 2001

> As I understand it, GPL code cannot be incorporated into new proprietary
> code, but proprietary code can use GPL libraries, and gcc can be used to
> create proprietary code, and so forth.

Warning, do not confuse GPL and LGPL.
Maybe the library you are talking about are LGPL and it is another story.

> For anyone to use the MtxOrb.c code, they'd have to abide by the GPL.
> However, if someone wrote a new (dynamically loaded) driver for LCDd, it
> could potentially be a proprietary binary-only library. In the same
> way, one could create a proprietary client for LCDd.

LCDd being also GPL, linking it to a proprietary binary-only library is a
NO-NO for me.
Having a proprietary client is NOT a problem at all, because it is not
linking.

> To me, there are a lot of reasons to allow proprietary dynamically
> loaded modules, and Linux is a good example of how beneficial it can
> be. Some of the reasons:

Linux is a BAD example, ask RMS about it.
By permiting proprietary loadable extention to the kernel,
Linus let the evil enter into the kernel! ;-)

> * High-profile corporate sponsors
If the software is good we don't need sponsors.

> * Support for more displays, products, etc.
If a vendor of LCD don't want to play by the GPL rule,
they those LCD won't be supported by LCDproc (my oppinion).
If a vendor give a binary only driver that is broken,
who will start crying for help to them.
We need FREEDOM to fix the bug, to support any OS/architecture, ...

David GLAUDE

PS: start the flame ;-)





Archive powered by MHonArc 2.6.18.

Top of page