>> > From GPL2:
>>> "However, as a special exception, the source code distributed need not
>>> include anything that is normally distributed (in either source or
>>> binary form) with the major components (compiler, kernel, and so on)
>>> of the operating system on which the executable runs, unless that
>>> component itself accompanies the executable. "
>>>
>>> I think the last sentence forbids it. But maybe it depends whether
>>> *that component* refers back to *anything* or *major components*.
>>>
>> I think that this allows it!
>>
>> See:
>>
>> "<snip> need not include anything that is normally distributed in <snip>
>> binary form <snip> with the <snip> compiler unless that [compiler] itself
>> accompanies the executable"
>>
>
> Even though "compiler" is listed
> explicitly in the parentheses, the wording is clearly "major
> components of the operating system" and I don't think VC++ is a
> component of Windows.
I disagree. The wording clearly considers compiler as a major component.
Why else would there be this clarifying, exemplifying list in the
parentheses right the word major components? So as far as GPLv2 is
concerned compiler is a major component of the system. And indeed
without a compiler (or some such) it is not feasible to have a
system. Yes, M$ sells and distributes it separately but to me this
(what and how Microsoft distributes things) does not define what a system
is. Which of course begs the question who defines what a system is ;-)
>> I think it is very un-ambiguous that "that component" refers to "major
>> component" as the previous sentence defines it.
>
> The previous sentence talks about major components of operating system
> (note the plural) and it is not at all clear what exactly, "that
> component" refers to. "any such component" would be probably better.
I'm not sure about the implications of the plural, if any. However I do not
see what other component 'that' could refer to than those previously
mentioned in the paragraph? It says something ('anything') is usually
(normally) distributed with components and this something is given exemption
from the source code distribution requirement if the component it usually is
distributed with is not distributed.
The wording could have been better but still I do not see any real ambiquity
there.
> Still, we can stick to the assumption that it's the MSVC++.
Yes, let's stick to that.
>
>> To me *this* paragraph cannot be used to justify not allowing distributing
>> GPLv2 code pre-linked with VC++ std libraries.
>
> It depends on whether you consider the MSVC++ runtime library as a
> (separate) major component, which is not clear. If you do, then you
> can't distribute it *along with* the binaries, as clearly stated by
> the last sentence.
>
Indeed it depends on that. But I offer to you that we cannot regard
MSVC++ runtime library as component because the license does not offer
anything to suggest this interpretation. On the other hand it says
(clearly or less clearly, depending on my/your point of view)
that a compiler is a component and along with something is normally
distributed, that something presumably being in someway related to
the issue of running and/or compiling programs, otherwise there
would have been no point in mentioning it in the text. In view
of that I construe that a runtime library is that 'anything' referred
in the language of the license.
>
>> It seems to me that one of the reason to add language related to
>> this paragraph into GPLv3 was to clarify this. From that I conclude
>> that the the clarified paragraph in v3 also clarifies the intention
>> of the v2 in this respect.
>
> Maybe. From my point of view, it also lessens the restrictions.
I'm not disagreeing with that. I'm just saying that IMO v2 already
allows what we are discussing here.
Well, I think we are more or less on the same page here.
I'm my view Octave/Michael could just continue distributing VC++ linked
binaries and with good reason too.
br Kusti
------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
Octave-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/octave-dev
