For Approval: Open Vendor Public License (OVPL) and Open Vendor Lesser Public License (OVLPL)

[Alex Bligh]

I've been looking around for how this was solved before.

I remember reading a license which has a specific carve-out where the
licensed product is a compiler, to ensure that object code produced
by the compiler wasn't subject to the terms of the license, even though
(because of the way compilers work) it technically included bits of
the compiler's object code (i.e. small chunks of instructions).

I'm pretty sure it was in an OSI approved license, but I can't find
the thing.

Any ideas?

Alex

--On 05 June 2005 20:06 -0400 Matthew Seth Flaschen <superm40 at comcast.net> 
wrote:

> Alex Bligh wrote:
>
>> Matthew,
>>
>> --On 03 June 2005 22:05 +0000 Matthew Seth Flaschen
>> <superm40 at comcast.net> wrote:
>>
>>> The license would then imply that you couldn't distribute an
>>> OpenVendor-licensed compiler along with third-party software compiled
>>> with it, unless the software compiled with it is treated as a
>>> Modification, forcing OpenVendor licensing.
>>
>>
>> I understand the problem, but I am not sure yours is the correct way of
>> solving it. If this is a problem that needs to be solved (see below),
>> then
>> a better way, I think, would be to handle the situation by exception
>> (i.e.
>> widely define Other Software, then make an exception for software
>> which is
>> purely compiler output. One of the existing OSI licenses does this,
>> though
>> I don't seem to be able to find it. I would suggest something like
>> adding to the end of 1.6 "excepting, in the case of Covered Software
>> whose purpose is to be used in Executable Form as a compiler or other
>> software development tool designed to transform Source Code into
>> Executable
>> form, use of the Covered Software solely for that purpose".
>>
>> I think there is also a philosophical difficulty here. If you look at
>> (say) a C compiler, as standard it will link in certain functions to
>> the resultant .o file. I'm not talking about standard libraries here,
>> I am talking about 'builtins'. Clearly they are covered by the terms
>> of the license (indeed, intentionally). You would have to get down
>> to something pretty basic (assembler, perhaps), before the Covered
>> Software added nothing to output - i.e. was purely translatory.
>>
>> However, I am unsure that in practice this is going to be a problem. What
>> you are worried about is the new file being covered by "D" thus
>> becoming a
>> Modification. Unless the new file is distributed or otherwise made
>> available *WITH* the Original Software, it won't be a modification in any
>> case. If they are not distributed together, then the that fact that
>> another
>> piece of software distributed with the Covered Software which happens
>> to be
>> compiled with the Covered Software is then outside the scope of a Larger
>> Work does not, without more, seem to create a licensing problem. I
>> suppose
>> where this would bite is if someone like Redhat were to distribute a
>> compiler under OVPL in the same distribution as something compiled
>> with it,
>> but under a different license. Then Redhat would be reliant on being a
>> licensee under the OVPL in order to be able to distribute, which would
>> bring the other work into the scope of the Modifications section, which
>> I can see might create problems.
>>
>> I'll think some more on this corner case and see if I can remember how
>> it was solved before.
>>
>> Alex
>>
> I'm willing to cooperate on that, but there should be some solution
>
>



Alex