Blog

MQTT represents a paradigm shift in industrial process control communication, is the primary communication protocol for IoT, and is anticipated to be the standard communication protocol for networked industrial process control devices – the IIoT.

A strategic opportunity may exist for an early market technology leader with a proven low-cost operations stack consisting of IIoT MQTT endpoints (with optional “intelligence at the edge”) providing data which directly result in the creation of orders or material movements in an ERP system, at a cost acceptable to SMEs. MQTT is still new technology for process control, and significant interest may also come from large enterprise investigative projects as they learn and find new strategies.

End-user MQTT References:

• Processing Magazine “Q&A: The evolution of MQTT for IIoT.” 
  Flow Control Magazine “How MQTT is advancing automation and control.” 
• OMRON NX102 Machine Automation Controller (example PLC with MQTT). 
• ISA Interchange “Why MQTT Is an Ideal Connectivity Protocol for the Industrial Internet of Things.” 
• Siemens Cloud Connect (uses MQTT as cloud protocol to transferring data to MindSphere, the “IoT Operating System from Siemens”). 
• Automation World “Is MQTT Winning the Industrial IoT Race?” 
• ProfiNet Control Newsletter “MQTT, open SCADA publish/subscribe protocol is getting what it needs to go industrial.” 
• MQTT Buddy “5 helpful scenarios where MQTT can be used for Industrial Automation.” 

Video and podcast interviews with Arlen Nipper, co-creator of MQTT.

• Arlen Nipper Ted Talk 2012.
• Arlen Nipper Interview on IoT For All podcast. 
• Arlen Nipper Interview on Human & Machine podcast. 

I like to think of Open Source as a legal framework that supports shared software development by a community. The license protects the investment made by the community (time coding, testing, writing bug reports, writing user manuals, supporting other members of the community, etc.), as well as protecting the community from an actor acting in bad faith.

When a company (a legal entity) develops software, the code generally belongs to the company, regardless of whether the programmer is a full-time employee or a contractor, and the developer is not entitled to a single character. Of course, developers still own the knowledge in their heads, and they can use that knowledge to re-create equivalent functionality (although other contractual restrictions, such as non-competition and non-disclosure agreements, may still apply).

A single developer providing software under an open source license is generally simply being altruistic and helping their fellow developers by providing tutorials, examples and proof-of-concepts consistent with a single developer project. The developer’s personal beliefs will direct the license, either “permissive” (e.g. the BSD license) or “copyleft” (e.g. the GPL).

A permissive license might be appropriate if the goal is to provide benefit to as many people as possible with minimum constraints (a permissive license typically only imposes keeping the original license and copyright notice, and prevents being sued for errors or not being fit for use).

However, if you believe someone who modifies your code has an obligation to share in kind, then imposing this through a copyleft license will likely be appropriate. Note though that the GPL only requires source to be shared with those who receive the software in non-source form, which may not include the original developer! Payment is irrelevant as far as the license is concerned.

The license becomes more significant for projects with multiple developers, projects that incorporate open-source software to expedite development, and companies who use the software. Vague ownership of the code or vague statements of allowed use creates risks for the entire community.

What if two developers work together for a year to create a software application but then part ways. Who owns the rights to the codebase? Do the developers share ownership jointly or individually? Can one developer continue development of the software on their own if the other developer doesn’t want them to? Does each developer have rights only to the characters they typed?

Vague ownership is also a risk for users if the project doesn’t have the legal right to offer the software, which could caused by something as simple as including a GPL library in a BSD project, using code available publically without authorization from the author, or a developer re-using old project code that was written for an employer instead of recreating it from scratch. If the software is an enterprise ERP, CRM or FRACAS system, extracting it from the business could be difficult and costly. Any company that proactively protects shareholders from risky legal situations would have to just walk away before even starting.

Licensing itself isn’t complicated, it’s all the other details…. 😉