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. > > 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 > > > > > -- > 真実はいつも一つ！/ Always, there's only one truth!
