<div dir="ltr"><div dir="ltr">On Sun, Jun 1, 2025 at 4:42 PM Azhar Momin <<a href="mailto:azhar-momin@outlook.com">azhar-momin@outlook.com</a>> wrote:</div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<p><br>
</p>
<div>On 6/1/25 1:14 AM, Ben Cooksley wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">On Sun, Jun 1, 2025 at 7:42 AM Albert Astals Cid
<<a href="mailto:aacid@kde.org" target="_blank">aacid@kde.org</a>> wrote:</div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">El
divendres, 30 de maig del 2025, a les 13:42:29 (Hora d’estiu
d’Europa <br>
central), Neal Gompa va escriure:<br>
> On Fri, May 30, 2025 at 7:36 AM Albert Astals Cid <<a href="mailto:aacid@kde.org" target="_blank">aacid@kde.org</a>>
wrote:<br>
> > El divendres, 30 de maig del 2025, a les 13:02:48
(Hora d’estiu d’Europa<br>
> > <br>
> > central), Neal Gompa va escriure:<br>
> > > On Fri, May 30, 2025 at 6:59 AM Albert Astals
Cid <<a href="mailto:aacid@kde.org" target="_blank">aacid@kde.org</a>>
wrote:<br>
> > > > El divendres, 30 de maig del 2025, a les
12:51:08 (Hora d’estiu<br>
> > > > d’Europa<br>
> > > > <br>
> > > > central), Neal Gompa va escriure:<br>
> > > > > On Fri, May 30, 2025 at 5:54 AM
Albert Astals Cid <<a href="mailto:aacid@kde.org" target="_blank">aacid@kde.org</a>> <br>
wrote:<br>
> > > > > > We are trying to move most of
the oss-fuzz related files to our<br>
> > > > > > reops<br>
> > > > > > instead of being in <a href="https://github.com/google/oss-fuzz/" rel="noreferrer" target="_blank">https://github.com/google/oss-fuzz/</a><br>
> > > > > > <br>
> > > > > > This will allow us to not have
to depend on other people to merge<br>
> > > > > > changes<br>
> > > > > > in them which sometimes
creates a bit of friction.<br>
> > > > > > <br>
> > > > > > The problem is that those
files are licenses under Apache 2 which<br>
> > > > > > is<br>
> > > > > > not<br>
> > > > > > mentioned in <a href="https://community.kde.org/Policies/Licensing_Policy" rel="noreferrer" target="_blank">https://community.kde.org/Policies/Licensing_Policy</a><br>
> > > > > > <br>
> > > > > > I would like to propose that
we add a point 18 to the policy that<br>
> > > > > > says<br>
> > > > > > <br>
> > > > > > 18. Files involved in the
oss-fuzz tooling can be licensed under<br>
> > > > > > the<br>
> > > > > > Apache<br>
> > > > > > License 2.0<br>
> > > > > > <br>
> > > > > > Comments?<br>
> > > > > > <br>
> > > > > > Please see<br>
> > > > > > <a href="https://invent.kde.org/frameworks/karchive/-/merge_requests/125/di" rel="noreferrer" target="_blank">https://invent.kde.org/frameworks/karchive/-/merge_requests/125/di</a><br>
> > > > > > ffs<br>
> > > > > > for one of the various places
we would use it.<br>
> > > > > <br>
> > > > > Why not maintain our own oss-fuzz
repo where all this is contained?<br>
> > > > > The karchive MR seems to pollute
the project with weird binary files<br>
> > > > > and such. I'd rather those not be
in the repo.<br>
> > > > <br>
> > > > That's orthogonal to the "Accepting
Apache 2" discussion, please let's<br>
> > > > focus on that.<br>
> > > <br>
> > > Honestly, it isn't. Because accepting that
stuff at all is kind of the<br>
> > > reason for this.<br>
> > > I am fine with accepting Apache-2.0 content
in a repo that's *all*<br>
> > > Apache-2.0 stuff.<br>
> > > From both the technical (this is goopy
garbage)<br>
> > <br>
> > Can you please not be so disrespectful with
something that is in no way<br>
> > garbage?<br>
> <br>
> The test case data files are *literally* garbage, so I
think it is accurate.<br>
> > > and licensing<br>
> > > (Apache-2.0 with no exception sucks)
perspective, I would only be okay<br>
> > > with it as its own repository.<br>
> > <br>
> > Sorry, but that is not going to happen, "tests"
for code need to be with<br>
> > the code, not somewhere else.<br>
> > <br>
> > Can you please explain me what problem you have
with a dozen of apt-get<br>
> > install/cmake/make lines being Apache-2.0?<br>
> > <br>
> > This is not going to pollute the rest of our code
because no one is going<br>
> > to need to reuse that for anything else.<br>
> <br>
> It's not the scripts, it's the garbage data files. <br>
<br>
The data files are new and if you read the merge request you
will see they are <br>
licensed under CC0-1.0<br>
<br>
> The scripts are not<br>
> even copyrightable in the first place and aren't worth
this discussion<br>
> about Apache-2.0. Moreover, they aren't even needed in
our environment<br>
> since we already have everything preinstalled in our CI
images.<br>
<br>
Our CI images are not useful/used in this scenario.<br>
</blockquote>
<div><br>
</div>
<div>Going a bit off topic here, but mind elaborating on
this? </div>
<div>Seems a bit weird to have to compile Qt + involved
Frameworks each time we want to do a oss-fuzz run -
especially when we already have built binaries (and it
doesn't look like they're doing anything too special when
compiling them either)</div>
</div>
</div>
</blockquote>
<p>There are a few reasons why we
can't reuse our existing binaries.<br>
<br>
First, OSS-Fuzz isolates its build and runtime environments. Since
the runtime environment can't access dependencies from the build
phase, everything must be statically linked into the fuzz targets.<br>
<br>
Second, OSS-Fuzz requires all code (including dependencies) to be
compiled with specific instrumentation flags (like
-fsanitize=address) for effective fuzzing. Their build environment
automatically applies the necessary compiler flags during
compilation. Pre-built binaries, even if statically linked, lack
this required instrumentation.</p></div></blockquote><div>Sounds like it is a separate platform.</div><div><br></div><div>What I was getting at though is if it is intended to deploy this sort of thing more widely, or we are intending to run it on a fairly regular basis, then we don't want to be compiling Qt and Frameworks everytime it runs.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<p></p>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> <br>
> The fuzzer code files basically force the project to be
LGPLv3+<br>
> licensed as distributed since the combined work of
LGPL-2.1-or-later +<br>
> Apache-2.0 means LGPL-3.0-or-later. I would prefer
asking Google OSPO<br>
> if they can be relicensed to something within our
policy instead. They<br>
> will likely grant it if we ask.<br>
<br>
If you want to ask them for a relicensing, sure, but as Ingo
mentioned your <br>
rationale does not hold water.<br>
<br>
Best Regards,<br>
Albert<br>
</blockquote>
<div><br>
</div>
<div>Cheers,</div>
<div>Ben</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
> <br>
> <br>
> <br>
> <br>
> --<br>
> 真実はいつも一つ！/ Always, there's only one truth!<br>
</blockquote>
</div>
</div>
</blockquote>
<br>
Best Regards,<br>
Azhar<br></div></blockquote><div><br></div><div>Regards,</div><div>Ben </div></div></div>