Licensing Policy: Accepting Apache 2 for oss-fuzz related files

[Azhar Momin]

On 6/1/25 1:14 AM, Ben Cooksley wrote:
> On Sun, Jun 1, 2025 at 7:42 AM Albert Astals Cid <aacid at 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
>     <aacid at 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
>     <aacid at 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
>     <aacid at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20250601/c8671eb1/attachment-0001.htm>