[License-discuss] License incompatibility (was Re: Open source license chooser choosealicense.com) launched.

[Al Foxone]

On Mon, Sep 2, 2013 at 4:16 AM, John Cowan <cowan at mercury.ccil.org> wrote:

> Al Foxone scripsit:
>
>> I doubt that "Red Hat’s own End User License Agreement" is
>> 'compatible' (according to you) with the GPL'd components in that
>> combined work as whole. Anyway, that combined work as a whole must be
>> full of proclaimed 'incompatibly' licensed components (once again
>> according to you). How come that this is possible?
>
> See GPLv2 section 2, the penultimate paragraph:
>
> # [M]ere aggregation of another work not based on the Program with the
> # Program (or with a work based on the Program) on a volume of a storage
> # or distribution medium does not bring the other work under the scope
> # of this License.

Ultimately to me that just says that the intended scope of
quasi-automatic aggregation (pooling) of copyrights under the GPL
('compatibility' as somehow less strict requirement aside) is limited
to (non-private) derivative works only.

But Mr Kuhn seems to disagree and I don't understand his position.

>
> The corresponding paragraph of the GPLv3 is the final one of Section 5:
>
> # A compilation of a covered work with other separate and independent
> # works, which are not by their nature extensions of the covered work,
> # and which are not combined with it such as to form a larger program,

This is somewhat problematic because it uses undefined terms such as
"by their nature extensions" and "a larger program"***. But I've been
told that such ambiguities are interpreted against the drafter /
licensor and not against the licensee.

So once again it seems to it says that the scope of reciprocation is
limited to (non-private) derivative works only... but Mr Kuhn seems to
disagree (at least with respect to "compatibility") and I don't
understand his position.

***) e.g. http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ibm.zos.zappldev/zappldev_91.htm

"Program management model in Language Environment

Application programming on z/OS

...

Program management

Program management defines the program execution constructs of an
application, and the semantics associated with the integration of
various management components of such constructs.

Three entities, process, enclave, and thread, are at the core of the
Language Environment program management model.

Processes

The highest level component of the Language Environment program model
is the process. A process consists of at least one enclave and is
logically separate from other processes. Language Environment
generally does not allow language file sharing across enclaves nor
does it provide the ability to access collections of externally stored
data.

Enclaves

A key feature of the program management model is the enclave, a
collection of the routines that make up an application. The enclave is
the equivalent of any of the following:

A run unit, in COBOL
A program, consisting of a main C function and its sub-functions, in C and C++
A main procedure and all of its subroutines, in PL/I
A program and its subroutines, in Fortran.

In Language Environment, environment is normally a reference to the
runtime environment of HLLs at the enclave level. The enclave consists
of one main routine and zero or more subroutines. The main routine is
the first to execute in an enclave; all subsequent routines are named
as subroutines.

Threads

Each enclave consists of at least one thread, the basic instance of a
particular routine. ..."