It would be great if JavaCC reproduced the input copyright/license
header in the output, but lacking that it seems reasonable to add
it. Although personally, I'd prefer that these derived files were
generated during the build and not checked into the source code
repository.
Markus KARG wrote on 12/15/18 3:26 AM:
That's
exactly the right question!
As
long as the input was done by a human, the machine only does
a technical translation of goods (but not a creation
of goods), so the output is just as eligible wrt.
copyright as the input. But here comes the problem and why I
mentioned particularly German law: If the input was not
eligible wrt. copyright (e. g. because it was just a few
mathematical symbols bot nothing "extraordinary" which is
"worth" getting protected by German law) then the output
also is not eligible wrt. copyright!
To
sum up: To be on the safe side in all countries, the
generated output must produce either exactly the same
license header than the input had (not any kind of standard),
or the tool must have a configurable option which
headers are to be generated so the caller can choose.
Otherwise there might always be some countries where the
generated output is just legally wrong.
-Markus
From: Bill Shannon
[mailto:bill.shannon@xxxxxxxxxx]
Sent: Samstag, 15. Dezember 2018 01:31
To: EE4J PMC Discussions; Markus KARG
Subject: Re: [ee4j-pmc] License guidance for
auto-generated files
I'm curious as
to what German law says about the copyright/license of the
output of a program for which the output depends on (is
derived from) input with a particular copyright/license.
It would seem weird/bad if simply running a
copyrighted/licensed document through a program produced
output that was not copyrighted/licensed. Wouldn't that be a
simple way to subvert the intent of the copyright/license?
There must be more to it than that.
Markus KARG wrote on 12/14/18 10:22 AM:
Ivar,
most
people from the US think they can export their legal
system to Europe. This simply does not work, as US
copyright laws and German copyright law is totally
different (e. g. in Germany you cannot see or buy IP but
you only can sell or buy licences to use IP). So as the EF
really cares about IP, they should ask the EF Europe / EF
Germany for their lawyer's opionions, instead of posting
individual non-official opinions.
As
I told you in JavaLand, in Germany rules are different
than in the US. A copyright can only be granted to humans,
and to do that, the human has to create a more or less exceptional
work by his own hands / brains (in particular,
things that the average engineer could invent
could not be copyrighted). So whatevery a machine
creates can definitively not be copyrighted! If a machine
applies a copyright into a machine-generated work, this
would be worthless (at best, it would be confusing;
at worst, it could be interpreted as an attempt of
fraud).
-Markus
Thanks Markus!
Do you by that say that it must NOT
be "1"? Or would that be ok as well?
Auto-generated
files (at least in Germany) do not fulfil any
criteria needed to be copyrighted at all, as
machines cannot hold copyright. Hence (at least in
Germany) it must be "2".
-Markus
I
would say "1" sounds like the reasonable answer,
but there may be some rules that I am not aware
of...
Hi,
The Jakarta EL Reference Implementation has a
JavaCC grammar for EL that
is licensed under the standard license:
EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0
This grammar is then used as an input to JavaCC
which generates a Java
parser for EL that consists of a handful of Java
files.
A question has arisen as to what license header
should be applied to the
generated files.
Is it:
1. The standard license?
2. No license (because they are auto-generated)?
3. Something else?
I'm expecting the answer to either be "1" or "1
or 2 but we recommend 1".
Currently, "1" is being used.
Thanks,
Mark
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password,
or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc
|
