The Things Network moves to remove TTN import functionality from ChirpStack v4

Just in case this makes a difference in anyone’s upgrade or migration plans:

Personal feelings on the matter omitted.

@bconway We are not making legal threats and this is not “personal” against ChirpStack. Not everything on GitHub can be used without permission. Also, one cannot use someone else’s trademark without permission. Open source software and its licenses is a different game than (open) data.

There is and was no open data license on the concerning repository. We spend a lot of time and resources on the content of that database. In this instance, GitHub is a great channel to receive contributions from the device maker community and to contribute ourselves, verify, review and validate. But a GitHub repository doesn’t provide a license to reuse and extract it in its entirety. Sure, if you want to copy paste a payload codec that you are missing from the Device Repository, that is fine.

If I write and publish a tool to export my data via your public API, would you also see that as a violation of your trademark?

  1. That depends on how you use our trademark (The Things Network, TTN)
  2. not sure which public API you mean, but those are likely covered by our terms of service or EULA
  3. you are talking about your data, but the Device Repository is not your data, and especially not the whole Device Repository.

Up to a couple of hours ago, there was a LICENSE file containing the Apache 2.0 license in the root of the repository, which as far as I understood covered content of the repository. This was removed by this commit a few hours ago.

5 Likes

I just answered Orne private, but for the record and future reference here’s the summary for everyone;

The Apache license for software products. Our intention was to build an API and software. We didn’t do that in the end. In the README, it was also mentioned that the API (that we never made) was Apache 2.0 licensed.

As the Apache license doesn’t cover data, we never assumed a license on contributed content. We respect device maker’s own copyright on their photos, device profiles, codecs etc. Some codecs have their own copyright header, which is fine. For us, to be able to use their data, we require contributors to sign the CLA. That gives us, and not third parties, the rights to use their information.

The Device Repository has grown since its inception, and so our efforts of obtaining, verifying and structuring it. We have quite a few things on our roadmap, and we’ll only be able to continue with this in a publicly visible repository if we protect our database rights.

The LoRa Alliance has a new specification (Automated Device Profile Download), an OpenAPI, to download LoRaWAN device profiles. This specification is currently in IP review. I’m one of the contributors. We will be offering this API publicly too, but that’s different from reusing or extracting the database as a whole.

I know I’m not making friends here, that’s not my intention, but you guys do deserve an explanation because I understand the points raised.

@johanstokking I’m struggling with this part. I can not find why the Apache license would not apply to the data of the repository. While it is commonly used for software code, there is nothing (as far as I understand) in the Apache license that states that it can not be used with non-software code:

“Source” form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files.

(https://www.apache.org/licenses/LICENSE-2.0)

As the LICENSE file was stored in the root of the repository, without any note that certain directories were excluded from this license (at least not that I’m aware of), isn’t it fair to assume that the whole repository was covered by the Apache license?

Could you explain why the data in the repository was excluded from the Apache license?

3 Likes

There was a note though, the README said the Apache license applied to the API: Add Database Protection Right notice (#550) · TheThingsNetwork/lorawan-devices@fd67319 · GitHub.

Because we do not own the data. The Things Industries obtains information from various (public) sources or it gets contributed by device makers. It’s their stuff: their logos, their photos, their brands, their codecs, their profiles. We would not want to impose a license on that, especially not a permissive software product license. Apache isn’t suitable and applicable to (and intended for) the data in the repository, it was for an API that we never made.

childish…shortsighted and telling… glad I migrated long ago

2 Likes

This post was flagged by the community and is temporarily hidden.

I’ve asked people to keep the discussion on-topic, but I am not a moderator. If there is no constructive discussion left to be had here, please close the thread.

It’s a real shame the LoRaWAN community cannot play nice together… ah well, onwards and upwards!

Dutch tech lawyer & blogger Arnoud Engelfriet concludes that within Dutch law (same country TTN is registered in) the APACHE license /would/ apply also to the data.

3 Likes

But, now when ttn and chirpstack uses the same codecs… wouldnt it be nice if all of the lora community came together as one and set up a repo with all codecs for everyone to use?

Especially if we could get all manufacturers to submit their codecs themselves instead of relaying on different parties to make their own all the time… it would allow for quicker and cheaper implementations which would push the userbase forward…

Of course it would have to start from scratch to allow every contributor to acknowledge the use of their codecs…

Just a thought…

3 Likes

He goes from the reasoning that the README’s legal notice limited the Apache license only to the API, to correctly guessing what we intended the API for, to stating that there was no API in the end so the license applies to everything. I don’t follow his conclusions, which don’t matter anyway because we control what happens with our repository. The value is really not in the data right now; the value is our continued effort to keep it updated, fix issues, add profiles, test codecs and keep chasing device makers to contribute. So even if you believe that you can snapshot a version before we removed the obsolete license, it will have lost its value next month.

For those who think that TTN is taking what belongs to the public: I actually spend a substantial amount of my professional time contributing to the LoRaWAN specifications to make sure we all align.

I’m one of the key contributors to the TS013 specification that standardizes the payload codec function API (name, arguments, return structure). This specification standardized precisely the codecs as we use them in The Things Stack and the Device Repository. As TS013 is being adopted by all LoRaWAN application servers (including all TTI’s competitors), device makers can just submit the codec they once wrote for TTN. Isn’t that great?

So instead of saying that ChirpStack adopted the payload codec API that TTN introduced, ChirpStack can now say it supports TS013 (thanks to TTN, but no need to mention that, but you’re welcome).

For this, I’m also contributor to another specification (Automated Device Profile Download), which is an OpenAPI to download profiles (and later codecs) in a standardized way. This is really what our (Apache licensed) API was going to be, until we decided to contribute these efforts to the LoRa Alliance to reach a broader audience, again, including all TTI’s competitors. For the greater good. This API is stuck somewhere in the release pipeline of the LoRa Alliance I’m afraid, but I think it will be published shortly.

Standards are the way forward, not extracting someone else’s database.