Relicensing (was Re: Initial cut at a Debian package linting wrapper for Firehose)

[David Malcolm]

On Sun, 2013-02-10 at 17:57 -0500, Paul Tagliamonte wrote:
> On Sun, Feb 10, 2013 at 04:21:14PM -0500, David Malcolm wrote:
> > On Sun, 2013-02-10 at 16:09 -0500, David Malcolm wrote:
> > > On Sat, 2013-02-09 at 18:48 -0500, Paul Tagliamonte wrote:
> > > > Hello, Firehosen,
> > > > 
> > > > I've just hacked a basic wrapper around one of the most used Debian
> > > > tools; Lintian. It's currently brokenish (need to work out some stray
> > > > Nones in the schema), but should be good to go shortly. Check it out on
> > > > GitHub[1]
> > > 
> > > Nice.  I started making a list of projects using Firehose in the
> > > README.rst and added a link.
> > > 
> > > > While wrapping it, I also added some helper functions which could use
> > > > some feedback. They're very Debian-centric, but could be simply adapted
> > > > for Firehose proper if we decided on that.
> > > 
> > > Those would be:
> > > https://github.com/paultag/storz/blob/master/storz/deb.py
> > > right?
> > > 
> > > If every Debian project using Firehose is going to use code like that,
> > > then it would makes sense to slurp that into Firehose itself, but I
> > > don't want to force dependencies on people using Firehose that aren't
> > > using the deb functionality (I see you have a couple of "from debian"
> > > imports, which don't exist on this box).
> > > So you could put these into a new firehose/debian.py, or alternatively
> > > put the imports into *method scope* within firehose/report.py, and have
> > > a couple of DebianBinary.from_deb() and DebianSource.from_dsc()
> > > classmethods.  (If you also want to slurp in the exception classes into
> > > firehose you'd want to rename them also, naturally)
> > 
> > Oh, and we chatted about this on IRC, but it's worth mentioning here:
> > we're going to relicense Firehose from GPLv3, probably to "LGPLv2.1 or
> > later", to allow it to be license-compatible with a broader array of
> > projects.  (I need it to be compatible with GPLv3 so that I can run it
> > from inside GCC, but I'd prefer a more liberal license so it can be used
> > e.g. in a wide array of web apps for reporting, and embedded in other
> > Python-based static analyzers).
> > 
> > See:
> > https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#GPL_Compatibility_Matrix
> > 
> > Paul: you already agreed to this on IRC, right?  The only other
> 
> Yep, but for the sake of having a GPG signed public message:
> 
> At Dave's discretion I hearby retroactively relicense all my work on
> firehose to be under the LGPL, the version of which Dave is free to
> choose. I'll assume this puts the code under LGPLv2.1+, and will modify
> the current source to reflect this. If that's not right, let me know.
> 
> > contributor so far is Michael Hrivnak (CCed) who verbally gave me
> > permission to relicense as I saw fit when we created this thing at
> > FUDcon a few weeks ago (and also another Red Hatter).   (Better to
> > relicense sooner rather than later, i.e. whilst the number of
> > contributors is small)
> 
> Aye! I'm generally perfectly fine with any DFSG free license, shouldn't
> make too much of a fuss here.

I've relicensed firehose as "LGPLv2.1 or later" as of:
https://github.com/fedora-static-analysis/firehose/commit/bfadb4d8414ecbdb6a3f2b836b504986e8c31767