> Luis Villa wrote:
>> That should be "any scripts..." not just "scripts", no?
On Sun, Aug 5, 2012 at 7:30 AM, Bradley M. Kuhn <bkuhn(a)ebb.org>
> What is the point of adding 'any'?
Luis Villa wrote on 6 August:
In this context, "any" would typically be read to mean
the additional implication that "every" was not used because there
might not be such scripts. So long as no other part of the language
does not explicitly require such a script to exist (which is currently
the case), it is essentially the same as your proposed "all," because
both "any" and "all" permit the case where no such scripts exist.
I suggested this because Richard's original language, without either
"any" or "all", was ambiguous as to whether or not the scripts were
required, and my sense is that "any" (i.e., permitting there to be no
scripts existing) was what was intended.
What an amazing bit of lawyer's sophistry. RMS' clearly intended in
GPLv2 that scripts and instructions should be provided in all cases.
It's therefore obviously a mistake to harm the language by adding any,
and what your argument above indicates is that the lack of "any" in
GPLv2's wording means that the scripts need to be provided even if they
don't exist yet if "control[ling] compilation and installation" is
impossible without scripts.
As you well know, Luis, violators seek this kind of sophistry to seek to
withhold scripts. Such is a license violation in my view. We
definitely need good detail in copyleft-next's Corresponding Source
definition to make it more difficult for violators to even make these
arguments anymore and waste our time with their sophistry.
It's not that these silly arguments are right: even the
violator-defending lawyers usually know they're making specious
arguments. But, the company is usually quite wealthy and can afford to
pay lawyers to burn the time of the small non-profits that stand up to
defend copyleft. So, they waste our time by making up these silly
arguments to avoid complying. We need copyleft-next to make it harder
for violation-defending lawyers to do this.
I dislike "know-how" because it is insanely vague.
Is that *really* the only reason you're arguing against know-how?
Much better to list the things (like configuration files) that might
contain such know-how.
I think copyleft-next needs the biggest laundry list here we can think
of. What's the harm in doing both: having know-how in there along with
everything else that's already there?
I'm not necessarily against adding more verbs (especially in the
group (build, compile, etc.))
Great. My merge request (describe below) offers them back.
but I think the license is stronger when the drafters can clearly
explain and describe what each verb they put in means :)
The problem is, as you well know, is that violators pay their lawyers to
come up with silly mis-readings of the license merely to avoid
Anyway, I notice that since I last posted on this thread, there's been
lots of changes to the Corresponding Source source definition. I've got
a lot of issues and concerns, that I've put together into a single merge
Each change is done as single commits on this branch:
and I was careful not to refill the paragraph so that Fontana can
cherry-pick if he wants.