[IP policy and license review] SBOMit Sandbox Project Entry #191
Comments
|
Please update the license for your specification from CC-BY-4.0 to the Community Specification License 1.0 I will perform a license intake scan once your reference implementation is complete and there is code to scan. This is separate from the "IP policy and license review" which is part of the project formation process. To complete the project formation process, you should reach out to the LF project formation team (Mike Dolan, Scott Nicholas, Jory Burson, Todd Benzies) to setup a project charter and be added to PCC. |
|
So our community had a big issue with this license early on with some participants strongly arguing we should avoid the OpenSSF because Apple and other companies don't like the CSL 1.0. We heard from David Wheeler and a few others that they would approve "a reasonable license" and that their charter wasn't meant to exclude, but to include a default. The CC-BY-4.0 license was specifically noted as acceptable to all parties, which is why we chose it. If after hearing this you're still requesting a license change, let me know who (Omkhar, etc.) we need to involve to get this quickly resolved... I would also like to politely suggest that either the OpenSSF clarifies a list of other acceptable license examples in their bylaws or the various folks at the OpenSSF move toward a common understanding that this is the one true license that must be used so that others have the right expectations... |
|
@JustinCappos I was not aware that there is a concern about using the Community Spec License. CC-BY-4.0 is a perfectly good license but is intended for static text like documentation, it doesn't say anything about how a reference implementation may be licensed for example. I would like to know why Apple has an issue with Community-Spec-1.0? Let's wait before making a change and decide which license is best, and if it's CC-BY-4.0 then we make sure an exception is granted. I will follow up next week. |
|
in-toto, GUAC, Witness, and all of the other tooling implementations I am aware of use Apache 2.0, which is listed as an approved license in section 5a1i of the OpenSSF Charter (Section 5, Page 9): We will use Apache 2.0 in the future for any new tools / repos added to the project. However, I think the point here is about documentation licensing, not software licensing, which we clearly meet the bar for. At the risk of sounding impolite, I am kindly asking you to please either promptly approve or promptly escalate. We're working on a timeline here for a bunch of reasons and this part of the process is taking longer than it has for other projects I've donated to the LF. |
|
Yep, Apache-2.0 is good for any code, tools, etc, including your reference implementation. Agreed, the only question here is which license you use for your spec. While the recommended license for a spec is the Community-Spec-1.0 license, I understand your concerns and that you want to use CC-BY-4.0. I will work with Amanda @hythloda and anyone else needed to get this resolved as quickly as possible. |
The problem with CC-BY is that it doesn't provide implementers with any protection against patents contributors to the specification may have. The Community Specification license framework does that.
This will need to be raised to the Governing Board which is the only entity capable of granting an exception. See section 5 of the charter: https://openssf.org/about/charter/ |
|
@TheFoxAtWork Sorry to drop you into the middle of a conversation out of the blue. Can you chime in here with more details about the legal objections to the Community-Spec-1.0? We went the direction of CC-BY as the CNCF suggests, but obviously we want to avoid any patent problems as well. |
|
@JustinCappos , no worries. I think I have mentioned previously potential concerns with the community spec 1.0, particularly compared with CC-BY-4.0 or Apache 2.0. First let me mention I am not a lawyer (IANAL). My understanding is limited to the context of a contributor's potential contributions to a community spec 1.0 licensed project and that impact on patents of their employer. As I understand it, the provisions regarding patents under Community Specification 1.0 are more problematic than those of CC-BY-4.0 in that (someone please correct my reading understanding of the license):
It is up to the project to determine the audience of desired contributors - which the project may endeavor to appeal to the maximum amount of contributors across multiple industry areas to drive better use cases and outcomes and they may do so in the form of license selection. SPIFFE, for instance, is Apache 2.0. OpenFeature is also Apache 2.0. Generally documentation is CC-BY-4.0, in my mind either Apache 2.0 or CC-BY-4.0 are likely more appealing to organizations with patents. I hope this is helpful. I would highly recommend consulting a lawyer familiar with experience in both patents and open source licensing to fully understand the impact here, particularly if they have experience in protecting those patents in a proactive capacity. My recommendation to the project here would be to request the Legal Committee or their equivalent determine their company's ability or hesitancy to contribute to such licensed projects. |
|
I'm not a lawyer either but I've many years of working in standards development and I'm quite familiar with this. What @TheFoxAtWork says is accurate but conversely it means that, as I was saying earlier, with CC-BY contributors to the spec make zero licensing commitments with regard to the IP their employer may have. This means a party could suggest adding to the spec a feature that reads on their IP and later on ask implementers to pay a license for infringing on their IP. The Community Specification aims at avoiding this kind of situation by ensuring that contributors commit to license any IP they might have on their contribution. While it may indeed dissuade some organizations from joining it is actually not very different from IP policies used in many standards organizations like W3C in which many companies participate. @mkdolan who's actually a lawyer at LF can provide additional information. |
|
Okay, and let me interject a dumb question here, but can we just license the spec as Apache 2.0? Is there some middle ground we can easily reach here? I don't want to exclude contributors and I definitely don't want to have a project where someone can later claim IP infringement. |
|
@JustinCappos what everyone is concerned about is the scope of an open source software license (e.g. Apache-2.0 or CC-BY-4.0). The grant in those licenses is generally to the words contributed. The words of the spec are not code and not useful beyond a general understanding. An actual implementation of the specification requires transposing the specification elements into source code - and the open source license doesn't cover that transposing to source code. If the words of a specification describe a function that is covered by the claims of a patent, then everyone who builds or implements code from that spec does not receive an explicit license to that patent. The open source license was specifically to the text of the spec and not to alternative implementations. A specification license is intended to be used to allow the grants to carry over to the implementation (e.g. source code or in some cases hardware designs). Often the open source implementation of a specification will be under an open source license (a good thing) but if the spec is under the same open source software license, it's unlikely the grants would extend to alternative implementations. This often becomes an issue if anyone has to do an alternative implementation to an open source project. E.g. it was an issue when the Docker containers specification would be implemented in other OSes or using alternative codebases to runc. So for Open Container Initiative that specification switched to an OWFa specification license to accomodate for the same patent and copyright grants to flow through to implementations of the specification. |
|
Okay, thank you for your response, @mkdolan . I'm finally understanding this as more than "license X is bad, use Y", which is really helpful. So, @TheFoxAtWork is not the only person whose employer had concerns with the OpenSSF's license. Is there a license that can let these folks contribute without causing the problems you describe? Do we need to pick one problem or the other? (And I'll be curious to pick your brain after this about whether we need to make any changes for our JDF project Uptane) |
|
@JustinCappos the OWFa specification patent license OCI license is one that everyone adopting containers is using / relying on but it does require a bit more overhead to make it work. The W3C license would fall into the same category. Both of those require execution of agreements (e.g. akin to CLAs) before contributing. The CSL advantage is that it's setup for a GitHub contribution style. We're only aware of 1 company that would be interested in a project but otherwise objected to the CSL. I can see if there's a way to address the concern they have. |
|
@mkdolan Okay, thanks for looking into this. @TheFoxAtWork , are the OWFa or W3C licenses acceptable to Apple? I don't love requiring this step, but in practice the number of editors on the TUF, in-toto, and Uptane specifications is fairly small. Each project likely has less than 30. The codebases get all the love. :) Right now I'm the only author of the specification draft. I'll keep it that way until we reach a point where we have agreement because I assume it'll be easier to change this way. |
|
I do not know.
On Mon, Aug 28, 2023 at 10:34 PM Justin Cappos ***@***.***> wrote:
@mkdolan <https://github.com/mkdolan> Okay, thanks for looking into this.
@TheFoxAtWork <https://github.com/TheFoxAtWork> , are the OWFa or W3C
licenses acceptable to Apple? I don't love requiring this step, but in
practice the number of editors on the TUF, in-toto, and Uptane
specifications is fairly small. Each project likely has less than 30. The
codebases get all the love. :)
Right now I'm the only author of the specification draft. I'll keep it
that way until we reach a point where we have agreement because I assume
it'll be easier to change this way.
—
Reply to this email directly, view it on GitHub
<#191 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AH6IRKJ6Y4RC64S4UDWKDMTXXVIKRANCNFSM6AAAAAA3SXIE5M>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
FYI: We have moved SBOMit to Community Specification License 1.0. See: SBOMit/specification#14 So, this issue likely can be resolved. |
|
Considering the new license the spec has passed the review and this issue can be closed. |
|
I have completed the intake form. |
and others
SBOMit is seeking Sandbox Project Entry into the OpenSSF under the Security Tools WG.
In following the Sandbox Process - the SBOMit Maintainers are requesting the "one-time IP policy and license review with The Linux Foundation" as part of our sandbox application.
SBOMit Links
SBOMit is licensed as
CC-BY-4.0.The text was updated successfully, but these errors were encountered: