On Thu, Mar 30, 2017 at 1:28 PM, Amos Jeffries <a...@treenet.co.nz> wrote:
> Thank you. > > Biggest issue I see is a bunch of License problems - which will affect > Ubuntu inclusion in similar ways IMHO: > I agree and thank you as nobody ever spotted (or cared about) that. But I know the Authors and can ask about a proper relicensing of those bits. TL;DR summary of the license todo: * debian/tests/test-squid.py is GPLv2 should be proper GPLv2+ * debian/tests/testlib.py bad copy of GPLv2+ should be proper GPLv2+ - edit hints that authors actually wanted it to be the incompatible? * debian/tests/testlib_httpd.py is GPLv3 should be GPLv2+ * debian/tests/squid add an explicit GPLv2+ License > [...] > would make the .deb package and everything inside it a GPLv3-only > offering. Even assuming tat is okay, a v3-only .deb makes the above > v2-only script issues worse. > I'm not a lawyer, but I think in the python + test case this is even more special. As there is no classic linking involved, but more important the tests are only part of the source, but not part of the .deb being produced. Never the less I clearly want to sort that out - thanks for bringing it up! - this appears to be a large and generic python library. Do we really > need to embed it anyway? can it not be pulled from some other package or > provided by the QA infrastructure itself? > It is part of a much bigger testsuite, therefore the bigger libraries. A package would only make sense if it would be packaged but it is not, the right way would be to pull from their git or such. But then that gets us back into the connectivity issues from DebCI/Ubuntu Test infrastructure. The benefit of taking the libs as-is was to be able to later on update them by copying in the newer versions / cherry-picking changes. Changes are needed over time as Distributions change every so slightly. Yet I agree that it might need only a small subset, would you be ok with me trimming that code down to the point that it will be only the test-squid.py with just the functions needed moved into it and a proper relicense from the original Authors? > I think a few basic changes to the test logic should be made to avoid > Internet access being required to send traffic to what are bogus URL > domains anyway. > It only goes to localhost/127.0.0.1 in what I sent, could you elaborate where you still see Internet access being required? The only references I still see are in the the header which would be removed in a cleanup anyway. Those headers refer mostly to its use in the wider QA suite and in the scope of being a dep8 test make it misunderstandable at best. [...] Also squid.conf can load a custom hosts file > to point any domains used at a server being run by the test > infrastructure, eg the Apache being run for other tests anyway. > I didn't know there was an apache around for such tests, but since the current code is self sufficient on its local host that would not be needed. And thereby would work also in e.g. local kvm based tests and such. It would be nice If you could ack the approach of: - clean .py files to be one file stripped to what is needed - re-licence by original Authors as proper GPLv2+ - add license to d/t/squid - keep tests themselve as-is (vs localhost) If you would do so I'd start getting in touch with the original Authors and once I have their ack start the cleanup/merge of the code.
