Hacker News new | ask | show | jobs
by gepoch 2619 days ago
I haven't seen this mentioned anywhere so I thought I'd post it to see what you all think... IANAL, IMHO, etc.

I searched for one of the unique tokens in the docs: https://www.google.com/search?q=0facda3319

That pulls up their SDK github repo: https://github.com/smartcar/node-sdk/blob/master/doc/readme....

Which is published with a standard MIT license: https://github.com/smartcar/node-sdk/blob/master/LICENSE.md

Which says (among other things): "Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software."

Which may have significantly complicated their copyright claim if Otonomo includes the MIT license and attribution to smartcar.. At the same time, I can't find Otonomo's docs anywhere.

Something to think about when setting up your GitHub license!

5 comments

In Github terms of service, if you make a repo public, others are free to view and fork it, apparently even if you place a commercial license on it, or no license. The lawyers will have to figure out if that means copy, use or whatever.

https://help.github.com/en/articles/licensing-a-repository

I believe this is a big problem with git or any of the current repo gui providers. A repository should not be able to be forked if it doesn't have a SPDIX license. Or at the very least users should be able to turn off forking ability in the repo settings.

It's usually not an issue but I have run into some small repositories that had no license, meaning I could -not- fork and modify for myself or a PR, legally. But this is not obvious at all unless you look for the license file or a manifest file.

Neither git nor github can automatically discern how the law applies in context in 195 nations without consulting a lawyer and honestly neither can you.

Unless you want to pay thousands of dollars per repo presumably everyone is going to continue not giving a damn.

If you don't want people to clone a repo don't upload it to a public github repo. If you are thinking of cloning realize that the ability to clone it gives you zero legal rights.

Anyway you cannot fix legal complexities with technology in this instance.

This could be a problem for ricardian contracts and/or smart contracts
Those don't solve anything, because the core problem is a human one. It needs to be legal in all the countries that they might apply to, and that still requires a lot of expertise. The person you are responding to says "this is a problem technology can't fix", I assume this is the reason.
> Or at the very least users should be able to turn off forking ability in the repo settings.

This is absurd. You don't have to use the "fork" button to copy a repository. It's as simple as cloning it and pushing it. Such a restriction servers no purpose at all.

There _is_ a difference between forking and cloning. Forking is always allowed by the github license:

> other GitHub users have the right to view and fork your repository _within the GitHub site_

^^ That's from the github website. Note that they only have permission to fork from within the website.

So such a restriction serves as a legal barrier - it leaves no legal way to copy the code.

GitHub doesn't have the ability to choose what is legal. Or a better way to put it, the law does not follow GitHub's Terms of Use. You can violate them all day long and have no legal repercussions. The most important thing about people putting software in open report is that demonstrates their intention to make their software available to the public, which makes a big difference in a court of law.
The github license is irrelevant here because they don't own the code. So there's no point in even mentioning that.
Obviously such an implementation would disable cloning as well.
Then make a private repo. Hosting a public repo that a company would have to pay a mechanical turk to scrape every single file from manually by viewing the RAW data is just obtuse.

If you want it open source, understand what that means before complaining about it. Otherwise don't release your software on an open source platform.

Why bother putting it on GitHub then? I expect to be able to git clone anything I find on GitHub. It's on you to determine how you can legally use the code.
GitHub would obviously also have to make the repo private as well, and then get into the business of interpreting and potentially defending the compatibility of their service against various licenses before making it public. That's unsustainable.
The onus is on the end user to make it private.
Just thinking aloud, but GitHub could warn, when setting up new projects that don't have an OSS license, that the user may wish to make the repo private.
Uh, if you don't wan't to fork, don't make it public in the first place? Code escrow is another thing, but that does not mean everyone needs access...
The two aren't necessarily mutually exclusive, although yes I would agree with you. -In the case- of a repository being public without a license however, forking and related things should still be disabled to prevent licensing headaches.
This shows a fundamental misunderstanding of how git works.

The main point of putting something on GitHub is to allow people to git clone it. Every git clone is a fork of the project.

