First of all, thank you for your thoughts! This is exactly what I'd hoped for. :) On 04/20/2010 10:50 AM, inode0 wrote: > Thanks for this explanation. I see points 2 and 3 above as compelling > reasons in support of the selected license. I'm sort of in the > position of being completely satisfied with this if reason 1 above was > fallout from reasons 2 and 3. If reason 1 was the starting point, I'm > still wondering why there would be a default preference for a > non-copyleft license. Yeah, the ordering there is closer to "3, 2, 1". Also, there was the conscious thought that we wanted to: * avoid issues of contention around default licensing (e.g. "How _dare_ you use this licensing! I didn't realize that would happen?!?") * motivate individuals who felt the default licensing was too broad to explicitly choose something more ... finer grained. I certainly think it is easier to nudge people in that direction than to have a more restrictive license as the unlicensed default. * ensure the greatest possible flexibility for future actions and use cases >> When we looked at content licensing, there was a much smaller set of >> licenses to consider. We wanted to use a license that was permissive and >> as compatible as possible with other content licensing. That narrowed it >> down pretty quickly to the Creative Commons licenses, and given the fact >> that the wiki had already switched to CC-BY-SA, we decided to go with >> it. The waiver of clause 4d was done when Red Hat Legal determined it >> had the potential, if enacted, to make the work non-free. > > Isn't CC-BY-SA copyleft, not permissive, and incompatible with the GPL? I'm going to defer to Richard on the last point, but I can honestly say, the fact that CC-BY-SA is copyleft wasn't really a deciding factor. The biggest factor for me was that it was already in use for much of Fedora's content (e.g. art, wiki), and was already reasonably accepted (and presumably, understood). It was never "okay, we want MIT, what is the content version of MIT". We wanted to try to address concerns around license proliferation (don't make a new license), compatibility (ensure that our choice is as compatible as possible with what is abundantly in use), and acceptability (will people be able to do what they need to do with the licensing terms, with the understanding that we may not be able to predict the range of use cases). For code, those boundaries are far better understood than content. > One thing I've never been completely clear about is where the line is > drawn in Fedora regarding what is code and what is content so I'm not > sure if there are edge cases where the CC-BY-SA being incompatible > with the GPL (assuming it is) would be an inconvenience. Well, we tried to define that in the FPCA, when we say "'Content' means any copyrightable material that is not Code", because it is simpler to define what is Code and say that everything else is Content, with the reserved right of the Fedora Board to classify things that may be less clear cut. > While not as common, something like the GNU All-Permissive License > seems like it might match your stated goals better in this case and is > really quite similar in spirit to the MIT License selected for code. > It isn't really a general content license but is intended for what is > commonly understood to be documentation included with code. Eh. I'm not sure it is. I do think that the common areas of content are worth targeting here, and trying to deal with in a focused manner. I posit that those areas are: * documentation * wiki pages * artwork * music I suspect that if pressed, the FSF would agree that the All-Permissive license (which in Fedora licensing lingo would be "Copyright only") is not necessarily a good fit for those items, preferring the FDL for docs and i dunno what for the rest. After all, we're not proposing to go with Public Domain (or Public Domain-esque CC-Zero licensing) here, which would arguably be as permissive as possible. In the area of content, it has been my experience that contributors in Fedora are concerned about attribution and reciprocity. They are also far more likely to not be easily able to explicitly license as part of the work (think art), and thus, fall into the default licensing language. From my perspective, using CC-BY-SA is a good fit for that specific use case. ~spot _______________________________________________ legal mailing list legal@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/legal