At 15:11 -0800 2005/03/10, Paul Eggert wrote:
>> I don't know what the default status is of works produced by X's use
>> of Y's copyrighted programs, but I rather suspect that such products
>> belong to X
>
>It depends on whether the produced works are "derivative works" of Y's
>copyrighted program
Paul Eggert wrote:
Sylvain Schmitz <[EMAIL PROTECTED]> writes:
It might have been true when these skeleton first appeared, but I
don't think it is any more, since both commercial and open source
implementations exist now.
OK, let's solve the problem. The first step: could you please come up
with a
[For some unknown reason, my email to Paul Eggert bounces.]
Paul Eggert's comment does not prove commonness :-), except perhaps in the
case of Yacc and related programs.
When I try to think about computer software in general, it always is the
principle that Paul Hilfinger indicates. If the progra
Paul Hilfinger <[EMAIL PROTECTED]> writes:
> Actually, I believe that the Berne convention gives no standing
> whatever to written copyright notices of this sort. Instead, if I
> produce a copyrightable work, that work is protected by copyright
> unless I take steps to make it otherwise.
Yes, th
> Hans Aberg <[EMAIL PROTECTED]> writes:
>
> > the output of a copyrighted program is rarely viewed as being
> > covered by the copyright of the program that made it.
>
> No, actually it's quite common. For example, if I run the traditional
> /usr/ccs/bin/yacc that is shipped with Solari
Hans Aberg <[EMAIL PROTECTED]> writes:
> the output of a copyrighted program is rarely viewed as being
> covered by the copyright of the program that made it.
No, actually it's quite common. For example, if I run the traditional
/usr/ccs/bin/yacc that is shipped with Solaris 9, the output file
y
Sylvain Schmitz <[EMAIL PROTECTED]> writes:
> It might have been true when these skeleton first appeared, but I
> don't think it is any more, since both commercial and open source
> implementations exist now.
OK, let's solve the problem. The first step: could you please come up
with a brief list
At 10:53 +0100 2005/03/10, Sylvain Schmitz wrote:
>Paul Hilfinger wrote:
>
>> In fact, this issue did get discussed when the GLR skeleton got
>> introduced, and the language (or lack of it) is, AIR, deliberate on
>> the part of the lead maintainers at the time. On consideration, I
>> would prefer
It would simplify if the supported Bison skeleton files were distributed
under the same copyright. The unsupported skeleton files, if any, should be
put in a special place, either in the distribution, or outside it, I think.
At 12:50 -0800 2005/03/09, Paul Hilfinger wrote:
>In fact, this issue did
>>> "Sylvain" == Sylvain Schmitz <[EMAIL PROTECTED]> writes:
> Paul Hilfinger wrote:
>> In fact, this issue did get discussed when the GLR skeleton got
>> introduced, and the language (or lack of it) is, AIR, deliberate on
>> the part of the lead maintainers at the time. On consideration, I
Paul Hilfinger wrote:
In fact, this issue did get discussed when the GLR skeleton got
introduced, and the language (or lack of it) is, AIR, deliberate on
the part of the lead maintainers at the time. On consideration, I
would prefer that the same terms apply to all skeletons as now apply
to the C
>>> "Paul" == Paul Hilfinger <[EMAIL PROTECTED]> writes:
> In fact, this issue did get discussed when the GLR skeleton got
> introduced, and the language (or lack of it) is, AIR, deliberate on
> the part of the lead maintainers at the time. On consideration, I
> would prefer that the same ter
In fact, this issue did get discussed when the GLR skeleton got
introduced, and the language (or lack of it) is, AIR, deliberate on
the part of the lead maintainers at the time. On consideration, I
would prefer that the same terms apply to all skeletons as now apply
to the C LALR(1) skeleton. I
This is most likely an error: The other skeleton files did not exist at the
time that stuff was written. Akim Demaille is resposnible for the C++ file
and Paul Hilfinger for the GLR file. They probably forgot to insert the
correct copyright. If so, this is a Bug-Bison issue.
At 14:28 +0100 2005/03
Hello,
I have read the "Conditions for Using Bison" on
page 3 of the Bison 2.0 documentation.
The first lines say:
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) p
15 matches
Mail list logo
