Clint Adams <[email protected]> writes: > On Tue, May 06, 2025 at 08:36:50AM -0700, Russ Allbery wrote:
>> Well, first, I continue to object to the idea that a model can be >> DFSG-free if it's trained on non-DFSG-free data. I think that makes it >> definitionally non-free. (I have read Aigars's arguments to the >> contrary and do not find them at all persusasive.) > We appear to have plenty of pre-trained models, apparently trained on > non-DFSG-free data, in main right now, which strikes me as a violation > of our current "preferred form of modification" rule. Yes. That's the conclusion I've arrived at as well, after thinking about this over the course of the discussion, although I suppose it's also an argument that I'm thinking about this wrong and the current status quo is fine. This is not something we've paid a lot of attention to, and I think we've defaulted to accepting stuff that claims to be under DFSG licenses. That's certainly what I did with gnubg when I was maintaining it. I never really thought about this issue. That means there are some practical problems with changing the de facto policy. I think if any of the options in the current GR except Aigars's (and maybe Sam's?) passes, that would effectively be a change in our current policy, even if the current policy is not precisely intentional. Personally, I think it would bring us back closer in line with our principles, but that doesn't make the practical problems go away. Right now is a really bad time to change our policies. Whatever we do, I don't think we should try to change anything before the release. Shortly after the release would be a much better time, so that we have some time to sort this out. We have previously had a lot of problems with the implementation of changes (either via GR or via delegate interpretation) from a de facto licensing policy and had to thrash out the implications with multiple GRs [1], which isn't very fun. I'm not sure that we've thought through the implications of this proposed change yet, and I'm not sure that we have a plan. The plan doesn't need to be in the GR, but I'd feel more comfortable if we had a list of affected packages and some idea of what we're going to do with them. That means I'm not sure how to vote on the current proposal as it currently stands. I'd rather not have to do a second GR just to clarify the timing of implementation given the upcoming release. Maybe there's still time to address that directly? Also, there is absolutely nothing wrong with temporarily withdrawing a GR (or even having it fail because we didn't realize in previous debian-project discussions that we'd not fully worked through the idea yet), and then bringing it back up when we have an implementation plan. [1] https://www.debian.org/vote/2004/vote_003 https://www.debian.org/vote/2004/vote_004 https://www.debian.org/vote/2006/vote_007 https://www.debian.org/vote/2008/vote_003 -- Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
