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.
>
> 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
