> IANAL, TINLA, but: I don't see a reason to treat this any differently to any of the other 'possibly wrong' things we publish, such as code, documentation, and license information. So we should apply our regular common sense and review/monitoring processes for VEX information just like we do for code and releases, and then publishing a 'not affected' statement (perhaps with a "Disclaimer: this does not constitute a security advice, consult your own security expert" note) should be fine. In the end it is in everyone's interest that we share this information if we have it. Companies that apply our software in particularly-risky areas will still have to do their own due diligence, the same way they don't take our word for "it's Apache 2.0 licensed" but do additional checks there as well.
IANAL,TINLA as well. But.... I think when we publish code, it is covered by our licence which explicitly removes our responsibility and due to the way the licence is constructed in Apache 2.0, we are even protected against not only against mistakes but also against any patent litigations (as of Apache 2.0) - I think it was very, very smart from the ASF people to come up with the patent protection clause there - basically ASF keeping in check everyone who would like to sue ASF for it. It's a marvel of legal stuff if you ask me. But VEX is a different thing. At some point of time VEX might be expected as what "regulators" want. And it will become much more "official" then. And .... Do we actually have a licence for the VEX we publish? Is it published under the ASF 2.0 and do we have proper protection there ? I seriously doubt either of the two statements are true: a) I think we do not have any way to put any licence attached to VEX we publish - until we have some ways that we can attach a licence they are published "as is" b) I think Apache 2.0 licence does not cover responsibility for 3rd-party vulnerabilities that we might assume by publishing VEX Possibly we need an Apache 3.0 licence that covers it - but again IANAL. But I would never, ever tell anyone "our project is not vulnerable to this 3rd-party vulnerabilty" if I am acting in "official" capacity - representing my PMC and ASF. This is far too risky IMHO On Wed, Feb 5, 2025 at 1:22 PM Piotr P. Karwasz <pi...@mailing.copernik.eu> wrote: > Hi Gary, > > On 5.02.2025 13:09, Gary Gregory wrote: > > Why is this not done as an Apache project? > > It is an experiment. For now we will profit from the simplified release > procedure and low support expectations for this kind of projects. Rest > assured that if this becomes popular enough, we'll submit it to Apache > or OWASP CycloneDX. > > SBOMs is such a moving target that half of the projects that exist today > will reach EOL in one year. > > Piotr > > [1] https://oss-review-toolkit.org/ort/ > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: security-discuss-unsubscr...@community.apache.org > For additional commands, e-mail: > security-discuss-h...@community.apache.org > >
