🚀 go-pugleaf

Some LPL questions for the FSF people:

	-Is the GNU Library Public License intended to cover programs
	like BISON ?

	-If so would source (.y files) have to be distributed to
	avoid substantial inclusion of GNU-ware and hence the LPL
	"executable" restrictions?

These restrictions would certainly frighten off some
(potentially) commercial users, but it at least the rest of
us would know where we stood.

To avoid such uncertainties I would suggest that the LPL be
rewritten to apply to ANY type of file whatsoever
(libraries, bison, even documentation), on the basis that:

	Any non-FSF-free distribution of a file which is `derived
	from' a `substantial' FSF-free file must also make available:
	a) all source, documentation & license requirements for the 
	FSF-free file.
	b) a method by which the non-free file can be regenerated.
	c) ALL material required to regenerate the non-free file by this
	method.

This new license could replace both the LPL and the GPL.

`Substantial' requires clarification, both here and in the
LPL.  In particular there MUST be a guarantee that ANYTHING
which appears in an #include-able FSF-free header file
(macros, classes, inline functions) is not, and will never
become, `substantial'.  Otherwise how can we ever know that
a header file is `safe to use'?

++++++ 
You've probably all heard this before and I don't want to
raise a storm, but I would also like to suggest that GNU/FSF
'go commercial' in the sense that commercial software
developers be permitted to include FSF software without the
above restrictions provided they pay FSF and/or the authors
of the FSF-ware appropriate $$$ and advertise their use of
FSF-ware. For the rest of us the FSF-ware would remain
inalienably FSF-free. The NO WARRANTY status of FSF-ware
would be maintained.

This would
a) keep the FSF-freedom we already have.
b) encourage the wider use of FSF-ware, especially by the
large commercial market, on terms the rich.com's ought to be
able to live with.
c) provide much needed funds to FSF and its contributers, thus
aiding & encouraging further contributions of FSF-ware.
d) further publicize FSF notions.

The disadvantages are
a) possible legal problems, especially with implied warranties.
b) FSF might become too commercialized.

I think (b) is unlikely given the proven idealism of the FSF
founders.

I for one would be much happier to contribute to GNU under
these conditions - I like the idea of free-ware but why
should I stop someone using it and paying me for it if they
don't agree?

An appropriate price would be a fair cut of the proceeds on
a `value-added' basis (perhaps by %-of-code-contributed), so
you would only have to pay a lot for FSF-ware if you made a
lot from it. This would be shared (say) 50/50 between FSF
and the code authors, with FSF doing the admin &
negotiation. A standard public `non-free free-ware' contract
for commercial users might even be possible.

(I feel that such value added pricing will come to be
accepted by the software industry in general -- if any of it
survives the current Great American Lawsuit battles --
because the future's object-oriented software tools will be
very much mix-&-match affairs, especially when real
object-databases come along.)

Who loses from this?
Comments?

Bill Triggs. Oxford University Robotics Lab.