LiGurOS duplicates _some_ Gentoo maintainer information. While the duplication of Gentoo metadata is "fine" as ::gentoo is distributed under the GPL-2, this came to my attention when I noticed that the numbers of packages I maintain differ between ::gentoo and the LiGurOS repository on repology. Some investigation has revealed that while _most_ of the packages I maintain retain my details in metadata.xml, app-antivirus/clamav has been "adopted" by the Liguros developers. I find this problematic: 1. LiGurOS should not include Gentoo maintainer information. I _do not_ maintain LiGurOS packages, and would prefer that my "blessing" is not implied by the metadata attached to a package in a repo that is _not the Gentoo Repo_. 2. If maintainer information is kept it seems disingenuous to strip _some_ maintainer information from _some_ packages in favour of LiGurOS maintainers. I assume that this action indicates that the LiGurOS maintainers actively maintain such packages downstream, but missing comments that reference Gentoo bugs (e.g _why_ >=rust-1.71 is required for clamav) would seem to indicate otherwise and may present a negative reputational impact to the Gentoo project that remains listed as a maintainer. 3. app-antivirus/clamav has been modified from what is distributed in the Gentoo repo and lists the Gentoo Antivirus Project as a maintainer. This is unacceptable; this is not the ebuild that we signed off on. At the very least, in the case where ebuilds or metadata are modified, LiGurOS _must not_ indicate that Gentoo supports, maintains, or provides this ebuild. See also: https://github.com/repology/repology-updater/issues/925 - request to drop maintainer info from Funtoo
(In reply to Matt Jolly from comment #0) > [...] > 2. If maintainer information is kept it seems disingenuous to strip _some_ > maintainer information from _some_ packages in favour of LiGurOS > maintainers. I assume that this action indicates that the LiGurOS > maintainers actively maintain such packages downstream, but missing comments > that reference Gentoo bugs (e.g _why_ >=rust-1.71 is required for clamav) > would seem to indicate otherwise and may present a negative reputational > impact to the Gentoo project that remains listed as a maintainer. > To be clear: have they stripped it, or just not updated it? What I can imagine happening is updating ebuilds but not keeping metadata.xml in sync, or similar?
(In reply to Sam James from comment #1) > To be clear: have they stripped it, or just not updated it? > > What I can imagine happening is updating ebuilds but not keeping > metadata.xml in sync, or similar? If it's just not being updated it's _at least_ two and a half years out of date - when mjo added themself as an independent maintainer: https://github.com/gentoo/gentoo/commit/02e0951baf6fb6c15e8ac77ed63bb8a5b60b9316 This is obsucured by the ~monthly "updating metadata" commits that seem to touch on app-antivirus/clamav which don't actually, you know, update any metadata: https://gitlab.com/liguros/liguros-repo/-/commits/develop/app-antivirus/clamav?ref_type=heads (Somewhat related question / side note: Is 'updating metadata' LiGurOS jargon for 'importing gentoo ebuilds'?) This hypothesis is actually supported by the local USE flags I added to clamav within the last few months _missing_ from the downstream metadata.xml, and the last commit touching the downstream metadata.xml being dated 2 May 2021, just before the package got an independent maintainer. They may only be _importing_ Gentoo metadata when a package is first added into their repo, rather than having a process to update metadata during whatever ETL operation they're doing to merge ::gentoo into their repo. That would be insane (but downstream repository management isn't really our can of worms). I suppose this may fall into 'stripping maintainers by virtue of not doing due diligence during package updates'; I am _somewhat_ concerned about the lack of local USE flags - I guess downstream QA doesn't check for that? I also note the presence of a non-GLEP-68 'origin' tag in metadata.xml which may indicate that the LiGurOS PM can track which packages come from Gentoo ("<origin>ports</origin>") without needing to retain Gentoo package maintainers or projects within their metadata.xml.
(In reply to Matt Jolly from comment #0) > [...] While the duplication of Gentoo metadata is "fine" as ::gentoo is > distributed under the GPL-2, [...] I agree, this is most certainly not a license issue. Maintainer information is a simple fact and therefore not even copyrightable, regardless of the license of the Gentoo repository. (Other parts of metadata may be copyrightable, e.g. longdescription.) License team is out of here, reassigning to trustees.
What I'm more interested about is this: -# Copyright 1999-2023 Gentoo Authors +# Copyright 2021-2023 Liguros Authors While I agree when they make even a single line change to an ebuild it becomes "theirs", but shouldn't the Gentoo copyright still be in place? Especially when the ebuilds are +95 % based on what comes from the Gentoo tree. So wouldn't this be right for the ebuilds they edit, when based on Gentoo ones: # Copyright 1999-2023 Gentoo Authors +# Copyright 2021-2023 Liguros Authors (Note: I have no idea, it's a legit question)
(In reply to Joonas Niilola from comment #4) > What I'm more interested about is this: > > -# Copyright 1999-2023 Gentoo Authors > +# Copyright 2021-2023 Liguros Authors > > While I agree when they make even a single line change to an ebuild it > becomes "theirs", but shouldn't the Gentoo copyright still be in place? > Especially when the ebuilds are +95 % based on what comes from the Gentoo > tree. You are right. Removing our copyright notice is a violation of the GPL (section 1 and 2 of GPL-2). Also, section 4: | 4. You may not copy, modify, sublicense, or distribute the Program | except as expressly provided under this License. Any attempt | otherwise to copy, modify, sublicense or distribute the Program is | void, and will automatically terminate your rights under this License. > So wouldn't this be right for the ebuilds they edit, when based on Gentoo > ones: > > # Copyright 1999-2023 Gentoo Authors > +# Copyright 2021-2023 Liguros Authors > > (Note: I have no idea, it's a legit question) Yes, this would be the correct approach.
