Re: Let's stop feeding the NVidia cuckoo
Matthew Garrett <mgarrett@chiark.greenend.org.uk> writes:
> Jeremy Hankins <nowan@nowan.org> wrote:
>> First of all (and most telling, to my view) there's are a lot of
>> "reasonably" in this definition. I think you're using these to paper
>> over a lot of difficult cases. It doesn't work very well for our
>> purposes because different people will always have different ideas of
>> what's reasonable. This is as opposed to the "preferred form" which in
>> the end depends on matters of fact (e.g., does the author *actually*
>> prefer that form?)
>
> Indeed. It's not intended to be a formal definition - it's how I feel we
> should treat source code. I don't claim that phrasing it in a useful way
> would be easy. However, I don't believe that we should be deciding such
> matters on the basis of ease of phrasing.
It doesn't need to be formal, but it does need to be useful. We want a
guideline that's not going to be subject (too much) to the whims of the
interpreter (d-l, mostly). Nothing you've suggested so far is either of
those. Frankly, if you continue to say that the definition we use is
bad without suggesting something better, I'm not going to be too
interested in listening to you.
>> Secondly, it seems that your definition is going to require extensive
>> documentation in cases where the knowledge required to modify the code
>> is specialized or arcane. Does a kernel patch require a treatise on
>> kernel internals to accompany the patch? For that matter, does it
>> require a copy of the kernel? After all, you can't very effectively
>> modify the patch without the kernel as well.
>
> If it's impractical for anyone other than the author to modify the code,
> then I think it's insufficiently modifiable. If the information needed
> to modify the code is either fairly widely known or fairly easily
> learned, then that doesn't apply.
So we have yet more nebulous wiggle in your definition: an exception for
cases where the necessary bits to modify the work are "fairly" widely
known or "fairly" easily learned.
What about something to interface with a unique protocol only used in a
particular industry? The protocol may be available, but no one outside
of the industry has even heard of it. You may even have to pay to get a
copy of the protocol specification.
> I don't think the mutt case is desperately important as far as free
> software is concerned, but if you weren't able to do that it would imply
> that you couldn't do many other things. It's reasonable to want to be
> able to incorporate code from an MTA into an MUA - it's not reasonable
> to expect to be able to do so for any given pair of them.
Why not? What guideline are you using to decide that the ascii art dog
of mutt code is reasonable, but moving code between works may not be?
>> I'm afraid I simply disagree here. I'm not willing to go to an
>> author and say "If you write in machine code your work can never be
>> Free."
>
> If nobody other than the author can modify a work, in what way is it
> free? We'd laugh at a license that attempted to claim that. Making it
> impossible through technical means should be equally non-free, even if
> that wasn't the author's intent.
Let's be practical here. How many cases are you talking about? Mostly,
if the author can do it and I can't it's because of skill level --
assuming I have access to everything the author does, as the "preferred
form" definition requires. If a truly egregious case came up and it was
clear to most folks that the author was either insane or malicious --
*and* a DD wanted to package it -- there'd be a lot of discussion of the
issue, and we'd resolve it somehow. But it would be an informed
discussion, knowing the particulars of the case, and the author might
even have a chance to chime in in his defense.
--
Jeremy Hankins <nowan@nowan.org>
PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
Reply to: