Re: [Plib-devel] Releasing PLIB 1.2 *soon*.

[Steve B. <sjb...@ai...>]

Eero Pajarre wrote:
> 
> Steve Baker wrote:
> >
> 
> > So, if the library is a DLL, he can do that - but there is a
> > good chance that if he does, the program will crash because
> > of the C++ issues.
> >
> 
> I really don't yet know if this would work. Almost certainly
> it would only work within a certain family of compilers.

The problem is with C++ and DLL's (or '.so's in UNIX/Linux)
is that any slight change to the C++ header file will generally
result in a new library module that will die when linked to
a program that was compiled with the old header.

That causes endless problems for the poor library maintainer
because he'll get lots of emails of the form "PLIB sucks -
it keeps crashing."...the problem being that someone upgraded
PLIB (either accidentally whilst installing something else
or on purpose) - and didn't recompile *all* the programs
that refer to it.

I'm absolutely adamant that I'm not going there.  PLIB support
already takes up *WAY* too much of my time.

You are at liberty (of course) to take a copy of PLIB, change it
to create DLL's, call it something slightly different (PLIBDLL
or something) and deal with the maintenance calls for that new
package yourself.

> Anyways I think it would satisfy at least the letter
> of the LGPL. (And it would not be any worse than
> distributing application .o files).

> Btw I am not
> 100% sure how inline functions behave regarding
> LGPL. Certainly they cannot be updated if the
> "client program" is not distributed as source code.
> (I know the license mentions inline funcs)

LGPL says:

  "If such an object file uses only numerical parameters, data
structure layouts and accessors, and small macros and small inline
functions (ten lines or less in length), then the use of the object
file is unrestricted, regardless of whether it is legally a derivative
work."

...so you shouldn't have a problem here.

> Assuming that this could be implemented for WIN32
> with an external .def file, would you include the
> .def file into plid distribution?

If I do that, Windoze users will build DLL's and I'll
get into the whole support rat's nest.

I'm sorry to seem unhelpful about this - but I'm absolutely
not going to do anything to PLIB that makes it harder to
maintain.

But really, you should stick with a staticly linked PLIB
and offer the '.o'/'.obj' files for your application.

Look at the problem carefully:

The relevent section of the LGPL says:

  "...linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a "work that uses the
library".  The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables."

...and section 6 says:

  "6. As an exception to the Sections above, you may also compile or
link a "work that uses the Library" with the Library to produce a
work containing portions of the Library, and distribute that work
under terms of your choice, provided that the terms permit
modification of the work for the customer's own use and reverse
engineering for debugging such modifications."

  "You must give prominent notice with each copy of the work that the
Library is used in it and that the Library and its use are covered by
this License.  You must supply a copy of this License." ....

Then, it goes on to say that you must provide source for the library
along with either .o/.obj's for the application - or the source code
for the application....although you can either:

* Distribute those files with the application ...OR...
* "Accompany the work with a written offer, valid for at least
  three years, to give the same user the {object files or source code}, for
  a charge no more than the cost of performing this distribution.
* Give access to those files on a web site or something but only if
  that's how the application was originally distributed.
* Mention that the user already has all those files (eg in the case
  of the GNU math library or something).

It seems to me that all you *really* need to do is to put a note in
the manual or 'README' file that says something to the effect of:

  "This package makes use of 'PLIB' - which is licensed under the
   Library GNU Public License.  Under the terms of that license,
   you are entitled to request certain materials that would allow
   you to re-link this package using a modified version of PLIB.
   This offer is valid for three years only - and you will be
   charged for the cost of distributing those materials.  Please
   write to the address below if you would like to take advantage
   of this facility."

...then you make a pile of about 50 floppies with the .o files and
PLIB sources, put them in a cupboard somewhere and forget about them.
The nebulous "cost of distributing" will put off the idly curious
and if someone really does want a copy - charge them whatever it costs
you to get an employee to answer the mail, pick up a floppy from the
cupboard and post it to the customer.  You can charge the actual
cost of doing this - so if your internal hourly rate for your staff
is $45 per hour and the cost of the floppy is $1 and the postage
$2 then you can demand $50 for this service.  If a ton of people
decide to take you up on it for some arcane reason, you won't lose
out.

I think you are making way to big a deal about this - it's a
no-brainer, really.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)