Tools, Borrowing Code and libtaskotron's License

[Mike Ruckman]

On Mon, 12 May 2014 22:00:33 -0600
Tim Flink <tflink at redhat.com> wrote:

> One of the things that I've wanted for taskotron is to keep the
> directive documentation inside the code for those directives - similar
> to how ansible does their documentation for modules [1].
> 
> [1] http://docs.ansible.com/modules_by_category.html
> 
> Mike has been working on some code to make that happen [2] (be nice if
> you review - I asked him to cut as many corners as possible for the
> moment) that borrows heavily from ansible since the approaches have
> quite a bit of overlap. The potential issue here is license
> incompatibility - libtaskotron (and all of the other qa devel
> projects) are gpl2+ and ansible is gpl3. If we take code from
> ansible, we'll have to re-license libtaskotron as gpl3.
> 
> [2] https://phab.qadevel.cloud.fedoraproject.org/D93
> 
> I'm not against doing this in principle but putting my "license
> pedant" hat on for a moment, I don't think it'll be quite as simple
> as changing some text files.
> 
>   - I'm not 100% clear on whether gpl3 code can use gpl2 libraries.
> I'm under the impression that there is generally accepted leeway here
>     in the case of dynamic languages like Python but I want to run
> this past FPC or Fedora legal first.
> 
>   - If gpl3 code can't use gpl2 libraries, we need to do a code audit
>     to verify that we aren't using anything that's strictly gpl2 only.
>     I did a quick check of libtaskotron and I think we're OK here but
> I haven't checked everything else.
> 
>   - Are we OK with saying "anything run by libtaskotron has to be gpl3
>     compatible"? This gets into another area that I'm personally fuzzy
>     on (the line between derivative and usage) but I don't know of any
>     gpl2-only or agpl libraries that we'd want to use with
> libtaskotron so this may end up being a non-issue entirely
> 
>   - This could cause problems if we share code between our other qa
>     projects since they're all gpl2+. On the other hand, all
>     contributions are gpl2+ so we can just re-license them as needed,
>     assuming that they don't link to anything that's strictly gpl2.
> 
> If we decide not to use the code in [2], we have 2 options for
> documentation:
> 
>   - completely re-implement the doc-building code in a way that avoids
>     the license issue
>   - find another way to do the directive documentation.
> 
> I'd appreciate thoughts on the issues here. I'm leaning towards
> "re-license as gpl3 and take the code from ansible" but I could be
> missing some complication here.
> 
> Tim

I'm not terribly familiar with the nuances of software licensing, but I
don't see a ton of reason to not re-license to gpl3 _aside_ from the
potential to not be able to use strictly gpl2 code in the future. The
code in question isn't terribly difficult to write from scratch - but in
the future we might need something that's gpl2 that *is* hard to write
from scratch.

That would be my only worry when it comes to re-licensing the whole
project for essentially one script.

// Mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/qa-devel/attachments/20140513/238db0d6/attachment.sig>