Index | Thread | Search

From:
"Omar Polo" <op@omarpolo.com>
Subject:
Re: fvwm(1): replace GPL-licensed code, fix bugs and add improvements
To:
David Uhden Collado <daviduhden@gmail.com>
Cc:
tech@openbsd.org
Date:
Wed, 29 Oct 2025 16:36:50 +0100

Download raw body.

Thread
David Uhden Collado <daviduhden@gmail.com> wrote:
> Hello everyone,
> 
> I have attached a patch to this email that focuses on three major areas:
> 
> First, FvwmRearrange has been completely rewritten to provide clearer 
> behavior, and the documentation has been updated. It now cleanly 
> separates tile and cascade modes, tightens argument semantics, and 
> behaves predictably with multiple monitors and large virtual desktops.
> 
> Second, the core and modules have transitioned to a safer 
> infrastructure. The legacy temp-file IPC has been replaced with pipes 
> and waitpid(). The key/placement logic is more robust, and the 
> widespread string/memory handling has been tightened (snprintf/strlcpy 
> and better bounds/NULL checks). Along the way, long-standing correctness 
> issues have been fixed, such as maximizing across virtual pages, 
> destroying live menus, and occasional PipeRead hangs.
> 
> Third, licensing is clarified across the tree. The COPYRIGHT file has 
> been updated, and GPL-licensed remnants have been replaced with 
> components under the ISC/OpenBSD license, including the new rearrange 
> code and color utilities. This aligns the codebase with the project's 
> stated copyright policy.
> 
> These changes aim to preserve backward compatibility with existing 
> configurations. I tested it on amd64, but not thoroughly. Further 
> testing, as well as compiling and testing on other platforms, is needed.
> 
> Best regards,

woah, that's quite the diff!

To be fair, and I'm saying it as a fairly new fvwm3 user, I'm not sure
how much interest there is to revamp the old version in xenocara, which
basically means forking it at this point.

it's certainly a lot of work just to get rid of some GPL'd code that has
been there for ages.

anyway, I feel like the diff is a bit too big to be handled in just one
go, especially since you're both improving and moving stuff around.

if you really have interest in working on this, I'd suggest to try to
split it in manegeable pieces, so that it can be reviewed and improve
the chances of it getting into the tree.

especially for the licensing part, which needs quite a throughful
inspection.

(these are just my two cents)


Thanks,
Omar Polo