[CMake] cmake license question (Was: CMake Modules)

[Jamie Jones]

On Wed, 2006-08-30 at 10:48 -0700, Brandon J. Van Every wrote:
> Joerg Mayer wrote: 
> > Hello List,
> > 
> > On Wed, Aug 30, 2006 at 04:16:00PM +0200, Andreas Schneider wrote:
> >   
> > > To get a module in the repository it needs to be at least under the New
> > > BSD License. Dual license with GPLv2 would be appreciated.
> > >     
> > 
> > The license discussion on #cmake got me wondering:
> > 
> > cmake itself is 4-clause BSD license (including the advertising clause)
> > which is incompatible with GPLv2.
> > 
> > This leads to some questions:
> > 
> > 1) What sense does it make to provide the code under GPLv2 when this
> >    license is incompatible to cmake anyway?
> >   
> 
> None.  Please get rid of the GPL.  I don't care about legal
> incompatibility; there probably isn't any.  I care about cultural
> incompatibility.

It was originally GPL only the archive - the compromise was that the
modules must be New BSD, and preferably dual licensed, so there is a
possibility that if the modules are well received they can transfer to
the official cmake distribution.

To make it clear. If you wish to contribute it would need to be under
the New BSD license - if you wish you may also dual license it with the
GPL. If it is GPL only - It can't go in the archive.

It is rather clear that you don't like the GPL, that's fine - but
ultimately the module authors decide what to license their work as.
Really, you are making a mountain out of a molehill.


>   A lot of companies, if they see a GPL on something, will simply
> refuse to use it.  Even if it's a dual license.  The legal risk is,
> "What?  What's this author doing?  Is he going to sue us someday or
> something?"  Nobody's going to take that risk for little snippets of
> build code.  Nobody's gonna hunt through an archive of build snippets
> to weed out GPL problems.  Uniform licensing is important to
> commercial interests, and it's why projects like Eclipse have one and
> only one license available.  Everyone knows what that license is, and
> if you don't want to make an archive contribution under that license,
> too bad.

Evidently those same companies have never ever read the license then. In
that case they have bigger issues to worry about then if they don't pay
attention to where their code come from. I'm a company - I use GPL code,
and in accordance with the license, if I change it and distribute those
changes, I make the source available. It's not exactly rocket science.


> >  I read
> >    that there was a discussion about the cdrecord build system recently
> >    which caused at least Debian to fork the project and replace the
> >    non-GPL compatible build system with a gpl-compatible one (or maybe
> >    still incompatible).
> >   
> 
> I would suggest drilling down to the exact details of why they made
> their decision.  I will wager, they made the decision for political
> and not legal reasons.

No, it was based on legal reasons. As a whole the work combined
different incompatible licenses, and as such only JS could distribute
it. Was an interesting "discussion" on the lists.

Regards,
Yagisan
-- 
Jamie Jones
Proprietor
E-Yagi Consulting
ABN: 32 138 593 410
Mob: +61 4 16 025 081
Email: eyagi.consulting at gmail.com
Web: http://www.eyagiconsulting.com

GPG/PGP signed mail preferred. No HTML mail. No MS Word attachments
PGP Key ID 0x4B6E7209
Fingerprint E1FD 9D7E 6BB4 1BD4 AEB9 3091 0027 CEFA 4B6E 7209
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : http://public.kitware.com/pipermail/cmake/attachments/20060831/2c25d641/attachment-0001.pgp