From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12240 invoked by alias); 31 Aug 2011 20:57:55 -0000 Received: (qmail 12195 invoked by uid 22791); 31 Aug 2011 20:57:53 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from out3.smtp.messagingengine.com (HELO out3.smtp.messagingengine.com) (66.111.4.27) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 31 Aug 2011 20:57:38 +0000 Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.messagingengine.com (Postfix) with ESMTP id 8849220E0C; Wed, 31 Aug 2011 16:57:37 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute4.internal (MEProxy); Wed, 31 Aug 2011 16:57:37 -0400 Received: from [158.147.67.90] (158-147-67-90.harris.com [158.147.67.90]) by mail.messagingengine.com (Postfix) with ESMTPSA id 334869606F4; Wed, 31 Aug 2011 16:57:37 -0400 (EDT) Message-ID: <4E5EA040.50001@cwilson.fastmail.fm> Date: Wed, 31 Aug 2011 20:57:00 -0000 From: Charles Wilson Reply-To: cgywin-licensing@cygwin.com User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Mailing List: CygWin-Apps , cygwin-licensing@cygwin.com Subject: Re: setup.exe opening page graphic References: <4E4AC4C2.5010307@etr-usa.com> <20110817154643.GE27614@calimero.vinschen.de> <4E4D7F19.9000707@etr-usa.com> <20110819153959.GA13266@calimero.vinschen.de> <4E4EE245.1080704@etr-usa.com> <20110820111627.GK13266@calimero.vinschen.de> <4E52A194.10308@etr-usa.com> <20110823141433.GA13527@calimero.vinschen.de> <20110830083138.GA9466@calimero.vinschen.de> <4E5D3F51.1040704@etr-usa.com> <20110831094206.GM30452@calimero.vinschen.de> <4E5E8202.7080004@etr-usa.com> In-Reply-To: <4E5E8202.7080004@etr-usa.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com X-SW-Source: 2011-08/txt/msg00241.txt.bz2 [moved to cygwin-licensing] On 8/31/2011 2:48 PM, Warren Young wrote: > Lacking any recommendation, I would have gone with some CC variant. I'll > look into FAL first now. > > If it turns out that I still like CC better, I'll check for GPL > compatibility. I can already rule out all the "Attribution" variants, > for the same reason 4-clause BSD is incompatible, right? The Creative Commons FAQ explicitly says that the CC licenses (all of them, except CC0) are incompatible with the GPL -- but they say that in the context of applying CC licenses to *software*. http://wiki.creativecommons.org/FAQ#Can_I_use_a_Creative_Commons_license_for_software.3F In fact, there ARE no non-attribution CC licenses anymore. They used to have some, back in the v1.0 days: http://creativecommons.org/licenses/sa/1.0/ but they are now "retired" and not recommended. OTOH, debian-legal says that CC-BY-SA v3.0 (*not* 2.0) is compatible with the DFSG...which is not, of course, the same as saying it is GPL compatible. http://wiki.debian.org/DFSGLicenses#Creative_Commons_Attribution_Share-Alike_.28CC-BY-SA.29_v3.0 http://www.gnu.org/licenses/license-list.html gnu.org says that neither CC-BY-2.0 nor CC-BY-SA-2.0 are GPL compatible. They make no statement concerning v3.0 of those licenses, but I rather suspect the 3.0 versions are also incompatible (-BY-). On this page: http://www.gnu.org/licenses/licenses.html FSF says "We don't take the position that artistic or entertainment works must be free, but if you want to make one free, we recommend the Free Art License (http://artlibre.org/licence/lalgb.html) The basic problem is, most "strong copyleft" licenses are mutually incompatible; this really can't be avoided because it's the part of each license that makes it "strong" that causes the difficulty; each license implements "strong" differently (usually by requiring derived works to carry *the same* license: you can't do that if two different licenses apply [*]). [*] Dual licensed software is different: it says you can accept one OR the other license: e.g. GPL OR MPL. GPL OR Proprietary. Not both-at-the-same-time. Old article, but contains quotes from FSF legal beagles: http://www.linux.com/archive/feed/119212 Short version: even the v3.0 CC-BY-SA licenses are probably incompatible with the GPL. You can get around that if your "derived work" -- software + art -- is a "mere aggregation". So, Q: is bundling an icon as a resource in an .exe "mere aggregation"? I think it CAN be -- in fact, I rely on it, in building cygicons.dll as a "mere aggregation" of several different icons with different licenses. OTOH, I dunno if you can plausibly make the argument that *the icon developed specifically for setup.exe*, when linked into that exe as a resource, it actually a "mere aggregation"! Anyway, Corinna's email above reports that the Red Hat lawyers say the 'free license' applied to the art, must "play nice along the GPL". If that means specifically "compatible with", then it rules out CC-BY-SA-2.0, CC-BY-2.0, and all other CC-BY-* (ND, NC) variants except CC0 It may -- probably does -- rule out CC-BY[-SA]-3.0 GPL itself is problematic, given the "preferred form for modification" of the source requirement. What IS that? I've looked over a ton of debates, incl. debian legal, and nobody seems to have a good answer. FAL -- is this really GPL compatible? http://en.wikipedia.org/wiki/Free_Art_License says "no" Section 5 of the FAL: 5. COMPATIBILITY A license is compatible with the Free Art License provided: it gives the right to copy, distribute, and modify copies of the work including for commercial purposes and [1]****without any other restrictions**** than those required by the respect of the other compatibility criteria; it [2]****ensures proper attribution of the work to its authors**** and access to previous versions of the work when possible; [3]****it recognizes the Free Art License as compatible (reciprocity);**** it requires that changes made to the work be subject to the same license or to a license which also meets these compatibility criteria. I think [1], [2], and [3] might be problems: [1] the GPL imposes a restriction that the FAL does not: GPL requires distribution of source code, while the FAL requires only "access to the previous version when possible" [2] isn't this like the advert clause in the original BSD? [3] the GPL certainly doesn't make any explicit reference to the the FAL, and the FSF doesn't seem to give any advisory opinion on whether the THEY recognize the FAL as compatible. But here's the elephant in the room: almost ALL discussions of license compatibility have to do with whether *software* under one license can be combined with *software* under another license. E.g. GPL apple + MIT apple. NOT GPL apple + FAL orange. So even though the FSF "recommends" the FAL for artistic works, they don't say how doing so would impact a derived work created by combining GPL software with FAL art. I think we're actually restricted to either: 1) the GPL -- but then there's that thorny "source" issue 2) a permissive license, like MIT/X, 3-clause BSD, CC0/public domain, etc. -- Chuck