Smart Cars and Dumb Plagiarism
What happens when one smart car company plagiarizes its competitor...
Yesterday, automotive API startup Smartcar posted a blog entry calling out its competitor, Otonomo, for allegedly plagiarism of its API documentation.
The news was widely picked up by the tech press, including TechCrunch, which highlighted Smartcar’s provided examples and the fact that Smartcar has sent a cease-and-desist letter to Otonomo over the alleged copying.
The evidence is, in a word, damming. The highlighted examples make it nearly impossible for Otonomo to have generated its API documentation any way other than by copying Smartcar’s pre-existing work.
More importantly, this is setting the stage for a potential legal battle between two well-funded startups that are aggressively trying to enter the rapidly-expanding space of smart vehicles.
Even more important, it’s a battle that could set the tone for other smart devices and future software development as this is likely a pattern that we will see again in the future.
Understanding APIs and Automobiles
To understand what is going on with this case, we first have to delve into APIs and, more specifically, API documentation.
API stands for Application Programming Interface is basically a set of instructions that tell one application or device how to interface with another. It can happen internally with a computer, for example a program uses an API to communicate with your operating system, between physical devices or over the Web, such as using Facebook’s API to post things directly from your site.
The API itself is the instructions that the can be interpreted. Basically, it says “If your program sends X, our application will return Y.” For example, if an application using an API sends a request for “Time” the application it is contacting would likely return the current time.
However, APIs can be incredibly complicated and developers, when building an application around an API, need good documentation to be able to know exactly how their app will function.
This is where both Smartcar and Otonomo step in. Right now, there are countless “smart” cars on the road, new vehicles that allow users to connect to them via the Web. However, all of those APIs are different so someone wanting to make an app that works with all cars is in a bind.
What both Smartcar and Otonomo are creating is a unified API that works with as many makes and models as possible. They serve as a middle man between the car manufacturer’s APIs and their customers.
The benefits of this could be widespread. For example, Smartcar says that you can use their API to build your own car sharing service that unlocks cars for customers automatically. Likewise, they suggest building an on-demand car wash service that can likewise unlock cars but also track to ensure they aren’t misused.
There’s little doubt that there is a market for this as the number of smart cars on the road continues to grow. In response to this Otonomo has received more than $50 million in funding and Smartcar has received at least $12 million.
However, amidst this flurry of funding aggressive coding comes a new plagiarism scandal, one where the evidence seems to largely speak for itself.
Examining the Plagiarism Allegations
The actual plagiarism allegations deal mostly with the API documentation provided by both Smartcar and Otonomo.
Smartcar backed up its allegations with a series of screenshots that highlighted the similarities between the two many of them focused less on copied text and more on the examples given.
For example:
If you look closely at the highlighted example, you see that, while the first two characters are different, they both use “a1b01e5-0497-417c-a30e-6df6ba33ba46” as the rest of the strong.
The odds of this happening by coincidence is infinitesimal. While there may not be much matching text between the two, the similarities in the code are a giveaway that either Otonomo copied Smartcar or the two had some kind of common sourcing.
However, the similarities get much more egregious as you look farther down in the comparisons.
Here we’re looking at several parameters, 7 in total, where both the parameter and the description are identical. Once again, the odds of this happening by coincidence are effectively nil so, as with the previous example, it’s either a case Otonomo copying Smartcar or some kind of common ancestry to the work.
There are other examples in the original blog post that either highlight common strings between the two or other matching text. However, even just looking at these two sets of images, it’s pretty clear that the work is not original.
To that end, Otonomo responded, in a reply to TechCrunch, and said, “We take Smartcar’s questions seriously and are conducting an investigation, but we remain confident that our rigorous standards of integrity remain uncompromized. If our investigation reveals any issues, we will immediately take the necessary steps to address them.”
As of right now, Otonomo has pulled down its API documentation site.
Still, the story leaves a lot of questions for the future, not just for Smartcar and Otonomo, but APIs and development in general.
Questions Moving Forward
Copying, when it comes to tech, is nothing new. Instagram copying Snapchat Stories caused a kerfuffle in 2017 but that only involved ideas and features, not actual code or verbiage.
Instead, this kind of verbatim copying is much more rare. The big story we’ve heard along these lines has been the Oracle v. Google case, which has focused on Google’s use of APIs from Oracle-owned Java to ensure that Java apps developed elsewhere would work on Google’s Android operating system.
The case has resulted a pair of District court decisions (including one trial) that have both been largely overturned by the Court of Appeals for the Federal Circuit. Google is petitioning, for the second time, for the Supreme Court to take the case. Otherwise, the case will had back to the lower court for damages to be determined.
However, the Oracle case dealt with interoperability. Google wanted to ensure that that apps developed for Oracle’s Java would work on Android without alteration so they copied the APIs and applied them to their own implementation. This Otonomo case deals not just with the copying of APIs, but also of the documentation.
Furthermore, Otonomo is also a direct competitor to Smartcar, in a way that Google and Oracle are not in this space. Also, Google and Oracle are both well-established companies with multiple product lines, for Smartcar and Otonomo, this is the only business they have at this time.
Whether this will come to legal blows remains to be seen. However, it’s likely going to be a defining story for both companies. Because, while it may be seen as shady for Google to copy Oracle’s API to avoid licensing Java, it’s a whole other matter to be accused of plagiarizing the very core of your business.
Even if a lawsuit is never filed, there will likely be fallout from this and other developers will be watching that fallout closely. After all, this issue of protecting APIs and API documentation is still fairly new and many of the boundaries are still being set.
Thanks to this case, Oracle v. Google won’t be the only test of those boundaries.
Bottom Line
To be clear, these are very complicated issues from a tech standpoint. Explaining what an API is, let alone why copying it may or may not be copyright infringement, is difficult (and I’m pretty sure I did a poor job of it).
But we have reached a point where tech is not only advancing faster than the law, but advancing faster than the understanding of those that write or interpret the law. To make matters worse, its far outpacing society’s ability to create social norms around citation and reuse.
Cases like this are important, even if they don’t make it a courtroom. They teach us a great deal about what uses are and are not acceptable and those social norms often find their way into legal decisions.
After all, courts often look to common practices when trying to rule in an unfamiliar area. Regardless of what happens, next, this case is likely to be a very important one to follow.
Want to Reuse or Republish this Content?
If you want to feature this article in your site, classroom or elsewhere, just let us know! We usually grant permission within 24 hours.