Page 60 - Proceedings of the 2017 ITU Kaleidoscope

2017 ITU Kaleidoscope Academic Conference

which the SSO specifies that any source code included in a any entity (including a cross-claim or counterclaim in a
standard must be made available under the BSD open lawsuit) alleging that the Work or a Contribution
source license, which applies both to essential and non- incorporated within the Work constitutes direct or
essential copyrights in software code. contributory patent infringement, otherwise the RF granting
Similarly, patents built on OSS code must not be ignored license will be terminated [32].” The application scope of
either. When standardization activities are closely the patent retaliation clause is defined by the scope of
connected with an open source project, as we learned from “Work” and “Contribution”. “Work” is not equal to
an empirical study on RDFa standards and the Drupal open “Contribution”, generally, the scope of “Work” can be
source project, overlapping is very likely to happen in these broader than “Contribution.” This means that both litigation
parallel developing situations, which is proved by the against “Contribution” that contains the patent in the matter
similar proportions of issues raised by the top raisers in and also other patent contained in the same “Work” will
W3C RDFa and Drupal RDFa of the contributions [26]. As trigger the patent retaliation and deny the patent right that
a result, whether SSOs need a separate patent license policy one may have received.
apart from FRAND on SEPs is an open question that needs
to be explored. 4.1. Limited to implementation
However, one should not expect a one-size-fits-all answer.
Detailed rules should be warily designed and aligned with The scope of application of the ETSI IPR policy and the
goals of a specific SSO on the extent to which it would like Apache v.2 are essential to our analysis. Boundaries are
to embrace OSS. Nevertheless, a more clarified IPRs policy defined, according to which, the OSM is confined to be an
would help fill the gaps in the current framework. implementation on NFV, and “…[n]either the CR’s nor the
OSG OSM Reports will contain code for direct inclusion
4. APACHE V.2 WORKS IN THE ETSI into an ISG NFV Group Specification”.
A pure implementation seems to be the ETSI’s design for
Having discussed these gaps and tensions, a recent case in hosting this open source project. Following our discussion
the ETSI might shed some light on how SSOs might be able in section 3.1, the FRAND commitment and Apache v.2
to cope while utilizing OSS. will apply to SEPs and the OSM, respectively. The two do
In April 2016, the ETSI, which is one of the key formal not necessarily encounter each other in the current phase of
SSOs in the telecommunication sector, launched an open OSM. Moreover, we observe that the ETSI MANO is an
source project “OSM” under the open source license emerging technology that no party has claimed SEPs on.
Apache v.2, which is aligned with ETSI Network Function Hence, there is less risk for open source developers to seek
Virtualization (NFV) Information Models[10]. In order to a patent license.
answer whether the ETSI is able to (totally or partially)
remove concerns in this project, we will analyze the 4. 2. Potential standardization activities in OSM
potentially applicable IPRs rules. These documents include:
ETSI IRP policies (which have been discussed in parts 2
and 3), the relevant Apache v.2 license clauses, and two Although the ToR went through great lengths to show that
specific documents governing the project, including the deliverables from OSM are not ETSI technical
OSM Terms of Reference (ToR), the Contributor License specifications, and that code will not be directly included in
Agreement (CLA), which has the same copyright and specifications, we find some clues in the projects that might
patent license rules with the Apache v.2. Here we draw a not be able to exempt all the possibilities for overlapping
simplified chart of the governing documents of IPRs of easily. One of the functions of OSM stated in the ToR is to
OSM in Figure1. “provide practical and essential feedback to the finalization
of the ETSI MANO stage two and three specifications.”
Such feedback helps formulate the ETSI MANO Standards
and the future 5G standards.
Moreover, it is fair to predict that standards that are based
on existing OSM implementations are possible. We argue
this for two reasons: first, we have seen multi-party de facto
standards (implementations) existed before selective
process and multi-protocol activities carried out by SSOs
such as the IETF or W3C [33][34]. Second, as we have
discussed in previous texts, technical sharing between
Fig. 1. Governing IPR rules in OSM RDFa standard and the Drupal project showed high
Apache v.2 is among the nine most popular OSLs identified possibility for overlapping function between SSO standards
by the OSI, accounting for 15.34% of the open source and an open source project.
projects in the records [31] . Major features have been Therefore, while direct inclusion of code has been avoided
noted in previous texts as well. Succinctly, it is not a by the ToR, there is still a high possibility that some
copyleft license. It has the so-called “patent retaliation” functions derived from OSM code can be adopted into
clause. The core idea is that while granting a RF on patents, ETSI NFV standards. Since OSM is a hosting open source
receivers are not allowed to initiate patent litigation against project in the ETSI, the patents based on such code are

– 44 –