GPL and closed source
David Woolley
forums at david-woolley.me.uk
Tue Jun 7 20:27:54 UTC 2011
Tzeng, Nigel H. wrote:
> On 6/6/11 3:29 AM, "David Woolley" <forums at david-woolley.me.uk> wrote:
>
> If the work is an aggregation why would the second group not be GPL
> compatible?
I'm assuming that <----> means "linking" in the sense understood by the
FSF. Actually, the FSF's definition of aggregation, seems fairly
liberal, in that they seem to accept closer coupling than simply a
collection of independent programs.
>
> If I write a GPL program that uses a BSD graphing package where
> proprietary plug-ins (additional graph types, renderers, skins, whatever)
> are available why would that BSD graphing package not be GPL compatible?
> Because someone has the ability to buy a proprietary plug in for it?
>
> As to whether the work is an aggregation reverts back to the deliberate
> confusion regarding what is or isn't a derived work.
>
To, me, the creation of a derivative work is pretty fundamental to the
design of the GPL.
The GPL dates from a time before DLLs and plugins, so they have
complicated the issue.
As I see it, the FSF aim are that:
- a non-"open source" program should not benefit from GPLed subroutines
(aimed at the proprietary program developer) - i.e. an anti freeloading
provision;
- an open source program should be usable without having to pay for a
proprietary library, and should be modifiable except for interfaces that
a fundamental to the OS or compiler - a freedom provision.
It was drafted at a time when all OSes were proprietary and
bootstrapping gcc would typically require a proprietary compiler.
I've used not-"open source" as the source for a proprietary program
could be available, but encumbered.
--
David Woolley
Emails are not formal business letters, whatever businesses may want.
RFC1855 says there should be an address here, but, in a world of spam,
that is no longer good advice, as archive address hiding may not work.
More information about the License-discuss
mailing list