In case you missed it, LinkedIn last month teamed up with GE, Hewlett Packard Enterprise, and a host of other companies serving the data center market to launch a foundation to govern its open source data center technology effort. The Open19 Foundation now administers the Open19 Project, which in many ways is similar to the Open Compute Project, started by Facebook, but also stands distinctly apart thanks to several key differences.
The most prominent point of contrast is Open19’s target audience: data center operators who are smaller than the hyper-scale cloud platforms operated by Facebook, Microsoft, Apple, and Google, some of OCP’s biggest data center-operator members. Another big difference is Open19’s big focus on edge compute in addition to core data center hardware.
There are other differences, but one that is especially telling about the nature of Open19 is the way its founders have chosen to treat intellectual property of the participating companies. Unlike OCP, which requires any company that wants to have a server or another piece of gear recognized as OCP-compliant to open source the entire thing, Open19 structured its licensing framework in a way that lets companies protect their IP and still participate. If HPE or one of the other participating hardware vendors wants to adopt Open19 standards for a server, for example, it doesn’t have to part with its rights to the technology inside that server for the foundation to recognize it as Open19-compliant.
“A lot of people are reluctant to be in an environment where they’re always required to put their IP out,” Yuval Bachar, a top infrastructure engineer at LinkedIn who is spearheading Open19, said in an interview with Data Center Knowledge. “We’re creating an environment where you’re not required [to open source IP] unless you participate actively and contribute to the project.”
LinkedIn owns all the current Open19 IP, which includes a “cage” that goes inside a standard data center rack, four standard server form factors that slide into the cage, a power shelf, which is essentially a single power supply for all the servers in the cage, and a network switch. The company is planning to contribute all of the above to the foundation, Bachar said, but it doesn’t expect other members to do the same. It might also contribute the technology inside the servers, although server innards aren’t part of Open19’s current focus.
“In Open19 you don’t have to contribute what’s inside your server,” he said. “Potentially, we as LinkedIn will do that, because we don’t see a competitive commercial advantage in actually doing our own servers.” But the likes of HPE, hyve, Flex, QCT, or Inspur have IP to protect, and the foundation doesn’t want that to hamper their participation.
Licenses Selected to Lower Risk
For cases where vendors do want to contribute technology to the project, Open19 has selected various types of licenses for different scenarios, all meant to further reduce friction associated with participation.
The default license for everything other than software, such as specification documents or schematics, is Creative Commons, Brad Biddle, legal counsel for the Open19 Foundation, said in an interview with Data Center Knowledge. Different flavors of CC that provide different levels of control apply depending on document type.
If a collaborative project results in a specification, or another document that others will implement in their own hardware, the parties that created it are required to grant a patent license for the parts they contributed on “RAND-Z terms.” RAND-Z — in which RAND stands for reasonable and non-discriminatory and Z for zero royalty – is a common scheme standards organizations use when somebody’s IP is essential to a standard.
Open19’s default license for software contributions is the MIT license, one of the most popular open source licenses. “It’s a very simple, permissive-style license, as opposed to copyleft license,” Biddle said. The license is used by popular open source projects such as Ruby on Rails, Node.js, and jQuery, among others. Copyleft licenses, such as the GPL, essentially require that the code, including any modifications, remains open source and compliant with the same license. Permissive-style licenses impose no such restrictions. In other words, if a company takes a piece of open source code from Open19 and modifies it, it doesn’t have to open source the modified version. “We were sensitive to not wanting to force implementers to license away technology as a price of implementation,” Biddle said. “Our default licenses don’t require any licenses back from the technology recipients.”
The same set of default licenses would apply to single-source contributions, such as LinkedIn’s Open19 designs. Biddle said he doesn’t expect the foundation to run ongoing development projects for single-source contributions and has designed that framework for one-off releases.
The foundation’s open source licensing choices and the freedom to participate without having to give away trade secrets are meant to make participation less risky for vendors and whoever else designs hardware or writes code. After all, the initiative’s success will depend on its ability to grow the ecosystem of companies that participate. Growing an open source data center hardware community is a chicken-and-egg puzzle. Unlike the world of open source software, where vendor participation is not a prerequisite for a thriving project, attracting more end users to an open source data center hardware project requires a variety of vendors willing to spend the resources necessary to design and produce the hardware, so end users can be sure they can actually source the technology and source it from multiple suppliers. Conversely, vendors are attracted by end users. Making it easier for vendors to play helps solve half of the puzzle.
Christine Hall contributed to this article.
All copyrights for this article are reserved to datacenterknowledge.com