Page 59 - Proceedings of the 2017 ITU Kaleidoscope

Challenges for a data-driven society

Lack of specific rules: : If there is a need for the ITU and granting underlining the patent right? We cannot find any
ETSI to change the software guidelines, the lack of any IPR entitlements for SSOs to do so in the current SSOs
rules governing embedded software in the IEEE poses more framework.
uncertainties. As a matter of fact, SSOs accredited by the Different from OSS implementation: It should be noted
American National Standard Institute (ANSI) may lack a that this sub-scenario is different from the OSS
particular clause for code ownership and distribution in implementation scenario we discussed in 3.1 in two aspects.
specifications, since the ANSI appears to discourage Firstly, as we have previously discussed regarding the
software from being embedded in specifications [24]. In compatibility between the FRAND license and OSLs, here
such absence, one can only refer to the copyright rules over it is more about which form of patent granting should
specifications, by which the distribution of code embedded prevail, the FRAND commitment or the RF granting from
in the specification will be substantially restricted, in OSLs. In the absence of specific rules by SSOs so far, it
contrast with the sharing and collaborating practice in the seems that open source terms are the only clear applicable
open source community. rule. In this case, RF granting will be the license fee to use
the embedded technology. Since the capability to collect
3.2.2. Code becomes essential royalties on patents are one of the main incentives for many
innovators to contribute technologies [30], it is unclear that
If the code included becomes essential copyright, it will whether such switch will be embraced by SSO members.
become more imperative to address the copyright issue we Besides the RF granting, perhaps a more troublesome
discussed above. concern is the cascade effects of OSLs. While enjoying the
Lack of specific rules: None of the three SSOs so far have patent for free, implementers have to be bound to other
a particular clause regarding essential copyright. The ETSI restrictions by an open source license. Some norms are not
IPR policy even emphasizes that software embedded in aligned with the current practice of SSOs. For instance,
specifications shall not be used as mandatory for open source licenses contain a “patent retaliation” clause
compliance [16]. Again, SSOs accredited by the ANSI, that generally discourages recipients from bringing patent
have been discouraged from including software in standards, litigation against the “work” that incorporates the patented
let alone letting them be essential. contribution, otherwise the patent right will be terminated.
FRAND commitment: In the absence of specific rules, one This prevents implementers from filing lawful litigation if
may refer to the same clause for patent license. For instance, they find that their patents (included in the same work)
in the ETSI, the essential claims subject to FRAND license have been infringed, which is guaranteed and encouraged
terms use the term “intellectual property rights”, which is by the current framework of SSOs and by competition
broad enough to encompass both copyright and patent authorities.
rights. Similarly, in the case of SEPs, implementers could
seek a FRAND copyright license --- which might bear 3.3 Conclusion
royalties --- to copy the standard (code). While in the
meantime, such code should be licensed under the original Having said the above, we find that gaps exist in the current
OSLs. It is unclear whether FRAND license terms or open
source licenses will prevail. In any case, as Bekkers and IPRs framework of the ITU, ETSI and IEEE, which pose
risks and impede SSOs from utilizing OSS.
Updegrove have noted:“ …patents and copyrights are
sufficiently different that using the same language do In addition, our preliminary legal analysis shows that
address both types of IPRs provides a less than ideal result” FRAND licenses do not necessarily conflict with most
[24]. OSLs (except GPL family licenses). However, in order to
encourage OSS implementations, SSOs would benefit from
3.2.3. Functions derived from open source code having specific terms to clarify the different applications of
the scope of FRAND and OSLs terms to avoid future
confusion. Particularly, practices such as patent exemption
If not directly using the code as (part of) technical (e.g. OpenBSC) for research or other non-commercial
specifications, functions derived from open source code
could be adopted in a standard. We have seen large purposes should be encouraged.
innovation flows in open source projects, it is fair to say More importantly, software guidelines of SSOs need to
some of these patents derived from open source code which change to keep apace with the growing role of software
may become SEPs. (OSS is only one model). SSOs such as the IEEE that do
RF license: If an open source license does not contain any not have a software guideline would benefit from
establishing new rules. For those that have already done
patent clauses, e.g. MIT or BSD, the patent issue could only
be left to the policies of a standard body, which might in the some work like the ITU and ETSI, an attentive update will
be in order to embrace open source working processes in
end subject to the FRAND commitment. However, if a
license contains a patent clause, e.g. the Apache v.2, the developing future standards. Although essential copyright is
less common than SEPs at the time of writing, we can now
patent right is granted on a RF base subject to the open
source license. The question would then be whether SSOs find at least one close example in the XML standard, which
contains code to the structured information it unifies.
can require the right owner who contribute the patent also
to the standard to license it under FRAND license even if Applying the same FRAND rule with SEPs is not the ideal
approach. One precedent can be learned from the IETF, in
there is already an open source license with RF patent

– 43 –