"He who receives an idea from me, receives instruction himself without lessening mine; as he who lights his taper at mine, receives light without darkening me. That ideas should freely spread from one to another over the globe, for the moral and mutual instruction of man, and improvement of his condition, seems to have been peculiarly and benevolently designed by nature, when she made them, like fire, expansible over all space, without lessening their density in any point, and like the air in which we breathe, move, and have our physical being, incapable of confinement or exclusive appropriation. Inventions then cannot, in nature, be a subject of property. Society may give an exclusive right to the profits arising from them, as an encouragement to men to pursue ideas which may produce utility, but this may or may not be done, according to the will and convenience of the society, without claim or complaint from anybody".
A platform of CEA building blocks, such as the out-of-the-box capabilities of the Coral CEA Sandbox, provides companies with the capability to quickly build new innovative products and services. Key considerations for users of the sandbox include intellectual property (IP), licensing, and any other dependencies inherited from use of the sandbox assets. This article presents some background on this topic and examples of how to address the associated implications.
A Little Background with a Software Bias
Intellectual property rights (IPR) refer to the exclusive rights granted to the creators of original works. By general convention, IP is comprised of products of the "human intellect that have commercial value and that receive legal protection", encompassing "creative works, products, processes, imagery, inventions, and services" under the protection of patent, copyright, trademark and trade secret law. Focusing narrowly on IPR as it pertains to software, we can expand on the concepts of patents and copyright:
Patentability: software patents typically fall in the domain of utility patents, where they are captured under the description of a process. They became prevalent in the US in the 1980's but were typically associated with software that interacted with hardware and related devices. Software patents are also applicable from a Canadian perspective, conditional that the software is integrated with a technology that is traditionally patentable.
Copyright: for purposes of the copyright law in general, software, including object code which can only be read by a machine, is typically considered a literary work. A software copyright owner has the exclusive right to: i) reproduce the work; ii) create derivative works; iii) distribute copies of the work; and iv) publicly display the work. Computer programs are protected as literary works within the meaning of Article 2 of the Berne Convention and such protection applies to computer programs, whatever the mode or form of their expression.
Although there may be different definitions by jurisdiction, all forms of software are protected by copyright. And when it comes to the application of an IPR within the software domain, the leaning tendency is towards a copyright directive rather than patents.
What is the relationship of copyright to license? In plain terms the distinction can be made as follows. If we make the analogy of code as a home, copyright can be said to be the ownership deeds of the home, and unless you assign those deeds to another entity, you retain ownership of the home. Licensing isn't about giving away that ownership, it is about setting the rules by which the home owner allows others to use their home.
Andreas Constantinou proposes that the use models and adoptions of specific licenses in different software domains are dependent on the needs and directions of the perspective ecosystems, and also the mechanisms that are provisioned to cater to member use patterns. When we consider software and its associated applicability of copyright, we typically think in relation to traditional client/server software rather than the newer software-as-a-service paradigm. Our concept of software needs to be updated. We need to address the questions of whether and how the contemporary software components and services which make up CEA should be licensed and whether the traditional software licenses can be applied. The question of whether "licenses are a legal artefact applicable to services" as propositioned by Gangadharan & D'Andrea, has been asserted positively in the previous work of Gangadharan.
We need to highlight the differences between the contemporary and traditional components, to identify applicable license criteria. Web services "are not targeted as standalone applications" and, unlike traditional software, "web services do not execute over any specific hardware or software platform". Moreover, when we compare the differences in the make up of web services, we can see that these differences center around the concepts of: i) hosted environments; ii) reuse models; iii) composition models; and iv) data.
As with traditional software, a web service can be proprietary or open. Gangadharan proposed a means of capturing the licensing patterns of web services, as summarized in Figure 1.
Figure 1: Web Service License Patterns
With this representation comes the implications for platform providers within the CEA domain. CEAs are building blocks that can be leveraged, reused, and combined. These components can be many, and their derivative web service complementors can have followed any of the patterns defined. Therefore, it is essential that CEA platforms provide mechanisms or incorporate process hooks that allow the user/member communities to have visibility of such dependencies, or a means by which the steps to address and resolve any associated incompatibilities can be automated.
Thoughts for Resolution
The assets deployed within CEA based platforms comprise various definitions, from the underlying building blocks, to the publicly visible enabler functionality of the web service components. Two suggested means by which the IP nuances within CEA could be addressed are through:
1. The utilization of various software IP audit services. The key players in this space are Black Duck Software, Palamida and Ottawa based Protecode. The majority of these services primarily focus on the compatibilities of open source licensing.
2. Employing or incorporating into the CEA governance platform a machine readable and automatible syntax for capturing the IP assets. A mechanism to approach this would be a solution based around Rights Expression Languages (RELs).
An example syntax that specifically focuses on automation prospects relates to ODRL-S, a profile which is based on the Open Digital Rights Language (ODRL). It is provided as a means to express a service license so that any services can automatically interpret the licensing dependencies from the clauses it presents. The five applicable clauses are: i) subject; ii) scope of rights; iii) financial terms; iv) warranties, indemnities, and limitation of liabilities; and 5) evolution. A key benefit of utilizing a methodology such as ODRL-S is that service level agreements (SLAs) requiring negotiations between a service consumer and provider could be circumvented. The license can now take the form of unilateral statement, specified by the provider to one or more consumers, without involving protracted negotiations for each engagement.
We expect that CEA will provide numerous new solutions and business prospects for many years to come. In order to ensure an uninhibited user community and open innovation, the providers of CEA platforms need to address the underlying IP needs of platform users. By addressing these needs and provisioning mechanisms for IP clarity, the organization removes impediments to productivity. Such mechanisms currently exist and the potential and advantages for automating these processes are evident, based around the many and varied interactions that need to be supported.