I would generally consider it a bug to not have any form of license in the repo, but from the top of the Readme (last modified 10 days ago):
"Contact Kevin (e.g., licensing, feature/documentation requests): k.concerns@gmail.com"
So if you're interested, I suggest you send Kevin an email.
Personally I think it would've been interesting if it was Free Software -- as this doesn't come with any license, it's essentially less useful than the 32bit kdb[1] -- and I can't imagine it's as feature complete, or has a similar level of documentation, support or real-world testing.
If the intention is to make the binaries deployable/usable, a license file/note in the Readme would be the absolute minimum requirement IMNHO.
Also find it strange to host just binary artefacts on github -- I can't see how that's useful for the author or the users. I suppose one could submit pull-requests against the python api, but then it would make more sense to split the repo in two -- one for the source-available (unknown license) python code -- and host the binary artefacts somewhere.
"Contact Kevin (e.g., licensing, feature/documentation requests): k.concerns@gmail.com"
So if you're interested, I suggest you send Kevin an email.
Personally I think it would've been interesting if it was Free Software -- as this doesn't come with any license, it's essentially less useful than the 32bit kdb[1] -- and I can't imagine it's as feature complete, or has a similar level of documentation, support or real-world testing.
If the intention is to make the binaries deployable/usable, a license file/note in the Readme would be the absolute minimum requirement IMNHO.
Also find it strange to host just binary artefacts on github -- I can't see how that's useful for the author or the users. I suppose one could submit pull-requests against the python api, but then it would make more sense to split the repo in two -- one for the source-available (unknown license) python code -- and host the binary artefacts somewhere.
[1] http://kx.com/software-download.php