Thank you very much for bringing this to our attention. I was not aware that the work of Dershowitz and Rheingold was released under such a restrictive license.
Calendrical Calculations has definitely been used as authorative reference, but not as a 1:1 source reference: To be more exact, I used the paper of the same name that can be found here: http://www.cs.tau.ac.il/~nachum/papers/cc-paper.pdf as authorative reference; the book supposedly contains a lot more information about a lot more calendars. - The 'Rata Die' format indeed has at least for different meanings (i.e. offset in days from four different epochs), and was used by others even before Calendrical Calculations. Interestingly, in the paper the term 'absolute day number' is used (and 'Rata Die' is nowhere to be found). - The conversion to/from the 'Gregorian day number' type of Rata Die for Calendar.ISO is not based on the algorithms of Calendrical Calculations, but on the algorithms used by the Erlang `:calendar` module (initially, these methods were called directly, but now they have been adapted to Elixir code to permit working with negative datetimes in the near future). Where `:calendar` got its inspiration I cannot say; part of the functionality is similar to the Lisp-code that Dershowitz and Rheingold propose in the Calendrical Calculations paper, but much of it is entirely different as well. - Working with day fractions in the way we do is novel; I do not know of any other place where in-day times are represented in such a precise format. - Converting between time formats is novel as well. - Most of the Calendrical Calculations paper (and as far as I know the book) goes on about converting other calendars to the Rata Die format at hand, and how the dates of certain holidays can be predicted, neither of which we do in Elixir's standard library. So I am happy to say that our implementation is very distant from the Lisp-implementation shown in the Calendrical Calculations paper. :-) ~Qqwy/Wiebe-Marten On Friday, July 14, 2017 at 1:17:50 AM UTC+2, Paul Schoenfelder wrote: > > Hey all, > > So I'm concerned about something I've noticed recently. I've seen multiple > mentions of this book (Calendrical Calculations by Reingold and Dershowitz) > and use of it's algorithms in Elixir's Calendar implementation, and I know > I mentioned it back when I first suggested the idea of using something like > the "rata die" concept to support multiple calendars. The problem is that > the code and algorithms in the book are restrictively licensed. I wrote to > Professor Reingold early last year (May-ish) about using the ideas from the > book in Timex to implement support for multiple calendars as well as > implement some of the alternate calendars, particularly the lunar ones. I > heard back from Professor Dershowitz fairly quickly, and the gist was that > I was free to use it for anything non-commercial, as long as it was > appropriately attributed and restricted to non-commercial use. Because of > this, I chose to avoid using it's contents as an implementation reference > in Timex because it is used in commercial software. Below is the reply I > received from him: > > Dear Paul, >> > > > >> Thank you for your generous thanks. >> Feel free to use our programs for your free (noncommercial) use, >> provided proper attribution is given to Calendrical Calculations. >> Please send us a link when you do publish anything. >> But if you distribute it, it must preserve the attribution and >> restriction to non-commercial usage. >> > > > Best, >> Nachum >> > > Recently in some PRs I happened to read through, I saw mention that the > contributor was implementing the code using the algorithms from Calendrical > Calculations. I think that could represent a real issue - Elixir is used in > commercial software, and it seems to me like this could open up the > language (or worse, the authors) to some kind of legal trouble. > > I haven't been reading calendar-related PRs in depth for some time now > because I've been pretty busy, so I don't know how much we've leaned on the > book in Elixir. The use of the "rata die" concept is probably less > troublesome since it's implementation is very different depending on what > date you choose for the conversion, but if we've followed the algorithm > from the book 1:1, then I think we'll have to change it. > > I apologize for not bringing this up sooner, it didn't occur to me until > today the ramifications - up until now I had just assumed we were using it > as an authoritative reference on how to build calendar code, rather than > using it as a source reference. > > If I'm mistaken about how we've been using it, awesome! I just want to > make sure we're in the clear :) > > Paul > > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/e2942790-cdd0-41ef-81c6-a412e9069784%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
