I don't work with Rust, but in general this is a very nice way to present a project's needs, in order to request contributors to help. I hope it works for them.
I also like the pragmatic approach, instead of saying "date APIs are hard, so we'll think until we've cracked it" they just explicitly plan on copying a popular one (the Joda-Time Java API, http://www.joda.org/joda-time/).
It's not illegal, it's just apparently impacted by copyright. Since Joda-Time is available under the Apache 2.0 license, that doesn't seem like an unsurmountable obstacle.
I'm not a legal scholar but it seems like Joda-Time's Apache 2.0 license can be rendered irrelevant if Joda copies API spellings from Oracle Java.
For example, Joda has a member function called .getYear(). Oracle java.util.date also has a .getYear(). At the time the author created Joda, the type of restrictive API copyright ruling that Oracle won wasn't part any programmer's mindset. If it was, maybe Joda would have called it .getAnnum() or .getOffsetfromZeroCE() or .getYYYYComponent().
If a company gets to release their API first with a .ToString() ... the next company has to call it something else such as .ReifyAsString() and then then next company after that has to name their API with yet another synonym such as .Stringify().
Continuing that scenario, could one even publish a blog post listing the complete 1-to-1 translation of Company A's API to Company B's API? Could one legally write a program that automatically converts one source code listing's API calls to another? Would those rosetta stone type of publications and dev tools be in violation of API copyrights?
Joda-Time doesn't copy 100% java.util.date but I don't know what the threshold is.
Also not a lawyer, but IIRC Oracle won on the grounds that the "structure, sequence and organization" of their API was a creative and copyrightable work, not just the odd descriptive name here and there.
One of the circuit court's stated reasons for ruling that the SSO holds for the Java API was because of the names:
The evidence showed that Oracle had "unlimited options as to the selection
and arrangement of the 7000 lines Google copied." Appellant Br. 50. Using
the district court's "java.lang.Math.max" example, Oracle explains that the
developers could have called it any number of things, including
"Math.maximum" or "Arith.larger." This was not a situation where Oracle was
selecting among preordained names and phrases to create its packages. As
the district court recognized, moreover, "the Android method and class names
could have been different from the names of their counterparts in Java and
still have worked." Copyrightability Decision, 872 F. Supp. 2d at 976.
Because "alternative experessions [we]re available," there is no merger.
See Atari, 975 F.2d at 840.
This is a broader point than "it was because of their names." As I understand it, the court is saying that Google copied the whole package structure of Java, including a whole tree of associated names. It's not just that some names happened to match up, but that the whole structure of the Java libraries was considered a creative work and Google copied that whole creative work. The names are a component of that, but you can't point at a name and say "That was the copyrighted thing," because it was the aggregate API that the court considered copyrightable.
(Again, not a lawyer or legal advice. This is just my layman's understanding.)
Yeah, I think you're right. It's the wholesale copying of a large chunk of the Java API rather than just the name of one thing.
Tangentially, I really disagree with the ruling. First, we have to figure out where to draw the line: if you can copyright a big API, can you copyright a small one (like, say, Iterable)? Second, there's legal precedent for allowing partial copies in cases where it's necessary for interoperability (Sega v. Accolade). Finally, the appeal for Lotus v. Borland allowed for wholesale copy of a command hierarchy for user interfaces, which has parallels to application programming interfaces that I think any programmer would find obvious. My favorite quote from that case:
[51] That the Lotus menu command hierarchy is a "method of operation" becomes
clearer when one considers program compatibility. Under Lotus's theory, if a
user uses several different programs, he or she must learn how to perform the
same operation in a different way for each program used. For example, if the
user wanted the computer to print material, then the user would have to learn
not just one method of operating the computer such that it prints, but many
different methods. We find this absurd. The fact that there may be many
different ways to operate a computer program, or even many different ways to
operate a computer program using a set of hierarchically arranged command
terms, does not make the actual method of operation chosen copyrightable; it
still functions as a method for operating the computer and as such is
uncopyrightable.
Anyway, I know you didn't ask for my opinion on the ruling but I just wanted to rant a little :) The circuit's ruling really pissed me off. Programming is hard enough without having to worry about whether or not our APIs are covered by an existing copyright.
>Joda-Time doesn't copy 100% java.util.date but I don't know what the threshold is.
I think they're safe, especially given that the process has actually come full circle now.
The new date time package in Java 8 (java.time) was developed under JSR310, whose spec lead is none other than the developer of Joda-Time, Stephen Colebourne [1]
For those that are interested, he wrote an interesting blog post way back in 2009 on why they chose to develop JSR-310 instead of using Joda as is [2], as well a more recent piece on the bits that didn't make the cut (and are thus now part of a separate project) [3].
To add on to what chc said: We should all remember, as technical people, that these laws are meant to be interpreted by humans, not machines. Even databases of information aren't copyrightable, much less the function names that a programer uses.
You clearly missed that fact that no judge, anywhere, would hold up names as why something was copyrightable. Instead, as my sibling comments say, what was found copyrightable was the "structure, sequence and organization" of their API. The court said that Google copied the whole package structure of Java, including a whole tree of names.
A Rust port of JodaTime should definitely be based on Jon Skeet's NodaTime (the .NET port) which probably maps easier to rust because of the closer similarity of C# to Rust (value types etc).
I also like the pragmatic approach, instead of saying "date APIs are hard, so we'll think until we've cracked it" they just explicitly plan on copying a popular one (the Joda-Time Java API, http://www.joda.org/joda-time/).