This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: setup.exe opening page graphic


[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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]