* Matthew Johnson:
On Fri Jan 02 19:50, Mike Hommey wrote:
As the GPL and CDDL are incompatible, as GPL code has some strange
interactions with other code (library linkage, etc.), and as I'm not
sure how sourced bash scripts are supposed to be considered in this
context, I wonder if having such a CDDL bash script would be
problematic license-wise.
There would be no problem with a CDDL bash script per-se, any more than
there would be with a CDDL jpeg or a GPL word document. I suppose you
could argue that since it is modifying the behaviour of one of bash's
built-in functions it counts under the (already dubious) GPL linkage
clause, but I think it would be a stretch.
The usual argument is that the program is a derived work of the
programming environment; it's not based on linking per se.
I don't know if this argument has been made for shell scripts
(especially those containing bashisms). The FSF position is reflected
in this statement:
| If a programming language interpreter is released under the GPL, does
| that mean programs written to be interpreted by it must be under
| GPL-compatible licenses?
|
| When the interpreter just interprets a language, the answer is
| no. The interpreted program, to the interpreter, is just data; a
| free software license like the GPL, based on copyright law, cannot
| limit what data you use the interpreter on. You can run it on any
| data (interpreted program), any way you like, and there are no
| requirements about licensing that data to anyone.
|
| However, when the interpreter is extended to provide “bindings”
| to other facilities (often, but not necessarily, libraries), the
| interpreted program is effectively linked to the facilities it
| uses through these bindings. So if these facilities are released
| under the GPL, the interpreted program that uses them must be
| released in a GPL-compatible way. The JNI or Java Native Interface
| is an example of such a binding mechanism; libraries that are
| accessed in this way are linked dynamically with the Java programs
| that call them. These libraries are also linked with the
| interpreter. If the interpreter is linked statically with these
| libraries, or if it is designed to link dynamically with these
| specific libraries, then it too needs to be released in a
| GPL-compatible way.
|
| Another similar and very common case is to provide libraries with
| the interpreter which are themselves interpreted. For instance,
| Perl comes with many Perl modules, and a Java implementation comes
| with many Java classes. These libraries and the programs that call
| them are always dynamically linked together.
|
| A consequence is that if you choose to use GPL'd Perl modules or
| Java classes in your program, you must release the program in a
| GPL-compatible way, regardless of the license used in the Perl or
| Java interpreter that the combined Perl or Java program will run
| on.
<http://www.fsf.org/licensing/licenses/gpl-faq.html#IfInterpreterIsGPL>
(For particular interpreters, the copyright holder might argue that
all non-trivial scripts are derived works of the interpret, so this is
less permissive than it seems at first glance.)