LCDproc development and user support list

Text archives Help


[Lcdproc] Re: GPL and loadable module


Chronological Thread 
  • From: wwf AT splatwerks.org (William W. Ferrell)
  • Subject: [Lcdproc] Re: GPL and loadable module
  • Date: Fri Dec 7 01:11:01 2001

---
ssrat AT mailbag.com
wrote ---
> Mr. Mailing wrote:
>
> > GPL first as it might be very important...
> > We are going to introduce loadable module in lcdproc API v0.5.
> > 1) This mean from a technical point of view that other program could use
> > our
> > module for displaying on LCD.
> > 2) Also from a technical point of view it also mean that someone could
> > write
> > a module without giving the code for it.
> >
> > AFAIK our little project is GNU GPL licenced.
>
> Little?? :)

Heh. I wondered about that too :)

> > I need main developer input on this issue.
> > It is a VERY important issue for me.
> > I personally don't wan't a closed application to benefit from my free
> > work.
> > If they want to use part of my work on MtxOrb driver, they can talk the
> > protocol and connect to LCDd accross the network.
>
> I guess I'm more open than that. Not so long ago, I had to deal with
> licensing when it came to my floppy-based distribution. I wound up
> selecting the MIT/X License (now the same as the BSD license) for the
> distribution, but used the GPL for individual program binaries.

My $0.02 on this issue:

There's not a whole helluva lot we can do to stop somebody from ripping
off LCDproc in whole or in part and using it in a closed-source product.
If someone were actually stupid enough to release something that produced
exact (or very similar) output to LCDproc and behaved in the same way (and
had the same bugs ;), I probably have grounds to sue for copyright
violations (even under the GPL), but otherwise there's not much I can do
about it.

> 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.

True. If you're using even a single line of code from LCDproc's sources,
you must abide by the GPL. Once we support loadable binary modules,
though, there's nothing stopping someone from releasing binaries only.

On the other hand, unless I have a damned good reason to, I won't promote
or advocate the use of a binary-only client or driver. At best, its author
would get a link from LCDproc's site to theirs. I won't host binary-only
drivers/clients nor provide much support for them.

I'm firmly planted in the Open Source camp, and I am most definitely
biased towards those who work with the same ideals. This isn't to say I
won't look at a cool closed-source client and say "hey that kicks ass!",
but I'm not going to bend over backwards to keep LCDproc compatible with
it or help out the author(s).

> 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:
>
> * High-profile corporate sponsors

Hehehehe. Speaking of which, do any high-profile (hell, even low-profile
:) corporations want to sponsor LCDproc? :) Source has to stay open, but
I'm sure a corporate sponsorship would help us all forgive a binary driver
or two :)

> * Wider distribution of program

This one's tough to justify in this situation. Search for "linux lcd" on
google and LCDproc is still near the top of the list. :) I've never
submitted the project to a search engine, and only ever announced it on
Freshmeat. We're pretty damned well-known now :)

> * Support for more displays, products, etc.

Again, in this realm of LCDs, I've found just about every company who
makes these things *quite* eager to share specs, documentation, support,
and in some cases even sample units to aid in development of drivers for
their products.

They might spend fifty bucks sending me (or a fellow developer) a display
unit, but they may well earn themselves that much in profit from sales of
just twenty units because LCDproc supports their displays. Most display
makers recognize this. Matrix Orbital, Crystal Fontz, and Scott Edwards
Electronics are the three who've lent the most help so far, and I've
always been receptive to unsolicited donations of LCD hardware so I can
get support implemented for a device.

Speaking of, is anyone using the Scott Edwards displays? I'm curious what
that driver's status is. Suppose I could just check myself, eh? :)

> There's any number of places you can go to see both sides of the
> argument. Probably the champions of either side are the GNU Project
> (GPL) and the FreeBSD team (BSD License).

To clearly state my position:

LCDproc can be used for any purpose, commercially or otherwise. If a
product is released for public (or private, commercial, or licensed)
consumption that is in part or wholly based on LCDproc or any of its code,
the source code to that product must be made publically available free of
charge, in its entirety.

A client or driver isn't a separate "product", because they won't work
with anything besides LCDproc. Thus, binary-only releases of such things
isn't a big deal, and will serve only to limit the adoption of that client
or driver. It shouldn't hurt LCDproc.




Archive powered by MHonArc 2.6.18.

Top of page