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

Bart Kelsey elbarto at gmail.com
Wed Dec 21 15:07:49 EST 2011


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.


> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/cc-community/attachments/20111221/a6f30476/attachment.html 


More information about the cc-community mailing list