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

Bart Kelsey elbarto at gmail.com
Wed Dec 21 19:10:37 EST 2011


On Wed, Dec 21, 2011 at 6:53 PM, Rob Myers <rob at robmyers.org> wrote:

> On 21/12/11 20:07, Bart Kelsey wrote:
> >
> > 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.)
>
> Sure. :-)
>
> My point is that the concepts of "specific files" and "generic editor"
> seem like they define objects or ways that objects act or are acted on
> but in fact they define *intentions*.
>

Is this somehow different from the way the GPL acts?

>
> > 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.
>
> Then Word is intended to load specific files. It always uses the same
> structure, they just have different names and modified contents. :-)
>

Now you're just pretending not to understand me, which is kind of uncool.
:)

>
> > 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.
>
> "True moddability" is again a definition of *intent*.
>

And? Honestly, that was a poor explanation.  My recent one covers it
better, I think.

>
> > 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.
>
> Varying from case to case where the same actions are performed or the
> same objects are involved reduces the certainty and thereby the value
> and the likely adoption of the CC licenses.
>

You're taking my words out of context.  The "cases" I'm referring to are
when people arrange their game script and data files in various ways.  Each
and every case outlined thus far has a clear answer.  The answer itself
does not vary if the arrangement of the files is the same.  You're keying
in on words that I used in order to avoid addressing the specific point
that I'm making.

Again, by the same token, there are different ways that you could arrange
and link your code, and you have to evaluate the terms of the GPL for each
way you do that.  The way the GPL acts "varies from case to case" in
exactly the same way.

>
> > 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.
>
> I am *entirely* sympathetic to the aim, but I think that is overreach
> compared to the power afforded to other artists.
>

That's a convenient excuse that works no matter who brings this up.  We
haven't addressed this need for anyone else, so why should we address it
for you?

For the record, if other artists have the same needs, I would fully support
them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/cc-community/attachments/20111221/c5aaf712/attachment-0001.html 


More information about the cc-community mailing list