Re: fvwm(1): replace GPL-licensed code, fix bugs and add improvements

Stuart Henderson wrote:
> On 2026/08/03 17:12, David Uhden Collado wrote:
>> Stuart Henderson wrote:
>>> On 2026/08/02 23:23, David Uhden Collado wrote:
>>>> I separated this work because the provenance and independence of the
>>>> replacement implementations require more careful review than ordinary
>>>> bug fixes.
>>>
>>> What _is_ the provenance of the replacement code implementations?
>>>
>> Robert Nation, Tom LaStrange, Charles Hines, Brady Montz, Dan Espen, Steve
>> Robbins, Paul Smith, Jason Tibbitts, Dominik Vogt, Bob Woodside, Maciej
>> Stachowiak, Greg J. Badros, and Andrew T. Veliath are free to pursue the
>> matter through the proper legal channels if they genuinely believe that I
>> have infringed their copyright. Since none of them appears to be based in
>> Spain, they would also have to establish jurisdiction and pursue the
>> corresponding international proceedings.
>>
>> A claimant would still need to prove ownership of the specific code at
>> issue, identify the allegedly copied expression, demonstrate actual
>> infringement rather than mere functional similarity, and establish
>> measurable damages caused by my non-commercial work. Unsupported accusations
>> and speculative threats are not evidence.
>>
>> I have no intention of being intimidated into abandoning independently
>> rewritten code merely because somebody invokes the GPL without demonstrating
>> what was supposedly copied, who owns it, or what legally actionable harm
>> occurred. If anyone believes they have a valid claim, they can present it
>> formally and prove it.
> 
> Huh? Just asking where the code in your jumbo diff came from.
> I was hoping for something like "I wrote it myself" (although half
> expecting "some LLM wrote it").
> 
> This very defensive rules-lawyer-ish statement does not fill me
> with confidence that this is code which OpenBSD can incorporate.
> 
> 
> Also there's your earlier "In order for FVWM to remain in the base
> system, a fork must be created and maintained" - well no. It could also
> remain how it is now...
> 
Sorry if my response came across as a little harsh. To be honest, I was 
surprised that something as visible and important to users as the 
default window manager had been neglected for so long.

That is also why my patches are so large. After roughly two decades with 
very few substantial changes, the code accumulated a considerable amount 
of technical debt, and I have been trying to address much of it at once.

When I asked about the origin of the code, what I meant was whether the 
rewritten implementation was sufficiently different to be considered new 
code. If so, there should be no doubt that I am its author.

I originally rewrote it in 2025, but I changed the copyright year to 
2026 because I made additional changes after returning to this thread. I 
should probably use 2025-2026 instead.

It is true that the existing code could simply be left as it is, with 
small compatibility patches added whenever necessary to keep it building 
with modern compilers. However, if the goal is to fix the underlying 
bugs, as well as the copyright problem that remained even when FVWM was 
kept at version 2.2.5, then there are only a few realistic options.

One option is to update it by incorporating more GPL-licensed code, but 
that would conflict with the project's copyright and licensing policy. 
The other is to reimplement the necessary functionality independently 
while preserving compatibility with existing configurations. That is the 
approach I have taken.