[cc-community] Strengthening the CC-BY-SA copyleft with respect to code

drew Roberts zotz at 100jamz.com
Wed Dec 21 18:01:20 EST 2011


On Wednesday 21 December 2011 15:07:49 Bart Kelsey wrote:
> On Wed, Dec 21, 2011 at 2:50 PM, Rob Myers <rob at robmyers.org> wrote:
> > My point, illustrated by the examples I gave, is that the actions
> > performed by the software are not enough to identify it as "generic
> > software".
>
> I honestly don't see where you're coming from.  None of the examples you
> gave are of programs that are intended to load one specific file.  They're
> all meant to view certain types of files.  (For the record, I'm not
> pretending not to understand what you're getting at -- I really don't see
> where my distinction doesn't obviously cover these cases.)
>
> > > This should apply in instances
> > > where someone writes a game or some other program that is *intended to
> > > load a specific piece of media*.
> >
> > This is trivial to work around. If I write a proprietary game that loads
> > an asset tree I simply have a registry key / command line parameter that
> > specifies the root of the tree in the filesystem (or the name of the
> > asset archive file). My proprietary game can now load any media in the
> > correct format, and is "generic software".
>
> Lacking any sort of outside scripts that tell the engine what to do with
> the files it loads, the engine is still assuming it's going to be getting
> specific files.  Just because it's not referencing those files by name
> doesn't mean that it's not intended to load them.
>
> > I'd also point out the history of the modding and abandonware scenes.
> > Particularly MAME, ScummVM, Id's software, and Sim City. Assets and
> > engines can be swapped even for the most singular works.
>
> This is very true, but depending on the engine, the data may be hidden,
> obfuscated, encrypted, checksummed, etc, to prevent that.  Certain engines
> leave their data open with the intent to make it replaceable.  In these
> cases, the engine is generic.  You aren't allowed to obfuscate your code
> under the GPL (or in later versions, use DRM or other measures to prevent
> changes from working) -- preventing that here as well would solve this
> issue as well.  If an engine is *truly* moddable from the ground up, it's
> generic.  Otherwise, it's not.

And if it is generic according to your terms, you propose that the 
licensed "art" be usable whether the engine is FOSS or not but if it is not 
generic but specific, you propose that the license on the "art" prohibit its 
use in such a case. Correct?
>
> > > Depending on the situation, that might
> > > be an entire game engine or it might be just the media and game scripts
> > > that run on top of that game engine.
> >
> > Do you mean that this varies from case to case, or that these are
> > alternative options for consideration as changes to the licence?
>
> I mean this varies from case to case.  Sometimes you stick a bunch of
> scripts in a directory (or pass a game script or data tree to the engine at
> the command line) and the script tells the engine what data to load and
> what to do with it.  Some engines are just hard-coded to load certain
> files.  The former case is a clear example of just bundling the data with
> the engine, so the engine wouldn't be covered.  The second case is
> referencing specific files, and in that case the engine would be covered as
> well.
>
> > > Also, to reiterate, I am not advocating replacing CC-BY-SA,
> > > necessarily.  If this would be too big of a change to the license, then
> > > a new license should be created.  I'd really hate for this discussion
> > > to be thrown out just because it doesn't fit CC-BY-SA.  It's still a
> > > need that needs to be addressed.
> >
> > If BY-SA isn't working well *within* game assets or mods, that's a need
> > that needs to be addressed.
>
> Judging by what you said above, I'm guessing we're referring to different
> issues.
>
> This could be ensured by the scripts within the game assets being GPL
> as-is.
>
> > To the extent that the script layer has "carnal knowledge" of the
> > internal data structures of the game engine, the entire game engine
> > would need to be GPL anyway.
>
> The idea here is to have a license that protects artists who want to create
> works to be included in FOSS.  Sure, anyone can GPL the scripts, but at the
> moment people could rip the art out of the game and implement a proprietary
> game using share-alike art.

If I read you right above, this would allow the art to be used in FOSS and 
non-FOSS generic code but only in FOSS non-generic code.

I will restate my general BY-SA strengthening proposal in slightly different 
language than the one I used recently.

I propose that we activate the SA provisions not on the creation of an 
adaptation of the work but on its "inclusion" in any work that itself gets a 
copyright. (I think this covers it but I need some back and forth discussion 
with interested parties to work the idea out. We can do this by not granting 
any of the provisions of the license (on of which is the making of copies for 
instance) unless this happened.

In this statement of the idea, SA would kick in like this:

For an adaptation, the adaptation must be SA too.

For non-adaptation inclusion, the meta-work and all included parts of the 
meta-work would need to be Free but not necessarily BY-SA.

Let's take the case of code and BY-SA art as we have been discussing.

BY-SA art can be included in any copyrighted work so long as that copyrighted 
work and all of its parts are Free. Some parts may not be copyleft though.

BY-SA art can be bundled in ways that no work of copyright is produced. say a 
random collection of art where it sits together with non-Free art and other 
non-Free works where there is no meta-work that is copyrightable.

BY-SA art cannot be used in ways where there is a meta-work that is non-Free 
or (is this possible) where there is a Free meta-work but where the meta-work 
contains non-Free "sub" works.

Why is this not a clean way to strengthen BY-SA?

all the best,

drew


More information about the cc-community mailing list