subunit-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

[Copied to subunit-dev for discussion on licencing, please only reply to
one of the lists :)]

On Mon, 2009-04-13 at 13:40 +0100, Michael Foord wrote:
> Robert Collins wrote:
> > On Mon, 2009-04-13 at 12:55 +0100, Michael Foord wrote:
> >
> >   
> >> In fact I'm not sure that as a 'collection of facts' a protocol itself 
> >> would even be licensable in the first place.
> >>
> >> FWIW the GPL license on subunit would also stop me using, re-using or 
> >> contributing to it.
> >>     
> >
> > This is only slightly useful to know - what would be much more useful
> > is:
> >  - what characteristics do you need changed in the licence to let you 
> >    use/reuse subunit
> >   
> 
> Because of the viral nature of GPL it is impossible to use it in [many] 
> commercial situations.
> 
> I don't like the license and don't wish to put this restriction on code 
> I release - this means I can't include GPL licensed code (LGPL is fine) 
> in my projects. The BSD, MIT, Apache and MS-PL are all perfectly decent 
> alternative licenses.

Ok, I understand that position.

> >  - what [other] characteristics do you need changed to be willing to 
> >    contribute to it
> >   
> 
> I'm interested in protocols for test result reporting - which sounds 
> like part of what subunit does.

[All of] :).

>  It is not something I currently have 
> bandwidth to contribute to, I'm still working through my backlog now 
> that my book is complete. Improving unittest itself is something I am 
> dedicating time to. FWIW the GPL license means that code from subunit 
> can't be reused in unittest should any of it prove relevant.

I have precise notes on the contributors and know them well; I assert
that there will be no issue in getting agreement to assign copyright to
the PSF if needed. I'll mull over a change to LGPL for subunit, though I
may split the codebase into a separate library-and-toolchain in that
event.

> > The GPL is my default licence, I use it until-and-unless there are
> > reasons to use a different licence. It doesn't mean I'm unwilling to
> > change.
> >   
> If you accept any contributions back to your code after original 
> licensing you no longer own the copyright on the whole work - and need 
> the permission of all contributors to relicense. This is why I tend to 
> choose a more permissive default license. (BSD has been my choice but 
> I'm considering switching to Apache because it explicitly handles the 
> licensing of contributions.)
> 
> Michael

Well, I think there are two conflated things here - copyright assignment
and license changing; with BSD you have exactly the same situation as
with [L]GPL - if you accept a patch from someone that is itself large
enough to accrue copyright protection, you can no longer distribute the
resulting work except under the combined licence terms for all the
combined components. The difference then is that BSD allows proprietary
versions under the original licence, and [L]GPL does not. One thing that
is becoming recognised as best practice is to seek copyright assignment
for projects regardless of the licence - note that Python itself asks
for such assignments to be made - to allow the project stewards to [for
instance] transfer the code to a larger body [such as the PSF].

-Rob

Attachment: signature.asc
Description: This is a digitally signed message part