search

CERTCC / SSVC

Stakeholder-Specific Vulnerability Categorization
https://certcc.github.io/SSVC/
Other
116 stars 32 forks source link

The license of the documentation is impractical for any use in any open source software, and other license issues #550

Open pombredanne opened 3 months ago

pombredanne commented 3 months ago

Describe the bug The license of the documentation is impractical for any use in any open source software. Could you work out something that makes it possible to reuse and include in an open source software package?

With open source, I cannot control commercial use or not.

It would be nice to consider a proper open source license for the docs and text such as a CC-BY or CC-BY-SA

Some other related license issues:

You have an excellent framework, but the licensing makes it's usage impossible for open source.

pombredanne commented 3 months ago

Also is the code in https://certcc.github.io/SSVC/ssvc-calc/ MIT or is this code under the proprietary license?

pombredanne commented 3 weeks ago

@ahouseholder gentle ping.

ahouseholder commented 3 weeks ago

Hi, I'm working this through our legal folks, so I don't have a definitive answer at the moment. However, I can say that our intent was that:

Just to confirm that I'm understanding the concern correctly, I think you're reacting to the documentation portion https://github.com/CERTCC/SSVC/blob/19f72a50bd2b142484233564e114bd636148dba0/LICENSE#L57-L61 and highlighting that it only allows the documentation to be included downstream without modification (or requires permission to modify). Is that accurate?

(any references to LICENSE.md are intended to mean https://github.com/CERTCC/SSVC/blob/main/LICENSE, that's just a typo in the boilerplate)

pombredanne commented 2 weeks ago

@ahouseholder Thank you for chiming in! I guess the "F" in "License" is for "Fun" ;)

You wrote:

Just to confirm that I'm understanding the concern correctly, I think you're reacting to the documentation portion and highlighting that it only allows the documentation to be included downstream without modification (or requires permission to modify). Is that accurate?

Yes this is accurate. This license statement is incompatible with an open source licensing. This would not be a problem if there were not data definitions (and possibly JS calculator code) in the documentation and that that would be necessarily copied when doing an implementation, and likely modified along the way.

And also this:

Permission is required for any other external and/or commercial use

External and commercial is pretty much the whole wild world.

I am assuming your concern is to keep the integrity of the SSVC specification and avoid derived work that would be still pretend to be SSVC? I am sure there are proper open source licenses that would support this. For code, the Apache has these effects for instance AFAIK.

You may want to direct your legal team to check this license https://github.com/CommunitySpecification/Community_Specification by @mkdolan from the Linux Foundation. This is a sensible and comprehensive license designed for specifications. It is used for specs in the space such as SPDX.

ahouseholder commented 2 weeks ago

I am assuming your concern is to keep the integrity of the SSVC specification and avoid derived work that would be still pretend to be SSVC? I am sure there are proper open source licenses that would support this. For code, the Apache has these effects for instance AFAIK.

It's actually a bit of a historical artifact due to the content of this repository having arrived via two distinct paths:

  1. The original SSVC docs we released as PDFs https://insights.sei.cmu.edu/library/prioritizing-vulnerability-response-a-stakeholder-specific-vulnerability-categorization-version-20/ carried the SEI's standard copyright blurb which is the origin of the "Permission is required for any other external and/or commercial use" line. I think the idea there is that "You can redistribute the PDF in its entirety but don't chop it up."
  2. The code came from the MIT license side of things, which we intended to be reusable subject to the MIT license requiring the copyright acknowledgement.

There's obviously a different set of assumptions behind those two paths, which is how we got here.

Thanks for your comments though. Our legal folks are aware of this thread and hopefully we'll come to some sort of resolution soon.

pombredanne commented 2 weeks ago

@ahouseholder re:https://github.com/CERTCC/SSVC/issues/550#issuecomment-2176928708

Thanks for your comments though. Our legal folks are aware of this thread and hopefully we'll come to some sort of resolution soon.

Thank you. You and SSVC are awesome.