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?
- That depends on how you use our trademark (The Things Network, TTN)
- not sure which public API you mean, but those are likely covered by our terms of service or EULA
- 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.
6 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.
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?
4 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
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.
Hi @johanstokking ,
Thank you for your previous comments, which I would like to take up briefly in parts and place my (personal) opinion.
From my experience, TTN/TTI is what it is today because of the openness, the free offer and thus the large mass of users who use it and thus also made it interesting for manufacturers. Without free offers it would never have been (also from my point of view) - at least not in this period of time - so successful, rightly so I think, because what TTI does, also for the community, is a very valuable contribution and also the LoRaWAN Alliance or LoRa(WAN) would not have become what it is today in this short time if there were pioneers like you (through TTN/TTI), but also the Loraserver project - today ChirpStack - the OpenSource idea here is that A wide variety of people are involved in the development, thus accelerating the development and sharing knowledge - I cannot understand why TTI is reacting in this explicit case in this way, although I can understand that through ‘competition’ such as the ChirpStack project 'the commercial part of TTI may be impaired and you want to defend USPs in this way.
As you have already described, the payloads and other data stored there are partly free contributions from the manufacturers, which TTI may have actively asked to maintain their devices there. That you check the data and pay attention to the quality is, in my view, exactly what applies to all data in an active (Git) repository and what is the task of every repository owner and not only applies to this part - but me let me teach you better. The following example shows that this is not always the case and of course cannot be the case (sorry for the missing PR for that). I further assume that the manufacturers are aware that they are now making the data available there under your license conditions? You may have informed them of this change.
Anyway - a central device and payload database / data source as you described - under the LoRaAlliance is certainly the best way to avoid exactly such a discussion in the future, because the manufacturers are certainly interested in having the best possible sales of the devices and thus reaching everyone who enables the integration of their devices and not only users of the TTN or the commercial products of TTI.
Finally, a big thank you to TTI, who make important contributions to the development of LoRaWAN, especially with the TTN network and the experience gained from it, and thus also contribute to the important development of the protocol by participating in the LoRaWAN Alliance. But also a big thank you to @brocaar, who - with the development of the ChirpStack - always stays very close to the current developments around LoRaWAN and offers an alternative for everyone - we live from alternatives and everyone should be able to use what is best for their application fits. We should also all uphold the open source idea, there are enough proprietary solutions that can get us into a situation over time that is difficult to get out of.
PS: Please don’t see yourselves as competitors - everyone can learn from everyone, always. There are enough black sheep in the LoRaWAN environment who don’t share their knowledge and just take it.
Best regards and thanks!
Thanks @AndreasW79 for sharing your view. I certainly agree; having high quality alternatives is great and differentiates LoRaWAN from competing LPWAN technologies. Do note that we did not make this license clarification to make ChirpStack less functional or out of competitive reasons (see my previous messages). In fact, we also do not consider ChirpStack competing, although for end users who are looking for a simple LNS they may consider The Things Stack vs ChirpStack. With my TTI hat on, I’m happy with any LoRaWAN developer community so that people choosing our commercial offering already gained quite some experience before scaling. Bottom line is that LoRaWAN is so attractive because this choice can be made. That said, I think that ChirpStack is a bit isolated from the LoRa Alliance and device maker ecosystem and there’s some room to integrate and partner, although I’m aware of @brocaar 's time constraints.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.