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

[Albert Astals Cid]

El diumenge, 1 de juny del 2025, a les 13:17:29 (Hora d’estiu d’Europa 
central), Ben Cooksley va escriure:
> 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.

We will not be running this, oss-fuzz/Google will be running it (as they do 
nowadays).

We are just moving most of the code to our repos to make it easier to change 
when needed.

Cheers,
  Albert

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