For Approval: Open Vendor Public License (OVPL) and Open Vendor Lesser Public License (OVLPL)
peter.moldave at gesmer.com
peter.moldave at gesmer.com
Thu Jun 30 12:36:07 UTC 2005
Perhaps you are thinking about the exception to the Bison product:
http://www.gnu.org/software/bison/manual/html_mono/bison.html#Conditions
Conditions for Using Bison
As of Bison version 1.24, we have changed the distribution terms for
yyparse to permit using Bison's output in nonfree programs when Bison is
generating C code for LALR(1) parsers. Formerly, these parsers could be
used only in programs that were free software.
The other GNU programming tools, such as the GNU C compiler, have never
had such a requirement. They could always be used for nonfree software.
The reason Bison was different was not due to a special policy decision;
it resulted from applying the usual General Public License to all of the
Bison source code.
The output of the Bison utility?the Bison parser file?contains a
verbatim copy of a sizable piece of Bison, which is the code for the
yyparse function. (The actions from your grammar are inserted into this
function at one point, but the rest of the function is not changed.)
When we applied the GPL terms to the code for yyparse, the effect was to
restrict the use of Bison output to free software.
We didn't change the terms because of sympathy for people who want to
make software proprietary. Software should be free. But we concluded
that limiting Bison's use to free software was doing little to encourage
people to make other software free. So we decided to make the practical
conditions for using Bison match the practical conditions for using the
other GNU tools.
This exception applies only when Bison is generating C code for an
LALR(1) parser; otherwise, the GPL terms operate as usual. You can tell
whether the exception applies to your .c output file by inspecting it to
see whether it says "As a special exception, when this file is copied by
Bison into a Bison output file, you may use that output file without
restriction."
Peter M. Moldave
Gesmer Updegrove LLP
40 Broad Street
Boston, MA 02109
617-531-8340 (direct) 617-350-6800 (main number)
617-531-8390 (direct fax) 617-350-6878 (main fax)
peter.moldave at gesmer.com
http://www.gesmer.com
|---------+--------------------------->
| | Alex Bligh |
| | <alex at alex.org.u|
| | k> |
| | |
| | 06/30/2005 04:12|
| | AM |
| | Please respond |
| | to Alex Bligh |
| | |
|---------+--------------------------->
>--------------------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: Matthew Seth Flaschen <superm40 at comcast.net> |
| cc: License Discuss <license-discuss at opensource.org>, Alex Bligh <alex at alex.org.uk> |
| Subject: Re: For Approval: Open Vendor Public License (OVPL) and Open Vendor Lesser Public License (OVLPL) |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
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
____________________________________________
This message has been scanned for viruses and dangerous content by Thing2
running MailScanner, Sophos AV, and SpamAssassin.
Please use caution opening attachments delivered by e-mail and notify the
HelpDesk if you have questions or concerns about attachments you receive.
*****************************************
Electronic mail from Gesmer Updegrove LLP, 40 Broad Street, Boston, MA 02109. Voice: (617) 350-6800, Fax: (617) 350-6878. This communication is intended only for the use of the individual or entity named as the addressee. It may contain information which is privileged and/or confidential under applicable law. If you are not the intended recipient or such recipient's employee or agent, you are hereby notified that any dissemination, copy or disclosure of this communication is strictly prohibited. If you have received this communication in error, please immediately notify Christopher O'Sullivan at (617) 350-6800 and notify the sender by electronic mail. Please expunge this communication without making any copies. Thank you for your cooperation.
More information about the License-discuss
mailing list