On Sun, Jun 1, 2025 at 4:42 PM Azhar Momin <azhar-mo...@outlook.com> wrote:
> > On 6/1/25 1:14 AM, Ben Cooksley wrote: > > On Sun, Jun 1, 2025 at 7:42 AM Albert Astals Cid <aa...@kde.org> wrote: > >> El divendres, 30 de maig del 2025, a les 13:42:29 (Hora d’estiu d’Europa >> central), Neal Gompa va escriure: >> > On Fri, May 30, 2025 at 7:36 AM Albert Astals Cid <aa...@kde.org> >> wrote: >> > > El divendres, 30 de maig del 2025, a les 13:02:48 (Hora d’estiu >> d’Europa >> > > >> > > central), Neal Gompa va escriure: >> > > > On Fri, May 30, 2025 at 6:59 AM Albert Astals Cid <aa...@kde.org> >> wrote: >> > > > > El divendres, 30 de maig del 2025, a les 12:51:08 (Hora d’estiu >> > > > > d’Europa >> > > > > >> > > > > central), Neal Gompa va escriure: >> > > > > > On Fri, May 30, 2025 at 5:54 AM Albert Astals Cid < >> aa...@kde.org> >> wrote: >> > > > > > > We are trying to move most of the oss-fuzz related files to >> our >> > > > > > > reops >> > > > > > > instead of being in https://github.com/google/oss-fuzz/ >> > > > > > > >> > > > > > > This will allow us to not have to depend on other people to >> merge >> > > > > > > changes >> > > > > > > in them which sometimes creates a bit of friction. >> > > > > > > >> > > > > > > The problem is that those files are licenses under Apache 2 >> which >> > > > > > > is >> > > > > > > not >> > > > > > > mentioned in >> https://community.kde.org/Policies/Licensing_Policy >> > > > > > > >> > > > > > > I would like to propose that we add a point 18 to the policy >> that >> > > > > > > says >> > > > > > > >> > > > > > > 18. Files involved in the oss-fuzz tooling can be licensed >> under >> > > > > > > the >> > > > > > > Apache >> > > > > > > License 2.0 >> > > > > > > >> > > > > > > Comments? >> > > > > > > >> > > > > > > Please see >> > > > > > > >> https://invent.kde.org/frameworks/karchive/-/merge_requests/125/di >> > > > > > > ffs >> > > > > > > for one of the various places we would use it. >> > > > > > >> > > > > > Why not maintain our own oss-fuzz repo where all this is >> contained? >> > > > > > The karchive MR seems to pollute the project with weird binary >> files >> > > > > > and such. I'd rather those not be in the repo. >> > > > > >> > > > > That's orthogonal to the "Accepting Apache 2" discussion, please >> let's >> > > > > focus on that. >> > > > >> > > > Honestly, it isn't. Because accepting that stuff at all is kind of >> the >> > > > reason for this. >> > > > I am fine with accepting Apache-2.0 content in a repo that's *all* >> > > > Apache-2.0 stuff. >> > > > From both the technical (this is goopy garbage) >> > > >> > > Can you please not be so disrespectful with something that is in no >> way >> > > garbage? >> > >> > The test case data files are *literally* garbage, so I think it is >> accurate. >> > > > and licensing >> > > > (Apache-2.0 with no exception sucks) perspective, I would only be >> okay >> > > > with it as its own repository. >> > > >> > > Sorry, but that is not going to happen, "tests" for code need to be >> with >> > > the code, not somewhere else. >> > > >> > > Can you please explain me what problem you have with a dozen of >> apt-get >> > > install/cmake/make lines being Apache-2.0? >> > > >> > > This is not going to pollute the rest of our code because no one is >> going >> > > to need to reuse that for anything else. >> > >> > It's not the scripts, it's the garbage data files. >> >> The data files are new and if you read the merge request you will see >> they are >> licensed under CC0-1.0 >> >> > The scripts are not >> > even copyrightable in the first place and aren't worth this discussion >> > about Apache-2.0. Moreover, they aren't even needed in our environment >> > since we already have everything preinstalled in our CI images. >> >> Our CI images are not useful/used in this scenario. >> > > Going a bit off topic here, but mind elaborating on this? > 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) > > There are a few reasons why we can't reuse our existing binaries. > > 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. > > 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. > Sounds like it is a separate platform. 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. > >> > >> > The fuzzer code files basically force the project to be LGPLv3+ >> > licensed as distributed since the combined work of LGPL-2.1-or-later + >> > Apache-2.0 means LGPL-3.0-or-later. I would prefer asking Google OSPO >> > if they can be relicensed to something within our policy instead. They >> > will likely grant it if we ask. >> >> If you want to ask them for a relicensing, sure, but as Ingo mentioned >> your >> rationale does not hold water. >> >> Best Regards, >> Albert >> > > Cheers, > Ben > > >> >> >> > >> > >> > >> > >> > -- >> > 真実はいつも一つ！/ Always, there's only one truth! >> > > Best Regards, > Azhar > Regards, Ben
