While running a little script I whipped up to show all packages with licenses not on a list I OKed, I noticed that every X.org 7.0 package has it's own license. On a hunch, I ran `fdupes /usr/portage/licenses/`. My suspicions were confirmed and I really think that the maintainers should also run it. fdupes does byte-for-byte comparison, so the amount of duplication will probably appear much higher when checked using something which ignores differing whitespace. If there's any way I can help out with this, just ask.
Yes, noticed this a while ago, too. This thwarts any approach to make use of the LICENSE variable to implement proper license management, is therefore quite annoying and imho not acceptable.
It's very difficult to created a unified license for the X packages. A vast majority of the packages do not have proper licensing files, and so many licenses are derived from the code. Now that things have settled down upstream, it might be safe to merge some of these licenses (although how to name them is another issue). However, we can only merge exact duplicates (content-wise) as far as I know, even if only the copyrights differ. (In reply to comment #1) > Yes, noticed this a while ago, too. This thwarts any approach to make use of > the LICENSE variable to implement proper license management, is therefore quite > annoying and imho not acceptable. > This point did not come up (iirc) in the discussion about these licenses on the gentoo-dev list several months ago.
I definitely agree that naming will be a problem. On the plus side, fdupes says that there are at least a dozen of them in the largest of the byte-for-byte identical groupings as well as 4 or 5 additional groups of 2-4 identical licenses, and I didn't try a whitespace-insensitive comparison.
With around 300 packages in modular X, it's my opinion that the additional maintenance burden of trying to deal with some of them being identical and some not is not worth the time involved for something that very few people care about.
Closing, see comment #4.
You're aware that this breaks GLEP 23, which is a GLEP that has been accepted by the council and is being implemented?
Reopenning. See comment #6
(In reply to comment #6) > You're aware that this breaks GLEP 23, which is a GLEP that has been accepted > by the council and is being implemented? > Incorrect, the GLEP has not been modified since 2004, accoring to GLEP 28, GLEP 23 is now deferred.
(In reply to comment #8) > (In reply to comment #6) > > You're aware that this breaks GLEP 23, which is a GLEP that has been accepted > > by the council and is being implemented? > > Incorrect, the GLEP has not been modified since 2004, accoring to GLEP 28, GLEP > 23 is now deferred. Which part of "GLEP 23 has been accepted by the council and is being implemented" is untrue?
If a Draft GLEP is inactive for more than 60 days or an Accepted GLEP is inactive for more than six months, then it would be marked as "deferred" on the main GLEP page [1]. Inactivity is defined simply as the GLEP author has not contacted the GLEP editors with either an update or a request to submit the GLEP for approval (in the case of a Draft GLEP) or a request that the GLEP be marked final (in the case of an Accepted GLEP). So when have any of these things happened?
Your comments don't have any relevance to your claim that my initial claim is "incorrect". I repeat: Which part of "GLEP 23 has been accepted by the council and is being implemented" is untrue?
I don't see how this violates GLEP 23. Could you point out the section it violates?
*yawn* instead of bitching over details why not have someone post a patch to resolve the issue Donnie has enough on his plate without having to worry over something stupid like LICENSE; if you care enough to complain, you care enough to fix it
If nobody else has volunteered by the time I can find or make some time, I'll make a patch. What options should I be using when generating a patch against the portage tree?
Just make sure it's a unified patch (-u). I use the options 'Naur', but if you're patching the license directory 'r' (recursive) and 'a' (forcibly compare things that don't look like text) will likely be pointless.
(In reply to comment #14) > If nobody else has volunteered by the time I can find or make some time, I'll > make a patch. What options should I be using when generating a patch against > the portage tree? Instead of wasting time on this, I'd love to see a patch that changes those ebuilds' DESCRIPTION to something else that "X.org ${PN} application" (such as the NAME section from 'man ${PN}' output. That could be actually useful for many more users than shuffling with licenses that noone cares about.
(In reply to comment #14) > If nobody else has volunteered by the time I can find or make some time, I'll > make a patch. What options should I be using when generating a patch against > the portage tree? Please reopen if/when this is supplied. I'm closing as WONTFIX because we won't be fixing this, but we are still open to patches. Thanks! (In reply to comment #16) > Instead of wasting time on this, I'd love to see a patch that changes those > ebuilds' DESCRIPTION to something else that "X.org ${PN} application" (such as > the NAME section from 'man ${PN}' output. That could be actually useful for > many more users than shuffling with licenses that noone cares about. I actually did this a few weeks ago, for all the ebuilds with accompanying man pages.
Sorry I didn't carry through with it promptly. Shortly after saying I would, Murphy's law kicked in and my life has been so busy I've had to almost cut contact with the general open-source world in order to keep up. I'll tag the e-mail notification of your message as TODO and get around to it when my life is again sane.
*** Bug 181377 has been marked as a duplicate of this bug. ***
*** Bug 258033 has been marked as a duplicate of this bug. ***
