[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: bash completion script licensing



* 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.)

IMHO, the statement is somewhat incomplete.  If you only program to
standardized interfaces (for which multiple implementations exist,
including non-GPLed ones), your code won't be a derived work of the
library.  However, this might be just wishful thinking on my part
because I think that the FSF has lost its original vision in this
particular area, and that the claim that you can create derived works
merely by reference to the original work is an expansionist copyright
policy, not much different from other forms of copyright extension.


Reply to: