On 2018-04-03 13:39, John Layt wrote:
On 3 April 2018 at 19:50, Brian Inglis <Brian.Inglis@systematicsw.ab.ca> wrote:
I doubt any issues with ports, as long as you don't publish the original Lisp, which is pretty straightforward code (except for the need to express formulae as Lisp expressions), or the output from the Lisp. Many of the formulae are obvious, published in their own earlier or others' works, or other public calendar software e.g. tzcode. Uses of non-creative non-original common public factual data and mathematical formulae (essential to all uses of calendars), including information from reverse engineering, appear to be unrestricted, from what I gather (IANAL).
Why do you have a concern regarding taint?
Mainly because I've contributed code to a dual-licensed GPL/commercial library that cannot accept code with non-commercial restrictions, but also due to past statements they've made and their own commercial licensing of the code and algorithms. I have no wish to become a test case in the remote and expensive American legal system :-)
I find it hard to believe their exteremely slow CL code has much commercial value. Algorithms seem to be consistently treated as mathematical formulae, and I doubt any countries (even the Vatican!) have claims on basic calendar facts, as that makes calendars unusable.
I fully agree that legally speaking their work probably is effectively public domain and free for use (or at least should be, your legal system may vary). As much as I disagree with their approach, I respect their wish to not share their work, it just means I've had to rely on more primary sources and my own deductions.
Very much not public domain, as R&D claim a copyright on their book, code, and its output, and provide a licence for some other NC reuses, reserving copying or sharing their expression. As researchers, they may prefer their work be shared widely, but CUP do imply the book is useless, except as a book to read. This group discussed a lot of these issues around the lawsuit, and around the possible use of the canonical IERS leap-seconds.list rather than the currently distributed NIST file. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada