Tim <tim-proje...@sentinelchicken.org> wrote:

> Hello,

> I have a moderately complex licensing scenario that I was hoping
> someone could help me navigate.  Here is what I *want* to do, though
> it may not work:

> A. Build a framework which is licensed under the LGPLv3

> B. Write "wrapper" plugins for the framework which link various
>   third-party libraries having multiple different open source
>   licenses, including CPL, IBM Public, old BSD, and GPL v2/v3

> C. Write proprietary, closed-source plugins for the framework which
>   are sold to help support development of the framework


> The most likely distribution model for each component, is that the
> framework and wrapper plugins would be distributed by me in one
> package; the third-party libraries would be distributed by Linux
> distributions in a standard way; and the proprietary plugins would be
> distributed in a separate package by me.  However, it may make sense
> to distribute all components together as a VM or something similar to
> make deployment easier.

> My questions are:

The obvious answer is you need to consult a specialist lawyer; nobody in
this mailing list is known to be such.  However...

> 1. Which of the above scenarios could cause licensing problems?
>   1.A. Does the use of a GPLv2 or GPLv3 third-party library create a
>        condition where the framework itself must be considered
>        "GPLed" such that the proprietary modules or other third-party
>        libraries are then incompatible?

"Must be considered" doesn't exist in this area.  You license your
software as you see fit, and whatever license you choose will place
restrictions on what it can be combined with.  It sounds like you want to
create a non-GPL derived work of GPL'd works.  Doing this is clearly
contrary to the aims of free software, and you can be certain that the
authors of the GPL took your strategy into account when formulating it.

>   1.B. Does the method of distribution of each components make a
>        difference?  If I strictly distribute each component
>        separately (or rely on OS distributions to distribute the
>        third-party libraries) does this help me avoid some issues?

Unlikely to make a difference.  Does a pair of shoes cease to be a pair
if you pack it in two separate boxes?  (A pair of trousers would,
though.  :-)

> 2. The plugins I write for my framework would be adhering to a
>   published API that is part of the framework.  Does this help me
>   satisfy any System Library clauses or something similar to avoid
>   license conflicts?

If your library is a legitimately licensed bona fide system library, then
there won't be a problem.  If, on the other hand, it's a
subterfuge to assist in the violation of the GPL, it won't work.

> Any other issues I should consider?  I just want to make sure I
> understand the implications of this approach and what restrictions I
> might be under if I try to push this as an open source development
> model.

What you're proposing isn't an open source development model.  It's a
closed source one where you intend to subvert the GPL for your purposes.
You're not the first person to dream up schemes like this, not by a long
way.  So far, none of them have come to anything.  That might be a guide
to the answers to your questions.

Why don't you just avoid GPL'd works altogether?  There's plenty of
imprisonable software available with licenses like the BSDs.  Or,
alternatively, write the missing bits yourself.

> Thank you,
> tim

-- 
Alan Mackenzie (Nuremberg, Germany).

_______________________________________________
gnu-misc-discuss mailing list
gnu-misc-discuss@gnu.org
https://lists.gnu.org/mailman/listinfo/gnu-misc-discuss

Reply via email to