Tools, Borrowing Code and libtaskotron's License

Tim Flink tflink at redhat.com
Tue May 13 04:00:33 UTC 2014


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
-------------- 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/20140512/a7064794/attachment.sig>


More information about the qa-devel mailing list