If you don't want something forked, don't put it on GitHub.

I understand how git works. I'm discussing the edge case scenario where someone uploads something but doesn't add a license. In that case, forking and cloning should be disabled, at the least.
Laws are different in different countries, e.g. it is not against the law to consume pirated content in Switzerland, but is illegal to share it further. So, if I have a pet project for my personal use then I can pretty much use anything I can find on the internet.
By hosting on github aren't you sharing it further?
GitHub require you license public repos to allow others to fork it. Whether they can use it for a specific purpose is still questionable - but clicking the fork button on github is allowed. They agreed when they uploaded the code.

Note that this is governed by GitHub’s TOS and supersedes anything in the License file.

> If you set your pages and repositories to be viewed publicly, you grant each User of GitHub a nonexclusive, worldwide license to use, display, and perform Your Content through the GitHub Service and to reproduce Your Content solely on GitHub as permitted through GitHub's functionality (for example, through forking)

So I can "perform" and "reproduce" content through forking, solely on Github. But I couldn't clone it, nor make modifications to my fork, if I read that correctly.

It makes little sense and could be avoided altogether by disabling forking for un-licensed repositories. Or by simply giving all new projects a default (with an opt-out option for no license or alternate licenses).

It makes more sense if you understand the license is about protecting GitHub and not you.

A disabled fork button unless the repo did a positive action would dilute the whole concept. The fork feature is key to the whole thing and is what made them different.

The MIT license appears to be on their client-side SDK. They are accusing Otonomo of cloning their API, not their SDK.
I was going to say the same, but it looks like the documentation mentioned is for the client indeed. If the client is MIT licensed, are you infringing on anything by writing a compatible API?
That question is the essence of the ongoing Oracle v. Google case:

https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google....

The difference is that even though the Java API was licensed under the GPL, Google did not accept the GPL license. They implemented the API without a license. Were they willing to implement their code under the GPL there would have been nothing that Oracle could have done.

I'm with others who say that an API should not be copyright-able, however it appears that in this case it doesn't matter. They may have a license! I haven't looked into it at all, but if it's true that Smartcar have implemented this API and distributed it under an MIT license, I think it will be really hard slogging to say, "We only meant to license some of the IP. We just gave a license and decided we'd wait until after the fact to tell people what it covered".

I am a huge advocate of free software, but it really bothers me when people license something without having any clue what it actually means. I can't tell you the number of projects I've encountered who say things like, "I put it under the GPL, but you can't sell it", or "I put it under an open source license, but you can't use any of the code; just look at it", or "I put this game under a free software license, but you can't use any of the story for the game because software licenses only cover code", or "I put my code in the public domain, but that doesn't mean you can make a few changes and claim that it's yours", etc, etc. If you want a "I'll tell you if it's ok after you've done it" license, don't grant a general license! Reserve all your rights and handle licencing on a case by case basis.

It wasn't Google who did it, but Apache: https://en.wikipedia.org/wiki/Apache_Harmony
Google had the choice to deal with Sun, but they though given Sun's account state they would get away with it, to the point that buying Sun to own Java wasn't even considered.
The APIs discussed in that case are only "classical" APIs, i.e. code APIs, not "web APIs", which are really protocols. Despite the fact that recently people have started calling protocols APIs, the two have huge differences from a copyright perspective[1], so that extrapolating from the former to the latter is tenuous, regardless of the ultimate outcome of that case.

