The clash of IoT IP policies: Intel vs Qualcomm

An added advantage to the patent pledge is that the party implementing the spec doesn't need to negotiate a licence, explained Updegrove. Rather than granting a licence, a company subject to such a policy simply commits not to sue the vendor. This is even better than a RAND, he added.

In the following pages, we have put together five things you need to know about IP policy differences between AllSeen and OIC, along with explanations for specific differences represented by those legal terms.

1. OIC consists of two separate legal entities

OIC comes with two legal entities, one responsible for developing specifications/certification programmes, and another, called IoTivity, specifically designed to be an open source project.

According to spokesperson David McCall, OIC is "unique in explicitly doing both, standard and open source, from the start and in parallel."

McCall defended the OIC structure by describing the combination of these two projects as "necessary to deliver an IoT communications framework across multiple vertical markets." He claimed that the diversity of industries covered by IoT has prompted the OIC to adopt this parallel structure. Some industries such as industrial, automotive and medical, for example, need a specification due to regulatory requirements, while other industries don't want to use open source code at all, McCall said.

He acknowledged that the OIC spec does not deliver code. "That's the role of the IoTivity, and it's essential in making IoT communications easy for developers and enabling a fast time to market."

2. AllSeen does everything in one entity

AllSeen is set up to do everything from handling contributions of project source code, to establishing certain requirements and/or tests developed, officially adopted and published by the Board of the AllSeen Alliance, and releasing AllSeen Alliance Code.

Some AllSeen members think that building a wall between software developers working on open source code and those who develop specs/certification is a bad idea. They say it's critical to give developers access to both code and spec. "We need to avoid endless permutations of spec implementations, sort of unfortunate things that happened with ZigBee."

3. OIC uses RAND-Z and Apache 2.0

OIC and the associated IoTivity open source project depend on separate patent policies, according to the OIC spokesperson.

He made it clear that neither of them are "non-assertion pledges," which OIC group believes "are untested for open source." Instead, McCall said they both grant royalty free licences but with slightly different availability.

IoTivity code is covered by Apache v2.0, one of the most popular Open Source Initiative approved licences. Contributors grant a licence for the claims of any patents they hold (the "necessary claims") that are required to implement code they submit. The license applies to anyone who uses the code (and follows the terms of the licence).

In the view of OIC advocates, "This is basically the best patent coverage available in any OSI approved open source licence. Anyone, whether an OIC member or not, can download, use, modify or contribute back IoTivity and will get the full benefit of the Apache 2.0 patent provisions."

Meanwhile, OIC is covered by RAND-Z patent licensing: Reasonable & Non-Discriminatory Zero royalty. This means that OIC members are granted a royalty-free licence to any necessary claims. They are required to implement OIC Specifications for the "compliant portion" of their product (i.e. the OIC bit), regardless of whether the member was involved in developing the relevant portion of the spec.

?? 1???2???3???4??