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

[Ben Cooksley]

On Sun, Jun 1, 2025 at 4:42 PM Azhar Momin <azhar-momin at 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 <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.
>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20250601/377bc850/attachment.htm>