Re: [License-discuss] License incompatibility (was Re: Open source license chooser choosealicense.com) launched.
On Mon, Sep 2, 2013 at 4:16 AM, John Cowan co...@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. ...
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
[License-discuss] Red Hat compilation copyright RHEL contract (was Re: License incompatibility)
Al Foxone asked me on Friday at 13:58 (EDT) about: http://www.redhat.com/f/pdf/corp/RH-3573_284204_TM_Gd.pdf ... At the same time, the combined body of work that constitutes Red Hat® Enterprise Linux® is a collective work which has been organized by Red Hat, and Red Hat holds the copyright in that collective work. Red Hat then permits others to copy, modify and redistribute the collective work. To grant this permission Red Hat usually uses the GNU General Public License (“GPL”) version 2 and Red Hat’s own End User License Agreement. It's certainly possible to license all sorts of copyrights under GPL, since it's a copyright license. Red Hat has chosen, IMO rather oddly, to claim strongly a compilation copyright on putting together RHEL and Red Hat licenses that copyright under terms of GPL. It's certainly possible to do that. It's admittedly a strange behavior, and I've been asking Red Hat Legal for many years now to explain better why they're doing this and what they believe it's accomplishing. I've yet to receive a straight answer. Can anyone from Red Hat on the list tell us if Red Hat Legal's answer remains: No comment? 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? However, don't conflate RHEL's compilation copyright issue with the RHEL customer contract. They're mostly unrelated issues. The RHEL customer contract has long been discussed, and it amounts to a if you exercise your rights under GPL, your money is no good here arrangement. That's not an arrangement that I think is reasonable (and it's why I wouldn't be a RHEL customer myself), but there's nothing in GPL (that I'm aware of) that requires that one keep someone as a customer. Imagine if GPL *did* forbid firing your customers! It'd really hurt independent contractors who offer Free Software support. Also, I encourage discerning carefully between mundane GPL violations and Free Software license incompatibility. While both could be classified as GPL violations, Free Software license incompatibility usually refers to a situation where Free Software authors seek to DTRT but are confused when navigating contradictions between two Free Software licenses for works they seek to combine. At most, you could say Free Software license incompatibility is a specialized case of a potential copyleft violation. However, that's a technically accurate but misleading characterization, since the motives are usually non-commercial, coupled with a desire to DTRT for the community. -- -- bkuhn ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Red Hat compilation copyright RHEL contract (was Re: License incompatibility)
Bradley M. Kuhn scripsit: It's certainly possible to license all sorts of copyrights under GPL, since it's a copyright license. Red Hat has chosen, IMO rather oddly, to claim strongly a compilation copyright on putting together RHEL and Red Hat licenses that copyright under terms of GPL. I don't see where the oddity comes in. If we grant that the compilation which is RHEL required a creative spark in the selection (for the arrangement is mechanical), then it is a fit object of copyright. By licensing that selection of works under the GPL, Red Hat permits another party (call it Teal Hat) to create and publish a derivative work (that is, a collection based on RHEL but containing additional works, or fewer works, or both). But Teal Hat must *not* prevent a third party (call it Chartreuse Hat) from creating yet a third collective work based on Teal Hat's. That seems to me a worthy purpose, and one that the FSF should encourage. RHEL is not as such free software, but it is a free collection-of-software, as opposed to a proprietary collection of free software. The RHEL customer contract has long been discussed, and it amounts to a if you exercise your rights under GPL, your money is no good here arrangement. That's not an arrangement that I think is reasonable (and it's why I wouldn't be a RHEL customer myself), but there's nothing in GPL (that I'm aware of) that requires that one keep someone as a customer. Indeed, it seems very reasonable to me that Red Hat doesn't want a direct competitor as a customer. It probably has customers that are competitors in a more indirect sense: IBM comes to mind as a possibility. -- I Hope, Sir, that we are notJohn Cowan mutually Un-friended by thisco...@ccil.org Difference which hath happened http://www.ccil.org/~cowan betwixt us. --Thomas Fuller, Appeal of Injured Innocence (1659) ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