Moreover, the court ruling makes it seem that if the intent is interoperability, fair use may apply (only the court rules Google's intent was not interoperability, as their implementation was intentionally incompatible).

Although in this particular case, it appears they can claim copyright violation on the documentation.

[1]: Most notably, in order to be copyrightable, a work has to be "fixed in a tangible medium of expression" (https://www.law.cornell.edu/uscode/text/17/102), i.e. you need to have a specific text (or image) that you can say, this is the work (although then even derivatives are protected). This is true for APIs, but not for protocols (or REST "APIs"). Whether this distinction makes sense to programmers or not is irrelevant. The same distinction holds for programs vs. algorithms: programs are "fixed in a tangible medium", and are subject to copyright, but algorithms are not, and not subject to copyright (but can be protected by patents).

The docs are also MIT licensed, aren't they?
I don't know, but the MIT license is given under conditions that can be violated.
I thought most people (including myself) on HN were in favor of Google in that case, that APIs shouldn't be copyrightable.

What exactly is Smartcar's product? Is it just the API design?

If so, I personally think this is in the same boat as that case, and I don't really see having the same API as copying either.

Not everyone, I am in favour of Java developers not having to write two versions of libraries thanks to Google's J++.
I agree that copyrighting and endpoint just because the request and response have the same structure is insane.

The docs would be something different thou, but again, I don't know how the docs were licensed.

Nokia, Cisco and others in the telecomunication industry usually patent network endpoints.
Compatible APIs happen all the time with SaaS. Look at all the S3 clones out there. Look at SignalWire, which cloned Twilio. It is very, very common.
Come on, this piece is written by someone who obviously doesn't know what he his talking about..

The entirety of his examples are focused on the Oauth API, which is a standard, and all the concepts and var names he shows as a steal of API are present in each and all Oauth authentication servers.

I mean, we have in our own api about 90% of the same verbiage for our own authentication doc, this is bog standard Auth code..

The same verbiage, as in large chunks of text are word-for-word identical? Because that’s what’s being alleged here; it doesn’t happen by accident (the chances of two people independently writing identical text are astronomically low for any significant amount of text), and it certainly constitutes copyright infringement unless it turns out that Smartcar put the documentation under an open source license somewhere. If, on the other hand, you just mean that your docs have a similar overall structure, because they’re documenting a similar API, that’s something completely different.
The API the guy is talking about is a freaking RFC!

The wording of this is found everywhere on the internet. Just search for one of the phrases you find and you'll have plenty of matches: https://www.google.com/search?q=%22The+number+of+seconds+the...

I understand the frustration of the guy, but this is not like they copied the business API, this is just the standard Oauth.

Anyways.. I'm starting to sound like an Otonomo PR guys.. I'm not, it's just that reading this article, I found myself pondering whether my current employer could be sued for this kind of trickery. I wrote the Oauth2 code in our product, and found myself writing the exact same doc (probably with different words).

How did Ottonomo end up with identical random identifiers? Are those from the RFC as well?
Even the design is the exact same, though. Did you accidentally rip off Oath's design as well?
What a plot twist. How embarrassing for Smartcar to have written this whole blog post and tried to sue them.
Meh not really.

The API client is MIT licensed but that doesn't mean the API itself is MIT licensed. Smartcar obviously would not release their server code as it is proprietary so the question becomes whether it is unethical or illegal to copy the design of it without seeing the code. Most people would also say it is unethical to copy your competitor's docs down to the examples and randomly generated tokens.

Note that the docs in the blog post are not the same as the markdown document in the repo that appears to be MIT licensed.

Since they copied the docs verbatim, I suspect they will change the docs very soon. I'd be quite ashamed if I were Otonomo. Whether they have to pay financial penalties or admit guilt in court, we'll see.

This situation makes me think of the video game industry and people recreating self hosted World of Warcraft servers by reversing the client code.

Blizzard was able to shut down the private servers.

https://github.com/mangoszero/server

https://www.google.com/amp/s/arstechnica.com/gaming/2017/07/...

There are still plenty of active private servers running.
> Most people would also say it is unethical to copy your competitor's docs down to the examples and randomly generated tokens.

<standard not-a-lawyer disclaimer> Would it be okay if they changed the tokens and kept everything else? Who benefits from Otonomo changing the examples?

Assuming a REST API is a non-enforceable contract for the sake of interoperability, it doesn't make sense for any party agreeing to it to "own" the contract itself, even if they were involved in writing it.

Especially when using words like "illegally", probably without consulting a lawyer. May now be open to countersuit for accusing them of illegal behavior.
> "...subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software."

Which they did not do.

Yeah, AGPL-3.0 was invented for a reason.