 Hi everybody. Thanks for joining me today on my presentation, Leveraging Specifications in Open Source Projects. Let me give you a quick summary of what I will cover today. This presentation is from the perspective of an open source community interested in developing or leveraging specifications as part of their collaborative efforts. I'll cover the following points. One, how open source projects can collaborate on open specifications. Considerations in implementing upstream specifications and code and overview on specification development at the Linux Foundation. We'll go into how you can create open specifications with the community specification license. And we'll explore a community specification license case study, the SPDX project. So first, let me give you some information about me. I am vice president of project formation for the Linux Foundation. I've been at the Linux Foundation for over six years. And I've been involved in setting up over 100 projects at the LF. I work with all with projects across all stages of development from early scoping to community formation and launch. I focus on all forms of open technical collaboration, including open source, open specifications and standards, open data and open governance networks. If you have questions about this presentation or interested in speaking with me about bringing a project to the LF, please reach out to me at s Nicholas at Linux Foundation.org. Quick disclaimer, while I am an attorney, I'm not your attorney. And you'll need to discuss any specific legal matters with your counsel. Let's take a quick look at what our specifications in very general terms standards and specifications refer to requirements that are documented and are required to be met by a particular design product or service. In this presentation, I will use specifications to refer to both standards and specifications. Let's talk about the importance of specifications which would have been with us for a very long time. In fact, the picture that you see at the bottom is of the British standard Whitworth, which is a screw thread specification that is 180 years old. The dependence on specifications and the recognition of their importance grew out of the Industrial Revolution. The 1800s saw the creation of international standards and international standards development bodies. Collaboration through the development of specifications remains critically important today. And this form of collaboration can be leveraged by open source communities to extend their work. We view open source and open specifications as complimentary and synergistic. Let's talk about additional details on the importance of specifications and how open source projects can benefit from open specifications. The specifications can amplify open source projects, ensuring that the resulting code is well defined, provides predictable performance, and the different implementations can interoperate with one another. Reliance upon an upstream specification in an open source project allows that project to utilize existing solutions and tap into third party development efforts that exist outside the project. This specification development effort to an existing open source project can increase that project's addressable footprint by enabling interoperability with other projects, products and services, and by providing an open license for implementations beyond code. So let's talk about some of the differences between open specification licenses and open source licenses. The development of open specifications and open source share numerous commonalities, but there are differences to consider. Open source licenses generally focus on license commitments from the contributor and extend the license to the code or documentation artifacts that are contributed. Open source foundation specification projects will frequently employ intellectual property frameworks that have license commitments that extend to implementation of the specification beyond code and secure license commitments from participants in the project versus just contributors. So let's look at the question, can an open source license be used for a specification, or do you have to use an open specification license. And then do use open source licenses for specifications. We have a number of projects that leverage the develop specifications using an open source license. There are situations where it is appropriate to use an open source or creative commons license in the development of a specification. And our projects that follow this approach include the new project within LF networking which uses CC by for we have numerous taxonomy and dictionary projects that also leverage a creative commons license for their specification work in setting up definitions. And the Onyx project within LF AI and data foundation uses the Apache 2.0 license for development of its specifications. Most of our open specification development efforts though, do use various forms of specification licensing in order to provide license clarity to the community, provide additional license clarity in their cases. Let's talk about how specifically an open source project can leverage specifications. Open source projects can one, implement upstream specifications to establish communication channels with third party standards development organizations and three host their own specification development efforts as part of the open source project. Diving this into this in more detail, looking at implementing upstream specifications. Open source projects are interested in working with a third party or upstream specification and turning that into code. There are various considerations that the project needs to take. This is the same as with leveraging an upstream specific, sorry, an upstream open source project where you have to understand what is the licensing framework for the open source component. So when you're looking at implementing an upstream specification into code, you need to ask the following types of questions. What are the terms and agreements applicable to the upstream specification. Do the contributors have the right to access the upstream specification. Is it protected under trade secret law and covered by non disclosure agreements. What is the licensing concerning the specification text itself. As opposed to the open source project, have the right to modify the specification in order to implement it in code. Simply because one can access a specification or one has a copy of the specification doesn't by itself, mean that you have the rights necessary to modify that specification or implement it and put it into code. Those questions need to be explored. Finally, there may be trademark considerations in implementing a specification and the patent landscape has to be understood. If this is an area where implementations may need and may trigger royalty obligations. That's something that the community should understand and know as they start the process of collaborating and relying on the result and collaboration. There may be noticed an attribution requirements unique to the specification that need to be incorporated in and maintained within the resulting code in the open source project. Some sticking points that may require additional analysis and in some cases may require conversations with the third party standards development organization can emerge and these include one restrictions on modification of specification texts. Confidentiality restrictions on the specification itself, payment requirements in order to state that an implementation is conformant to the specification. And for the patent and royalty landscape concerning the specification needs to be understood and understood by the community. In these cases, we recommend that projects engage with the upstream specification project in discussions to find potential solutions, or to better understand that royalty payments will be required. Right, let's look at the second area on how open source projects can leverage specifications and that's through maintaining formal communications with third party standards development organizations. Communities have long understood the value of leveraging work done outside of any one particular project. In the case of specification efforts, it can be very helpful to have organized communication between one open source project and the upstream specification community. Even if there's significant overlap between the participants of both projects, it can be very useful to have a formal communications channel. Additionally, standards organizations have used agreements that they call liaison agreements to establish these types of relationships at the Linux Foundation, we typically use something that we call a memorandum of understanding or a letter of intent or similar. In these cases, the purpose of the agreement or the memorandum of understanding is to establish points of contact for information sharing between the specification project and the open source project, and to scope out areas of interest to the parties in collaboration. And these can also provide a useful vehicle for resolving potential incompatibilities from a licensing perspective. If there is a path to resolution that works for both the standards development organization and the open source project. I'll give some quick examples of agreements that and collaborations at the Linux Foundation has put in place and announced with third party standards development organizations. You can see these here we announced a memorandum of understanding with Etsy. There is a collaboration between the LF networking project on that and MES. We have a collaboration with team forum. And this year, we signed a liaison agreement. And we have a collaboration between our project C2PA and IPTC. All right, so let's turn to how a project, an open source project can develop a specification itself. That's the third way that an open source project can leverage specifications. So just as projects will collaborate using various open source licenses. Projects can establish specification efforts using a specification license framework. At the Linux Foundation, we have a number of different specification development frameworks that are open source projects can use. I'll first provide some background information on the specification approaches that we take the open specification approaches we take at the Linux Foundation. So the office has been supporting the development of specifications for a long time. In fact, the Linux Foundation itself was originally formed. The merger of the open standards development labs and the free standards group, including individual working groups and sub projects of projects we have over 100 projects and sub projects involved in aspects of developing or implementing specifications. We use various legal entities for hosting specification projects and can support everything from lightweight development efforts to formal specification projects that that intend ultimately to submit specifications for ISO status. Here's a slide with logos of many of the specification projects that we host. I won't go through each one here. But again, we host a large number of specification efforts. And it's an area of collaboration that we view as very important. So how we specifically structure specification projects. We have a number of frameworks for supporting and open communities development of the specification project. And again, as I mentioned, these range from lightweight, meaning easy to establish without necessarily a lot of formality to more formal structures. For standard development, we have two primary approaches for constructing specification governance, lightweight and fast moving projects that leverage community specification license, and I'll go through that in detail in the following slides, and more formal projects established within our joint development foundation hosting entity using our JDF governance templates, where a hierarchy of authority is more helpful to the community. Ultimately, we have the ability to customize our community specification projects and our open source projects. And so here you see a spectrum of how we're able to support specification development efforts on the one hand, we can have the very fast and lightweight specification projects where collaboration is done in a repository to something more customized to finally our JDF traditional mode standards, where it's leveraging a formal approach using standard templates to drive specification development. So into each of these types of structures where we support the development specifications in more detail and I'm going to start with the community specification license, which we presented specifically my believe Mike Dolan presented to this community last year. The community specification license incorporates all the terms and processes required for specification development into one set of files located in a repository. It is designed to enable collaboration on a specification at the speed of open source. The community specification license is self contained in its repository, and that repository has the license agreement, as well as the governance and a code of conduct and other material operating policies, all within that set of folders and launching a community specification project is as easy as cloning that repository and making a couple adjustments to starting files. You can walk through what those adjustments are. So at the heart of the community specification license project is of course the community specification license, and I'll focus on a couple areas of this license. I'm going to show some texts on the screen. We're not going to go line by line necessarily, but I want to look at a couple key components, and this will tie into some of the differences between open specification license and an open specification license that we talked about earlier. So, the first part I'm showing here of the community specification license is a copyright grant. So there is a grant made for contributions to the specification. And this includes, this is a copyright license and notably this includes the right for the project to submit the specification to another standards organization. And that's something that we enable for all of our projects whether they're leveraging a lightweight specification, or our JDF traditional mode approach, where we provide the ability for projects to submit the specifications, for example to an international standards body. There is an attribution requirement for development under the community specification license and that's detailed here as well. And this is a patent license. There is a patent license granted by contributors, and this is open source like in that aspect to necessary claims in the contributors contributions and to the draft specification that is within scope. So we're going to talk about scope scopes very important to a specification project. We'll go through that in more detail but when we talk about scope recall that the patent license commitment with respect to the draft specification is within scope, nothing outside of scope is covered by that section, that provision of the patent license. And then also there's a patent license for approved specifications. Again, it's a license to necessary claims in the approved specification that are within scope for a licensees implementation. In both cases, contributions, and with respect to draft specification and approve specifications. You'll see a reference to accept for claims that are excluded. And we'll talk about that next. There is a mechanism for the exclusion of certain claims from a contribution that was made, or from a from a final specification. And that procedure is detailed in section three of the license, specifically notice needs to be filed with the community. And that's done by making a poll request to the necessary file in the repo that will immediately put the community on notice as to whether a patent has been filed. Or sorry, immediately notice as to whether a patent claim rather has been excluded from the licensing commitment and source code license. So in the context of an open source project overall. Of course, there will be code being developed by the project on that code development can continue as it has been before, but there may be specific areas of code that want that that it's easiest to develop as part of the specification effort. For example, if there's example code or other other helpful code. And in those cases, the source code licenses for that code will be whatever is described in the repositories and if it isn't described then the default licenses the MIT license. So that is the community specification license. Again, lightweight repository based. Let's look at the other structure that we offer. And we have a number of projects in the 20s. Using this approach, which is standing up a project within our joint development foundation project sanity. In 2019 the joint development foundation, join the Linux foundation family, JDF projects can be thought of as a standards development organization in a box with templates and governance structures that allow for the rapid creation and stand up of a standard specification project. In a JDF traditional mode specification project members agreed in the project governance and licensing terms through the execution of membership agreements draft specifications are developed within working groups, and a steering committee approves the final specifications. This is a copy of the first page of a JDF foundation project membership agreement, and you'll see here signature blocks. So immediately, this is one difference in terms of structure and formality between a JDF project in traditional mode and a community specification project, where in a community specification license projects. You can start contributing to the project by contributing to the repo that may require in some cases execution of the CLA if a project is using it but joining the project is as simple as contributing to the repo in a joint development foundation project traditional mode. There is a detailed agreement that sets forth the operating structure for the project, as well as the intellectual property framework for the project and each working group. And that agreement needs to be signed by North authorized corporate representative. So let's look at some of the differences between a community specification project and joint development foundation project in its traditional mode. Our membership agreements required as I just reviewed a JDF project will have a membership agreement so yes, a membership agreement is required in a JDF project in a community in a community specification project they're not required. It can implement a CLA but a formal membership agreement is not part of community specifications by default. Is there a steering committee that approves final deliverables and final specifications. Yes, in the case of a JDF project, not by default, in the case of a community specifications project. Now you'll notice in some of these cases I'm saying not by default community specifications is a highly flexible approach, and it is possible to modify the governance documents as we'll look at it following slides to make adjustments to add in a steering committee or other body that is responsible for specific actions. Turning back to this, again, in a JDF project, we have a steering committee that approves the final specification, that's not necessarily the case for the community specification and it isn't the status by default. Is there support for what multiple working groups in both structures. Absolutely. Yes, in a JDF project, each working group will have its own working group charter. In a community specification project, each working group will have its own repository and either a link to the primary license files for the project. Or a copy of all those files in both cases, a community specification projects working group will need to have a working group specific scope statement. Can these projects raise funds as part of Linux Foundation. Both are types of projects here can raise funds we can add a fundraising vehicle around both types of efforts is funding required. No, in both cases, though it is strongly recommended in the JDF component in the JDF project structure because of the additional complexity of that type of a project. And finally, let's look at a legal entity for the project. Is it required. It is required, and we do stand up a separate legal entity we use a series LLC for JDF projects for community specification projects are operating within a repo. The legal entity is not required. But if it is desirable to the community, we can always use one of our hosting entities to stand up a series LLC for the project and give it its own legal identity. So, let's let's talk about the specifics of enabling development of a specification within an open source project. In two approaches, community specification and JDF traditional mode, the fastest approach for an existing open source project that is already doing development and code, and is interested now in collaborating on the development of a specification. The fastest approach will probably be development under community specification license. And so, what we'll do from here is a look at how an open source project can leverage the community specification license. There are extensive opportunities for projects collaborate using the JDF traditional mode and offline for anyone interested in that structure. It's more formal with the steering committee and members that join. Please reach out to us and we can talk to you about how those projects can be set up to support an existing open source effort. But from here, I'm going to focus on an existing open source project utilizing the community specification license. So, how do you start a community specification project. Now, as I talked about in describing how all of the governance documents are located in the repo, you simply clone the repo. So you go to this location. These are all of the documents, and we'll look through these in detail in a moment, and you clone it, and you put it in your repository for this for the development of the specification, and you modify a number of files to have those be customized for your particular project. So this is it. This is the community specification license. These are all of the files or rather their names and summaries. There's a getting started document that explains the exact process on how you can clone the repo and start developing your own specification. There's a contributor license agreement. Not all projects have to use it. But if you want to use a contributor license agreement as part of your community specification project. The template is provided here. We do recommend always using automation in the case of projects that are leveraging CLA is of course automation such as our easy CLA tool can greatly simplify the administration and management of CLA is document number one is the community specification license itself when I showed you select provisions the copyright and patent license from that document. It's that is the document that I was displaying. These files are intended to be adjusted for continuity of and similarity of licenses of course we asked that projects not customize the license itself. Number two is the scope statement. And this is very important from the intellectual property perspective it's important in understanding what areas the project is interested in collaborating and what areas are out of scope. Notices for filing notices and putting the community on notice of things such as patent exclusions license. You can detail the licenses such as the open source licenses for project wanted to use a data license you would explain that here. The governance file is how the community will govern itself. The contributing file is a set of contribution guidelines again that can be adjusted by the community for development of the specification file number seven here has a template that you can follow and there's a default code of conduct for the project. And the last file is a read me overview file. So, you've clone the repo. What next. Well, the next step is to update the notices to provide contact for any code of conduct issues, and then to also update the scope and defile to reflect the scope of the project as we've talked about this is critically important in the specification project, because the intellectual property grants, specifically, you'll call the patent licenses that I described within the community specification license. Those are made with respect to the scope of the project. And so, each projects working group needs to have its own scope document, and that should be maintained. In addition to the licenses and the scope files. There's a governance file that that can be adjusted if required. Again, the governance is designed to have all the components necessary in terms of how the project should operate. However, there's an opportunity to customize these files to reflect how the open source community is currently getting its work done. So, in the default structure, the default governance file of a community specification project. There is not, for example, the concept of the steering committee. However, many of our open source projects. will leverage a technical oversight body, we often call these technical steering committees or technical oversight committees, I'll call the, I'll call them technical steering committees for now. The project is using a technical steering committee for for its code work and wants to continue to rely on that body for technical oversight of the specification. The governance MD file can be modified to point back up to the technical steering committee and to explain the role of the technical steering committee in development and oversight of the specification. It's not about how there's a code of conduct. Similarly, if the project already has its own code of conduct, the code of conduct file can be updated to align the code of conduct of the specification development effort with the code of conduct of the open source project overall. One other nuance that I'll mention here is operating under the community specification license, of course, means that a project is operating under a license that is not most likely its primary open source license. If it's a Linux foundation project, it's most likely operating under a technical charter and this technical charter has the mechanics on how decisions are made and how that open source project operates but it also has an intellectual property section. And assuming this is our standard model that intellectual property section would have a couple statements. First, it would have the license of the project. And second, it would have a mechanism for approving an alternative license. Finally, the charter itself can be amended. So when a Linux foundation project is interested in implementing a specification, it should also briefly look at its charter document and just verify whether it needs to make any adjustments in its governance to reflect the development of a specification, which is development of an open specification under a license that is different from the license that may be set forth in the charter. Two specific ways of doing this in the technical charter construct that I just described. One, you can amend the charter that typically requires a higher vote. And while it's not complicated and our projects adjust and evolve their charters all the time, it is, it is a little bit more time intensive than the second approach that I'm going to mention, which is we have the alternative approval mechanism for approving alternative licenses, the technical steering committee can vote and approve an alternative license for use by the project. And then that would be documented in the records of the actions of the technical steering committee, the technical steering committee can vote on the creation of the specification project and approve the use of the community license. And if it's our standard project charter. That's all that's required to enable the project to begin to work under the community specification license for our projects. If you're looking at this type of question, please reach out to us, and we can glance at the charter very quickly and tell you what sort of actions would be easiest to get the community specification project or some project rather approved as part of the open source Alright, on this page, we have some common questions that come up. I'm not going to go through all of these but but let me touch on some of them. Again, we've talked about separate working groups. Yes, separate working groups are a mechanism that both are formal JF projects but our community specification license projects support and a related question here is how do you set up the files for separate working groups. You'll need a copy of the specification projects set of community specification license files in every repository. Now that doesn't mean you have to necessarily copy and paste all of the files and every repository. You can use a pointer to point back to a primary set of files. Recall that each working group will need its own scope statement. So whether you point back to the primary set of community specification license files that the specification project has prepared for itself, or you copy them. You will need to have a working group specific scope statement. If you only have one working group then you only have one scope statement as well. Does a community specification license project have to use a CLA. No, there are two forms and two approaches for binding a contributor and a participant in the project. We move the commitments in the community specification license and one is by making a contribution to the repo. The other is by signing the CLA. What if the project grows and becomes more complicated and decides that it's ready for more formality. The way we structure our projects is the Linux foundation is to make them forward compatible so we can take something that starts as a community community specification license, and we can add additional functionality, additional formality. If it's required over time, we can start with a community specification license project, and then we can add a joint development foundation structure around it, for example. We can add a funding component to support a project. If that becomes necessary, not necessary to start with funding but it can always be considered as an add on by the community. And finally, the option of submitting a project for considerations for ISO status is an option for our projects as well. So for our final bit of time here, and I do want to hold some time for questions. I'm going to take a look at a case study, specifically, our SPDX project. SPDX stands for software packet data exchange. This is an open standard for communicating software build material information, including components, licenses, copyrights and security references. SPDX reduces redundant work by providing a common format for companies and communities to share important data about about software licenses, copyrights and security references, thereby streamlining and improving compliance. In fact, in September 9 of this year, this month, we announced that SPDX specification has been published as ISO IEC 5962-2021 and recognizes the international open standard for security, license compliance and other software supply chain artifacts. ISO IEC JTC1 is an independent non-governmental standards body. SPDX has recently decided to leverage community specification license in its future versions of the SPDX specification. Prior versions have been and will remain licensed under CC by 3.0. The primary repository for SPDX community specification license development can be found at the link here. And again, what do we see when we turn to the SPDX repository? We see the same set of files that we saw as the primary files of the community specification license. Each of these, except of course this is the community specification license, if needed have been customized for the SPDX project. Specifically, the scope now reflects the specific scope that has been the scope and focus of the SPDX project and the governance file has been updated. I won't go through this line by line, but I wanted to highlight the changes in the governance file because they have been modified to reflect how the specification project involves in the case of SPDX, these separate teams that are working together, a technical team, a legal team and an outreach team. Finally, the SPDX project is governed by a steering committee that consists of the chair of the project, the project's team leads, and up to two representatives of project members. So a couple of things I'll highlight here. While the default community specification license doesn't have a steering committee, we can modify the governance document to add a steering committee and reflect that. So anytime that open source project is interested in developing around standards and specification, we can use the community specification license and modifications to the governance file to reflect the operating procedures and the governance procedures that that open source project already has in place and is already working for that project. So in conclusion, we have extensive capabilities at the Linux Foundation to support the development of open specifications, and we've used specifications as an important component of open collaboration. Open source projects can leverage specifications through implementation of upstream specifications. And by establishing relationships with standards development organizations and three by developing their own specifications within their own projects. When implementing upstream specifications, open source communities must first assess the rights they may have to the upstream materials, just as with upstream open source dependencies. Finally, open source projects and communities can easily add development of a specification through the community specification license. I want to thank you for your time today. And I am now available in the Slack channel for questions. Alternatively, if you'd like to talk to us about bringing your project to the Linux Foundation, or you have questions following the Q&A session, please reach out to me at www.linuxfoundation.org. Thank you again. And now we'll take questions.