Re: Notice of MIT License violation by Roberto Foglietta

Hi,

On Mon, Apr 27, 2026 at 08:51:37PM +0200, Roberto A. Foglietta wrote:
> > I guess if you delete the interactive banner message you need to provide
> > the same information by other means (documentation, etc.). In this case
> > the year range "2015-2019" does not exist anymore in that source file,
> > so it will be difficult for provide that original intact copyright string.
> 
> Nice catch!
> 
> /* jdupes (C) 2015-2018 Jody Bruchon <[email protected]>
>    Derived from fdupes (C) 1999-2018 Adrian Lopez
> 
> +:git-shell:jodybox:busybox> sw 97e3b97e6 | grep \(C\)
> -      printf("\nCopyright (C) 2015-2019 by Jody Bruchon
> <[email protected]>\n");
> 
> However, I have no clue if 2019 refers to the code or the additional
> printf, in the second case 2019 should go away with the printf
> otherwise 2019 should go on the top of the header. In this second case
> is Jody that missed to update the header or more likely as per my
> interpretation printf was part of the changed code/text in 2019. Most
> of the printf in that code NEED to be shortened down, anyway.

This is one of the reasons not to tamper with copyright notices - it's
much easier to leave them as is, so you don't have to second-guess or
be afraid of offending someone, or need a lawyer.

> > What's also bad they modified the code but didn't update the printed
> > version strings, so now there's two "jdupes" that report the same version
> > to user but have different code.
> 
> In fact, the printf has been deleted. Now there are two copies and one
> did not bother the user with a copyright message like all the other
> busybox applets do.
> 
> Please, be practical. Propose a patch if you can. Otherwise move to
> whatsapp groups to debate about stuff that has nothing to do with
> busybox.
> 
> I have been explicitly asked to bring back this m-list to a working
> state, make this easier, please.

Sorry, but I use and develop only mainline busybox, it's also what this
mailing list is about. I'm not going to propose patch for some random
github fork. I've checked some links you advertise here, and commented
them, but just to "burn ice" (as we say in Finland). I think you should
just follow the normal patch sending process.

It's also strange you ask people to move away; maybe you should instead
create a dedicated list for your great fork and security work.

A.