Hey Rawlin- Thanks for doing more digging on the licensing aspect. I think we could find a way to make this work. The Apache FAQs are fuzzy for stuff like the boot loader exception, but would probably be ok. I dont think there is any issue including the python interpreter as PSF is an Apache friendly license.
I think Go sounds like a great idea for the db/admin.pl replacement script —Eric > On Nov 13, 2018, at 12:55 PM, Rawlin Peters <[email protected]> wrote: > > replies inline > > On Mon, Nov 12, 2018 at 4:59 PM Eric Friedrich -X (efriedri - TRITON > UK BIDCO LIMITED c/o Alter Domus (UK) Limited -OBO at Cisco) > <[email protected]> wrote: >> Is pyyaml part of the batteries-included packages? >> If not, we’ll need a way to distribute pyyaml.whl as part of the traffic ops >> RPM. (For those of us without permitted Internet access in our deployments, >> installing via pip means standing up our own private PyPi repo) at each of >> our customers- something I would really like to avoid. >> >> I don't believe it is part of the standard library, but I do believe >> we can figure out a way to keep it all self-contained to the traffic >> ops RPM without requiring internet access at install time. I think >> https://github.com/pyinstaller/pyinstaller is more than capable of >> doing that on Linux/Mac/Windows. I just tried it out on my Python >> version of db/admin.pl on my mac, and it created a self-contained >> binary of 4.7MB size that seems to work just fine. It does still >> depend on the external commands like `psql` et al. from the postgres >> package, but that's no different from the current Perl version. Do you >> think that would be sufficient? >> >> I think pyinstaller also solves the python2 vs python3 availability >> problem, since the interpreter is packaged into the resulting binary >> itself. >> EF> I think that would be OK. The licensing on that one is GPLv2 which is >> category X to include in source (we can distribute the boot loader though). >> Do you know of any alternatives with more compatible licensing? > > It wouldn't need to be included in the source; it would just be used > at build time. But there is also this information on its website > (http://www.pyinstaller.org/license.html): > >> PyInstaller is distributed under the GPL license (see the file COPYING.txt >> in the source code), with a special exception which allows to use >> PyInstaller to build and distribute non-free programs (including commercial >> ones). In other words, you have no restrictions in using PyInstaller as-is, >> but any kind of modifications to it will have to comply with the GPL >> license. See also our FAQ. > > According to https://www.apache.org/legal/resolved.html#prohibited we > are ok to use a GPL'ed tool during the build but cannot include the > GPL'ed source code in our distribution. > > There is also the question of actually including/distributing the > python interpreter+standard library in our rpm (as part of the > standalone binary produced by pyinstaller), but I believe that should > be fine according to > https://wiki.python.org/moin/PythonSoftwareFoundationLicenseFaq#Can_I_bundle_Python_with_my_non-open-source_application.3F. > Here is is the relevant quote: > >> Can I bundle Python with my non-open-source application? >> Yes. Unlike some open source licenses, the PSF License allows Python to be >> included in non-open applications, either in unmodified or modified form. > > That said, I'm starting to lean more towards Golang for replacing > db/admin.pl, because we already use it heavily and it checks off a lot > of the boxes. It might seem a bit like overkill for scripting stuff, > but there is definitely growing usage of Go as a script-like > executable (see > and > https://github.com/erning/gorun) for things you'd normally just write > in Bash or some other scripting language. There's just a lot more > involved in using Python for this (pyinstaller, pipenv, 2 vs 3, etc) > than Go. > > - Rawlin
