On Mon, 12 May 2014 22:00:33 -0600 Tim Flink <tfl...@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
signature.asc
Description: PGP signature
_______________________________________________ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
