Help on Dual-Licensing Strategy

[Karsten M. Self]

on Sun, Sep 09, 2001 at 08:44:49PM +0100, rghoo (rghoo at yahoo.co.uk) wrote:
> 
> Hi,
> I would like to release some software withdual licensing. I have heard
> of this being done with GPL and a seperate commercial license;
> however, I need to allow the open source code to link with non-free
> software - this seems to exclude GPL.
>  
> So, the next obvious consideration seems to be a dual license using
> LGPL. That solves the above problem, but does it introduce new
> problems?...
>  
> What about contributions from 3rd parties - would they be discouraged
> from contributing with the knowledge that their contributions could be
> exploited (exploitation seems to be possible anyway with most
> non-GPL-based open source licenses since they allow private forking).
>  
> Under a LGPL dual-license, reasons to pay for the commercial license
> (rather than sticking with the LGPL side) include not being forced to
> distribute the source code, the freedom to fork the code privately,
> re-licensing permission, or some other 'special' privileges.
>  
> Does this make sense, or am I missing something? Is dual-licensing a
> dangerous game or is it a good compromise, allowing both commercial
> exploitation for those that are prepared to pay for it and free use of
> the software for those that don't want to pay.
>  
> Has anyone seen this approach elsewhere?
>  
> Thanks for any new perspectives/opinions that you can offer.
> Regards, Rghoo.


Please set your mailer to send text rather than HTML, particularly to
list or Usenet posts.

Please set your mailer/editor linewrap to 68-75 characters.  I strongly
recommend 72 as a good default.

Thank you.


Addressing your question:  if you are the sole author of a work, you
yourself aren't restricted with what you can do with future versions of
your work by the terms of any free software / OSI-Open Source license
I'm aware of.  Your sublicensees are.

In this case, licensing under, say, the GPL and a proprietary license is
effectively saying "you can use this software under the terms of one, or
both, of the following licenses".

However, in the event your code becomes mingled with other code under
other terms (say, exclusively proprietary code, or exclusively GPLd
code), then the combined derivative work has to answer to other owners.
My own feeling is that dual licensing is a bit like sugar-coating a
pill.  The real medicine is the free software license (frequently the
GPL/LGPL), while the sugar is something added to make the package
paletable to (usually) corporate tastes.  However, it's often found that
the sugar without the pill isn't very effective.

The risk of dual-licensing is creating license-incompatible forks should
some downstream licensee choose to exercise only a subset of the
licenses.

In practice, I've not yet seen this occur.

Cheers.

-- 
Karsten M. Self <kmself at ix.netcom.com>          http://kmself.home.netcom.com/
 What part of "Gestalt" don't you understand?             There is no K5 cabal
  http://gestalt-system.sourceforge.net/               http://www.kuro5hin.org
   Free Dmitry! Boycott Adobe! Repeal the DMCA!    http://www.freesklyarov.org
Geek for Hire                        http://kmself.home.netcom.com/resume.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20010910/4354ff9b/attachment.sig>