Is the GPL the right way to force IoT standardization?
Is the GPL the right way to force IoT standardization?
The Internet of Things has tremendous potential, but remains a mishmash of conflicting “standards” that don’t talk to each other. As various vendors erect data silos in the sky, what is actually needed is increased developer communication between disparate IoT projects.
I’ve argued before that this is one reason IoT needs to be open sourced, providing neutral territory for developers to focus on code, not business models. But there’s still an open question as to what kind of open source best facilitates developer-to-developer sharing. In Cessanta CTO and co-founder Sergey Lyubka’s view, the restrictive GNU General Public License (GPLv2) is the right way to license IoT, at least for now.
He might be right.
Giving developers something to work with
By Evans Data estimates, there are now 6.2 million developers worldwide focused on IoT applications and systems, up from 4.1 million developers last year, a 34% increase. Importantly, this swelling developer population isn’t primarily interested in cashing in on IoT. As VisionMobile’s extensive survey data uncovers, these developers are mostly looking for fun and a challenge as they explore IoT boundaries.
Not surprisingly, then, open source has become the lingua franca of IoT projects, with 91% of IoT developers acknowledging the use of open source software in at least one area of their projects, according to a separate VisionMobile survey. The reason, the report concludes, is that “open source technology is very strong in solving the nitty-gritty, niche challenges that developers have; areas that commercial vendors would struggle to address.”
The question, then, isn’t whether open source should be part of IoT. It is, and will continue to be such. No, the question is what kind of open source license is best-suited to reaching this growing population of IoT developers.
Permissive or insistent?
According to Lyubka, a more restrictive, free software license like the GPLv2 is the best approach for IoT licensing, at least as it pertains to firmware. In his view, the GPL ensures that “firmware [will be] easily available and affordable for prototyping and DIYing.”
He also feels it’s the best license because it affords the developer the option to dual-license her code, offering a proprietary (“commercial”) license of the same code so that the originating developer gets paid while the downstream developer can use the code without concern of having to open source her own proprietary code.
He explains this in more detail:
We need more developers to easily access the internet of things and code for connected devices. We need to share ideas amongst engineers and product developers to better understand what works and what doesn’t.
There is no reason why startups, DIYers and even established companies should have to pay for firmware as they experiment and prototype exciting new products that will help fulfill the market mandate.
At the same time, businesses who develop IoT solutions need to be able to compensate their developers to keep making those IoT solutions stronger, simpler and more scalable for everyone.
That’s why the GPLv2 option, in my opinion, works again for IoT firmware. Once someone commercially applies your code and doesn’t want to open their own solution, they pay.
Though I’ve spent years arguing that such restrictive licensing inhibits developer adoption and offers a poor way to monetize code, Lyubka may have a point in this early IoT market. It’s true that developers increasingly turn to permissive, Apache-style licensing (or completely eschew licensing), but there’s something to be said for a copyleft approach, forcing developers to stick together in the early days of a project, IoT or otherwise.
Would copyleft help us standardize IoT?
Given the tremendous importance of standardizing IoT protocols and firmware, allowing disparate systems to talk to each other and even share code, it makes sense to keep developers from pulling code and embedding it in a proprietary product, thereby creating more IoT silos.
The early days of Linux, for example, were arguably aided by GPL licensing that kept all the developers rowing in the same direction, differentiating themselves at the packaging layer rather than in foundational code differences between distributions.
In the long run, permissive licensing like MIT or Apache strikes me as the absolute best approach, given their propensity to lower barriers to developer adoption. But there just might be reason to force IoT firmware to cohere, at least in the early days.
I’d love to hear your thoughts, one way or another.
The post Is the GPL the right way to force IoT standardization? appeared first on ReadWrite.
(22)
