On Sat, Aug 07, 2004 at 07:14:02AM +0200, Wouter van Ooijen wrote:
> OK BAJ, I re-read the LGPL one more time :)

It's a sticky one. I've found that when reading stuff from the FSF it's
best to figure out what rights they are trying to protect.

> So I backtrack my objections to LGPL-ed embedded libraries to the fact
> that you can not use such a library to create a realy closed
> pay-per-chip product.

Why not? The rebuild right is annoying. Let's set it aside for now under
the guise of even if you can build new firmware, there's no way to get it
into the product.

So what's left? If you use LGPL libraries unmodified, then the combo of
yourcode+lgpllib firmware is yours to do what you wish. You can charge pay
per chip.  You can restrict distribution. You can relicense it. Folks can't
copy it.  Presuming that yourcode is closed source and your own clean code,
then the only right a user has is to sell the product. Nothing more. Nothing
less.

The LGPL is very very careful to separate the library source and binary from
the yourcode source and binary. As long as you use the library unmodified
you can treat the result as proprietary code (exempting the rebuild right
of course).


>
> Note that as author of a library that is exactly what you might want to
> prevent,

Well the LGPL isn't the right way to do it. That's the big difference between
the LGPL and the GPL. If you want to "force" source code release of yourcode
and allow for unlimited redistribution, then make the library a GPL library.

> it that case (L)GPL is a perfect license for your library.

Nope. GPL is perfect for that. The LGPL expressly recinds the encumbrance
of code that uses the library right. If you just use an LGPL library then
you have no restrictions other than the rebuild right.

> But
> when you want to promote a concept like a communication protocol I still
> hold that a more premissive license will promote the concept better (at
> the cost of making the downstream product less free).

Actually for the protocol itself isn't really relavent one way or the other.
However if a reference code implementation accompanied it, then the license
would be important. Truthfully a more restrictive license may actually be
more helpful:

1) It would guarantee consistency of implementations.
2) It could facilitate central coordination of reference library code.

But think in general for embedded systems, an Embedded GPL which the LGPL
with section 6 (rebuild right) dropped is appropriate. In short:

1) yourcode+egpllib is yours to do what you want.
2) Changes to egpllib must be distributed if the modified lib is distributed
   in any form.

That's equitable. Folks can use the library as they see fit, but any changes
get filtered back to the development community.

Again I agree that the rebuild right is a bit overbearing in an embedded
environment.

BAJ

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body