Fwd: Fwd: Pull #14907

Tue Jul 1 01:43:22 PDT 2025

Hi John,

This is a mail describing the Elliott copyright problem.
In an other mail in this thread you said you will take care.

Probably just ignoring this is the best solution for this topic.

We should not take any PRs from this person, but someone like me could 
accidentally apply a PR from him if it is otherwise fine.

Hauke

-------- Forwarded Message --------
Subject: Re: Fwd: Pull #14907
Date: Tue, 4 Jun 2024 23:01:39 +0300
From: Stijn Tintel <stijn at linux-ipv6.be>
To: John Crispin <john at phrozen.org>, Hauke Mehrtens <hauke at hauke-m.de>, 
Jo-Philipp Wich <jo at mein.io>, Felix Fietkau <nbd at nbd.name>, Rafał 
Miłecki <zajec5 at gmail.com>

Hi,

By "GPL" in 1, do you mean "GPL-3.0"? If yes, does that mean we can 
include GPL-3.0 licensed code in openwrt.git without issue? I brought 
this up previously in #openwrt-adm and the only direct response was from 
rmilecki, suggesting we should contact lawyers. I agree with this, and 
in addition think we should have a vote.

Stijn

On 3/06/2024 13:26, John Crispin wrote:
> Hi,
>
> I spoke with Jow, we would propose the following approach
>
> 1) contact Oliver and ask if it is ok to use GPL and add Eliot as an 
> author, commit that change
>
> 2) in the following commit delete the script and tell them to 
> re-submit it in the maintainer repo
>
>     John
>
> On 03.06.24 09:17, Stijn Tintel wrote:
>>
>> Hi guys,
>>
>> Can we check with SFC if there's any chance if this guy files a DMCA 
>> claim it would actually result in a takedown? And if yes, is removing 
>> the script (scripts/kernel_bump.sh) enough to avoid that?
>>
>> Thanks,
>> Stijn
>>
>>
>>
>> -------- Forwarded Message --------
>> Subject:     Pull #14907
>> Date:     Sun, 2 Jun 2024 22:14:46 -0700
>> From:     Elliott Mitchell <ehem+openwrt at m5p.com>
>> To:     stijn at linux-ipv6.be
>>
>>
>>
>> I've been willing to re-license the content of pull #14907 from the
>> start. Issue is, in order to change the license I need to see some
>> benefit. You may be able to demand most developers change their license,
>> but that is due to their goal being strictly to get their name out.
>>
>> Trick is the situation with #14907 is rather different. With
>> 7b7f1702163, Olliver Schinagl has admitted a portion was copied from my
>> work. The portion may be small, but it is distinct enough to be
>> recognizable. Since the script is still GPL3+ the license on the script
>> in OpenWRT is wrong and this complicates matters.
>>
>> Since Git keeps full history, it is impossible to make that disappear
>> without rebasing and I'm pretty sure you don't want to do that. Yet
>> unless that is done I can issue a DMCA claim and take down the OpenWRT
>> repository.
>>
>> As a result changing the license is valuable enough to the OpenWRT
>> project so as to need negotiation.
>>
>> I'm not planning to ask for much, but right now you're offering me
>> absolutely nothing and simply demanding something. That is not how
>> negotiations work so this are stalled and I'm having to consider 
>> options.
>>
>>
>> I don't know any of the parameters you or Hauke Mehrtens have when doing
>> bisecting with Git.
>>
>> For your prespective, I tend to average using `git blame` about once
>> per day. I can go for several weeks without using it, but then one day
>> I'll use it several times. I've stated before I can run `git blame` on
>> a 2000-line file in FreeBSD's repository (which has 5x the number of
>> commits that OpenWRT has) in 10 seconds. Using --find-copies-harder on
>> OpenWRT's repository turns this into a 10 minute operation.
>>
>> Being more than an order of magnitude slower (not quite 2) really does
>> amount to breaking it.
>>
>> I've got no idea of how often `git bisect` is used. I've got no ideas
>> how many steps are involved in the typical session. I've got no idea
>> how long your usual test cycle takes. I suspect you're usually using at
>> least 5 steps, in which case encountering an unbuildable commit would
>> at worst involve a 5-20% slowdown. That isn't in the same league.
>>
>>
>> The script in #14907 already features a very potent countermeasure to
>> alleviate the issue of unbuildable commits on bisecting. The measure is
>> the script is designed for being run *once* for each kernel update.
>>
>> Rather than creating ~50 unbuildable commits/year to individually create
>> new configurations for each target, it is instead meant to do all 
>> devices
>> at once.
>>
>> I hope the reduction in unbuildable commits is sufficient, but 
>> creating a
>> script to do automated skipping of the unbuilable commits is possible.I
>> though would first need confidence time spent on such a script would not
>> be wasted. Right now I have none.
>>
>>
>> I am also concerned all of the concerns besides the license apply 
>> just as
>> well to #14713. Yet #14713 got in with those issues. It is
>> inappropriate to only demand things without also demanding them of
>> someone else doing similar things.
>>
>>
>> That is the situation. I'm quite willing to allow GPLv2, but that needs
>> negotiation and you're not negotiating.
>>
>>
>> -- 
>> (\___(\___(\______         --=> 8-) EHM <=-- ______/)___/)___/)
>>   \BS (    |ehem+sigmsg at m5p.com   PGP 87145445         |   ) /
>>    \_CS\   |  _____  -O #include <stddisclaimer.h> O- _____  |   /  _/
>> 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 
>> 8714\_|_/___/5445
>>
>>