psi29a wrote:
Does this mean that the whole suite is then also CC-BY-SA or only just that asset?
TL:DR; The freer assets can keep their original licenses.
I feel like a convincing case could be made for either, but it's basically irrelevant because CC licenses are non-exclusive. You could license the entire *.omwgame file as CC-by-SA while also allowing the freer (CC0, OGA-by, CC-by) assets to keep their original licenses on top of being made available under CC-by-SA (which they already were anyway, due to compatibility), so the ways in which these assets can be used
need not change. Since the licenses and URI/URLs need to be included in the attribution file anyway, the overall effect is that assets that are currently only available as CC-by-SA will continue to be CC-by-SA, and the freer assets will continue to be available under their own freer license as well as CC-by-SA, which is the same result as licensing them individually.
So the credits file might be something like this (but probably phrased much better):
The OpenMW Example Suite is licensed under Creative Commons Attribution Share-Alike 4.0, copyright 2016 of the OpenMW Suite Bureau. It contains original work as well as derivatives of the following freely-licensed and public domain assets:
Item 1, by Artist A, CC-by, example.com/item1
Item 2, by Artist B, CC-by-SA, example.com/item2
CC-by-SA would only be a problem for assets that weren't allowed to be combined with it, such as "all rights reserved", NC, or ND -- none of which are free/libre anyway -- so this doesn't affect us.
The crux of the issue is whether compiling disparate assets into a game file creates a new work of creativity. I'm no lawyer, but copyright law suggests that it is:
Compilations of data or compilations of preexisting works (also known as “collective works”) may also be copyrightable if the materials are selected, coordinated, or arranged in such a way that the resulting work as a whole constitutes a new work. When the collecting of the preexisting material that makes up the compilation is a purely mechanical task with no element of original selection, coordination, or arrangement, such as a white-pages telephone directory, copyright protection for the compilation is not available. Some examples of compilations that may be copyrightable are:
• A directory of the best services in a geographic region
• A list of the best short stories of 2011
• A collection of sound recordings of the top hits of 2004
• A book of greatest news photos
• A website containing text, photos, and graphics
• An academic journal containing articles on a particular topic
• A newspaper comprised of articles by different journalists
• A catalog comprised of text and photographs
In the above examples, original authorship may be involved in deciding which were the best stories, the biggest hits, greatest photos, the appropriate article for the serial, and in what order to present the respective works within the compilation.
http://copyright.gov/circs/circ14.pdf
Essentially, is it just a dump of random assets in no particular arrangement, or were the components put together in a way that required some expression of creativity? I'd say the example suite (and any other mods) are firmly in the latter camp.
Do we have any 'free-er' alternatives?
Most of the FOSS games I'm familiar with use CC-by-SA (FLARE, 0 A.D., MegaGlest), so that would really hamstring us if we decide against allowing that license. Hopefully my copyright explanation renders this a nonissue.
Animations, sadly, are only supported in NIF so there will need to be some rather nasty porting there.
This is a problem that I don't really have a good solution for. AFAIK, the Blender NIF exporter only works for archaic versions of Blender, and animations made in modern versions may not be compatible with earlier versions, so modern animations might not be usable. So we can either 1.) animate everything in Blender 2.49b or earlier, 2.) convince somebody to update the NIF exporter to work with modern versions of Blender, or 3.) convince somebody to get another format working in OMW. For me, #1 is the immediately actionable choice, while #2 and #3 can be filed under "it sure would be nice if somebody did that eventually".
We currently only support NIF and OSG-native statics, can these assets be ported? I would prefer OSG-native of course.
I haven't run into any issues that would keep anything in my collection from being exported as *.osgt files.
Does this sound reasonable?
No complaints here.