Creative Commons - User contributions [en]

Tech team handbook

2012-06-15T21:15:12Z

Christopher Webber:

This page meta-documents the tech team tooling. All pages of canonical, decent documentation for tech team resources should be listed here.

* [[Translation tooling]]: describes how to extract translations and how the translation ecosystem works
* cc.engine infrastructure: check out cc.engine, cd to docs/ directory, run "make", open index.html in browser.
* Deploying code (EXPAND):
** http://teamspace.creativecommons.org/Cc.controlpanel
* Updating RDF
** [[CC License Rdf Overview]]
* [[Source Repository Information]]: Lists what all the SVN repositories are for... git repositories already [[http://code.creativecommons.org/viewgit/ self-described]]
* [[Core developer introduction]]

Tech team handbook

2012-06-15T21:14:44Z

Christopher Webber:

Tech team handbook

2012-06-15T21:13:43Z

Christopher Webber:

This page meta-documents the tech team tooling. All pages of canonical, decent documentation for tech team resources should be listed here.

* [[Translation tooling]]: describes how to extract translations and how the translation ecosystem works
* cc.engine infrastructure: check out cc.engine, cd to docs/ directory, run "make", open index.html in browser.
* Deploying code (EXPAND):
** http://teamspace.creativecommons.org/Cc.controlpanel
* Updating RDF
* [[Source Repository Information]]: Lists what all the SVN repositories are for... git repositories already [[http://code.creativecommons.org/viewgit/ self-described]]
* [[Core_developer_introduction]

Tech team handbook

2012-06-15T21:09:49Z

Christopher Webber:

This page meta-documents the tech team tooling. All pages of canonical, decent documentation for tech team resources should be listed here.

* [[Translation tooling]]: describes how to extract translations and how the translation ecosystem works
* cc.engine infrastructure: check out cc.engine, cd to docs/ directory, run "make", open index.html in browser.

* [[Source Repository Information]]: Lists what all the SVN repositories are for... git repositories already [[http://code.creativecommons.org/viewgit/ self-described]]

Games using CC licensed assets

2012-04-30T17:50:34Z

Christopher Webber:

Some examples to be added at http://creativecommons.org/tag/video-game

http://freegamedev.net/wiki/Complete_open_source_games lists a number of games, some with CC licensed assets, some assets under software licenses.

http://freegamedev.net/wiki/Art_licensing_guide looks interesting.

Similarly, some comments on this at http://www.freedesktop.org/wiki/Games/Upstream#Source

==Go Ollie==
* http://www.tweeler.com/index.php?PAGE=goollie_info&PLATFORM=linux&CATEGORY=commercial&GENRE=all
* Found via http://identi.ca/notice/24239197 -- "logos are nonfree but can be disabled. Art is all free, IIRC CC BY SA, music is vorbis and code is GPL"
* Software license: GPL
* Content license: CC BY-SA

==LinCity NG==
* http://lincity-ng.berlios.de/wiki/index.php/Main_Page
* Software license: GPL
* Content license: GPL or CC BY-SA (dual license)

==REMIX THIS GAME==
* http://dto.github.com/notebook/remix-this-game.html
* Found via http://games.slashdot.org/story/10/07/18/227243/Remix-This-Game-mdash-a-Free-Software-Experiment
* Software license: GPLv3
* Content license: CC BY-SA

==Scorched 3D==
* http://www.scorched3d.co.uk/
* Software license: GPL
* Content license: CC BY-SA

==Scourge==
* http://scourgeweb.org/tiki-index.php
* Software license: GPL
* Content license: Mostly CC BY-SA, with exceptions (see [http://scourgeweb.org/tiki-view_forum_thread.php?comments_parentId=1280&topics_threshold=0&topics_offset=12&topics_sort_mode=lastPost_desc&topics_find=&forumId=3 this discussion])

==SuperTux==
* http://supertux.org
* Software license: GPL
* Content license: GPL or CC BY-SA (dual license)

==Tremulous==
* http://tremulous.net/
* Software license: GPL
* Content license: CC BY-SA

==Yo Frankie==
* http://yofrankie.org
* Particularly interesting for using the blender game engine...
* Software license: GPL
* Content license: CC BY

Day Against DRM

2012-04-18T20:29:28Z

Christopher Webber: Created page with "{{Event |Event Name=Day Against DRM |Mainurl=http://dayagainstdrm.org |date=2012/05/04 |end_date=2012/05/04 |Location=International |EventType=distributed activism |EventCateg..."

{{Event
|Event Name=Day Against DRM
|Mainurl=http://dayagainstdrm.org
|date=2012/05/04
|end_date=2012/05/04
|Location=International
|EventType=distributed activism
|EventCategory=DRM, Free Culture, Free Software,
}}
On May 4th, the Defective by Design DRM Elimination Crew will be running an event in Boston. People are also encouraged to set up days of action in their own communities internationally.

Translation tooling

2012-03-15T20:07:12Z

Christopher Webber: Added a whole lot of translation tooling details

= Adding or changing strings =

For details on this, read the "structure of our translation toolchain"

== Extracting translations ==

Instead of providing a master.po file, the same information is pulled automagically from cc.engine's templates, in the content of the trans tags.

# Make modifications to cc.engine templates, commit, push, etc.
# In cc.i18n (using either buildout or virtualenv) run ./runcheckout.sh && ./extract.sh
# git add cc/i18n/po/en/cc_org.po
# git commit -m "Extracting new strings for translation"
# git push origin master

...done!

== Push source file up to transifex ==

# ssh a7.creativecommons.org
# sudo su cronuser
# cd /home/cronuser/transifex.net_i18n_checkout/
# git pull
# tx push -s

That last command will push the source file (english .po file you committed) up to transifex.

= Structure of our translation toolchain =

== Where are our translations? ==

First of all, we maintain our translations on Transifex. Our
affiliates mostly handle our translations.

https://www.transifex.net/projects/p/CC/resource/deeds-choosers/

== What tools do we use? ==

Translations are in gettext format.

We used to use zope's i18n toolchain for translations. Things used to
be in "logical key" format, where there was a symbolic representation
of each translation (almost like a variable that mapped to the
string). We switched to english keys because that's what most of the
world does, and doing otherwise required an insanely complex and
fragile system that we spent a ton of time maintaining.

These days it's pretty simple... just mark a string for translation by
wrapping it in gettext() or _() or whatever. Then we can auto-extract
things.

If you read the "extracting translations" section above, or even ran
the commands, you may have wondered, "Whoa, that ran like magic! All
of these translations just got pulled out! How the hell did that
work?"

The answer is pretty simple! We use [http://babel.edgewall.org Babel]
to extract strings.

When you run ./runcheckouts.sh, it checks out all the packages we
extract translations from. And ./extract.sh extracts all the
translations from them by reading babel.ini to find out all the stuff
it should extract.

Most of the extractors are pretty standard (jinja2 and python are
bundled by jinja2 and babel respectively), but we've defined our own
for extracting from RDF in cc/i18n/tools/extractors.py (defined as an
entry point in setup.py)

So anyway, transifex has a client that we use to push up the new
translations with. Anyway, just see above for that.

There are actually two cronjobs that run, translations related. A few
times an hour new translations are pulled down, and a new translation
tarball is built. (They're currently separate scripts but maybe they
could be merged?

These commands can be found in the cronuser crontab.

# Pull changes from Tx.net and push them to our repos
5 * * * * ~/bin/sync_i18n_with_transifex.sh > /dev/null
10 * * * * ~/bin/sync_i18n-ccsearch_with_transifex.sh > /dev/null

# Update cc.i18n tarball
*/15 * * * * /usr/bin/ionicer && nice -n 19 bash /var/www/staging.creativecommons.org/make_i18n_sdist.sh > /dev/null

One more thing to note: we have a translations statistics tool that's
run every time the sdist is built. It writes out a csv file that
keeps several bits of information, including percentages. We have a
translation threshold at the top of cc/i18n/util.py ... translations
have to be above this level to show up in the "available languages"
box on various pages of cc.engine!

Tech team handbook

2012-03-15T00:44:11Z

Christopher Webber:

Tech team handbook

2012-03-15T00:31:35Z

Christopher Webber: Created page with "This page meta-documents the tech team tooling. All pages of canonical, decent documentation for tech team resources should be listed here. * Translation tooling: descri..."

Summer of Code 2012

2012-03-01T02:49:17Z

Christopher Webber:

This year Creative Commons has a much more limited focus on what we
would like to see out of Google Summer of Code than in previous years.
A specific project is listed below:

== Creative Commons LibreOffice (OpenOffice) plugin updates ==

We'd like to see various updates to the LibreOffice plugin. We've had
significant work done on the
[http://wiki.creativecommons.org/OpenOffice_Plugin_Updates OpenOffice plugin]
over the last few years,
[http://labs.creativecommons.org/2010/07/03/creative-commons-open-office-plugin-gets-a-new-ui-and-supports-for-public-domain-tools/ particularly in 2010].

We'd like to see more work done on the plugin. Some particular things we'd like to see:

* Get the extension added to the [http://extensions.libreoffice.org/extension-center LibreOffice extension center]
* General UI cleanup: eg, make the tabs be actual tabs, if possible
* Switch [http://creativecommons.org/choose/publicdomain-2 Public Domain Certification] tool to use [http://creativecommons.org/choose/mark/ Public Domain Mark] instead
* Rewrite from Java to Python
* ???

== Other projects ==

While CC's scope of interest is limited this year, we encourage applying to other projects. Here are some that are in particular important to free cultural production and curation; any improvements to these programs (and many others) help build the commons:

* Blender
* Inkscape
* GIMP
* Libre.fm
* LibreOffice
* MediaGoblin
* [https://www.mediawiki.org/wiki/Summer_of_Code_2012 Mediawiki]
* [http://wiki.musicbrainz.org/Development/Summer_of_Code/2012 MusicBrainz]
* [https://wiki.openstreetmap.org/wiki/Google_Summer_of_Code/2012 OpenStreetMap]

Developer Challenges

2012-02-29T23:52:24Z

Christopher Webber: Updated the GSOC link

[[Category:Developer]]

{{Infobox|'''Here for [http://www.google-melange.com/gsoc/homepage/google/gsoc2012 Google Summer of Code]? See [[Summer of Code 2012]] for details about what we're looking for in applications this year. Please read that page... most of the ideas below do not apply this year.'''}}

{{Infobox|This page is for ideas and wishes: technology projects that would be beneficial for Creative Commons and our community, but which we don't have resources to build ourselves. If you've found a '''bug''' or have a feature request for existing tools/services, please report it in the [http://code.creativecommons.org/issues bug tracker].}}

We have ideas. Lots of ideas. And some of them might just be darn cool. So we challenge you, dear developer, help us out and win fame and glory (and maybe, just maybe, [http://creativecommons.org/weblog/entry/4293 a job]).

Some challenges have been met and completed, but fret not -- there are still lots of opportunities for fame and glory.

For more ways to participate take a look at the the [[Developers]] portal.

{{#forminput:Challenge|35||Add a New Challenge}}

== Google Summer of Code Ideas ==

We think these ideas are right-sized for Google [[Summer of Code]] projects. We'll definitely accept applications for ideas that aren't on this list, but these are a good starting point.

{{#ask:
[[Category:Challenge]]
[[Has Challenge Type::Developer]]
[[Is Complete::false]]
[[Has Tag::gsoc]]
| ?Related To
}}

== Open Challenges ==

{{#ask:
[[Category:Challenge]] [[Has Challenge Type::Developer]] [[Is Complete::false]]
| ?Related To
| ?Has Tag
}}

== Completed Challenges ==

{{#ask:
[[Category:Challenge]]
[[Has Challenge Type::Developer]]
[[Is Complete::true]]
| ?Related To
| ?Has Tag
}}

Developer Challenges

2012-02-29T23:51:31Z

Christopher Webber:

[[Category:Developer]]

{{Infobox|'''Here for [http://www.google-melange.com/gsoc/org/show/google/gsoc2012/cc Google Summer of Code]? See [[Summer of Code 2012]] for details about what we're looking for in applications this year. Please read that page... most of the ideas below do not apply this year.'''}}

{{Infobox|This page is for ideas and wishes: technology projects that would be beneficial for Creative Commons and our community, but which we don't have resources to build ourselves. If you've found a '''bug''' or have a feature request for existing tools/services, please report it in the [http://code.creativecommons.org/issues bug tracker].}}

We have ideas. Lots of ideas. And some of them might just be darn cool. So we challenge you, dear developer, help us out and win fame and glory (and maybe, just maybe, [http://creativecommons.org/weblog/entry/4293 a job]).

Some challenges have been met and completed, but fret not -- there are still lots of opportunities for fame and glory.

For more ways to participate take a look at the the [[Developers]] portal.

{{#forminput:Challenge|35||Add a New Challenge}}

== Google Summer of Code Ideas ==

We think these ideas are right-sized for Google [[Summer of Code]] projects. We'll definitely accept applications for ideas that aren't on this list, but these are a good starting point.

{{#ask:
[[Category:Challenge]]
[[Has Challenge Type::Developer]]
[[Is Complete::false]]
[[Has Tag::gsoc]]
| ?Related To
}}

== Open Challenges ==

{{#ask:
[[Category:Challenge]] [[Has Challenge Type::Developer]] [[Is Complete::false]]
| ?Related To
| ?Has Tag
}}

== Completed Challenges ==

{{#ask:
[[Category:Challenge]]
[[Has Challenge Type::Developer]]
[[Is Complete::true]]
| ?Related To
| ?Has Tag
}}

Developer Challenges

2012-02-29T23:51:09Z

Christopher Webber: Fixed GSOC 2012 wiki link

[[Category:Developer]]

{{Infobox|'''Here for [http://www.google-melange.com/gsoc/org/show/google/gsoc2011/cc Google Summer of Code]? See [[Summer of Code 2012]] for details about what we're looking for in applications this year. Please read that page... most of the ideas below do not apply this year.'''}}

{{Infobox|This page is for ideas and wishes: technology projects that would be beneficial for Creative Commons and our community, but which we don't have resources to build ourselves. If you've found a '''bug''' or have a feature request for existing tools/services, please report it in the [http://code.creativecommons.org/issues bug tracker].}}

We have ideas. Lots of ideas. And some of them might just be darn cool. So we challenge you, dear developer, help us out and win fame and glory (and maybe, just maybe, [http://creativecommons.org/weblog/entry/4293 a job]).

Some challenges have been met and completed, but fret not -- there are still lots of opportunities for fame and glory.

For more ways to participate take a look at the the [[Developers]] portal.

{{#forminput:Challenge|35||Add a New Challenge}}

== Google Summer of Code Ideas ==

We think these ideas are right-sized for Google [[Summer of Code]] projects. We'll definitely accept applications for ideas that aren't on this list, but these are a good starting point.

{{#ask:
[[Category:Challenge]]
[[Has Challenge Type::Developer]]
[[Is Complete::false]]
[[Has Tag::gsoc]]
| ?Related To
}}

== Open Challenges ==

{{#ask:
[[Category:Challenge]] [[Has Challenge Type::Developer]] [[Is Complete::false]]
| ?Related To
| ?Has Tag
}}

== Completed Challenges ==

{{#ask:
[[Category:Challenge]]
[[Has Challenge Type::Developer]]
[[Is Complete::true]]
| ?Related To
| ?Has Tag
}}

Developer Challenges

2012-02-29T23:50:35Z

Christopher Webber: Updated for GSOC 2012

[[Category:Developer]]

{{Infobox|'''Here for [http://www.google-melange.com/gsoc/org/show/google/gsoc2011/cc Google Summer of Code]? See [[Google Summer of Code 2012]] for details about what we're looking for in applications this year. Please read that page... most of the ideas below do not apply this year.'''}}

{{Infobox|This page is for ideas and wishes: technology projects that would be beneficial for Creative Commons and our community, but which we don't have resources to build ourselves. If you've found a '''bug''' or have a feature request for existing tools/services, please report it in the [http://code.creativecommons.org/issues bug tracker].}}

We have ideas. Lots of ideas. And some of them might just be darn cool. So we challenge you, dear developer, help us out and win fame and glory (and maybe, just maybe, [http://creativecommons.org/weblog/entry/4293 a job]).

Some challenges have been met and completed, but fret not -- there are still lots of opportunities for fame and glory.

For more ways to participate take a look at the the [[Developers]] portal.

{{#forminput:Challenge|35||Add a New Challenge}}

== Google Summer of Code Ideas ==

We think these ideas are right-sized for Google [[Summer of Code]] projects. We'll definitely accept applications for ideas that aren't on this list, but these are a good starting point.

{{#ask:
[[Category:Challenge]]
[[Has Challenge Type::Developer]]
[[Is Complete::false]]
[[Has Tag::gsoc]]
| ?Related To
}}

== Open Challenges ==

{{#ask:
[[Category:Challenge]] [[Has Challenge Type::Developer]] [[Is Complete::false]]
| ?Related To
| ?Has Tag
}}

== Completed Challenges ==

{{#ask:
[[Category:Challenge]]
[[Has Challenge Type::Developer]]
[[Is Complete::true]]
| ?Related To
| ?Has Tag
}}

Summer of Code 2012

2012-02-29T23:32:40Z

Christopher Webber: /* Creative Commons LibreOffice (OpenOffice) plugin updates */

This year Creative Commons has a much more limited focus on what we
would like to see out of Google Summer of Code than in previous years.
A specific project is listed below:

== Creative Commons LibreOffice (OpenOffice) plugin updates ==

We'd like to see various updates to the LibreOffice plugin. We've had
significant work done on the
[http://wiki.creativecommons.org/OpenOffice_Plugin_Updates OpenOffice plugin]
over the last few years,
[http://labs.creativecommons.org/2010/07/03/creative-commons-open-office-plugin-gets-a-new-ui-and-supports-for-public-domain-tools/ particularly in 2010].

We'd like to see more work done on the plugin. Some particular things we'd like to see:

* Get the extension added to the [http://extensions.libreoffice.org/extension-center LibreOffice extension center]
* General UI cleanup: eg, make the tabs be actual tabs, if possible
* Switch [http://creativecommons.org/choose/publicdomain-2 Public Domain Certification] tool to use [http://creativecommons.org/choose/mark/ Public Domain Mark] instead
* ???

== Other projects ==

CC's scope of inis limited this year, here are some other great
projects which are participating in GSOC that we think are also
important to commons building.

* Wordpress
* MediaGoblin
* Libre.fm

Summer of Code 2012

2012-02-29T23:18:27Z

Christopher Webber: Fix bullet points

Summer of Code 2012

2012-02-29T23:17:58Z

Christopher Webber: Starting GSOC 2012 page

4.0/Attribution and marking

2012-02-13T22:59:08Z

Christopher Webber: Commented on machine-readability of credits or marks

{{4.0 Issue}}

<div style="padding: 1em; margin-bottom: 1em; border: 1px dotted red; background-color: #eee; width: 97%;">
'''Page summary:''' This page aggregates discussion topics involving attribution and marking requirements, as the two are closely related and have never been clearly or uniformly differentiated. Attribution has been a standard feature of all CC licenses since the [http://creativecommons.org/weblog/entry/4216 version 2.0 suite]. Currently, attribution requirements are primarily contained in Section 4 of the 3.0 licenses. Marking requirements are interspersed throughout the license, including (in version 3.0) in Section 3(b), 4(a) and 4(b) of the licenses permitting adaptations, and in Section 4(a) of the two ND licenses (BY-ND and BY-NC-ND).
</div>

== Attribution ==

The current 3.0 licenses require users of a work to implement the following in any reasonable manner: <ref> See the [http://wiki.creativecommons.org/Marking/Users#Marking_on_Your_Site Marking Page] for further information.</ref>

* keep copyright notices intact; and
* reasonable to the medium or means used by the licensee,
** provide the name the original author (or her pseudonym, or other attribution party, when provided);
** provide the title of the work if supplied;
** include the URI associated with the work (if it refers to the copyright notice or licensing information); and
** where an adaptation is created (when permitted by the license), include a credit stating that the work has been used in the adaptation <ref>Per Section 4(b) of the license, in the case of an adaptation or collection, where a credit for all contributing authors appears, the credit required must be at least as prominent as the credits for other contributing authors.</ref>

All 3.0 licenses allow licensors to request removal of the credit when their works are reproduced in a collection, as well as when their works are adapted (where permitted by the licenses). Specifically, all six version 3.0 licenses provide: <ref>See Section 4(a) of the licenses. </ref>

:: ''If You create a Collection, upon notice from any Licensor You must, to the extent practicable, remove from the Collection any credit as required by Section 4(__), as requested.''

:: And in BY, BY-SA, BY-NC-SA, and BY-NC, additionally:

:: ''If You create an Adaptation, upon notice from any Licensor You must, to the extent practicable, remove from the Adaptation any credit as required by Section 4(__), as requested.'' <ref>See Section 4(a) of the licenses that permit adaptations.</ref>

The attribution requirement is reflected on the [http://creativecommons.org/licenses/by/3.0/ CC deeds] as:

:: ''Attribution – You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work).''

A few [[Case_Law|legal decisions]] have successfully enforced the attribution requirement.

The attribution requirements have drawn some criticism:
# General difficulty understanding what is required on the part of licensees, in part due to the “reasonable to the medium or means” language but also because the language is difficult to parse.
# Are too onerous and do not align with community practices.
# The requirements insufficiently anticipate or account for analog distributions and performances, making it challenging to comply (same criticism is equally applicable to other marking requirements, below).
# Absence of a mechanism for requesting or permitting removal of a credit for reproductions of an unmodified work when not reproduced as part of a collection.<ref>Although, a licensor may always enter into a separate agreement with licensees to have attribution waived.</ref>

'''Note: For criticisms, issues and proposals relating to attribution requirements for adaptations, please see the [[4.0/Treatment of adaptations]] page.'''

=== Proposals for attribution in 4.0 ===
''For ease of reference on discussion lists, please do not alter proposal numbers.''

[Note: these proposals are not necessarily mutually exclusive]

'''''BY Proposal No. 1:''''' '''Consolidate the attribution requirements into a single location within the licenses (e.g., Section 4) and simplify language, including all other marking requirements (see below), such as providing the URI for the license.'''
* Pros: Users of licensed works would understand requirements more easily, which fosters reuse.
* Cons:
* Other comments:

'''''BY Proposal No. 2:''''' '''Introduce further flexibility into the requirements, to bring them closer into alignment with community practices.'''
* Pros: This would reduce unintentional violations of the licenses, which is especially important because a violation of the license results in automatic termination.
* Cons:
* Other comments: For example, one [http://lists.ibiblio.org/pipermail/cc-licenses/2012-January/006604.html proposal] from license-discuss is to remove the provision requiring that a credit for an adaptation or collection must be as prominent as the other contributing authors. This requirement might be excessive in some circumstances.

'''''BY Proposal No. 3:''''' '''Expand the existing mechanism for requesting removal of the attribution credit so licensors can request removal for any reuse.'''
* Pros: There may be situations where licensors would prefer not to be associated with a particular website, and this would enable them to avoid association by removing attribution credit.
* Cons: Allows people to require removal of author's name even where credit is accurate and factual.
* Other comments:

'''''BY Proposal No. 4:''''' '''Create a mechanism in the license allowing licensors to waive attribution completely.'''
* Pros: Potentially useful for keeping alive CC BY-SA but waiving BY aspect without needing a separate and incompatible copyleft (CC SA, which existed and has been deprecated for some time)
* Cons: Reduces need for and potential adoption of CC0.
* Other comments: Couldn't a licensor waive attribution requirements outside of the license with an additional statement and without needing to add anything to the legalcode?

'''''BY Proposal No. 5:''''' '''Relax the requirement to "keep intact" copyright notice, notice referring to the license, and notice referring to disclaimers of warranty; and allow translation, contextualization, and possibly other modification of those notices.'''
* Pros: Reduces the risk for users to overlook copyright notice, notice referring to the license, or notice referring to disclaimers of warranty. This risk is higher in at least 2 situations: 1) When those notices are written in languages that a user do not understand well; and 2) When the work under a CC license is long or complex. For example, a notice referring to disclaimers of warranty might not be easily detectable in a given photo gallery web site with multiple pages with many different sections. (And you are required to keep intact "all" such notices.)
** Allowing contextualization of the notices would reduce the risk of bearing non-sensical or even ineffective notices. For example, if you use a text from web page to create a book, to "keep intact" a notice saying "content of this web page is under CC-BY 3.0 Unported" does not make good sense for readers of a book. (And in practice, many license notices are written in this kind of context-specific way.)
** In some cases, to "keep intact" a notice is impossible. For example, a notice may be given as an audio, as a part of radio program. A user cannot "keep intact" the audio notice if he wants to use the content of the audio for a photo or a book. More importantly, notice seems to be given visually in many cases, by using a CC license logo. To keep intact a logo may be challenge if a user wants to create a non-visual work, or use the work in an environment where only text-data is usable.
** In theory, this requirement to keep intact "all" notices could be used to intentionally block further reuse even when license and technology would allow reuse. Imagine a user of a licensed CC-BY-SA work adds a few hundred notices to an Adaptation. Those who wishes to use such work would find it very difficult to comply with the requirement to keep intact "all" such notices. Allowing more flexible attribution and marking would prevent such effort. Another theoretical example would be to embed notices in easy-to-overlook places within a movie, a video game, or a long book. A user may need to first find all the notices to comply with the requirement to keep intact "all" notices.
** Note also that reuse (creation of adaptations/ derivatives) under BY-SA licenses would end up accumulating license notices. "This work is licensed under Creative Commons 2.0 Generic" may appear "This work is licensed under Creative Commons 3.0 US." That would look like the work is dual-licensed, while it is not. It is simply that an original work was under 2.0, and a derivative is under 3.0.
* Cons: Like many relaxation of requirements, it could serve as an opening for unwanted exploitation.
* Other comments: I think there is some room for interpretation what exactly is to "keep intact."

'''''BY Proposal No. 6:''''' '''Make clearer what is meant by "credit" by stopping the use of the word in two different ways.''' - "a credit identifying the use of the Work in the Adaptation" is one place where the word appears, and "remove ... any credit as required by Section 4(b), as requested" is another place where the same word is used but to mean a wider set of information.
* Pros: Increase the ease of complying the license terms, and reduce unintended failure to comply with the requirements.
* Cons:
* Other comments:

'''''BY Proposal No. 7:''''' '''Explicitly allow attribution via a provision of a URI, when a web page with that URI provides attribution'''
* Pros: This would solve the problem sometimes referred to as attribution stack-up - when there are too many authors to attribute to, that would restrict the scope of reuse. Allowing the use of a web page to provide attribution, and requiring just a display of its URL for attribution would make reuse possible in those cases. A typical example - copying some text from Wikipedia's heavily edited article to a blog. If you need to copy the whole list of the authors, it could be difficult and time-consuming. If you could simply show a URL of the page on Wikipedia where you can see a list of people edited the page, that would be a lot easier and quicker.
* Cons:
* Other comments:

'''''BY Proposal No. 8:''''' '''Consider giving the right to request credit removal to actual people receiving credits.''' - The current license allows only licensor to make such a request. Note that a CC licensed work may not carry information about licensor's name or contact at all. Credits may tell licensee about authors and other entities the credits are given to. When a CC-BY-SA work is adapted a few times by a few different parties, a licensee may not be able to tell who the licensors are.
* Pros: When removal request has to come from a licensor, there are two consequences: 1) A licensee cannot tell a removal request coming from authentic licensor from fake one, and 2) authors and other entities receiving credits may or may not necessarily know how to contact a licensor when they want to request a removal.
* Cons: A complication could still arise if this proposal is implemented because authentification of authors and other entities receiving credits are not easy, either. It is perhaps easier than telling who is a licensor for a given set of credit.
* Other comments: In general, it is not easy to understand the distinction between an author and a licensor.

'''''BY Proposal No. 9:''''' '''Consider limiting the "keep intact" and other crediting & marking obligations to only those pieces of information that are clearly present and easily identifiable. Make a licensee's failure to comply with properly crediting not a trigger for terminating the license.''' - For example, it is often difficult to tell if a URI accompanying a work is "specified" by the licensor. The same can be said even about the name of an author, when there are more than one name displayed for the same account. Flickr accounts may have an account name and a name of a person. It may be difficult to tell if a file name is meant to be a title for a photo or the photo is untitled. Many blog posts are accompanied by poster's account names, separate from their full names (typically linked from those nick names), which is different from name of the organization (typically found at the copyright notice) the blog is for. Which name is "supplied" as the name of the Original Author in this case?
* Pros: Increased ease of use of licensed works.
* Cons: In theory, unwanted crediting, or omission thereof may increase.
* Other comments:

'''''BY Proposal No.10:''''' '''Consider increasing machine-readability of credits and marks.'''
* Pros: If a simple script can identify all or most of the information needed for giving a credit, it would improve license compliance for a wider range of works and licensees.
* Cons: If done in legalcode(?) this could result in massive incompliance with licenses, as machine-readability is hard to get right
* Other comments: It seems like this should be done regardless, but in external tooling work by the tech team and the rest of the CC-using ecosystem?

'''''BY Proposal No. 11:''''' '''Clarify the language about URI specified by the licensor''' - currently it says, in part, "unless such URI does not refer to the copyright notice or licensing information for the Work," and what it means seems to be "as long as resource identified by such URI includes the copyright notice or licensing information for the Work."
* Pros:
* Cons:
* Other comments:

'''''BY Proposal No. 12:''''' '''Remove provision that allows licensors to request removal of attribution or amend it to cover only requests for removal of misleading or inaccurate attribution.'''
* Pros: This provision arguably does not meet the Debian Free Software Guidelines because it requires removal of attribution upon request, even where attribution is accurate and not misleading.
* Cons:
* Other comments: More information about this proposal is included in this [http://lists.ibiblio.org/pipermail/cc-licenses/2012-January/006602.html email thread] from license-discuss.

'''''BY Proposal No. __:''''' '''____'''
* Pros:
* Cons:
* Other comments:

''Please add other BY proposals here, and number them sequentially.''

== Marking requirements ==
Beyond the marking requirements related to attribution described above, the CC licenses contain additional requirements for properly marking a CC-licensed work:

* in those licenses that permit adaptations (BY, BY-NC, BY-SA, BY-NC-SA), if an adaptation is made (including any translation in any medium), the licensee must take reasonable steps to clearly label, demarcate or otherwise identify that changes were made to the original Work"; <ref> See Section 3(b) of the licenses that permit adaptations.</ref>
* for every copy of the work distributed or publicly performed, the licensee must: <ref> See Section 4(a) of the licenses.</ref>
** include a copy of, or the Uniform Resource Identifier (URI) for the license;
** keep intact all notices that refer to the license and to the disclaimer of warranties;
* for every adaptation of the work that is distributed or publicly performed (where adaptations are permitted), the licensee must: <ref> See Section 4(b) of the licenses that permit adaptations</ref>:
** include a copy of, or the URI for, the license (for the original work); <ref> The international (unported) BY-SA and BY-NC-SA incorrectly refer to "Applicable License" in Section 4(b). This is a [http://wiki.creativecommons.org/Legalcode_errata#Incorrect_reference_to_.22the_Applicable_License.22 known error].</ref>
** keep intact all notices that refer to the license (for the original work) and to the disclaimer of warranties.

These marking requirements have attracted some criticism:
# For adaptations, lack of clarity or uniformity as to placement of the mark or label indicating that changes were made to the original work.
# Absence of flexibility (such as through a reasonableness requirement) for inclusion of the URI.

'''Note: For proposals relating to marking requirements for adaptations, please see the [[4.0/Treatment of adaptations]] page.'''

=== Proposals for marking requirements in 4.0 ===
''For ease of reference on discussion lists, please do not alter proposal numbers.''

'''''Marking Proposal No. 1:''''' '''Making the inclusion of the URI subject to a "reasonable to the medium or means" requirement'''
* Pros
* Cons
* Other comments

''Please add other marking proposals here, and number them sequentially.''

== Related debate ==
''We encourage you to sign up for the license discussion mailing list, where we will be debating this and other 4.0 proposals. HQ will provide links to related email threads from the license discussion mailing list here.''

== Relevant references ==
''Please add citations that ought inform this 4.0 issue here.''
* ePSIplatform guest blog post dated February 11th, 2011: "[http://epsiplatform.eu/content/cc-tools-and-psi-supporting-attribution-protecting-reputation-and-preserving-integrity CC tools and PSI: Supporting attribution, protecting reputation, and preserving integrity]"
* [http://wiki.creativecommons.org/Marking/Users Best Practices for Marking Content with CC Licenses: Users]

== Notes ==
<references/>

4.0/Attribution and marking

2012-02-13T22:57:22Z

Christopher Webber: Commenting on where waiving attribution may be useful

{{4.0 Issue}}

<div style="padding: 1em; margin-bottom: 1em; border: 1px dotted red; background-color: #eee; width: 97%;">
'''Page summary:''' This page aggregates discussion topics involving attribution and marking requirements, as the two are closely related and have never been clearly or uniformly differentiated. Attribution has been a standard feature of all CC licenses since the [http://creativecommons.org/weblog/entry/4216 version 2.0 suite]. Currently, attribution requirements are primarily contained in Section 4 of the 3.0 licenses. Marking requirements are interspersed throughout the license, including (in version 3.0) in Section 3(b), 4(a) and 4(b) of the licenses permitting adaptations, and in Section 4(a) of the two ND licenses (BY-ND and BY-NC-ND).
</div>

== Attribution ==

The current 3.0 licenses require users of a work to implement the following in any reasonable manner: <ref> See the [http://wiki.creativecommons.org/Marking/Users#Marking_on_Your_Site Marking Page] for further information.</ref>

* keep copyright notices intact; and
* reasonable to the medium or means used by the licensee,
** provide the name the original author (or her pseudonym, or other attribution party, when provided);
** provide the title of the work if supplied;
** include the URI associated with the work (if it refers to the copyright notice or licensing information); and
** where an adaptation is created (when permitted by the license), include a credit stating that the work has been used in the adaptation <ref>Per Section 4(b) of the license, in the case of an adaptation or collection, where a credit for all contributing authors appears, the credit required must be at least as prominent as the credits for other contributing authors.</ref>

All 3.0 licenses allow licensors to request removal of the credit when their works are reproduced in a collection, as well as when their works are adapted (where permitted by the licenses). Specifically, all six version 3.0 licenses provide: <ref>See Section 4(a) of the licenses. </ref>

:: ''If You create a Collection, upon notice from any Licensor You must, to the extent practicable, remove from the Collection any credit as required by Section 4(__), as requested.''

:: And in BY, BY-SA, BY-NC-SA, and BY-NC, additionally:

:: ''If You create an Adaptation, upon notice from any Licensor You must, to the extent practicable, remove from the Adaptation any credit as required by Section 4(__), as requested.'' <ref>See Section 4(a) of the licenses that permit adaptations.</ref>

The attribution requirement is reflected on the [http://creativecommons.org/licenses/by/3.0/ CC deeds] as:

:: ''Attribution – You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work).''

A few [[Case_Law|legal decisions]] have successfully enforced the attribution requirement.

The attribution requirements have drawn some criticism:
# General difficulty understanding what is required on the part of licensees, in part due to the “reasonable to the medium or means” language but also because the language is difficult to parse.
# Are too onerous and do not align with community practices.
# The requirements insufficiently anticipate or account for analog distributions and performances, making it challenging to comply (same criticism is equally applicable to other marking requirements, below).
# Absence of a mechanism for requesting or permitting removal of a credit for reproductions of an unmodified work when not reproduced as part of a collection.<ref>Although, a licensor may always enter into a separate agreement with licensees to have attribution waived.</ref>

'''Note: For criticisms, issues and proposals relating to attribution requirements for adaptations, please see the [[4.0/Treatment of adaptations]] page.'''

=== Proposals for attribution in 4.0 ===
''For ease of reference on discussion lists, please do not alter proposal numbers.''

[Note: these proposals are not necessarily mutually exclusive]

'''''BY Proposal No. 1:''''' '''Consolidate the attribution requirements into a single location within the licenses (e.g., Section 4) and simplify language, including all other marking requirements (see below), such as providing the URI for the license.'''
* Pros: Users of licensed works would understand requirements more easily, which fosters reuse.
* Cons:
* Other comments:

'''''BY Proposal No. 2:''''' '''Introduce further flexibility into the requirements, to bring them closer into alignment with community practices.'''
* Pros: This would reduce unintentional violations of the licenses, which is especially important because a violation of the license results in automatic termination.
* Cons:
* Other comments: For example, one [http://lists.ibiblio.org/pipermail/cc-licenses/2012-January/006604.html proposal] from license-discuss is to remove the provision requiring that a credit for an adaptation or collection must be as prominent as the other contributing authors. This requirement might be excessive in some circumstances.

'''''BY Proposal No. 3:''''' '''Expand the existing mechanism for requesting removal of the attribution credit so licensors can request removal for any reuse.'''
* Pros: There may be situations where licensors would prefer not to be associated with a particular website, and this would enable them to avoid association by removing attribution credit.
* Cons: Allows people to require removal of author's name even where credit is accurate and factual.
* Other comments:

'''''BY Proposal No. 4:''''' '''Create a mechanism in the license allowing licensors to waive attribution completely.'''
* Pros: Potentially useful for keeping alive CC BY-SA but waiving BY aspect without needing a separate and incompatible copyleft (CC SA, which existed and has been deprecated for some time)
* Cons: Reduces need for and potential adoption of CC0.
* Other comments: Couldn't a licensor waive attribution requirements outside of the license with an additional statement and without needing to add anything to the legalcode?

'''''BY Proposal No. 5:''''' '''Relax the requirement to "keep intact" copyright notice, notice referring to the license, and notice referring to disclaimers of warranty; and allow translation, contextualization, and possibly other modification of those notices.'''
* Pros: Reduces the risk for users to overlook copyright notice, notice referring to the license, or notice referring to disclaimers of warranty. This risk is higher in at least 2 situations: 1) When those notices are written in languages that a user do not understand well; and 2) When the work under a CC license is long or complex. For example, a notice referring to disclaimers of warranty might not be easily detectable in a given photo gallery web site with multiple pages with many different sections. (And you are required to keep intact "all" such notices.)
** Allowing contextualization of the notices would reduce the risk of bearing non-sensical or even ineffective notices. For example, if you use a text from web page to create a book, to "keep intact" a notice saying "content of this web page is under CC-BY 3.0 Unported" does not make good sense for readers of a book. (And in practice, many license notices are written in this kind of context-specific way.)
** In some cases, to "keep intact" a notice is impossible. For example, a notice may be given as an audio, as a part of radio program. A user cannot "keep intact" the audio notice if he wants to use the content of the audio for a photo or a book. More importantly, notice seems to be given visually in many cases, by using a CC license logo. To keep intact a logo may be challenge if a user wants to create a non-visual work, or use the work in an environment where only text-data is usable.
** In theory, this requirement to keep intact "all" notices could be used to intentionally block further reuse even when license and technology would allow reuse. Imagine a user of a licensed CC-BY-SA work adds a few hundred notices to an Adaptation. Those who wishes to use such work would find it very difficult to comply with the requirement to keep intact "all" such notices. Allowing more flexible attribution and marking would prevent such effort. Another theoretical example would be to embed notices in easy-to-overlook places within a movie, a video game, or a long book. A user may need to first find all the notices to comply with the requirement to keep intact "all" notices.
** Note also that reuse (creation of adaptations/ derivatives) under BY-SA licenses would end up accumulating license notices. "This work is licensed under Creative Commons 2.0 Generic" may appear "This work is licensed under Creative Commons 3.0 US." That would look like the work is dual-licensed, while it is not. It is simply that an original work was under 2.0, and a derivative is under 3.0.
* Cons: Like many relaxation of requirements, it could serve as an opening for unwanted exploitation.
* Other comments: I think there is some room for interpretation what exactly is to "keep intact."

'''''BY Proposal No. 6:''''' '''Make clearer what is meant by "credit" by stopping the use of the word in two different ways.''' - "a credit identifying the use of the Work in the Adaptation" is one place where the word appears, and "remove ... any credit as required by Section 4(b), as requested" is another place where the same word is used but to mean a wider set of information.
* Pros: Increase the ease of complying the license terms, and reduce unintended failure to comply with the requirements.
* Cons:
* Other comments:

'''''BY Proposal No. 7:''''' '''Explicitly allow attribution via a provision of a URI, when a web page with that URI provides attribution'''
* Pros: This would solve the problem sometimes referred to as attribution stack-up - when there are too many authors to attribute to, that would restrict the scope of reuse. Allowing the use of a web page to provide attribution, and requiring just a display of its URL for attribution would make reuse possible in those cases. A typical example - copying some text from Wikipedia's heavily edited article to a blog. If you need to copy the whole list of the authors, it could be difficult and time-consuming. If you could simply show a URL of the page on Wikipedia where you can see a list of people edited the page, that would be a lot easier and quicker.
* Cons:
* Other comments:

'''''BY Proposal No. 8:''''' '''Consider giving the right to request credit removal to actual people receiving credits.''' - The current license allows only licensor to make such a request. Note that a CC licensed work may not carry information about licensor's name or contact at all. Credits may tell licensee about authors and other entities the credits are given to. When a CC-BY-SA work is adapted a few times by a few different parties, a licensee may not be able to tell who the licensors are.
* Pros: When removal request has to come from a licensor, there are two consequences: 1) A licensee cannot tell a removal request coming from authentic licensor from fake one, and 2) authors and other entities receiving credits may or may not necessarily know how to contact a licensor when they want to request a removal.
* Cons: A complication could still arise if this proposal is implemented because authentification of authors and other entities receiving credits are not easy, either. It is perhaps easier than telling who is a licensor for a given set of credit.
* Other comments: In general, it is not easy to understand the distinction between an author and a licensor.

'''''BY Proposal No. 9:''''' '''Consider limiting the "keep intact" and other crediting & marking obligations to only those pieces of information that are clearly present and easily identifiable. Make a licensee's failure to comply with properly crediting not a trigger for terminating the license.''' - For example, it is often difficult to tell if a URI accompanying a work is "specified" by the licensor. The same can be said even about the name of an author, when there are more than one name displayed for the same account. Flickr accounts may have an account name and a name of a person. It may be difficult to tell if a file name is meant to be a title for a photo or the photo is untitled. Many blog posts are accompanied by poster's account names, separate from their full names (typically linked from those nick names), which is different from name of the organization (typically found at the copyright notice) the blog is for. Which name is "supplied" as the name of the Original Author in this case?
* Pros: Increased ease of use of licensed works.
* Cons: In theory, unwanted crediting, or omission thereof may increase.
* Other comments:

'''''BY Proposal No.10:''''' '''Consider increasing machine-readability of credits and marks.'''
* Pros: If a simple script can identify all or most of the information needed for giving a credit, it would improve license compliance for a wider range of works and licensees.
* Cons:
* Other comments:

'''''BY Proposal No. 11:''''' '''Clarify the language about URI specified by the licensor''' - currently it says, in part, "unless such URI does not refer to the copyright notice or licensing information for the Work," and what it means seems to be "as long as resource identified by such URI includes the copyright notice or licensing information for the Work."
* Pros:
* Cons:
* Other comments:

'''''BY Proposal No. 12:''''' '''Remove provision that allows licensors to request removal of attribution or amend it to cover only requests for removal of misleading or inaccurate attribution.'''
* Pros: This provision arguably does not meet the Debian Free Software Guidelines because it requires removal of attribution upon request, even where attribution is accurate and not misleading.
* Cons:
* Other comments: More information about this proposal is included in this [http://lists.ibiblio.org/pipermail/cc-licenses/2012-January/006602.html email thread] from license-discuss.

'''''BY Proposal No. __:''''' '''____'''
* Pros:
* Cons:
* Other comments:

''Please add other BY proposals here, and number them sequentially.''

== Marking requirements ==
Beyond the marking requirements related to attribution described above, the CC licenses contain additional requirements for properly marking a CC-licensed work:

* in those licenses that permit adaptations (BY, BY-NC, BY-SA, BY-NC-SA), if an adaptation is made (including any translation in any medium), the licensee must take reasonable steps to clearly label, demarcate or otherwise identify that changes were made to the original Work"; <ref> See Section 3(b) of the licenses that permit adaptations.</ref>
* for every copy of the work distributed or publicly performed, the licensee must: <ref> See Section 4(a) of the licenses.</ref>
** include a copy of, or the Uniform Resource Identifier (URI) for the license;
** keep intact all notices that refer to the license and to the disclaimer of warranties;
* for every adaptation of the work that is distributed or publicly performed (where adaptations are permitted), the licensee must: <ref> See Section 4(b) of the licenses that permit adaptations</ref>:
** include a copy of, or the URI for, the license (for the original work); <ref> The international (unported) BY-SA and BY-NC-SA incorrectly refer to "Applicable License" in Section 4(b). This is a [http://wiki.creativecommons.org/Legalcode_errata#Incorrect_reference_to_.22the_Applicable_License.22 known error].</ref>
** keep intact all notices that refer to the license (for the original work) and to the disclaimer of warranties.

These marking requirements have attracted some criticism:
# For adaptations, lack of clarity or uniformity as to placement of the mark or label indicating that changes were made to the original work.
# Absence of flexibility (such as through a reasonableness requirement) for inclusion of the URI.

'''Note: For proposals relating to marking requirements for adaptations, please see the [[4.0/Treatment of adaptations]] page.'''

=== Proposals for marking requirements in 4.0 ===
''For ease of reference on discussion lists, please do not alter proposal numbers.''

'''''Marking Proposal No. 1:''''' '''Making the inclusion of the URI subject to a "reasonable to the medium or means" requirement'''
* Pros
* Cons
* Other comments

''Please add other marking proposals here, and number them sequentially.''

== Related debate ==
''We encourage you to sign up for the license discussion mailing list, where we will be debating this and other 4.0 proposals. HQ will provide links to related email threads from the license discussion mailing list here.''

== Relevant references ==
''Please add citations that ought inform this 4.0 issue here.''
* ePSIplatform guest blog post dated February 11th, 2011: "[http://epsiplatform.eu/content/cc-tools-and-psi-supporting-attribution-protecting-reputation-and-preserving-integrity CC tools and PSI: Supporting attribution, protecting reputation, and preserving integrity]"
* [http://wiki.creativecommons.org/Marking/Users Best Practices for Marking Content with CC Licenses: Users]

== Notes ==
<references/>

Translation tooling

2012-01-27T23:38:37Z

Christopher Webber: Described how to push the source file up to Transifex

This currently describes the translation tooling as exists in the i18noverhaul branches. Hopefully in a couple of weeks this will be the case for the normal next/master branches!

== Extracting translations ==

# First, get a cc.i18n checkout and do the usual thing. Buildout, virtualenv... whatever.
# Run ./runcheckouts.sh && ./extract.sh
# Commit english .po

...done!

== Push source file up to transifex ==

# ssh a7.creativecommons.org
# sudo su cronuser
# cd /home/cronuser/transifex.net_i18n_checkout/
# git pull
# tx push -s

That last command will push the source file (english .po file you committed) up to transifex.

Translation tooling

2012-01-18T16:20:19Z

Christopher Webber: Simpler

4.0/Games 3d printing and functional content

2012-01-04T23:04:08Z

Christopher Webber: Added a bit on Blender at Arne's suggestion; in fact I linked to the GPL for artists page

= Background =

The purpose of this page is to collect thoughts on issues that affect
games and projects that span the domains of cultural and
functional/software works. There are actually quite a few categories
of works that cross this domain, but games, as creative works that *by
necessity* combine code and artwork together, perhaps expose and
encounter some of these issues the most clearly. However games are
not the only area that contain this overlap; for example, 3d printing
is an emerging medium where the line between funtional and cultural is
either blurred or interwoven. It's likely that as the spaces of free
software and free culture (ideally) grow, we'll continue to see more
and more examples of this overlap.

Most of this wiki page will involve issues of the code/functional and
cultural works overlap, but some bits at the end will cover some other
issues raised by speaking with members of the free software gaming
community.

== Background on separation of functional/software and cultural layers ==

As further background, traditionally we've held a fairly clear
division between the free culture and free software spaces. This
division is partly because it's a useful distinction, and partly a
historic one. (The FSF has held this position or something like it
for a long time; alluded to slightly on their
[http://www.gnu.org/philosophy/free-system-distribution-guidelines.html#non-functional-data distribution guidelines about non-functional data].)

It looks something like:

.----------.
| CONTENT |
+----------+
| CODE |
'----------'

In a game context, content might be art, music, story, plain character
descriptions. Code would be the game engine, game scripting, etc.

In a free-as-in-freedom type environment the former would be under
free culture and the user freedom respecting subset of Creative
Commons licenses, and code would be free software licenses such as
MIT/BSD or the GPL.

One of the other results of this (licensing) division though is that
you can also have one half of this layer be proprietary and the other
be free-as-in-freedom. So, for example, the first person shooter
Quake was released under the GPL but the game content was kept
proprietary. Likewise, it's possible that someone could have a game
whose assets were released completely as free cultural works but the
software wasn't; this hasn't seemed to have happened (but some artists
have expressed concern about it). But outside of games, people play
CC licensed content in proprietary media players or view them in
proprietary browsers all the time.

In general, the software/content division in many areas works just
fine as separate layers. But sometimes there is a certain kind of
content that spans both. For example say you have a game that's using
CC BY-SA content and the GPL for the engine. In this you have level
files or character description files saying this is placed here, that's
there, and here's a cute block of text describing this creature if you
look at them in info mode. At this point, that sounds like content,
and so falls into the CC licensing. But what happens if in this same
file there's a certain amount of scripting? It has logic, it assigns
variables, but it also has some programming code.

.----------------.
|CONTENT.--------.|
| |scripted||
+-------| level |+
|CODE '--------'|
| |
'-----------------'

This actually happens all the time in games (both Wesnoth and Frogatto
use an engine that's a bunch of config files that describe maps,
scenarios, storylines, and creatures but which contain a functional
programming language embedded inside them also; see
[http://svn.gna.org/viewcvs/wesnoth/trunk/data/campaigns/Heir_To_The_Throne/scenarios/05b_Isle_of_the_Damned.cfg?view=markup this wesnoth level file which looks like mostly data]
and
[https://github.com/frogatto/frogatto/blob/master/data/objects/enemies/bosses/moth_boss.cfg this boss file from Frogatto that looks like code].
<ref>Technically Frogatto developers consider this to be all content,
but it's also an interpreted language. The intention here isn't to
pass judgement on their interpretation (if the developers don't intend
to enforce the copyleft on the scripting layer, they're the only ones
that can do that anyway) but their files provide pretty clear examples
despite them drawing a line somewhere else.</ref> If for example we
consider a game engine that uses Python as an interpreted language but
which has a backend bound by the GPL to have to follow the GPL, surely
combo content/code files like this might provide an "intertwined data
and code" scenario.
<ref>In fact, this issue comes up with Blender all the time, which
*does* have a backend which is scriptable with Python; see Blender's
[http://www.blender.org/education-help/faq/gpl-for-artists/ GPL for
artists page]... although I'm somewhat unconvinced that all of the
statements on that page make sense, it does demonstrate the complexity
of things.</ref>

This might seem like a very one-off type of consideration, something
not worth considering generally with CC, but I don't think it is.
Surely we want to see more free software and free culture overlapping,
and it is likely that when that happens there may be scenarios when
that happens where some sort of difficult intertwining of code and
content will happen and we'll have to consider what to do about
copyleft incompatibility.

Here's another example not game related, rooted in the physical space:
3d printing. There's a potential that 3d printing could become (and
actually, it's already starting to become) the type of revolution for
physical things what computers and the internet have been for
information.

The most popular 3d printer is something called the
[http://reprap.org/wiki/RepRap RepRap], which has been released under
the GPL. Arguably because of the strength of this copyleft, several
commercial versions have been released such as the
[http://store.makerbot.com/thing-o-matic-kit-mk7.html MakerBot Thing-O-Matic].
But here's an iteration of the 3d printer called the
[http://www.thingiverse.com/thing:14111 Ronthomp Mendel]
which is labeled as being BY-SA, even though it uses a GPL'ed design.

Now, technically the BY-SA and the GPL are not compatible, and it's
probable that this is an issue of education because maybe the Ronthomp
Mendel should simply be under the GPL as well. But here's a
question... what if the Ronthomp Mendel were making use of some BY-SA
parts? What is someone tried to make a new 3d printer that made use
of some cool new gear system that someone released as BY-SA?

One could argue that in the copyleft scope, functional things such as
the RepRap should be GPL'ed (citation needed, but it's been argued at
least by Eben Moglen that GPL is great for hardware because it also
takes advantage of GPL's patent pool protections) and that purely
cultural things such as the
[http://www.thingiverse.com/thing:10367 Octocat print] should be CC BY-SA.
But a) not everyone has agreed on this, plenty of people are using
BY-SA for functional works, and b) this breakdown itself could really
stop working right when we try to create a new project that combines
cultural and functional works.

(One could possibly ask
[http://www.publicknowledge.org/blog/3d-printing-settlers-catan-probably-not-illeg how far copyright applies to functional 3d printed works]
(and therefore, how far copyleft applies), and there's not much
background to show how it applies at all yet. I'm writing this
assuming it does apply.)

To more clearly illustrate the problem, let me first make a list of
some various cool 3d printable things under different licenses:

GPL things:
* [http://reprap.org/wiki/RepRap RepRap 3d printer] (on which most modern 3d printers are based)
* [http://www.thingiverse.com/thing:951 Bead belt gear]

BY-SA things:
* [http://www.thingiverse.com/thing:13368 Motorized functional differential gear system]
* [http://www.thingiverse.com/thing:14599 Robot chassis]
* [http://www.thingiverse.com/thing:10367 Octocat]

BY things:
* [http://www.thingiverse.com/thing:13827 Botmobile dune buggy]

From this list of things already we can see a list of things that
could be blocked. Say you want to power your 3d printer by human
energy by plugging in the motorized functional differential gear
system? Okay, maybe possibly you could argue that that's functional
and should have been GPL'ed, but what about the dune buggy, which is
closer to a children's toy? What about combining that with some
GPL'ed part?

But most complicated of all, what if you wanted to make a walking
cat-robot that uses a BY-SA cat design (maybe the head of the octocat)
and combines it with the robot chassis and some bears and the bead
belt gear and a bunch of other things. Suddenly we've a cool
intersection of culture and functionality is blocked by two copyleft
licenses that both have the same (and best) intentions at heart.
We've blocked the cat-robot from ever being born (well, within license
compliance) by best-intentions-copyleft. This is a problem, and if
the world continues to develop in the direction we want it to, I think
we're going to start seeing it a lot more.

= Possible actions =
== GPL compatibility ==

Probably the most actionable and most urgently raised amongst issues
when discussing with relevant community members is that of a one-way
compatibility between CC BY-SA (and probably also CC BY) and the GPL.
It's almost certainly not possible at this point (and probably
undesirable) that GPL->BY-SA compatibility is possible, but if we
choose to do it BY-SA->GPL (and probably BY->GPL) should be.

The benefits of this is that it will resolve the tricky issues with
"interwoven" content and cultural works. Clashes in copyleft licenses
which share the same goals are unfortunate if they block useful things
from being created. As
[https://creativecommons.org/weblog/entry/30676#comment-356183 Arne Babenhauserheide said],

<blockquote>... the case of cc-by-sa not being comptible with the GPL is very sad,
because they share exactly the same goals: Copyleft. Thus their
incompatibility creates a real split in cultural works. If the 4.0
licenses could make it possible to combine cc works under licenses
with compatible concepts (cc by, cc by-sa) with the GPL, that would be
a huge step towards a unified free culture.</blockquote>

So what are potential downsides? The main downside is that
[http://wiki.creativecommons.org/Frequently_Asked_Questions#Can_I_apply_a_Creative_Commons_license_to_software.3F Creative Commons licenses are not acceptable for software]
and we don't want to spread a misconception that they are. If we go
forward with this, we should develop strong messaging that makes clear
that software should still not be released as BY-SA and that this is
for avoiding conflicts in complicated areas of interwoven cultural and
functional/software works.

The other possible downside is whether or not source requirements for
art might make incorporating BY-SA works with the GPL difficult. Ie,
there is no source requirement for BY-SA, and there is one for the
GPL. The GPL says:

The “source code” for a work means the preferred form of the work
for making modifications to it. “Object code” means any non-source
form of a work.

See also the "source release" section of this document for detailing
on the complexities of source code requirements in BY-SA. But as for
fulfilling the requirements of the GPL, what about the following:

* In programming, the division of what source and object code is well understood. In content it's more of a gradient
* For example, the Blender Foundation releases all the "source code" of its films such as Big Buck Bunny and etc by releasing the .blend files (though it is not a requirement of the license).
* However, what if someone made a remix of Big Buck Bunny where they changed the order of scenes, added a psychadelic overlay, and added new music. But the "source" they worked with was not on the .blend file level, but by remixing the rendered film itself. If incorporated with a GPL'ed work, would the source requirement apply, and would it in fact require sharing the source all the way down to the original .blend files?
* What about a film like Sita Sings the Blues, which is BY-SA but from which the source files were never redistributed at all? It's unlikely the content/code layers would be intertwined if combined with software, but let's pretend for a moment that it was. Would "combining" with a GPL'ed work mean requiring distribution of the original files from which the film was made? What if those were lost? What if there's still a lot you can do without the "original source files", although admittedly not as much as if you had them?
* In other words, just how far does "preferred form of the work for making modifications to it" go down? What if people are remixing it on different layers, and the artists themselves prefer separate layers? Does the GPL give flexibility here?

== Scoping copyleft across and code ==

Bart Kelsey has written an excellent article,
"[http://freegamer.blogspot.com/2011/12/why-we-need-better-copyleft-for-artists.html Why we need a stronger copyleft for artists, and how this might be accomplished]".

It's best just to read that article, but the crux of the argument is
that artists who contribute artwork to free software games often worry
that their artwork will be "lifted" and dropped into some proprietary
game. In other words, something along the lines of this:

,---------YOINK----------,
| V
.---------------. .---------------.
| FaiF CONTENT | | FaiF CONTENT |
+---------------+ +---------------+
| FaiF CODE | | CLOSED CODE |
'---------------' '---------------'

Where FaiF stands for "Free as in Freedom". The argument is that if
you're producing free-as-in-freedom content, you won't want your
content being lifted and dropped into a proprietary codebase (ie, my
dragon creature which is BY-SA could still be used with a game with a
proprietary engine). Bart has pointed out that if the artwork were
done in something like the GIMP, it would be considered on a separate
layer, so even if copyleft like CC BY-SA were used, it could still be
compromised by being lifted and dropped into a proprietary
codebase... but if the artwork were instead done embedded into the
codebase itself like so:

/* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation, either version 3 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/

var smiley = [
0,0,0,0,0,0,1,1,1,1,0,0,0,0,0,0,
0,0,0,0,1,1,0,0,0,0,1,1,0,0,0,0,
0,0,0,1,0,0,0,0,0,0,0,0,1,0,0,0,
0,0,1,0,0,0,0,0,0,0,0,0,0,1,0,0,
0,1,0,0,1,1,0,0,0,0,1,1,0,0,1,0,
0,1,0,0,1,1,0,0,0,0,1,1,0,0,1,0,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,1,0,0,0,0,0,0,0,0,1,0,0,1,
0,1,0,0,1,0,0,0,0,0,0,1,0,0,1,0,
0,1,0,0,0,1,1,1,1,1,1,0,0,0,1,0,
0,0,1,0,0,0,0,0,0,0,0,0,0,1,0,0,
0,0,0,1,0,0,0,0,0,0,0,0,1,0,0,0,
0,0,0,0,1,1,0,0,0,0,1,1,0,0,0,0,
0,0,0,0,0,0,1,1,1,1,0,0,0,0,0,0,
];

So, why should artists who use normal, real graphical tools not get
the same copyleft benefit of keeping their stuff protected with the
rest of the program under the GPL as do coders or artists who would
use a text-editor to hardcode their assets into their work? Are
artists being treated as if they are using some sort of second class
citizen copyleft then? Some artists in the FOSS gaming area feel that
they would be. (Some have even expressed interest in preventing
proprietization by using an -NC license, but there's an irony there in
that an NC license is proprietary anyway.)

The proposal then is for a copyleft license whose requirements reach
across the content layer over into the software layer, requiring a
free software licensed engine or etc. Complexities quickly arise as
in terms of "what about viewing the image in a proprietary browser or
other viewer, etc" and Bart has proposed trying to seperate terms out
for that, particularly by doing packaging-based copyleft.

It's easy to be sympathetic about why artists don't want their work
used in a proprietary engine. The issue is complex, and Bart has
tried to weigh out some pros and cons of this in his blogpost above.
There's also some risk in that some authors have expressed interest in
making a separate copyleft license. This could be very unfortunate
for license proliferation reasons, and especially because copyleft
does best when there's a
[http://gondwanaland.com/mlog/2007/12/01/copyleft-pd/ single copyleft license per domain].

But here's another set of likely complexities with this:

'''Number one:''' In the example shown above, in a sense it's not true
that artists get a second class copyleft. The reverse also applies:

.---------------. .----------------.
| FaiF CONTENT | | CLOSED CONTENT |
+---------------+ +----------------+
| FaiF CODE | | FaiF CODE |
'---------------' '----------------'
| ^
'-----------YOINK---------------'

So while it's true that in the dual-layer system, copylefted
free-as-in-freedom content can be "yoinked" and dumped into a
proprietary game or game engine. But the reverse is also true;
copylefted game engine code can also be yoinked and used with to power
a free-engine-yet-proprietary game using proprietary assets. So
second class citizenship is not true; both sides are cat risk of
having their separate layer yoinked and used in something proprietary.

'''Number two:''' Getting the copyleft-works-across-layers bit to work
right without restricting mere viewer programs could be very hard to
write the correct way, could be excessively complex, and could even
end up in a license that's deemed nonfree if done wrong.

'''Number three:''' The current "separate layers" distinction between
code and content may result in some un-ideal circumstances, but people
have come to rely on it, and it's probably significantly easier to
manage things preserving these layers than to change them.

'''Number four:''' There's still a significant amount of copyleft
protection being done on the content layer even if the culture layer
is dropped onto a proprietary software layer. To put it this way: Say
Zynga or Nintendo were to take your CC BY-SA licensed 3d model and
were to drop it into their proprietary game with their proprietary
engine. If the copyleft layer really does span the whole content
layer, then that means that they also have to release all the rest of
their content to stay in compliance, and that's potentially a
tremendous payback on its own in a way.

That said, it's very reasonable that some artists are frustrated with
this copyleft divide and we should take this into careful consideration.

== Increasing/clarifying scope of what's a derivative ==

The 3.0 Creative Commons licenses provide clarification on what is and
isn't an adaptation/derivative as opposed to a mere collection:

For the avoidance of doubt, where the Work is a musical work,
performance or phonogram, the synchronization of the Work in
timed-relation with a moving image ("synching") will be considered
an Adaptation for the purpose of this License.

Various people in the free software gaming community have commented on
the fact that it would be good to get more clarifications in the
license about what's an adaptation, making it clear that combining
works in a game ''is'' a derivative. For example, this "syncing"
example probably intends to cover works such as multiple character
models that are BY-SA all placed together and interacting in the same
file, but it doesn't explicitly say so.

One concern that has been raised is that the part that "binds"
together various assets in a game is the engine itself, and that if
the copyleft doesn't extend to the engine layer, maybe it doesn't
properly encompass all assets:

[asset] [asset] [asset]
\ | /
\ | /
[engine]
|
V
Player experience

There's a good chance this isn't a concern however, as there's plenty
of things that aren't game engines that also load a bunch of separate
components and combine them into a single media experience.

Even so, it would be helpful to make clear that something along the
lines of loading several pieces of media together, for example in a
game, was a clear adaptation.

== Source release? ==

Right now, unlike the GPL, BY-SA does not have a requirement for
source release. It's been proposed that this could possibly become a
requirement in CC BY-SA 4.0, but this seems unlikely:

* This could mean plenty of works never released with sources before will suddenly become out of compliance
* Unlike with software, where there's a clear binary of source or no source, in other forms of content it's often a gradient. See Big Buck Bunny/Sita Sings the Blues examples described the GPL compatibility section of this document.

It's likely we can't or shouldn't make this a requirement for CC BY-SA
4.0, but perhaps we could improve messaging generally to encourage
more community sharing of sources.

== DRM in BY-SA but not BY ==

In talking to some OpenGameArt members about licensing issues, several
expressed interest in keeping anti-DRM provisions in BY-SA as it's a
copyleft license, but remove them from CC BY (under the rationale the
CC BY approximately the equivalent of MIT/BSD licenses and CC BY-SA
approximately the equivalent of the GPL).

<references/>

4.0/Games 3d printing and functional content

2012-01-04T22:57:36Z

Christopher Webber: /* Background on separation of functional/software and cultural layers */

= Background =

The purpose of this page is to collect thoughts on issues that affect
games and projects that span the domains of cultural and
functional/software works. There are actually quite a few categories
of works that cross this domain, but games, as creative works that *by
necessity* combine code and artwork together, perhaps expose and
encounter some of these issues the most clearly. However games are
not the only area that contain this overlap; for example, 3d printing
is an emerging medium where the line between funtional and cultural is
either blurred or interwoven. It's likely that as the spaces of free
software and free culture (ideally) grow, we'll continue to see more
and more examples of this overlap.

Most of this wiki page will involve issues of the code/functional and
cultural works overlap, but some bits at the end will cover some other
issues raised by speaking with members of the free software gaming
community.

== Background on separation of functional/software and cultural layers ==

As further background, traditionally we've held a fairly clear
division between the free culture and free software spaces. This
division is partly because it's a useful distinction, and partly a
historic one. (The FSF has held this position or something like it
for a long time; alluded to slightly on their
[http://www.gnu.org/philosophy/free-system-distribution-guidelines.html#non-functional-data distribution guidelines about non-functional data].)

It looks something like:

.----------.
| CONTENT |
+----------+
| CODE |
'----------'

In a game context, content might be art, music, story, plain character
descriptions. Code would be the game engine, game scripting, etc.

In a free-as-in-freedom type environment the former would be under
free culture and the user freedom respecting subset of Creative
Commons licenses, and code would be free software licenses such as
MIT/BSD or the GPL.

One of the other results of this (licensing) division though is that
you can also have one half of this layer be proprietary and the other
be free-as-in-freedom. So, for example, the first person shooter
Quake was released under the GPL but the game content was kept
proprietary. Likewise, it's possible that someone could have a game
whose assets were released completely as free cultural works but the
software wasn't; this hasn't seemed to have happened (but some artists
have expressed concern about it). But outside of games, people play
CC licensed content in proprietary media players or view them in
proprietary browsers all the time.

In general, the software/content division in many areas works just
fine as separate layers. But sometimes there is a certain kind of
content that spans both. For example say you have a game that's using
CC BY-SA content and the GPL for the engine. In this you have level
files or character description files saying this is placed here, that's
there, and here's a cute block of text describing this creature if you
look at them in info mode. At this point, that sounds like content,
and so falls into the CC licensing. But what happens if in this same
file there's a certain amount of scripting? It has logic, it assigns
variables, but it also has some programming code.

.----------------.
|CONTENT.--------.|
| |scripted||
+-------| level |+
|CODE '--------'|
| |
'-----------------'

This actually happens all the time in games (both Wesnoth and Frogatto
use an engine that's a bunch of config files that describe maps,
scenarios, storylines, and creatures but which contain a functional
programming language embedded inside them also; see
[http://svn.gna.org/viewcvs/wesnoth/trunk/data/campaigns/Heir_To_The_Throne/scenarios/05b_Isle_of_the_Damned.cfg?view=markup this wesnoth level file which looks like mostly data]
and
[https://github.com/frogatto/frogatto/blob/master/data/objects/enemies/bosses/moth_boss.cfg this boss file from Frogatto that looks like code].
<ref>Technically Frogatto developers consider this to be all content,
but it's also an interpreted language. The intention here isn't to
pass judgement on their interpretation (if the developers don't intend
to enforce the copyleft on the scripting layer, they're the only ones
that can do that anyway) but their files provide pretty clear examples
despite them drawing a line somewhere else.</ref> If for example we
consider a game engine that uses Python as an interpreted language but
which has a backend bound by the GPL to have to follow the GPL, surely
combo content/code files like this might provide an "intertwined data
and code" scenario.

This might seem like a very one-off type of consideration, something
not worth considering generally with CC, but I don't think it is.
Surely we want to see more free software and free culture overlapping,
and it is likely that when that happens there may be scenarios when
that happens where some sort of difficult intertwining of code and
content will happen and we'll have to consider what to do about
copyleft incompatibility.

Here's another example not game related, rooted in the physical space:
3d printing. There's a potential that 3d printing could become (and
actually, it's already starting to become) the type of revolution for
physical things what computers and the internet have been for
information.

The most popular 3d printer is something called the
[http://reprap.org/wiki/RepRap RepRap], which has been released under
the GPL. Arguably because of the strength of this copyleft, several
commercial versions have been released such as the
[http://store.makerbot.com/thing-o-matic-kit-mk7.html MakerBot Thing-O-Matic].
But here's an iteration of the 3d printer called the
[http://www.thingiverse.com/thing:14111 Ronthomp Mendel]
which is labeled as being BY-SA, even though it uses a GPL'ed design.

Now, technically the BY-SA and the GPL are not compatible, and it's
probable that this is an issue of education because maybe the Ronthomp
Mendel should simply be under the GPL as well. But here's a
question... what if the Ronthomp Mendel were making use of some BY-SA
parts? What is someone tried to make a new 3d printer that made use
of some cool new gear system that someone released as BY-SA?

One could argue that in the copyleft scope, functional things such as
the RepRap should be GPL'ed (citation needed, but it's been argued at
least by Eben Moglen that GPL is great for hardware because it also
takes advantage of GPL's patent pool protections) and that purely
cultural things such as the
[http://www.thingiverse.com/thing:10367 Octocat print] should be CC BY-SA.
But a) not everyone has agreed on this, plenty of people are using
BY-SA for functional works, and b) this breakdown itself could really
stop working right when we try to create a new project that combines
cultural and functional works.

(One could possibly ask
[http://www.publicknowledge.org/blog/3d-printing-settlers-catan-probably-not-illeg how far copyright applies to functional 3d printed works]
(and therefore, how far copyleft applies), and there's not much
background to show how it applies at all yet. I'm writing this
assuming it does apply.)

To more clearly illustrate the problem, let me first make a list of
some various cool 3d printable things under different licenses:

GPL things:
* [http://reprap.org/wiki/RepRap RepRap 3d printer] (on which most modern 3d printers are based)
* [http://www.thingiverse.com/thing:951 Bead belt gear]

BY-SA things:
* [http://www.thingiverse.com/thing:13368 Motorized functional differential gear system]
* [http://www.thingiverse.com/thing:14599 Robot chassis]
* [http://www.thingiverse.com/thing:10367 Octocat]

BY things:
* [http://www.thingiverse.com/thing:13827 Botmobile dune buggy]

From this list of things already we can see a list of things that
could be blocked. Say you want to power your 3d printer by human
energy by plugging in the motorized functional differential gear
system? Okay, maybe possibly you could argue that that's functional
and should have been GPL'ed, but what about the dune buggy, which is
closer to a children's toy? What about combining that with some
GPL'ed part?

But most complicated of all, what if you wanted to make a walking
cat-robot that uses a BY-SA cat design (maybe the head of the octocat)
and combines it with the robot chassis and some bears and the bead
belt gear and a bunch of other things. Suddenly we've a cool
intersection of culture and functionality is blocked by two copyleft
licenses that both have the same (and best) intentions at heart.
We've blocked the cat-robot from ever being born (well, within license
compliance) by best-intentions-copyleft. This is a problem, and if
the world continues to develop in the direction we want it to, I think
we're going to start seeing it a lot more.

= Possible actions =
== GPL compatibility ==

Probably the most actionable and most urgently raised amongst issues
when discussing with relevant community members is that of a one-way
compatibility between CC BY-SA (and probably also CC BY) and the GPL.
It's almost certainly not possible at this point (and probably
undesirable) that GPL->BY-SA compatibility is possible, but if we
choose to do it BY-SA->GPL (and probably BY->GPL) should be.

The benefits of this is that it will resolve the tricky issues with
"interwoven" content and cultural works. Clashes in copyleft licenses
which share the same goals are unfortunate if they block useful things
from being created. As
[https://creativecommons.org/weblog/entry/30676#comment-356183 Arne Babenhauserheide said],

<blockquote>... the case of cc-by-sa not being comptible with the GPL is very sad,
because they share exactly the same goals: Copyleft. Thus their
incompatibility creates a real split in cultural works. If the 4.0
licenses could make it possible to combine cc works under licenses
with compatible concepts (cc by, cc by-sa) with the GPL, that would be
a huge step towards a unified free culture.</blockquote>

So what are potential downsides? The main downside is that
[http://wiki.creativecommons.org/Frequently_Asked_Questions#Can_I_apply_a_Creative_Commons_license_to_software.3F Creative Commons licenses are not acceptable for software]
and we don't want to spread a misconception that they are. If we go
forward with this, we should develop strong messaging that makes clear
that software should still not be released as BY-SA and that this is
for avoiding conflicts in complicated areas of interwoven cultural and
functional/software works.

The other possible downside is whether or not source requirements for
art might make incorporating BY-SA works with the GPL difficult. Ie,
there is no source requirement for BY-SA, and there is one for the
GPL. The GPL says:

The “source code” for a work means the preferred form of the work
for making modifications to it. “Object code” means any non-source
form of a work.

See also the "source release" section of this document for detailing
on the complexities of source code requirements in BY-SA. But as for
fulfilling the requirements of the GPL, what about the following:

* In programming, the division of what source and object code is well understood. In content it's more of a gradient
* For example, the Blender Foundation releases all the "source code" of its films such as Big Buck Bunny and etc by releasing the .blend files (though it is not a requirement of the license).
* However, what if someone made a remix of Big Buck Bunny where they changed the order of scenes, added a psychadelic overlay, and added new music. But the "source" they worked with was not on the .blend file level, but by remixing the rendered film itself. If incorporated with a GPL'ed work, would the source requirement apply, and would it in fact require sharing the source all the way down to the original .blend files?
* What about a film like Sita Sings the Blues, which is BY-SA but from which the source files were never redistributed at all? It's unlikely the content/code layers would be intertwined if combined with software, but let's pretend for a moment that it was. Would "combining" with a GPL'ed work mean requiring distribution of the original files from which the film was made? What if those were lost? What if there's still a lot you can do without the "original source files", although admittedly not as much as if you had them?
* In other words, just how far does "preferred form of the work for making modifications to it" go down? What if people are remixing it on different layers, and the artists themselves prefer separate layers? Does the GPL give flexibility here?

== Scoping copyleft across and code ==

Bart Kelsey has written an excellent article,
"[http://freegamer.blogspot.com/2011/12/why-we-need-better-copyleft-for-artists.html Why we need a stronger copyleft for artists, and how this might be accomplished]".

It's best just to read that article, but the crux of the argument is
that artists who contribute artwork to free software games often worry
that their artwork will be "lifted" and dropped into some proprietary
game. In other words, something along the lines of this:

,---------YOINK----------,
| V
.---------------. .---------------.
| FaiF CONTENT | | FaiF CONTENT |
+---------------+ +---------------+
| FaiF CODE | | CLOSED CODE |
'---------------' '---------------'

Where FaiF stands for "Free as in Freedom". The argument is that if
you're producing free-as-in-freedom content, you won't want your
content being lifted and dropped into a proprietary codebase (ie, my
dragon creature which is BY-SA could still be used with a game with a
proprietary engine). Bart has pointed out that if the artwork were
done in something like the GIMP, it would be considered on a separate
layer, so even if copyleft like CC BY-SA were used, it could still be
compromised by being lifted and dropped into a proprietary
codebase... but if the artwork were instead done embedded into the
codebase itself like so:

/* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation, either version 3 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/

var smiley = [
0,0,0,0,0,0,1,1,1,1,0,0,0,0,0,0,
0,0,0,0,1,1,0,0,0,0,1,1,0,0,0,0,
0,0,0,1,0,0,0,0,0,0,0,0,1,0,0,0,
0,0,1,0,0,0,0,0,0,0,0,0,0,1,0,0,
0,1,0,0,1,1,0,0,0,0,1,1,0,0,1,0,
0,1,0,0,1,1,0,0,0,0,1,1,0,0,1,0,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,1,0,0,0,0,0,0,0,0,1,0,0,1,
0,1,0,0,1,0,0,0,0,0,0,1,0,0,1,0,
0,1,0,0,0,1,1,1,1,1,1,0,0,0,1,0,
0,0,1,0,0,0,0,0,0,0,0,0,0,1,0,0,
0,0,0,1,0,0,0,0,0,0,0,0,1,0,0,0,
0,0,0,0,1,1,0,0,0,0,1,1,0,0,0,0,
0,0,0,0,0,0,1,1,1,1,0,0,0,0,0,0,
];

So, why should artists who use normal, real graphical tools not get
the same copyleft benefit of keeping their stuff protected with the
rest of the program under the GPL as do coders or artists who would
use a text-editor to hardcode their assets into their work? Are
artists being treated as if they are using some sort of second class
citizen copyleft then? Some artists in the FOSS gaming area feel that
they would be. (Some have even expressed interest in preventing
proprietization by using an -NC license, but there's an irony there in
that an NC license is proprietary anyway.)

The proposal then is for a copyleft license whose requirements reach
across the content layer over into the software layer, requiring a
free software licensed engine or etc. Complexities quickly arise as
in terms of "what about viewing the image in a proprietary browser or
other viewer, etc" and Bart has proposed trying to seperate terms out
for that, particularly by doing packaging-based copyleft.

It's easy to be sympathetic about why artists don't want their work
used in a proprietary engine. The issue is complex, and Bart has
tried to weigh out some pros and cons of this in his blogpost above.
There's also some risk in that some authors have expressed interest in
making a separate copyleft license. This could be very unfortunate
for license proliferation reasons, and especially because copyleft
does best when there's a
[http://gondwanaland.com/mlog/2007/12/01/copyleft-pd/ single copyleft license per domain].

But here's another set of likely complexities with this:

'''Number one:''' In the example shown above, in a sense it's not true
that artists get a second class copyleft. The reverse also applies:

.---------------. .----------------.
| FaiF CONTENT | | CLOSED CONTENT |
+---------------+ +----------------+
| FaiF CODE | | FaiF CODE |
'---------------' '----------------'
| ^
'-----------YOINK---------------'

So while it's true that in the dual-layer system, copylefted
free-as-in-freedom content can be "yoinked" and dumped into a
proprietary game or game engine. But the reverse is also true;
copylefted game engine code can also be yoinked and used with to power
a free-engine-yet-proprietary game using proprietary assets. So
second class citizenship is not true; both sides are cat risk of
having their separate layer yoinked and used in something proprietary.

'''Number two:''' Getting the copyleft-works-across-layers bit to work
right without restricting mere viewer programs could be very hard to
write the correct way, could be excessively complex, and could even
end up in a license that's deemed nonfree if done wrong.

'''Number three:''' The current "separate layers" distinction between
code and content may result in some un-ideal circumstances, but people
have come to rely on it, and it's probably significantly easier to
manage things preserving these layers than to change them.

'''Number four:''' There's still a significant amount of copyleft
protection being done on the content layer even if the culture layer
is dropped onto a proprietary software layer. To put it this way: Say
Zynga or Nintendo were to take your CC BY-SA licensed 3d model and
were to drop it into their proprietary game with their proprietary
engine. If the copyleft layer really does span the whole content
layer, then that means that they also have to release all the rest of
their content to stay in compliance, and that's potentially a
tremendous payback on its own in a way.

That said, it's very reasonable that some artists are frustrated with
this copyleft divide and we should take this into careful consideration.

== Increasing/clarifying scope of what's a derivative ==

The 3.0 Creative Commons licenses provide clarification on what is and
isn't an adaptation/derivative as opposed to a mere collection:

For the avoidance of doubt, where the Work is a musical work,
performance or phonogram, the synchronization of the Work in
timed-relation with a moving image ("synching") will be considered
an Adaptation for the purpose of this License.

Various people in the free software gaming community have commented on
the fact that it would be good to get more clarifications in the
license about what's an adaptation, making it clear that combining
works in a game ''is'' a derivative. For example, this "syncing"
example probably intends to cover works such as multiple character
models that are BY-SA all placed together and interacting in the same
file, but it doesn't explicitly say so.

One concern that has been raised is that the part that "binds"
together various assets in a game is the engine itself, and that if
the copyleft doesn't extend to the engine layer, maybe it doesn't
properly encompass all assets:

[asset] [asset] [asset]
\ | /
\ | /
[engine]
|
V
Player experience

There's a good chance this isn't a concern however, as there's plenty
of things that aren't game engines that also load a bunch of separate
components and combine them into a single media experience.

Even so, it would be helpful to make clear that something along the
lines of loading several pieces of media together, for example in a
game, was a clear adaptation.

== Source release? ==

Right now, unlike the GPL, BY-SA does not have a requirement for
source release. It's been proposed that this could possibly become a
requirement in CC BY-SA 4.0, but this seems unlikely:

* This could mean plenty of works never released with sources before will suddenly become out of compliance
* Unlike with software, where there's a clear binary of source or no source, in other forms of content it's often a gradient. See Big Buck Bunny/Sita Sings the Blues examples described the GPL compatibility section of this document.

It's likely we can't or shouldn't make this a requirement for CC BY-SA
4.0, but perhaps we could improve messaging generally to encourage
more community sharing of sources.

== DRM in BY-SA but not BY ==

In talking to some OpenGameArt members about licensing issues, several
expressed interest in keeping anti-DRM provisions in BY-SA as it's a
copyleft license, but remove them from CC BY (under the rationale the
CC BY approximately the equivalent of MIT/BSD licenses and CC BY-SA
approximately the equivalent of the GPL).

<references/>

4.0/Games 3d printing and functional content

2012-01-04T22:56:04Z

Christopher Webber: Actually adding references section; oops :)

= Background =

The purpose of this page is to collect thoughts on issues that affect
games and projects that span the domains of cultural and
functional/software works. There are actually quite a few categories
of works that cross this domain, but games, as creative works that *by
necessity* combine code and artwork together, perhaps expose and
encounter some of these issues the most clearly. However games are
not the only area that contain this overlap; for example, 3d printing
is an emerging medium where the line between funtional and cultural is
either blurred or interwoven. It's likely that as the spaces of free
software and free culture (ideally) grow, we'll continue to see more
and more examples of this overlap.

Most of this wiki page will involve issues of the code/functional and
cultural works overlap, but some bits at the end will cover some other
issues raised by speaking with members of the free software gaming
community.

== Background on separation of functional/software and cultural layers ==

As further background, traditionally we've held a fairly clear
division between the free culture and free software spaces. This
division is partly because it's a useful distinction, and partly a
historic one. (The FSF has held this position or something like it
for a long time; alluded to slightly on their
[http://www.gnu.org/philosophy/free-system-distribution-guidelines.html#non-functional-data distribution guidelines about non-functional data].)

It looks something like:

.----------.
| CONTENT |
+----------+
| CODE |
'----------'

In a game context, content might be art, music, story, plain character
descriptions. Code would be the game engine, game scripting, etc.

In a free-as-in-freedom type environment the former would be under
free culture and the user freedom respecting subset of Creative
Commons licenses, and code would be free software licenses such as
MIT/BSD or the GPL.

One of the other results of this (licensing) division though is that
you can also have one half of this layer be proprietary and the other
be free-as-in-freedom. So, for example, the first person shooter
Quake was released under the GPL but the game content was kept
proprietary. Likewise, it's possible that someone could have a game
whose assets were released completely as free cultural works but the
software wasn't; this hasn't seemed to have happened (but some artists
have expressed concern about it). But outside of games, people play
CC licensed content in proprietary media players or view them in
proprietary browsers all the time.

In general, the software/content division in many areas works just
fine as separate layers. But sometimes there is a certain kind of
content that spans both. For example say you have a game that's using
CC BY-SA content and the GPL for the engine. In this you have level
files or character description files saying this is placed here, that's
there, and here's a cute block of text describing this creature if you
look at them in info mode. At this point, that sounds like content,
and so falls into the CC licensing. But what happens if in this same
file there's a certain amount of scripting? It has logic, it assigns
variables, but it also has some programming code.

.----------------.
|CONTENT.--------.|
| |scripted||
+-------| level |+
|CODE '--------'|
| |
'-----------------'

This actually happens all the time in games (both Wesnoth and Frogatto
use an engine that's a bunch of config files that describe maps,
scenarios, storylines, and creatures but which contain a functional
programming language embedded inside them also; see
[http://svn.gna.org/viewcvs/wesnoth/trunk/data/campaigns/Heir_To_The_Throne/scenarios/05b_Isle_of_the_Damned.cfg?view=markup this wesnoth level file which looks like mostly data]
and
[https://github.com/frogatto/frogatto/blob/master/data/objects/enemies/bosses/moth_boss.cfg this boss file from Frogatto that looks like code]
<ref>... technically Frogatto developers consider this to be all content,
but it's also an interpreted language. The intention here isn't to
pass judgement on their interpretation (if the developers don't intend
to enforce the copyleft on the scripting layer, they're the only ones
that can do that anyway) but their files provide pretty clear examples
despite them drawing a line somewhere else.</ref> If for example we
consider a game engine that uses Python as an interpreted language but
which has a backend bound by the GPL to have to follow the GPL, surely
combo content/code files like this might provide an "intertwined data
and code" scenario.

This might seem like a very one-off type of consideration, something
not worth considering generally with CC, but I don't think it is.
Surely we want to see more free software and free culture overlapping,
and it is likely that when that happens there may be scenarios when
that happens where some sort of difficult intertwining of code and
content will happen and we'll have to consider what to do about
copyleft incompatibility.

Here's another example not game related, rooted in the physical space:
3d printing. There's a potential that 3d printing could become (and
actually, it's already starting to become) the type of revolution for
physical things what computers and the internet have been for
information.

The most popular 3d printer is something called the
[http://reprap.org/wiki/RepRap RepRap], which has been released under
the GPL. Arguably because of the strength of this copyleft, several
commercial versions have been released such as the
[http://store.makerbot.com/thing-o-matic-kit-mk7.html MakerBot Thing-O-Matic].
But here's an iteration of the 3d printer called the
[http://www.thingiverse.com/thing:14111 Ronthomp Mendel]
which is labeled as being BY-SA, even though it uses a GPL'ed design.

Now, technically the BY-SA and the GPL are not compatible, and it's
probable that this is an issue of education because maybe the Ronthomp
Mendel should simply be under the GPL as well. But here's a
question... what if the Ronthomp Mendel were making use of some BY-SA
parts? What is someone tried to make a new 3d printer that made use
of some cool new gear system that someone released as BY-SA?

One could argue that in the copyleft scope, functional things such as
the RepRap should be GPL'ed (citation needed, but it's been argued at
least by Eben Moglen that GPL is great for hardware because it also
takes advantage of GPL's patent pool protections) and that purely
cultural things such as the
[http://www.thingiverse.com/thing:10367 Octocat print] should be CC BY-SA.
But a) not everyone has agreed on this, plenty of people are using
BY-SA for functional works, and b) this breakdown itself could really
stop working right when we try to create a new project that combines
cultural and functional works.

(One could possibly ask
[http://www.publicknowledge.org/blog/3d-printing-settlers-catan-probably-not-illeg how far copyright applies to functional 3d printed works]
(and therefore, how far copyleft applies), and there's not much
background to show how it applies at all yet. I'm writing this
assuming it does apply.)

To more clearly illustrate the problem, let me first make a list of
some various cool 3d printable things under different licenses:

GPL things:
* [http://reprap.org/wiki/RepRap RepRap 3d printer] (on which most modern 3d printers are based)
* [http://www.thingiverse.com/thing:951 Bead belt gear]

BY-SA things:
* [http://www.thingiverse.com/thing:13368 Motorized functional differential gear system]
* [http://www.thingiverse.com/thing:14599 Robot chassis]
* [http://www.thingiverse.com/thing:10367 Octocat]

BY things:
* [http://www.thingiverse.com/thing:13827 Botmobile dune buggy]

From this list of things already we can see a list of things that
could be blocked. Say you want to power your 3d printer by human
energy by plugging in the motorized functional differential gear
system? Okay, maybe possibly you could argue that that's functional
and should have been GPL'ed, but what about the dune buggy, which is
closer to a children's toy? What about combining that with some
GPL'ed part?

But most complicated of all, what if you wanted to make a walking
cat-robot that uses a BY-SA cat design (maybe the head of the octocat)
and combines it with the robot chassis and some bears and the bead
belt gear and a bunch of other things. Suddenly we've a cool
intersection of culture and functionality is blocked by two copyleft
licenses that both have the same (and best) intentions at heart.
We've blocked the cat-robot from ever being born (well, within license
compliance) by best-intentions-copyleft. This is a problem, and if
the world continues to develop in the direction we want it to, I think
we're going to start seeing it a lot more.

= Possible actions =
== GPL compatibility ==

Probably the most actionable and most urgently raised amongst issues
when discussing with relevant community members is that of a one-way
compatibility between CC BY-SA (and probably also CC BY) and the GPL.
It's almost certainly not possible at this point (and probably
undesirable) that GPL->BY-SA compatibility is possible, but if we
choose to do it BY-SA->GPL (and probably BY->GPL) should be.

The benefits of this is that it will resolve the tricky issues with
"interwoven" content and cultural works. Clashes in copyleft licenses
which share the same goals are unfortunate if they block useful things
from being created. As
[https://creativecommons.org/weblog/entry/30676#comment-356183 Arne Babenhauserheide said],

<blockquote>... the case of cc-by-sa not being comptible with the GPL is very sad,
because they share exactly the same goals: Copyleft. Thus their
incompatibility creates a real split in cultural works. If the 4.0
licenses could make it possible to combine cc works under licenses
with compatible concepts (cc by, cc by-sa) with the GPL, that would be
a huge step towards a unified free culture.</blockquote>

So what are potential downsides? The main downside is that
[http://wiki.creativecommons.org/Frequently_Asked_Questions#Can_I_apply_a_Creative_Commons_license_to_software.3F Creative Commons licenses are not acceptable for software]
and we don't want to spread a misconception that they are. If we go
forward with this, we should develop strong messaging that makes clear
that software should still not be released as BY-SA and that this is
for avoiding conflicts in complicated areas of interwoven cultural and
functional/software works.

The other possible downside is whether or not source requirements for
art might make incorporating BY-SA works with the GPL difficult. Ie,
there is no source requirement for BY-SA, and there is one for the
GPL. The GPL says:

The “source code” for a work means the preferred form of the work
for making modifications to it. “Object code” means any non-source
form of a work.

See also the "source release" section of this document for detailing
on the complexities of source code requirements in BY-SA. But as for
fulfilling the requirements of the GPL, what about the following:

* In programming, the division of what source and object code is well understood. In content it's more of a gradient
* For example, the Blender Foundation releases all the "source code" of its films such as Big Buck Bunny and etc by releasing the .blend files (though it is not a requirement of the license).
* However, what if someone made a remix of Big Buck Bunny where they changed the order of scenes, added a psychadelic overlay, and added new music. But the "source" they worked with was not on the .blend file level, but by remixing the rendered film itself. If incorporated with a GPL'ed work, would the source requirement apply, and would it in fact require sharing the source all the way down to the original .blend files?
* What about a film like Sita Sings the Blues, which is BY-SA but from which the source files were never redistributed at all? It's unlikely the content/code layers would be intertwined if combined with software, but let's pretend for a moment that it was. Would "combining" with a GPL'ed work mean requiring distribution of the original files from which the film was made? What if those were lost? What if there's still a lot you can do without the "original source files", although admittedly not as much as if you had them?
* In other words, just how far does "preferred form of the work for making modifications to it" go down? What if people are remixing it on different layers, and the artists themselves prefer separate layers? Does the GPL give flexibility here?

== Scoping copyleft across and code ==

Bart Kelsey has written an excellent article,
"[http://freegamer.blogspot.com/2011/12/why-we-need-better-copyleft-for-artists.html Why we need a stronger copyleft for artists, and how this might be accomplished]".

It's best just to read that article, but the crux of the argument is
that artists who contribute artwork to free software games often worry
that their artwork will be "lifted" and dropped into some proprietary
game. In other words, something along the lines of this:

,---------YOINK----------,
| V
.---------------. .---------------.
| FaiF CONTENT | | FaiF CONTENT |
+---------------+ +---------------+
| FaiF CODE | | CLOSED CODE |
'---------------' '---------------'

Where FaiF stands for "Free as in Freedom". The argument is that if
you're producing free-as-in-freedom content, you won't want your
content being lifted and dropped into a proprietary codebase (ie, my
dragon creature which is BY-SA could still be used with a game with a
proprietary engine). Bart has pointed out that if the artwork were
done in something like the GIMP, it would be considered on a separate
layer, so even if copyleft like CC BY-SA were used, it could still be
compromised by being lifted and dropped into a proprietary
codebase... but if the artwork were instead done embedded into the
codebase itself like so:

/* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation, either version 3 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/

var smiley = [
0,0,0,0,0,0,1,1,1,1,0,0,0,0,0,0,
0,0,0,0,1,1,0,0,0,0,1,1,0,0,0,0,
0,0,0,1,0,0,0,0,0,0,0,0,1,0,0,0,
0,0,1,0,0,0,0,0,0,0,0,0,0,1,0,0,
0,1,0,0,1,1,0,0,0,0,1,1,0,0,1,0,
0,1,0,0,1,1,0,0,0,0,1,1,0,0,1,0,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,1,0,0,0,0,0,0,0,0,1,0,0,1,
0,1,0,0,1,0,0,0,0,0,0,1,0,0,1,0,
0,1,0,0,0,1,1,1,1,1,1,0,0,0,1,0,
0,0,1,0,0,0,0,0,0,0,0,0,0,1,0,0,
0,0,0,1,0,0,0,0,0,0,0,0,1,0,0,0,
0,0,0,0,1,1,0,0,0,0,1,1,0,0,0,0,
0,0,0,0,0,0,1,1,1,1,0,0,0,0,0,0,
];

So, why should artists who use normal, real graphical tools not get
the same copyleft benefit of keeping their stuff protected with the
rest of the program under the GPL as do coders or artists who would
use a text-editor to hardcode their assets into their work? Are
artists being treated as if they are using some sort of second class
citizen copyleft then? Some artists in the FOSS gaming area feel that
they would be. (Some have even expressed interest in preventing
proprietization by using an -NC license, but there's an irony there in
that an NC license is proprietary anyway.)

The proposal then is for a copyleft license whose requirements reach
across the content layer over into the software layer, requiring a
free software licensed engine or etc. Complexities quickly arise as
in terms of "what about viewing the image in a proprietary browser or
other viewer, etc" and Bart has proposed trying to seperate terms out
for that, particularly by doing packaging-based copyleft.

It's easy to be sympathetic about why artists don't want their work
used in a proprietary engine. The issue is complex, and Bart has
tried to weigh out some pros and cons of this in his blogpost above.
There's also some risk in that some authors have expressed interest in
making a separate copyleft license. This could be very unfortunate
for license proliferation reasons, and especially because copyleft
does best when there's a
[http://gondwanaland.com/mlog/2007/12/01/copyleft-pd/ single copyleft license per domain].

But here's another set of likely complexities with this:

'''Number one:''' In the example shown above, in a sense it's not true
that artists get a second class copyleft. The reverse also applies:

.---------------. .----------------.
| FaiF CONTENT | | CLOSED CONTENT |
+---------------+ +----------------+
| FaiF CODE | | FaiF CODE |
'---------------' '----------------'
| ^
'-----------YOINK---------------'

So while it's true that in the dual-layer system, copylefted
free-as-in-freedom content can be "yoinked" and dumped into a
proprietary game or game engine. But the reverse is also true;
copylefted game engine code can also be yoinked and used with to power
a free-engine-yet-proprietary game using proprietary assets. So
second class citizenship is not true; both sides are cat risk of
having their separate layer yoinked and used in something proprietary.

'''Number two:''' Getting the copyleft-works-across-layers bit to work
right without restricting mere viewer programs could be very hard to
write the correct way, could be excessively complex, and could even
end up in a license that's deemed nonfree if done wrong.

'''Number three:''' The current "separate layers" distinction between
code and content may result in some un-ideal circumstances, but people
have come to rely on it, and it's probably significantly easier to
manage things preserving these layers than to change them.

'''Number four:''' There's still a significant amount of copyleft
protection being done on the content layer even if the culture layer
is dropped onto a proprietary software layer. To put it this way: Say
Zynga or Nintendo were to take your CC BY-SA licensed 3d model and
were to drop it into their proprietary game with their proprietary
engine. If the copyleft layer really does span the whole content
layer, then that means that they also have to release all the rest of
their content to stay in compliance, and that's potentially a
tremendous payback on its own in a way.

That said, it's very reasonable that some artists are frustrated with
this copyleft divide and we should take this into careful consideration.

== Increasing/clarifying scope of what's a derivative ==

The 3.0 Creative Commons licenses provide clarification on what is and
isn't an adaptation/derivative as opposed to a mere collection:

For the avoidance of doubt, where the Work is a musical work,
performance or phonogram, the synchronization of the Work in
timed-relation with a moving image ("synching") will be considered
an Adaptation for the purpose of this License.

Various people in the free software gaming community have commented on
the fact that it would be good to get more clarifications in the
license about what's an adaptation, making it clear that combining
works in a game ''is'' a derivative. For example, this "syncing"
example probably intends to cover works such as multiple character
models that are BY-SA all placed together and interacting in the same
file, but it doesn't explicitly say so.

One concern that has been raised is that the part that "binds"
together various assets in a game is the engine itself, and that if
the copyleft doesn't extend to the engine layer, maybe it doesn't
properly encompass all assets:

[asset] [asset] [asset]
\ | /
\ | /
[engine]
|
V
Player experience

There's a good chance this isn't a concern however, as there's plenty
of things that aren't game engines that also load a bunch of separate
components and combine them into a single media experience.

Even so, it would be helpful to make clear that something along the
lines of loading several pieces of media together, for example in a
game, was a clear adaptation.

== Source release? ==

Right now, unlike the GPL, BY-SA does not have a requirement for
source release. It's been proposed that this could possibly become a
requirement in CC BY-SA 4.0, but this seems unlikely:

* This could mean plenty of works never released with sources before will suddenly become out of compliance
* Unlike with software, where there's a clear binary of source or no source, in other forms of content it's often a gradient. See Big Buck Bunny/Sita Sings the Blues examples described the GPL compatibility section of this document.

It's likely we can't or shouldn't make this a requirement for CC BY-SA
4.0, but perhaps we could improve messaging generally to encourage
more community sharing of sources.

== DRM in BY-SA but not BY ==

In talking to some OpenGameArt members about licensing issues, several
expressed interest in keeping anti-DRM provisions in BY-SA as it's a
copyleft license, but remove them from CC BY (under the rationale the
CC BY approximately the equivalent of MIT/BSD licenses and CC BY-SA
approximately the equivalent of the GPL).

<references/>

4.0/Games 3d printing and functional content

2012-01-04T22:54:19Z

Christopher Webber: Making a couple of tweaks per Arne's suggestions

= Background =

The purpose of this page is to collect thoughts on issues that affect
games and projects that span the domains of cultural and
functional/software works. There are actually quite a few categories
of works that cross this domain, but games, as creative works that *by
necessity* combine code and artwork together, perhaps expose and
encounter some of these issues the most clearly. However games are
not the only area that contain this overlap; for example, 3d printing
is an emerging medium where the line between funtional and cultural is
either blurred or interwoven. It's likely that as the spaces of free
software and free culture (ideally) grow, we'll continue to see more
and more examples of this overlap.

Most of this wiki page will involve issues of the code/functional and
cultural works overlap, but some bits at the end will cover some other
issues raised by speaking with members of the free software gaming
community.

== Background on separation of functional/software and cultural layers ==

As further background, traditionally we've held a fairly clear
division between the free culture and free software spaces. This
division is partly because it's a useful distinction, and partly a
historic one. (The FSF has held this position or something like it
for a long time; alluded to slightly on their
[http://www.gnu.org/philosophy/free-system-distribution-guidelines.html#non-functional-data distribution guidelines about non-functional data].)

It looks something like:

.----------.
| CONTENT |
+----------+
| CODE |
'----------'

In a game context, content might be art, music, story, plain character
descriptions. Code would be the game engine, game scripting, etc.

In a free-as-in-freedom type environment the former would be under
free culture and the user freedom respecting subset of Creative
Commons licenses, and code would be free software licenses such as
MIT/BSD or the GPL.

One of the other results of this (licensing) division though is that
you can also have one half of this layer be proprietary and the other
be free-as-in-freedom. So, for example, the first person shooter
Quake was released under the GPL but the game content was kept
proprietary. Likewise, it's possible that someone could have a game
whose assets were released completely as free cultural works but the
software wasn't; this hasn't seemed to have happened (but some artists
have expressed concern about it). But outside of games, people play
CC licensed content in proprietary media players or view them in
proprietary browsers all the time.

In general, the software/content division in many areas works just
fine as separate layers. But sometimes there is a certain kind of
content that spans both. For example say you have a game that's using
CC BY-SA content and the GPL for the engine. In this you have level
files or character description files saying this is placed here, that's
there, and here's a cute block of text describing this creature if you
look at them in info mode. At this point, that sounds like content,
and so falls into the CC licensing. But what happens if in this same
file there's a certain amount of scripting? It has logic, it assigns
variables, but it also has some programming code.

.----------------.
|CONTENT.--------.|
| |scripted||
+-------| level |+
|CODE '--------'|
| |
'-----------------'

This actually happens all the time in games (both Wesnoth and Frogatto
use an engine that's a bunch of config files that describe maps,
scenarios, storylines, and creatures but which contain a functional
programming language embedded inside them also; see
[http://svn.gna.org/viewcvs/wesnoth/trunk/data/campaigns/Heir_To_The_Throne/scenarios/05b_Isle_of_the_Damned.cfg?view=markup this wesnoth level file which looks like mostly data]
and
[https://github.com/frogatto/frogatto/blob/master/data/objects/enemies/bosses/moth_boss.cfg this boss file from Frogatto that looks like code]
<ref>... technically Frogatto developers consider this to be all content,
but it's also an interpreted language. The intention here isn't to
pass judgement on their interpretation (if the developers don't intend
to enforce the copyleft on the scripting layer, they're the only ones
that can do that anyway) but their files provide pretty clear examples
despite them drawing a line somewhere else.</ref> If for example we
consider a game engine that uses Python as an interpreted language but
which has a backend bound by the GPL to have to follow the GPL, surely
combo content/code files like this might provide an "intertwined data
and code" scenario.

This might seem like a very one-off type of consideration, something
not worth considering generally with CC, but I don't think it is.
Surely we want to see more free software and free culture overlapping,
and it is likely that when that happens there may be scenarios when
that happens where some sort of difficult intertwining of code and
content will happen and we'll have to consider what to do about
copyleft incompatibility.

Here's another example not game related, rooted in the physical space:
3d printing. There's a potential that 3d printing could become (and
actually, it's already starting to become) the type of revolution for
physical things what computers and the internet have been for
information.

The most popular 3d printer is something called the
[http://reprap.org/wiki/RepRap RepRap], which has been released under
the GPL. Arguably because of the strength of this copyleft, several
commercial versions have been released such as the
[http://store.makerbot.com/thing-o-matic-kit-mk7.html MakerBot Thing-O-Matic].
But here's an iteration of the 3d printer called the
[http://www.thingiverse.com/thing:14111 Ronthomp Mendel]
which is labeled as being BY-SA, even though it uses a GPL'ed design.

Now, technically the BY-SA and the GPL are not compatible, and it's
probable that this is an issue of education because maybe the Ronthomp
Mendel should simply be under the GPL as well. But here's a
question... what if the Ronthomp Mendel were making use of some BY-SA
parts? What is someone tried to make a new 3d printer that made use
of some cool new gear system that someone released as BY-SA?

One could argue that in the copyleft scope, functional things such as
the RepRap should be GPL'ed (citation needed, but it's been argued at
least by Eben Moglen that GPL is great for hardware because it also
takes advantage of GPL's patent pool protections) and that purely
cultural things such as the
[http://www.thingiverse.com/thing:10367 Octocat print] should be CC BY-SA.
But a) not everyone has agreed on this, plenty of people are using
BY-SA for functional works, and b) this breakdown itself could really
stop working right when we try to create a new project that combines
cultural and functional works.

(One could possibly ask
[http://www.publicknowledge.org/blog/3d-printing-settlers-catan-probably-not-illeg how far copyright applies to functional 3d printed works]
(and therefore, how far copyleft applies), and there's not much
background to show how it applies at all yet. I'm writing this
assuming it does apply.)

To more clearly illustrate the problem, let me first make a list of
some various cool 3d printable things under different licenses:

GPL things:
* [http://reprap.org/wiki/RepRap RepRap 3d printer] (on which most modern 3d printers are based)
* [http://www.thingiverse.com/thing:951 Bead belt gear]

BY-SA things:
* [http://www.thingiverse.com/thing:13368 Motorized functional differential gear system]
* [http://www.thingiverse.com/thing:14599 Robot chassis]
* [http://www.thingiverse.com/thing:10367 Octocat]

BY things:
* [http://www.thingiverse.com/thing:13827 Botmobile dune buggy]

From this list of things already we can see a list of things that
could be blocked. Say you want to power your 3d printer by human
energy by plugging in the motorized functional differential gear
system? Okay, maybe possibly you could argue that that's functional
and should have been GPL'ed, but what about the dune buggy, which is
closer to a children's toy? What about combining that with some
GPL'ed part?

But most complicated of all, what if you wanted to make a walking
cat-robot that uses a BY-SA cat design (maybe the head of the octocat)
and combines it with the robot chassis and some bears and the bead
belt gear and a bunch of other things. Suddenly we've a cool
intersection of culture and functionality is blocked by two copyleft
licenses that both have the same (and best) intentions at heart.
We've blocked the cat-robot from ever being born (well, within license
compliance) by best-intentions-copyleft. This is a problem, and if
the world continues to develop in the direction we want it to, I think
we're going to start seeing it a lot more.

= Possible actions =
== GPL compatibility ==

Probably the most actionable and most urgently raised amongst issues
when discussing with relevant community members is that of a one-way
compatibility between CC BY-SA (and probably also CC BY) and the GPL.
It's almost certainly not possible at this point (and probably
undesirable) that GPL->BY-SA compatibility is possible, but if we
choose to do it BY-SA->GPL (and probably BY->GPL) should be.

The benefits of this is that it will resolve the tricky issues with
"interwoven" content and cultural works. Clashes in copyleft licenses
which share the same goals are unfortunate if they block useful things
from being created. As
[https://creativecommons.org/weblog/entry/30676#comment-356183 Arne Babenhauserheide said],

<blockquote>... the case of cc-by-sa not being comptible with the GPL is very sad,
because they share exactly the same goals: Copyleft. Thus their
incompatibility creates a real split in cultural works. If the 4.0
licenses could make it possible to combine cc works under licenses
with compatible concepts (cc by, cc by-sa) with the GPL, that would be
a huge step towards a unified free culture.</blockquote>

So what are potential downsides? The main downside is that
[http://wiki.creativecommons.org/Frequently_Asked_Questions#Can_I_apply_a_Creative_Commons_license_to_software.3F Creative Commons licenses are not acceptable for software]
and we don't want to spread a misconception that they are. If we go
forward with this, we should develop strong messaging that makes clear
that software should still not be released as BY-SA and that this is
for avoiding conflicts in complicated areas of interwoven cultural and
functional/software works.

The other possible downside is whether or not source requirements for
art might make incorporating BY-SA works with the GPL difficult. Ie,
there is no source requirement for BY-SA, and there is one for the
GPL. The GPL says:

The “source code” for a work means the preferred form of the work
for making modifications to it. “Object code” means any non-source
form of a work.

See also the "source release" section of this document for detailing
on the complexities of source code requirements in BY-SA. But as for
fulfilling the requirements of the GPL, what about the following:

* In programming, the division of what source and object code is well understood. In content it's more of a gradient
* For example, the Blender Foundation releases all the "source code" of its films such as Big Buck Bunny and etc by releasing the .blend files (though it is not a requirement of the license).
* However, what if someone made a remix of Big Buck Bunny where they changed the order of scenes, added a psychadelic overlay, and added new music. But the "source" they worked with was not on the .blend file level, but by remixing the rendered film itself. If incorporated with a GPL'ed work, would the source requirement apply, and would it in fact require sharing the source all the way down to the original .blend files?
* What about a film like Sita Sings the Blues, which is BY-SA but from which the source files were never redistributed at all? It's unlikely the content/code layers would be intertwined if combined with software, but let's pretend for a moment that it was. Would "combining" with a GPL'ed work mean requiring distribution of the original files from which the film was made? What if those were lost? What if there's still a lot you can do without the "original source files", although admittedly not as much as if you had them?
* In other words, just how far does "preferred form of the work for making modifications to it" go down? What if people are remixing it on different layers, and the artists themselves prefer separate layers? Does the GPL give flexibility here?

== Scoping copyleft across and code ==

Bart Kelsey has written an excellent article,
"[http://freegamer.blogspot.com/2011/12/why-we-need-better-copyleft-for-artists.html Why we need a stronger copyleft for artists, and how this might be accomplished]".

It's best just to read that article, but the crux of the argument is
that artists who contribute artwork to free software games often worry
that their artwork will be "lifted" and dropped into some proprietary
game. In other words, something along the lines of this:

,---------YOINK----------,
| V
.---------------. .---------------.
| FaiF CONTENT | | FaiF CONTENT |
+---------------+ +---------------+
| FaiF CODE | | CLOSED CODE |
'---------------' '---------------'

Where FaiF stands for "Free as in Freedom". The argument is that if
you're producing free-as-in-freedom content, you won't want your
content being lifted and dropped into a proprietary codebase (ie, my
dragon creature which is BY-SA could still be used with a game with a
proprietary engine). Bart has pointed out that if the artwork were
done in something like the GIMP, it would be considered on a separate
layer, so even if copyleft like CC BY-SA were used, it could still be
compromised by being lifted and dropped into a proprietary
codebase... but if the artwork were instead done embedded into the
codebase itself like so:

/* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation, either version 3 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/

var smiley = [
0,0,0,0,0,0,1,1,1,1,0,0,0,0,0,0,
0,0,0,0,1,1,0,0,0,0,1,1,0,0,0,0,
0,0,0,1,0,0,0,0,0,0,0,0,1,0,0,0,
0,0,1,0,0,0,0,0,0,0,0,0,0,1,0,0,
0,1,0,0,1,1,0,0,0,0,1,1,0,0,1,0,
0,1,0,0,1,1,0,0,0,0,1,1,0,0,1,0,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,1,0,0,0,0,0,0,0,0,1,0,0,1,
0,1,0,0,1,0,0,0,0,0,0,1,0,0,1,0,
0,1,0,0,0,1,1,1,1,1,1,0,0,0,1,0,
0,0,1,0,0,0,0,0,0,0,0,0,0,1,0,0,
0,0,0,1,0,0,0,0,0,0,0,0,1,0,0,0,
0,0,0,0,1,1,0,0,0,0,1,1,0,0,0,0,
0,0,0,0,0,0,1,1,1,1,0,0,0,0,0,0,
];

So, why should artists who use normal, real graphical tools not get
the same copyleft benefit of keeping their stuff protected with the
rest of the program under the GPL as do coders or artists who would
use a text-editor to hardcode their assets into their work? Are
artists being treated as if they are using some sort of second class
citizen copyleft then? Some artists in the FOSS gaming area feel that
they would be. (Some have even expressed interest in preventing
proprietization by using an -NC license, but there's an irony there in
that an NC license is proprietary anyway.)

The proposal then is for a copyleft license whose requirements reach
across the content layer over into the software layer, requiring a
free software licensed engine or etc. Complexities quickly arise as
in terms of "what about viewing the image in a proprietary browser or
other viewer, etc" and Bart has proposed trying to seperate terms out
for that, particularly by doing packaging-based copyleft.

It's easy to be sympathetic about why artists don't want their work
used in a proprietary engine. The issue is complex, and Bart has
tried to weigh out some pros and cons of this in his blogpost above.
There's also some risk in that some authors have expressed interest in
making a separate copyleft license. This could be very unfortunate
for license proliferation reasons, and especially because copyleft
does best when there's a
[http://gondwanaland.com/mlog/2007/12/01/copyleft-pd/ single copyleft license per domain].

But here's another set of likely complexities with this:

'''Number one:''' In the example shown above, in a sense it's not true
that artists get a second class copyleft. The reverse also applies:

.---------------. .----------------.
| FaiF CONTENT | | CLOSED CONTENT |
+---------------+ +----------------+
| FaiF CODE | | FaiF CODE |
'---------------' '----------------'
| ^
'-----------YOINK---------------'

So while it's true that in the dual-layer system, copylefted
free-as-in-freedom content can be "yoinked" and dumped into a
proprietary game or game engine. But the reverse is also true;
copylefted game engine code can also be yoinked and used with to power
a free-engine-yet-proprietary game using proprietary assets. So
second class citizenship is not true; both sides are cat risk of
having their separate layer yoinked and used in something proprietary.

'''Number two:''' Getting the copyleft-works-across-layers bit to work
right without restricting mere viewer programs could be very hard to
write the correct way, could be excessively complex, and could even
end up in a license that's deemed nonfree if done wrong.

'''Number three:''' The current "separate layers" distinction between
code and content may result in some un-ideal circumstances, but people
have come to rely on it, and it's probably significantly easier to
manage things preserving these layers than to change them.

'''Number four:''' There's still a significant amount of copyleft
protection being done on the content layer even if the culture layer
is dropped onto a proprietary software layer. To put it this way: Say
Zynga or Nintendo were to take your CC BY-SA licensed 3d model and
were to drop it into their proprietary game with their proprietary
engine. If the copyleft layer really does span the whole content
layer, then that means that they also have to release all the rest of
their content to stay in compliance, and that's potentially a
tremendous payback on its own in a way.

That said, it's very reasonable that some artists are frustrated with
this copyleft divide and we should take this into careful consideration.

== Increasing/clarifying scope of what's a derivative ==

The 3.0 Creative Commons licenses provide clarification on what is and
isn't an adaptation/derivative as opposed to a mere collection:

For the avoidance of doubt, where the Work is a musical work,
performance or phonogram, the synchronization of the Work in
timed-relation with a moving image ("synching") will be considered
an Adaptation for the purpose of this License.

Various people in the free software gaming community have commented on
the fact that it would be good to get more clarifications in the
license about what's an adaptation, making it clear that combining
works in a game ''is'' a derivative. For example, this "syncing"
example probably intends to cover works such as multiple character
models that are BY-SA all placed together and interacting in the same
file, but it doesn't explicitly say so.

One concern that has been raised is that the part that "binds"
together various assets in a game is the engine itself, and that if
the copyleft doesn't extend to the engine layer, maybe it doesn't
properly encompass all assets:

[asset] [asset] [asset]
\ | /
\ | /
[engine]
|
V
Player experience

There's a good chance this isn't a concern however, as there's plenty
of things that aren't game engines that also load a bunch of separate
components and combine them into a single media experience.

Even so, it would be helpful to make clear that something along the
lines of loading several pieces of media together, for example in a
game, was a clear adaptation.

== Source release? ==

Right now, unlike the GPL, BY-SA does not have a requirement for
source release. It's been proposed that this could possibly become a
requirement in CC BY-SA 4.0, but this seems unlikely:

* This could mean plenty of works never released with sources before will suddenly become out of compliance
* Unlike with software, where there's a clear binary of source or no source, in other forms of content it's often a gradient. See Big Buck Bunny/Sita Sings the Blues examples described the GPL compatibility section of this document.

It's likely we can't or shouldn't make this a requirement for CC BY-SA
4.0, but perhaps we could improve messaging generally to encourage
more community sharing of sources.

== DRM in BY-SA but not BY ==

In talking to some OpenGameArt members about licensing issues, several
expressed interest in keeping anti-DRM provisions in BY-SA as it's a
copyleft license, but remove them from CC BY (under the rationale the
CC BY approximately the equivalent of MIT/BSD licenses and CC BY-SA
approximately the equivalent of the GPL).

4.0/Games 3d printing and functional content

2012-01-04T22:41:42Z

Christopher Webber:

= Background =

The purpose of this page is to collect thoughts on issues that affect
games and projects that span the domains of cultural and
functional/software works. There are actually quite a few categories
of works that cross this domain, but games, as creative works that *by
necessity* combine code and artwork together, perhaps expose and
encounter some of these issues the most clearly. However games are
not the only area that contain this overlap; for example, 3d printing
is an emerging medium where the line between funtional and cultural is
either blurred or interwoven. It's likely that as the spaces of free
software and free culture (ideally) grow, we'll continue to see more
and more examples of this overlap.

Most of this wiki page will involve issues of the code/functional and
cultural works overlap, but some bits at the end will cover some other
issues raised by speaking with members of the free software gaming
community.

== Background on separation of functional/software and cultural layers ==

As further background, traditionally we've held a fairly clear
division between the free culture and free software spaces. This
division is partly because it's a useful distinction, and partly a
historic one. (The FSF has held this position or something like it
for a long time; alluded to slightly on their
[http://www.gnu.org/philosophy/free-system-distribution-guidelines.html#non-functional-data distribution guidelines about non-functional data].)

It looks something like:

.----------.
| CONTENT |
+----------+
| CODE |
'----------'

In a game context, content might be art, music, story, plain character
descriptions. Code would be the game engine, game scripting, etc.

In a free-as-in-freedom type environment the former would be under
free culture and the user freedom respecting subset of Creative
Commons licenses, and code would be free software licenses such as
MIT/BSD or the GPL.

One of the other results of this (licensing) division though is that
you can also have one half of this layer be proprietary and the other
be free-as-in-freedom. So, for example, the first person shooter
Quake was released under the GPL but the game content was kept
proprietary. Likewise, it's possible that someone could have a game
whose assets were released completely as free cultural works but the
software wasn't; this hasn't seemed to have happened (but some artists
have expressed concern about it). But outside of games, people play
CC licensed content in proprietary media players or view them in
proprietary browsers all the time.

In general, the software/content division in many areas works just
fine as separate layers. But sometimes there is a certain kind of
content that spans both. For example say you have a game that's using
CC BY-SA content and the GPL for the engine. In this you have level
files or character description files saying this is placed here, that's
there, and here's a cute block of text describing this creature if you
look at them in info mode. At this point, that sounds like content,
and so falls into the CC licensing. But what happens if in this same
file there's a certain amount of scripting? It has logic, it assigns
variables, but it also has some programming code.

.----------------.
|CONTENT.--------.|
| |scripted||
+-------| level |+
|CODE '--------'|
| |
'-----------------'

This actually happens all the time in games (both Wesnoth and Frogatto
use an engine that's a bunch of config files that describe maps,
scenarios, storylines, and creatures but which contain a functional
programming language embedded inside them also; see
[http://svn.gna.org/viewcvs/wesnoth/trunk/data/campaigns/Heir_To_The_Throne/scenarios/05b_Isle_of_the_Damned.cfg?view=markup this wesnoth level file which looks like mostly data]
and
[https://github.com/frogatto/frogatto/blob/master/data/objects/enemies/bosses/moth_boss.cfg this boss file from Frogatto that looks like code]
... technically Frogatto developers consider this to be all content,
but it's also an interpreted language. The intention here isn't to
pass judgement on their interpretation (if the developers don't intend
to enforce the copyleft on the scripting layer, they're the only ones
that can do that anyway) but their files provide pretty clear examples
despite them drawing a line somewhere else, and if for example we
consider a game engine that uses Python as an interpreted language but
which has a backend bound by the GPL to have to follow the GPL, surely
combo content/code files like this might provide an "intertwined data
and code" scenario.

This might seem like a very one-off type of consideration, something
not worth considering generally with CC, but I don't think it is.
Surely we want to see more free software and free culture overlapping,
and it is likely that when that happens there may be scenarios when
that happens where some sort of difficult intertwining of code and
content will happen and we'll have to consider what to do about
copyleft incompatibility.

Here's another example not game related, rooted in the physical space:
3d printing. There's a potential that 3d printing could become (and
actually, it's already starting to become) the type of revolution for
physical things what computers and the internet have been for
information.

The most popular 3d printer is something called the
[http://reprap.org/wiki/RepRap RepRap], which has been released under
the GPL. Arguably because of the strength of this copyleft, several
commercial versions have ben released such as the
[http://store.makerbot.com/thing-o-matic-kit-mk7.html MakerBot Thing-O-Matic].
But here's an iteration of the 3d printer called the
[http://www.thingiverse.com/thing:14111 Ronthomp Mendel]
which is labeled as being BY-SA, even though it uses a GPL'ed design.

Now, technically the BY-SA and the GPL are not compatible, and it's
probable that this is an issue of education because maybe the Ronthomp
Mendel should simply be under the GPL as well. But here's a
question... what if the Ronthomp Mendel were making use of some BY-SA
parts? What is someone tried to make a new 3d printer that made use
of some cool new gear system that someone released as BY-SA?

One could argue that in the copyleft scope, functional things such as
the RepRap should be GPL'ed (citation needed, but it's been argued at
least by Eben Moglen that GPL is great for hardware because it also
takes advantage of GPL's patent pool protections) and that purely
cultural things such as the
[http://www.thingiverse.com/thing:10367 Octocat print] should be CC BY-SA.
But a) not everyone has agreed on this, plenty of people are using
BY-SA for functional works, and b) this breakdown itself could really
stop working right when we try to create a new project that combines
cultural and functional works.

(One could possibly ask
[http://www.publicknowledge.org/blog/3d-printing-settlers-catan-probably-not-illeg how far copyright applies to functional 3d printed works]
(and therefore, how far copyleft applies), and there's not much
background to show how it applies at all yet. I'm writing this
assuming it does apply.)

To more clearly illustrate the problem, let me first make a list of
some various cool 3d printable things under different licenses:

GPL things:
* [http://reprap.org/wiki/RepRap RepRap 3d printer] (on which most modern 3d printers are based)
* [http://www.thingiverse.com/thing:951 Bead belt gear]

BY-SA things:
* [http://www.thingiverse.com/thing:13368 Motorized functional differential gear system]
* [http://www.thingiverse.com/thing:14599 Robot chassis]
* [http://www.thingiverse.com/thing:10367 Octocat]

BY things:
* [http://www.thingiverse.com/thing:13827 Botmobile dune buggy]

From this list of things already we can see a list of things that
could be blocked. Say you want to power your 3d printer by human
energy by plugging in the motorized functional differential gear
system? Okay, maybe possibly you could argue that that's functional
and should have been GPL'ed, but what about the dune buggy, which is
closer to a children's toy? What about combining that with some
GPL'ed part?

But most complicated of all, what if you wanted to make a walking
cat-robot that uses a BY-SA cat design (maybe the head of the octocat)
and combines it with the robot chassis and some bears and the bead
belt gear and a bunch of other things. Suddenly we've a cool
intersection of culture and functionality is blocked by two copyleft
licenses that both have the same (and best) intentions at heart.
We've blocked the cat-robot from ever being born (well, within license
compliance) by best-intentions-copyleft. This is a problem, and if
the world continues to develop in the direction we want it to, I think
we're going to start seeing it a lot more.

= Possible actions =
== GPL compatibility ==

Probably the most actionable and most urgently raised amongst issues
when discussing with relevant community members is that of a one-way
compatibility between CC BY-SA (and probably also CC BY) and the GPL.
It's almost certainly not possible at this point (and probably
undesirable) that GPL->BY-SA compatibility is possible, but if we
choose to do it BY-SA->GPL (and probably BY->GPL) should be.

The benefits of this is that it will resolve the tricky issues with
"interwoven" content and cultural works. Clashes in copyleft licenses
which share the same goals are unfortunate if they block useful things
from being created. As
[https://creativecommons.org/weblog/entry/30676#comment-356183 Arne Babenhauserheide said],

<blockquote>... the case of cc-by-sa not being comptible with the GPL is very sad,
because they share exactly the same goals: Copyleft. Thus their
incompatibility creates a real split in cultural works. If the 4.0
licenses could make it possible to combine cc works under licenses
with compatible concepts (cc by, cc by-sa) with the GPL, that would be
a huge step towards a unified free culture.</blockquote>

So what are potential downsides? The main downside is that
[http://wiki.creativecommons.org/Frequently_Asked_Questions#Can_I_apply_a_Creative_Commons_license_to_software.3F Creative Commons licenses are not acceptable for software]
and we don't want to spread a misconception that they are. If we go
forward with this, we should develop strong messaging that makes clear
that software should still not be released as BY-SA and that this is
for avoiding conflicts in complicated areas of interwoven cultural and
functional/software works.

The other possible downside is whether or not source requirements for
art might make incorporating BY-SA works with the GPL difficult. Ie,
there is no source requirement for BY-SA, and there is one for the
GPL. The GPL says:

The “source code” for a work means the preferred form of the work
for making modifications to it. “Object code” means any non-source
form of a work.

See also the "source release" section of this document for detailing
on the complexities of source code requirements in BY-SA. But as for
fulfilling the requirements of the GPL, what about the following:

* In programming, the division of what source and object code is well understood. In content it's more of a gradient
* For example, the Blender Foundation releases all the "source code" of its films such as Big Buck Bunny and etc by releasing the .blend files (though it is not a requirement of the license).
* However, what if someone made a remix of Big Buck Bunny where they changed the order of scenes, added a psychadelic overlay, and added new music. But the "source" they worked with was not on the .blend file level, but by remixing the rendered film itself. If incorporated with a GPL'ed work, would the source requirement apply, and would it in fact require sharing the source all the way down to the original .blend files?
* What about a film like Sita Sings the Blues, which is BY-SA but from which the source files were never redistributed at all? It's unlikely the content/code layers would be intertwined if combined with software, but let's pretend for a moment that it was. Would "combining" with a GPL'ed work mean requiring distribution of the original files from which the film was made? What if those were lost? What if there's still a lot you can do without the "original source files", although admittedly not as much as if you had them?
* In other words, just how far does "preferred form of the work for making modifications to it" go down? What if people are remixing it on different layers, and the artists themselves prefer separate layers? Does the GPL give flexibility here?

== Scoping copyleft across and code ==

Bart Kelsey has written an excellent article,
"[http://freegamer.blogspot.com/2011/12/why-we-need-better-copyleft-for-artists.html Why we need a stronger copyleft for artists, and how this might be accomplished]".

It's best just to read that article, but the crux of the argument is
that artists who contribute artwork to free software games often worry
that their artwork will be "lifted" and dropped into some proprietary
game. In other words, something along the lines of this:

,---------YOINK----------,
| V
.---------------. .---------------.
| FaiF CONTENT | | FaiF CONTENT |
+---------------+ +---------------+
| FaiF CODE | | CLOSED CODE |
'---------------' '---------------'

Where FaiF stands for "Free as in Freedom". The argument is that if
you're producing free-as-in-freedom content, you won't want your
content being lifted and dropped into a proprietary codebase (ie, my
dragon creature which is BY-SA could still be used with a game with a
proprietary engine). Bart has pointed out that if the artwork were
done in something like the GIMP, it would be considered on a separate
layer, so even if copyleft like CC BY-SA were used, it could still be
compromised by being lifted and dropped into a proprietary
codebase... but if the artwork were instead done embedded into the
codebase itself like so:

/* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation, either version 3 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/

var smiley = [
0,0,0,0,0,0,1,1,1,1,0,0,0,0,0,0,
0,0,0,0,1,1,0,0,0,0,1,1,0,0,0,0,
0,0,0,1,0,0,0,0,0,0,0,0,1,0,0,0,
0,0,1,0,0,0,0,0,0,0,0,0,0,1,0,0,
0,1,0,0,1,1,0,0,0,0,1,1,0,0,1,0,
0,1,0,0,1,1,0,0,0,0,1,1,0,0,1,0,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,
1,0,0,1,0,0,0,0,0,0,0,0,1,0,0,1,
0,1,0,0,1,0,0,0,0,0,0,1,0,0,1,0,
0,1,0,0,0,1,1,1,1,1,1,0,0,0,1,0,
0,0,1,0,0,0,0,0,0,0,0,0,0,1,0,0,
0,0,0,1,0,0,0,0,0,0,0,0,1,0,0,0,
0,0,0,0,1,1,0,0,0,0,1,1,0,0,0,0,
0,0,0,0,0,0,1,1,1,1,0,0,0,0,0,0,
];

So, why should artists who use normal, real graphical tools not get
the same copyleft benefit of keeping their stuff protected with the
rest of the program under the GPL as do coders or artists who would
use a text-editor to hardcode their assets into their work? Are
artists being treated as if they are using some sort of second class
citizen copyleft then? Some artists in the FOSS gaming area feel that
they would be. (Some have even expressed interest in preventing
proprietization by using an -NC license, but there's an irony there in
that an NC license is proprietary anyway.)

The proposal then is for a copyleft license whose requirements reach
across the content layer over into the software layer, requiring a
free software licensed engine or etc. Complexities quickly arise as
in terms of "what about viewing the image in a proprietary browser or
other viewer, etc" and Bart has proposed trying to seperate terms out
for that, particularly by doing packaging-based copyleft.

It's easy to be sympathetic about why artists don't want their work
used in a proprietary engine. The issue is complex, and Bart has
tried to weigh out some pros and cons of this in his blogpost above.
There's also some risk in that some authors have expressed interest in
making a separate copyleft license. This could be very unfortunate
for license proliferation reasons, and especially because copyleft
does best when there's a
[http://gondwanaland.com/mlog/2007/12/01/copyleft-pd/ single copyleft license per domain].

But here's another set of likely complexities with this:

'''Number one:''' In the example shown above, in a sense it's not true
that artists get a second class copyleft. The reverse also applies:

.---------------. .----------------.
| FaiF CONTENT | | CLOSED CONTENT |
+---------------+ +----------------+
| FaiF CODE | | FaiF CODE |
'---------------' '----------------'
| ^
'-----------YOINK---------------'

So while it's true that in the dual-layer system, copylefted
free-as-in-freedom content can be "yoinked" and dumped into a
proprietary game or game engine. But the reverse is also true;
copylefted game engine code can also be yoinked and used with to power
a free-engine-yet-proprietary game using proprietary assets. So
second class citizenship is not true; both sides are cat risk of
having their separate layer yoinked and used in something proprietary.

'''Number two:''' Getting the copyleft-works-across-layers bit to work
right without restricting mere viewer programs could be very hard to
write the correct way, could be excessively complex, and could even
end up in a license that's deemed nonfree if done wrong.

'''Number three:''' The current "separate layers" distinction between
code and content may result in some un-ideal circumstances, but people
have come to rely on it, and it's probably significantly easier to
manage things preserving these layers than to change them.

'''Number four:''' There's still a significant amount of copyleft
protection being done on the content layer even if the culture layer
is dropped onto a proprietary software layer. To put it this way: Say
Zynga or Nintendo were to take your CC BY-SA licensed 3d model and
were to drop it into their proprietary game with their proprietary
engine. If the copyleft layer really does span the whole content
layer, then that means that they also have to release all the rest of
their content to stay in compliance, and that's potentially a
tremendous payback on its own in a way.

That said, it's very reasonable that some artists are frustrated with
this copyleft divide and we should take this into careful consideration.

== Increasing/clarifying scope of what's a derivative ==

The 3.0 Creative Commons licenses provide clarification on what is and
isn't an adaptation/derivative as opposed to a mere collection:

For the avoidance of doubt, where the Work is a musical work,
performance or phonogram, the synchronization of the Work in
timed-relation with a moving image ("synching") will be considered
an Adaptation for the purpose of this License.

Various people in the free software gaming community have commented on
the fact that it would be good to get more clarifications in the
license about what's an adaptation, making it clear that combining
works in a game ''is'' a derivative. For example, this "syncing"
example probably intends to cover works such as multiple character
models that are BY-SA all placed together and interacting in the same
file, but it doesn't explicitly say so.

One concern that has been raised is that the part that "binds"
together various assets in a game is the engine itself, and that if
the copyleft doesn't extend to the engine layer, maybe it doesn't
properly encompass all assets:

[asset] [asset] [asset]
\ | /
\ | /
[engine]
|
V
Player experience

There's a good chance this isn't a concern however, as there's plenty
of things that aren't game engines that also load a bunch of separate
components and combine them into a single media experience.

Even so, it would be helpful to make clear that something along the
lines of loading several pieces of media together, for example in a
game, was a clear adaptation.

== Source release? ==

Right now, unlike the GPL, BY-SA does not have a requirement for
source release. It's been proposed that this could possibly become a
requirement in CC BY-SA 4.0, but this seems unlikely:

* This could mean plenty of works never released with sources before will suddenly become out of compliance
* Unlike with software, where there's a clear binary of source or no source, in other forms of content it's often a gradient. See Big Buck Bunny/Sita Sings the Blues examples described the GPL compatibility section of this document.

It's likely we can't or shouldn't make this a requirement for CC BY-SA
4.0, but perhaps we could improve messaging generally to encourage
more community sharing of sources.

== DRM in BY-SA but not BY ==

In talking to some OpenGameArt members about licensing issues, several
expressed interest in keeping anti-DRM provisions in BY-SA as it's a
copyleft license, but remove them from CC BY (under the rationale the
CC BY approximately the equivalent of MIT/BSD licenses and CC BY-SA
approximately the equivalent of the GPL).

4.0/Games 3d printing and functional content

2011-12-22T18:03:32Z

Christopher Webber: Added section on GPL and BY-SA compatibility

4.0/Games 3d printing and functional content

2011-12-22T17:44:05Z

Christopher Webber: moved 4.0/Games and functional content to 4.0/Games 3d printing and functional content: 3d printing has become a huge part of this article

4.0/Games and functional content

2011-12-22T17:44:05Z

Christopher Webber: moved 4.0/Games and functional content to 4.0/Games 3d printing and functional content: 3d printing has become a huge part of this article

#REDIRECT [[4.0/Games 3d printing and functional content]]

4.0/Games 3d printing and functional content

2011-12-22T17:15:31Z

Christopher Webber: Adding some stuff per Rob Myers' suggestions.

4.0/Games 3d printing and functional content

2011-12-22T16:58:56Z

Christopher Webber: Removing a couple of unnecessary newlines

= Games and Functional Content =

== Background ==

The purpose of this page is to collect thoughts on issues that affect
games and projects that span the domains of cultural and
functional/software works. There are actually quite a few categories
of works that cross this domain, but games, as creative works that *by
necessity* combine code and artwork together, perhaps expose and
encounter some of these issues the most clearly. However games are
not the only area that contain this overlap; for example, 3d printing
is an emerging medium where the line between funtional and cultural is
either blurred or interwoven. It's likely that as the spaces of free
software and free culture (ideally) grow, we'll continue to see more
and more examples of this overlap.

Most of this wiki page will involve issues of the code/functional and
cultural works overlap, but some bits at the end will cover some other
issues raised by speaking with members of the free software gaming
community.

=== Background on separation of functional/software and cultural layers ===

As further background, traditionally we've held a fairly clear
division between the free culture and free software spaces. This
division is partly because it's a useful distinction, and partly a
historic one. It looks something like:

.----------.
| CONTENT |
+----------+
| CODE |
'----------'

In a game context, content might be art, music, story, plain character
descriptions. Code would be the game engine, game scripting, etc.

In a free-as-in-freedom type environment the former would be under
free culture and the user freedom respecting subset of Creative
Commons licenses, and code would be free software licenses such as
MIT/BSD or the GPL.

One of the other results of this (licensing) division though is that
you can also have one half of this layer be proprietary and the other
be free-as-in-freedom. So, for example, the first person shooter
Quake was released under the GPL but the game content was kept
proprietary. Likewise, it's possible that someone could have a game
whose assets were released completely as free cultural works but the
software wasn't; this hasn't seemed to have happened (but some artists
have expressed concern about it). But outside of games, people play
CC licensed content in proprietary media players or view them in
proprietary browsers all the time.

In general, the software/content division in many areas works just
fine as separate layers. But sometimes there is a certain kind of
content that spans both. For example say you have a game that's using
CC BY-SA content and the GPL for the engine. In this you have level
files or character description files saying this is placed here, that's
there, and here's a cute block of text describing this creature if you
look at them in info mode. At this point, that sounds like content,
and so falls into the CC licensing. But what happens if in this same
file there's a certain amount of scripting? It has logic, it assigns
variables, but it also has some programming code.

.----------------.
|CONTENT.--------.|
| |scripted||
+-------| level |+
|CODE '--------'|
| |
'-----------------'

This actually happens all the time in games (both Wesnoth and Frogatto
use an engine that's a bunch of config files that describe maps,
scenarios, storylines, and creatures but which contain a functional
programming language embedded inside them also; see
[http://svn.gna.org/viewcvs/wesnoth/trunk/data/campaigns/Heir_To_The_Throne/scenarios/05b_Isle_of_the_Damned.cfg?view=markup this wesnoth level file which looks like mostly data]
and
[https://github.com/frogatto/frogatto/blob/master/data/objects/enemies/bosses/moth_boss.cfg this boss file from Frogatto that looks like code]
... technically Frogatto developers consider this to be all content,
but it's also an interpreted language. The intention here isn't to
pass judgement on their interpretation (if the developers don't intend
to enforce the copyleft on the scripting layer, they're the only ones
that can do that anyway) but their files provide pretty clear examples
despite them drawing a line somewhere else, and if for example we
consider a game engine that uses Python as an interpreted language but
which has a backend bound by the GPL to have to follow the GPL, surely
combo content/code files like this might provide an "intertwined data
and code" scenario.

This might seem like a very one-off type of consideration, something
not worth considering generally with CC, but I don't think it is.
Surely we want to see more free software and free culture overlapping,
and it is likely that when that happens there may be scenarios when
that happens where some sort of difficult intertwining of code and
content will happen and we'll have to consider what to do about
copyleft incompatibility.

Here's another example not game related, rooted in the physical space:
3d printing. There's a potential that 3d printing could become (and
actually, it's already starting to become) the type of revolution for
physical things what computers and the internet have been for
information.

The most popular 3d printer is something called the
[http://reprap.org/wiki/RepRap RepRap], which has been released under
the GPL. Arguably because of the strength of this copyleft, several
commercial versions have ben released such as the
[http://store.makerbot.com/thing-o-matic-kit-mk7.html MakerBot Thing-O-Matic].
But here's an iteration of the 3d printer called the
[http://www.thingiverse.com/thing:14111 Ronthomp Mendel]
which is labeled as being BY-SA, even though it uses a GPL'ed design.
Now, technically the BY-SA and the GPL are not compatible, and it's
probable that this is an issue of education because maybe the Ronthomp
Mendel should simply be under the GPL as well. But here's a
question... what if the Ronthomp Mendel were making use of some BY-SA
parts? What is someone tried to make a new 3d printer that made use
of some cool new gear system that someone released as BY-SA?

One could argue that in the copyleft scope, functional things such as
the RepRap should be GPL'ed (citation needed, but it's been argued at
least by Eben Moglen that GPL is great for hardware because it also
takes advantage of GPL's patent pool protections) and that purely
cultural things such as the
[http://www.thingiverse.com/thing:10367 Octocat print] should be CC BY-SA.
But a) not everyone has agreed on this, plenty of people are using
BY-SA for functional works, and b) this breakdown itself could really
stop working right.

To more clearly illustrate the problem, let me first make a list of
some various cool 3d printable things under different licenses:

GPL things:
* [http://reprap.org/wiki/RepRap RepRap 3d printer] (on which most modern 3d printers are based)
* [http://www.thingiverse.com/thing:951 Bead belt gear]

BY-SA things:
* [http://www.thingiverse.com/thing:13368 Motorized functional differential gear system]
* [http://www.thingiverse.com/thing:14599 Robot chassis]
* [http://www.thingiverse.com/thing:10367 Octocat]

BY things:
* [http://www.thingiverse.com/thing:13827 Botmobile dune buggy]

From this list of things already we can see a list of things that
could be blocked. Say you want to power your 3d printer by human
energy by plugging in the motorized functional differential gear
system? Okay, maybe possibly you could argue that that's functional
and should have been GPL'ed, but what about the dune buggy, which is
closer to a children's toy? What about combining that with some
GPL'ed part? But most complicated of all, what if you wanted to make
a walking cat-robot that uses a BY-SA cat design (maybe the head of
the octocat) and combines it with the robot chassis and some bears and
the bead belt gear and a bunch of other things. Suddenly we've a cool
intersection of culture and functionality is blocked by two copyleft
licenses that both have the same (and best) intentions at heart.
We've blocked the cat-robot from ever being born (well, within license
compliance) by best-intentions-copyleft. This is a problem, and if
the world continues to develop in the direction we want it to, I think
we're going to start seeing it a lot more.

== Copyleft ==

=== GPL compatibility ===

=== Scoping copyleft across and code? ===

=== Increasing/clarifying scope of what's a derivative ===

== Other issues ==

=== Source release? ===
=== DRM in BY-SA but not BY ===

4.0/Games 3d printing and functional content

2011-12-22T16:54:39Z

Christopher Webber: Massiely increased section on background of seperaction of functional/software and cultural layers

= Games and Functional Content =

== Background ==

The purpose of this page is to collect thoughts on issues that affect
games and projects that span the domains of cultural and
functional/software works. There are actually quite a few categories
of works that cross this domain, but games, as creative works that *by
necessity* combine code and artwork together, perhaps expose and
encounter some of these issues the most clearly. However games are
not the only area that contain this overlap; for example, 3d printing
is an emerging medium where the line between funtional and cultural is
either blurred or interwoven. It's likely that as the spaces of free
software and free culture (ideally) grow, we'll continue to see more
and more examples of this overlap.

Most of this wiki page will involve issues of the code/functional and
cultural works overlap, but some bits at the end will cover some other
issues raised by speaking with members of the free software gaming
community.

=== Background on separation of functional/software and cultural layers ===

As further background, traditionally we've held a fairly clear
division between the free culture and free software spaces. This
division is partly because it's a useful distinction, and partly a
historic one. It looks something like:

.----------.
| CONTENT |
+----------+
| CODE |
'----------'

In a game context, content might be art, music, story, plain character
descriptions. Code would be the game engine, game scripting, etc.

In a free-as-in-freedom type environment the former would be under
free culture and the user freedom respecting subset of Creative
Commons licenses, and code would be free software licenses such as
MIT/BSD or the GPL.

One of the other results of this (licensing) division though is that
you can also have one half of this layer be proprietary and the other
be free-as-in-freedom. So, for example, the first person shooter
Quake was released under the GPL but the game content was kept
proprietary. Likewise, it's possible that someone could have a game
whose assets were released completely as free cultural works but the
software wasn't; this hasn't seemed to have happened (but some artists
have expressed concern about it). But outside of games, people play
CC licensed content in proprietary media players or view them in
proprietary browsers all the time.

In general, the software/content division in many areas works just
fine as separate layers. But sometimes there is a certain kind of
content that spans both. For example say you have a game that's using
CC BY-SA content and the GPL for the engine. In this you have level
files or character description files saying this is placed here, that's
there, and here's a cute block of text describing this creature if you
look at them in info mode. At this point, that sounds like content,
and so falls into the CC licensing. But what happens if in this same
file there's a certain amount of scripting? It has logic, it assigns
variables, but it also has some programming code.

.----------------.
|CONTENT.--------.|
| |scripted||
+-------| level |+
|CODE '--------'|
| |
'-----------------'

This actually happens all the time in games (both Wesnoth and Frogatto
use an engine that's a bunch of config files that describe maps,
scenarios, storylines, and creatures but which contain a functional
programming language embedded inside them also; see

[http://svn.gna.org/viewcvs/wesnoth/trunk/data/campaigns/Heir_To_The_Throne/scenarios/05b_Isle_of_the_Damned.cfg?view=markup this wesnoth level file which looks like mostly data]
and
[https://github.com/frogatto/frogatto/blob/master/data/objects/enemies/bosses/moth_boss.cfg this boss file from Frogatto that looks like code]
... technically Frogatto developers consider this to be all content,

but it's also an interpreted language. The intention here isn't to
pass judgement on their interpretation (if the developers don't intend
to enforce the copyleft on the scripting layer, they're the only ones
that can do that anyway) but their files provide pretty clear examples
despite them drawing a line somewhere else, and if for example we
consider a game engine that uses Python as an interpreted language but
which has a backend bound by the GPL to have to follow the GPL, surely
combo content/code files like this might provide an "intertwined data
and code" scenario.

This might seem like a very one-off type of consideration, something
not worth considering generally with CC, but I don't think it is.
Surely we want to see more free software and free culture overlapping,
and it is likely that when that happens there may be scenarios when
that happens where some sort of difficult intertwining of code and
content will happen and we'll have to consider what to do about
copyleft incompatibility.

Here's another example not game related, rooted in the physical space:
3d printing. There's a potential that 3d printing could become (and
actually, it's already starting to become) the type of revolution for
physical things what computers and the internet have been for
information.

The most popular 3d printer is something called the
[http://reprap.org/wiki/RepRap RepRap], which has been released under
the GPL. Arguably because of the strength of this copyleft, several
commercial versions have ben released such as the
[http://store.makerbot.com/thing-o-matic-kit-mk7.html MakerBot Thing-O-Matic].
But here's an iteration of the 3d printer called the
[http://www.thingiverse.com/thing:14111 Ronthomp Mendel]
which is labeled as being BY-SA, even though it uses a GPL'ed design.
Now, technically the BY-SA and the GPL are not compatible, and it's
probable that this is an issue of education because maybe the Ronthomp
Mendel should simply be under the GPL as well. But here's a
question... what if the Ronthomp Mendel were making use of some BY-SA
parts? What is someone tried to make a new 3d printer that made use
of some cool new gear system that someone released as BY-SA?

One could argue that in the copyleft scope, functional things such as
the RepRap should be GPL'ed (citation needed, but it's been argued at
least by Eben Moglen that GPL is great for hardware because it also
takes advantage of GPL's patent pool protections) and that purely
cultural things such as the
[http://www.thingiverse.com/thing:10367 Octocat print] should be CC BY-SA.
But a) not everyone has agreed on this, plenty of people are using
BY-SA for functional works, and b) this breakdown itself could really
stop working right.

To more clearly illustrate the problem, let me first make a list of
some various cool 3d printable things under different licenses:

GPL things:
* [http://reprap.org/wiki/RepRap RepRap 3d printer] (on which most modern 3d printers are based)
* [http://www.thingiverse.com/thing:951 Bead belt gear]

BY-SA things:
* [http://www.thingiverse.com/thing:13368 Motorized functional differential gear system]
* [http://www.thingiverse.com/thing:14599 Robot chassis]
* [http://www.thingiverse.com/thing:10367 Octocat]

BY things:
* [http://www.thingiverse.com/thing:13827 Botmobile dune buggy]

From this list of things already we can see a list of things that
could be blocked. Say you want to power your 3d printer by human
energy by plugging in the motorized functional differential gear
system? Okay, maybe possibly you could argue that that's functional
and should have been GPL'ed, but what about the dune buggy, which is
closer to a children's toy? What about combining that with some
GPL'ed part? But most complicated of all, what if you wanted to make
a walking cat-robot that uses a BY-SA cat design (maybe the head of
the octocat) and combines it with the robot chassis and some bears and
the bead belt gear and a bunch of other things. Suddenly we've a cool
intersection of culture and functionality is blocked by two copyleft
licenses that both have the same (and best) intentions at heart.
We've blocked the cat-robot from ever being born (well, within license
compliance) by best-intentions-copyleft. This is a problem, and if
the world continues to develop in the direction we want it to, I think
we're going to start seeing it a lot more.

== Copyleft ==

=== GPL compatibility ===

=== Scoping copyleft across and code? ===

=== Increasing/clarifying scope of what's a derivative ===

== Other issues ==

=== Source release? ===
=== DRM in BY-SA but not BY ===

4.0/Games 3d printing and functional content

2011-12-21T23:31:22Z

Christopher Webber: Starting work on the games and functional content page

Translation tooling

2011-11-18T20:27:41Z

Christopher Webber: /* Extracting translations */

== Extracting translations ==

At the time of writing, you have to mess with this a bit, but pretty soon here will be the simple instructions for extracting translations:

# First, get a cc.i18n checkout and do the usual thing. Buildout, virtualenv... whatever.
# Run ./runcheckouts.sh which should check out all the repositories we'll extract from into checkouts/ (which is .gitignore'd)
# ./bin/pybabel extract -F babel.ini -o cc/i18n/po/en/cc_org.po .

Translation tooling

2011-11-18T20:16:56Z

Christopher Webber: Created page with "== Extracting translations == At the time of writing, you have to mess with this a bit, but pretty soon here will be the simple instructions for extracting translations: # Firs..."

Global Summit 2011/Unconference

2011-09-02T01:06:15Z

Christopher Webber: /* Free software tools for creating free culture */

== Potential unconference session topics ==
There's a lot of time to run informal, unconference sessions and workshops during the CC Global Summit. We have several extra rooms available. Below is a non-comprehensive list of session ideas which are not a part of the formal Summit program. We encourage interested persons to sketch out ideas for the topics below, or add different ones if you're so inclined. Also, please suggest a preferred time slot for your session, which are listed at the bottom of the page. Note that your session doesn't have to fill the entire time available.

=== CC and EULA compatibility ===
[please provide a rough session description, preferred time slot, and and why people should come]

=== Beginners guide to CC ===
[please provide a rough session description, preferred time slot, and and why people should come]

=== CC technology licensing tools and other tech projects update ===
[please provide a rough session description, preferred time slot, and and why people should come]

=== Free software tools for creating free culture ===

* Organizer(s): Christopher Allan Webber
* Timeslot: no preference
* Description: Learn about and discuss various free and open source software tools for creating free culture, particularly on the graphics end (Blender, GIMP, Inkscape, MyPaint, etc)

=== translation tools Q&A ===
[please provide a rough session description, preferred time slot, and and why people should come]

=== How to create short videos like CC NZ ===
[please provide a rough session description, preferred time slot, and and why people should come]

=== ACTA discussion ===
[please provide a rough session description, preferred time slot, and and why people should come]

=== CC and piracy discussion ===
[please provide a rough session description, preferred time slot, and and why people should come]

=== Government transparency and CC's role in addressing corruption ===
[please provide a rough session description, preferred time slot, and and why people should come]

=== Communia presentation and discussion ===
[please provide a rough session description, preferred time slot, and and why people should come]

=== Global community communication strategies: best practices from Wikimedia, Global Voices, others ===
[please provide a rough session description, preferred time slot, and and why people should come]

=== Integrating CC licenses and tools in gov policy/open gov toolkit ===
[please provide a rough session description, preferred time slot, and and why people should come]

=== Open access and students ===
[please provide a rough session description, preferred time slot, and and why people should come]

=== Arab World arts events ===
[please provide a rough session description, preferred time slot, and and why people should come]

=== LRMI project ===
* Organizer(s): Greg Grossmeier
* Timeslot: no preference
* Description: Learn about CC's exciting education metadata project, the [[LRMI|Learning Resource Metadata Initiative]]

== Open Times ==
* Friday 14:00-15:00 (2 time slots)
* Friday 15:00-16:00 (2 time slots)
* Friday 16:20-18:00 (4 time slots)

* Saturday 9:00-10:30 (2 time slots)
* Saturday 11:00-11:50 (4 time slots)
* Saturday 12:00-12:50 (2 time slots)
* Saturday 13:00-13:50 (1 time slot)
* Saturday 13:00-14:20 (1 time slot)
* Saturday 14:00-15:20 (1 time slot)
* Saturday 14:30-15:50 (1 time slot)
* Saturday 15:30-15:50 (1 time slot)
* Saturday 16:00-16:50 (2 time slots)

* Sunday 9:00-10:40 (3 time slots)
* Sunday 11:00-12:30 (2 time slots)
* Sunday 14:00-15:40 (4 time slots)

CC License Rdf Overview

2011-08-02T22:17:56Z

Christopher Webber:

The purpose of this article is basic documentation of the directories within the [http://code.creativecommons.org/viewgit/license.rdf.git/ cc.licenserdf] project.

== cc/licenserdf/licenses/ ==

=== License RDF Files ===
This directory contains an rdf file for every license we have. Each file is named to match the url path to it on the cc website, where underscores are replaced by slashes. An example of this is so:

* cc/licenserdf/licenses/creativecommons.org_publicdomain_zero_1.0_.rdf

Which corresponds to [http://creativecommons.org/publicdomain/zero/1.0/ this page].

=== The cc:legalcode Node(s) ===

If the jurisdiction for one of these licenses has one translation available for its legal code; then there is only one instance of this node in the rdf file for that license. This node contains the url to the legal code's page in its rdf:resource attribute.

If the jurisdiction has multiple translations available, there will be multiple instances of this node within the RDF file. There will also be instances of an additional node, called rdf:Description. The rdf:Description instances also contain the same url to the legal code, but under their rdf:about attribute. The rdf:Description instances each all have a child node dcq:language, who's inner text is the locale abbreviation for that translation.

It is the cc:legalcode and rdf:Description nodes that directly impact what links to legal code will appear on the deed's page.

=== The dc:title Nodes ===

These nodes are generated automatically by scripts in the project's tools directory.

=== d:title xml:lang="i18n" ===

This is a special instance of the dc:title node, identified by having "i18n" as the language name, instead of a locale abbreviation. The contents of this node is a python string template, and is used by a script to generate the other translation nodes for the subject predicate combination described by the string template.

The presence of this is a hack, not a standard practice; and may be unique to our codebase.

=== foaf:logo ===

In the rdf:resource attribute, each instance of this node contains a link to a different button graphic for the license, which ideally one displays proudly with the licensed content whatever webpage it appears upon. While many licenses will use the same images, each license variation contains a different url for its images. This is so we can use traffic statistics to get a good picture on the actual usage of our licenses, and which versions there of.

== cc/licenserdf/rdf/ ==

=== images.rdf ===

To quote Chris, "too be honest, I've never touched it."
...
Alright then =)

=== index.rdf ===

This file is automatically generated by a script. It is the combination of all of the rdf files in the cc/licenserdf/license folder.

=== jurisdictions.rdf ===

This file used to be for determining which languages to use for jurisdictions, but it may be no longer in use.

=== ns.html ===

Same as http://creativecommons.org/ns
Outlines the terms in the namespace for [http://wiki.creativecommons.org/CC_REL CC REL]. Contains a link to schema.rdf.

=== schema.rdf ===

The RDFa contents of http://creativecommons.org/ns (ns.html), but in the RDF/XML format. This would only ever need to be modified if we add more terms in our namespace.

== cc/licenserdf/tests/ ==

Unit tests for this project.

== cc/licenserdf/tools/ ==

=== add.py ===

This tool might not be in use anymore.

=== gen_i18n_titles.py ===

This tool automatically generates the <dc:title xml:lang="i18n"> nodes in the various rdf files in the cc.licenserdf/license/ directory. This was implemented during the sanity project.

=== __init__.py ===

Empty.

=== jurisdiction.py ===

This file contains tools for adding, launching & getting info about jurisdictions. Details on usage are out of the scope of this article.

=== merge.py ===

This tool generates the index.rdf file.

=== rebuild_images.py ===

To quote Chris again, "Looks interesting, but I've never touched it".

=== support.py ===

Contains miscellaneous tools for the project, much as cc/licenserdf/util.py also does. This separation between the two files is not due to any particular design decision, but rather is a quirk. The two files probably could be merged together at some point. (Is this accurate?)

=== translate_rdf.py ===

Automatically generates translations via the xml:lang="i18n" string template nodes.

Core developer introduction

2011-07-14T18:57:10Z

Christopher Webber:

== First week or two: getting acclimated ==

=== Server / git access ===
* Generate SSH key
* Coordinate with nkinkade about getting on servers
* Coordinate about getting git access

=== Get cc packages set up with zc.buildout ===

Do git checkouts *via ssh* for all of these packages:

* cc.license
* cc.licenserdf
* cc.engine
* cc.i18n
* cc.api
* cc.deedscraper

You should then set up zc.buildout. For more about what zc.buildout
is, let's talk on the phone.

python bootstrap.py && ./bin/buildout

=== Get server running ===

In cc.engine:

./bin/paster serve cc.engine.ini --reload

=== Get cross-package virtualenv working ===

http://labs.creativecommons.org/2010/03/16/using-virtualenv-and-zc-buildout-together/

This will be important when you have to work on multiple packages that
affect each other at once.

=== Reading materials ===

You aren't expected to completely grasp all of this immediately.

* Read the cc.engine docs/ materials
* Read the RDFa primer: http://www.w3.org/TR/xhtml-rdfa-primer/
* Play with http://creativecommons.org/choose/ and see how the output there has RDFa embedded in it
* ... don't bother reading the RDF primer immediately, let's talk about it on the phone
* http://wiki.creativecommons.org/CC_REL
* http://en.wikipedia.org/wiki/XML_namespace
* Read: http://labs.creativecommons.org/2009/12/18/understanding-the-state-of-sanity-via-whiteboards-and-ascii-art/
* Read: http://labs.creativecommons.org/2010/01/06/caching-deeds-for-peak-performance/
* If you get stuck on git, http://progit.org/book/ is really great.

Some general CC pages you should read:

* http://creativecommons.org/licenses/
* All sections on http://creativecommons.org/about
* The FAQ http://wiki.creativecommons.org/FAQ
* The CC0 FAQ http://wiki.creativecommons.org/CC0_FAQ
* The Public Domain Mark FAQ http://wiki.creativecommons.org/PDM_FAQ

== Backups! ==

You should have the machine you work on have backups done regularly and automatically. We have some in-house backup machines, but you can backup locally, even to an external drive. You just need to backup your data.

Some of us like using Dirvish for this.

== Start working on tickets ==

EG, with Jon Palecek, we're starting with:

http://wiki.creativecommons.org/Clarity_Project

Talk and pick out the appropriate tickets

Core developer introduction

2011-07-13T14:00:39Z

Christopher Webber:

== First week or two: getting acclimated ==

=== Server / git access ===
* Generate SSH key
* Coordinate with nkinkade about getting on servers
* Coordinate about getting git access

=== Get cc packages set up with zc.buildout ===

Do git checkouts *via ssh* for all of these packages:

* cc.license
* cc.licenserdf
* cc.engine
* cc.i18n
* cc.api
* cc.deedscraper

You should then set up zc.buildout. For more about what zc.buildout
is, let's talk on the phone.

python bootstrap.py && ./bin/buildout

=== Get server running ===

In cc.engine:

./bin/paster serve cc.engine.ini --reload

=== Get cross-package virtualenv working ===

http://labs.creativecommons.org/2010/03/16/using-virtualenv-and-zc-buildout-together/

This will be important when you have to work on multiple packages that
affect each other at once.

=== Reading materials ===

You aren't expected to completely grasp all of this immediately.

* Read the cc.engine docs/ materials
* Read the RDFa primer: http://www.w3.org/TR/xhtml-rdfa-primer/
* Play with http://creativecommons.org/choose/ and see how the output there has RDFa embedded in it
* ... don't bother reading the RDF primer immediately, let's talk about it on the phone
* http://wiki.creativecommons.org/CC_REL
* http://en.wikipedia.org/wiki/XML_namespace
* Read: http://labs.creativecommons.org/2009/12/18/understanding-the-state-of-sanity-via-whiteboards-and-ascii-art/
* Read: http://labs.creativecommons.org/2010/01/06/caching-deeds-for-peak-performance/
* If you get stuck on git, http://progit.org/book/ is really great.

== Backups! ==

You should have the machine you work on have backups done regularly and automatically. We have some in-house backup machines, but you can backup locally, even to an external drive. You just need to backup your data.

Some of us like using Dirvish for this.

== Start working on tickets ==

EG, with Jon Palecek, we're starting with:

http://wiki.creativecommons.org/Clarity_Project

Talk and pick out the appropriate tickets

Core developer introduction

2011-07-11T15:26:08Z

Christopher Webber: /* Reading materials */

== First week or two: getting acclimated ==

=== Server / git access ===
* Generate SSH key
* Coordinate with nkinkade about getting on servers
* Coordinate about getting git access

=== Get cc packages set up with zc.buildout ===

Do git checkouts *via ssh* for all of these packages:

* cc.license
* cc.licenserdf
* cc.engine
* cc.i18n
* cc.api
* cc.deedscraper

You should then set up zc.buildout. For more about what zc.buildout
is, let's talk on the phone.

python bootstrap.py && ./bin/buildout

=== Get server running ===

In cc.engine:

./bin/paster serve cc.engine.ini --reload

=== Get cross-package virtualenv working ===

http://labs.creativecommons.org/2010/03/16/using-virtualenv-and-zc-buildout-together/

This will be important when you have to work on multiple packages that
affect each other at once.

=== Reading materials ===

You aren't expected to completely grasp all of this immediately.

* Read the cc.engine docs/ materials
* Read the RDFa primer: http://www.w3.org/TR/xhtml-rdfa-primer/
* Play with http://creativecommons.org/choose/ and see how the output there has RDFa embedded in it
* ... don't bother reading the RDF primer immediately, let's talk about it on the phone
* http://wiki.creativecommons.org/CC_REL
* http://en.wikipedia.org/wiki/XML_namespace
* Read: http://labs.creativecommons.org/2009/12/18/understanding-the-state-of-sanity-via-whiteboards-and-ascii-art/
* Read: http://labs.creativecommons.org/2010/01/06/caching-deeds-for-peak-performance/
* If you get stuck on git, http://progit.org/book/ is really great.

== Start working on tickets ==

EG, with Jon Palecek, we're starting with:

http://wiki.creativecommons.org/Clarity_Project

Talk and pick out the appropriate tickets

Core developer introduction

2011-07-11T15:22:33Z

Christopher Webber: /* Reading materials */

== First week or two: getting acclimated ==

=== Server / git access ===
* Generate SSH key
* Coordinate with nkinkade about getting on servers
* Coordinate about getting git access

=== Get cc packages set up with zc.buildout ===

Do git checkouts *via ssh* for all of these packages:

* cc.license
* cc.licenserdf
* cc.engine
* cc.i18n
* cc.api
* cc.deedscraper

You should then set up zc.buildout. For more about what zc.buildout
is, let's talk on the phone.

python bootstrap.py && ./bin/buildout

=== Get server running ===

In cc.engine:

./bin/paster serve cc.engine.ini --reload

=== Get cross-package virtualenv working ===

http://labs.creativecommons.org/2010/03/16/using-virtualenv-and-zc-buildout-together/

This will be important when you have to work on multiple packages that
affect each other at once.

=== Reading materials ===

You aren't expected to completely grasp all of this immediately.

* Read the cc.engine docs/ materials
* Read the RDFa primer: http://www.w3.org/TR/xhtml-rdfa-primer/
* Play with http://creativecommons.org/choose/ and see how the output there has RDFa embedded in it
* ... don't bother reading the RDF primer immediately, let's talk about it on the phone
* http://wiki.creativecommons.org/CC_REL
* Read: http://labs.creativecommons.org/2009/12/18/understanding-the-state-of-sanity-via-whiteboards-and-ascii-art/
* Read: http://labs.creativecommons.org/2010/01/06/caching-deeds-for-peak-performance/
* If you get stuck on git, http://progit.org/book/ is really great.

== Start working on tickets ==

EG, with Jon Palecek, we're starting with:

http://wiki.creativecommons.org/Clarity_Project

Talk and pick out the appropriate tickets

Core developer introduction

2011-07-11T15:02:13Z

Christopher Webber: /* Get cc packages set up with zc.buildout */

== First week or two: getting acclimated ==

=== Server / git access ===
* Generate SSH key
* Coordinate with nkinkade about getting on servers
* Coordinate about getting git access

=== Get cc packages set up with zc.buildout ===

Do git checkouts *via ssh* for all of these packages:

* cc.license
* cc.licenserdf
* cc.engine
* cc.i18n
* cc.api
* cc.deedscraper

You should then set up zc.buildout. For more about what zc.buildout
is, let's talk on the phone.

python bootstrap.py && ./bin/buildout

=== Get server running ===

In cc.engine:

./bin/paster serve cc.engine.ini --reload

=== Get cross-package virtualenv working ===

http://labs.creativecommons.org/2010/03/16/using-virtualenv-and-zc-buildout-together/

This will be important when you have to work on multiple packages that
affect each other at once.

=== Reading materials ===

You aren't expected to completely grasp all of this immediately.

* Read the cc.engine docs/ materials
* Read the RDFa primer: http://www.w3.org/TR/xhtml-rdfa-primer/
* Play with http://creativecommons.org/choose/ and see how the output there has RDFa embedded in it
* ... don't bother reading the RDF primer immediately, let's talk about it on the phone
* Read: http://labs.creativecommons.org/2009/12/18/understanding-the-state-of-sanity-via-whiteboards-and-ascii-art/
* Read: http://labs.creativecommons.org/2010/01/06/caching-deeds-for-peak-performance/
* If you get stuck on git, http://progit.org/book/ is really great.
* http://wiki.creativecommons.org/CC_REL

== Start working on tickets ==

EG, with Jon Palecek, we're starting with:

http://wiki.creativecommons.org/Clarity_Project

Talk and pick out the appropriate tickets

Core developer introduction

2011-07-11T14:31:39Z

Christopher Webber: /* Reading materials */

== First week or two: getting acclimated ==

=== Server / git access ===
* Generate SSH key
* Coordinate with nkinkade about getting on servers
* Coordinate about getting git access

=== Get cc packages set up with zc.buildout ===

Do git checkouts *via ssh* for all of these packages:

* cc.license
* cc.licenserdf
* cc.engine
* cc.i18n

You should then set up zc.buildout. For more about what zc.buildout
is, let's talk on the phone.

python bootstrap.py && ./bin/buildout

=== Get server running ===

In cc.engine:

./bin/paster serve cc.engine.ini --reload

=== Get cross-package virtualenv working ===

http://labs.creativecommons.org/2010/03/16/using-virtualenv-and-zc-buildout-together/

This will be important when you have to work on multiple packages that
affect each other at once.

=== Reading materials ===

You aren't expected to completely grasp all of this immediately.

* Read the cc.engine docs/ materials
* Read the RDFa primer: http://www.w3.org/TR/xhtml-rdfa-primer/
* Play with http://creativecommons.org/choose/ and see how the output there has RDFa embedded in it
* ... don't bother reading the RDF primer immediately, let's talk about it on the phone
* Read: http://labs.creativecommons.org/2009/12/18/understanding-the-state-of-sanity-via-whiteboards-and-ascii-art/
* Read: http://labs.creativecommons.org/2010/01/06/caching-deeds-for-peak-performance/
* If you get stuck on git, http://progit.org/book/ is really great.
* http://wiki.creativecommons.org/CC_REL

== Start working on tickets ==

EG, with Jon Palecek, we're starting with:

http://wiki.creativecommons.org/Clarity_Project

Talk and pick out the appropriate tickets

Core developer introduction

2011-07-11T14:31:08Z

Christopher Webber: Created page with "== First week or two: getting acclimated == === Server / git access === * Generate SSH key * Coordinate with nkinkade about getting on servers * Coordinate about getting git acc..."

== First week or two: getting acclimated ==

=== Server / git access ===
* Generate SSH key
* Coordinate with nkinkade about getting on servers
* Coordinate about getting git access

=== Get cc packages set up with zc.buildout ===

Do git checkouts *via ssh* for all of these packages:

* cc.license
* cc.licenserdf
* cc.engine
* cc.i18n

You should then set up zc.buildout. For more about what zc.buildout
is, let's talk on the phone.

python bootstrap.py && ./bin/buildout

=== Get server running ===

In cc.engine:

./bin/paster serve cc.engine.ini --reload

=== Get cross-package virtualenv working ===

http://labs.creativecommons.org/2010/03/16/using-virtualenv-and-zc-buildout-together/

This will be important when you have to work on multiple packages that
affect each other at once.

=== Reading materials ===

You aren't expected to completely grasp all of this immediately.

* Read the cc.engine docs/ materials
* Read the RDFa primer: http://www.w3.org/TR/xhtml-rdfa-primer/
* Play with http://creativecommons.org/choose/ and see how the output there has RDFa embedded in it
* ... don't bother reading the RDF primer immediately, let's talk about it on the phone
* Read: http://labs.creativecommons.org/2009/12/18/understanding-the-state-of-sanity-via-whiteboards-and-ascii-art/
* Read: http://labs.creativecommons.org/2010/01/06/caching-deeds-for-peak-performance/
* If you get stuck on git, http://progit.org/book/ is really great.

== Start working on tickets ==

EG, with Jon Palecek, we're starting with:

http://wiki.creativecommons.org/Clarity_Project

Talk and pick out the appropriate tickets

I18n sanity

2011-06-15T23:18:29Z

Christopher Webber: more nowiki!

== The problem ==

We use logical keys for our translations for historical reasons (years
ago when our tools were written in TCL that's how you did it, and Zope
allows for the option).

Logical keys aren't bad on their own... the problem is that in general
the rest of the world doesn't seem to use them. Thusly we've had to
write our own tools to move our translation files around, sync things,
etc; these tools require a lot of specialized knowledge to maintain
and tend to be fairly fragile. It would be significantly easier
on ourselves if we could just move away from them.

To do that, we need to move from logical to english keys. Given the
complexity of our existing system this won't be easy... one attempt at
moving was made before and was later given up on. Here's to success
on the second try! A relevant plan is laid out below.

== The plan! ==

The general plan is that we'll have a script that can go and extract
everything automatically from our sets of tools that use cc.i18n.

=== Switch back cc.i18n to Babel and just wrap writing in polib ===

I've half fixed some recent issues we've found with the polib, but not
completely. It might not be worth finishing fixing these if we're
going to tear this all down anyway. It might be worth just switching
things back to Babel and wrapping the writing calls in polib to handle
the formatting pains we were having with Transifex and git without
having to worry about things working properly otherwise.

=== Moving cc.engine templates to Jinja2... why? ===

Why Jinja2? Why move templating systems at all?

Actually I like Zope Page Templates, and it's actually possible to not
use logical keys with them. However certain types of translations
require *manually editing* the extracted strings (basically ones with
special xml attributes), which simply won't work in a glorious future
of automatic-extraction.

Jinja2 seems to be the most popular templating system right now and is
almost exactly like Django's templating system with a few
improvements. (You can pass in arguments to functions! Etc.) There
are a few other templating systems perhaps worthy of consideration
(Mako, etc) but they don't look like they have anything better to
offer, particularly in the area of translation stuff.

=== The <nowiki>{{ cctrans() }}</nowiki> intermediary step ===

Jinja has a kind of translation system we can use with {% trans %}
tags, but jumping straight into jinja with {% trans %} tags probably
won't work because of several things that end up in a kind of
chicken-egg problem:

* Jinja2's variables-in-translations setup is different, using %(foo)s variable style rather than ${foo} style we currently use
* Moving templates from one system to another is non-trivial. We're going to need to make sure our templates actually *work* at the same time that we're trying to migrate to the same format. That's not easy to do both.

To fix this, we should use an interim <nowiki>cctrans()</nowiki> function inside the templates, kind of like:

<code>
<nowiki>{{ cctrans("logical_key_name", var=foo.bar(), blah=baz) }}</nowiki>
</code>

Later on these can be auto-translated into *real* trans tags like:

<code>
{% trans var=foo.bar(), blah=baz %}
text content of trans goes here! Figured out by reading from the
logical keys.
{% endtrans %}
</code>

=== Metamorphosis tools ===

./gregor.py ? :)

==== template metamorphosis ====

We need to move our templates from <nowiki>{{ cctrans() }}->{% trans %},</nowiki> as
described above. The tools should be smart enough to make the ${foo}
to %(foo)s transformation as described below also.

==== ${foo} to %(foo)s metamorphosis ====

We'll also need to convert all ${foo} to %(foo)s in the .po files and
alert translators that this is the new format. (Also, will
translators be okay with this confusing "s" after %(foo) in %(foo)s?
Will that confuse them?)

=== Move our other programs over. ===

Probably cc.license, cc.api, cc.i18n, cc.deedscraper scraper might all
need some (comparatively small) adjustments for this format.

=== Write script to auto-extract everything ===

Not only do we need to auto-extract things from all projects, we need
to combine them into one big file. We should run a check to make sure
we aren't "missing" anything and if we are if it's still a string in
use.

=== Moving files and Transifex considerations? ===

We'll also be moving the structure of files around, so maybe we'll
need to change our layout? Or maybe we won't, maybe we can keep the
old layout and just change our programs to expect the new one with the
po-style files in the same place.

Anyway, does this affect Transifex? We'll need to think carefully
about this.

I18n sanity

2011-06-15T23:18:04Z

Christopher Webber: Fixing the wiki markup. Not a mediwiki extension :)

== The problem ==

We use logical keys for our translations for historical reasons (years
ago when our tools were written in TCL that's how you did it, and Zope
allows for the option).

Logical keys aren't bad on their own... the problem is that in general
the rest of the world doesn't seem to use them. Thusly we've had to
write our own tools to move our translation files around, sync things,
etc; these tools require a lot of specialized knowledge to maintain
and tend to be fairly fragile. It would be significantly easier
on ourselves if we could just move away from them.

To do that, we need to move from logical to english keys. Given the
complexity of our existing system this won't be easy... one attempt at
moving was made before and was later given up on. Here's to success
on the second try! A relevant plan is laid out below.

== The plan! ==

The general plan is that we'll have a script that can go and extract
everything automatically from our sets of tools that use cc.i18n.

=== Switch back cc.i18n to Babel and just wrap writing in polib ===

I've half fixed some recent issues we've found with the polib, but not
completely. It might not be worth finishing fixing these if we're
going to tear this all down anyway. It might be worth just switching
things back to Babel and wrapping the writing calls in polib to handle
the formatting pains we were having with Transifex and git without
having to worry about things working properly otherwise.

=== Moving cc.engine templates to Jinja2... why? ===

Why Jinja2? Why move templating systems at all?

Actually I like Zope Page Templates, and it's actually possible to not
use logical keys with them. However certain types of translations
require *manually editing* the extracted strings (basically ones with
special xml attributes), which simply won't work in a glorious future
of automatic-extraction.

Jinja2 seems to be the most popular templating system right now and is
almost exactly like Django's templating system with a few
improvements. (You can pass in arguments to functions! Etc.) There
are a few other templating systems perhaps worthy of consideration
(Mako, etc) but they don't look like they have anything better to
offer, particularly in the area of translation stuff.

=== The <nowiki>{{ cctrans() }}</nowiki> intermediary step ===

Jinja has a kind of translation system we can use with {% trans %}
tags, but jumping straight into jinja with {% trans %} tags probably
won't work because of several things that end up in a kind of
chicken-egg problem:

* Jinja2's variables-in-translations setup is different, using %(foo)s variable style rather than ${foo} style we currently use
* Moving templates from one system to another is non-trivial. We're going to need to make sure our templates actually *work* at the same time that we're trying to migrate to the same format. That's not easy to do both.

To fix this, we should use an interim <nowiki>cctrans()</nowiki> function inside the templates, kind of like:

<code>
<nowiki>{{ cctrans("logical_key_name", var=foo.bar(), blah=baz) }}</nowiki>
</code>

Later on these can be auto-translated into *real* trans tags like:

<code>
{% trans var=foo.bar(), blah=baz %}
text content of trans goes here! Figured out by reading from the
logical keys.
{% endtrans %}
</code>

=== Metamorphosis tools ===

./gregor.py ? :)

==== template metamorphosis ====

We need to move our templates from {{ cctrans() }}->{% trans %}, as
described above. The tools should be smart enough to make the ${foo}
to %(foo)s transformation as described below also.

==== ${foo} to %(foo)s metamorphosis ====

We'll also need to convert all ${foo} to %(foo)s in the .po files and
alert translators that this is the new format. (Also, will
translators be okay with this confusing "s" after %(foo) in %(foo)s?
Will that confuse them?)

=== Move our other programs over. ===

Probably cc.license, cc.api, cc.i18n, cc.deedscraper scraper might all
need some (comparatively small) adjustments for this format.

=== Write script to auto-extract everything ===

Not only do we need to auto-extract things from all projects, we need
to combine them into one big file. We should run a check to make sure
we aren't "missing" anything and if we are if it's still a string in
use.

=== Moving files and Transifex considerations? ===

We'll also be moving the structure of files around, so maybe we'll
need to change our layout? Or maybe we won't, maybe we can keep the
old layout and just change our programs to expect the new one with the
po-style files in the same place.

Anyway, does this affect Transifex? We'll need to think carefully
about this.

I18n sanity

2011-06-15T22:20:18Z

Christopher Webber: Adding the rest of the plan.

== The problem ==

We use logical keys for our translations for historical reasons (years
ago when our tools were written in TCL that's how you did it, and Zope
allows for the option).

Logical keys aren't bad on their own... the problem is that in general
the rest of the world doesn't seem to use them. Thusly we've had to
write our own tools to move our translation files around, sync things,
etc; these tools require a lot of specialized knowledge to maintain
and tend to be fairly fragile. It would be significantly easier
on ourselves if we could just move away from them.

To do that, we need to move from logical to english keys. Given the
complexity of our existing system this won't be easy... one attempt at
moving was made before and was later given up on. Here's to success
on the second try! A relevant plan is laid out below.

== The plan! ==

The general plan is that we'll have a script that can go and extract
everything automatically from our sets of tools that use cc.i18n.

=== Switch back cc.i18n to Babel and just wrap writing in polib ===

I've half fixed some recent issues we've found with the polib, but not
completely. It might not be worth finishing fixing these if we're
going to tear this all down anyway. It might be worth just switching
things back to Babel and wrapping the writing calls in polib to handle
the formatting pains we were having with Transifex and git without
having to worry about things working properly otherwise.

=== Moving cc.engine templates to Jinja2... why? ===

Why Jinja2? Why move templating systems at all?

Actually I like Zope Page Templates, and it's actually possible to not
use logical keys with them. However certain types of translations
require *manually editing* the extracted strings (basically ones with
special xml attributes), which simply won't work in a glorious future
of automatic-extraction.

Jinja2 seems to be the most popular templating system right now and is
almost exactly like Django's templating system with a few
improvements. (You can pass in arguments to functions! Etc.) There
are a few other templating systems perhaps worthy of consideration
(Mako, etc) but they don't look like they have anything better to
offer, particularly in the area of translation stuff.

=== The {{ cctrans() }} intermediary step ===

Jinja has a kind of translation system we can use with {% trans %}
tags, but jumping straight into jinja with {% trans %} tags probably
won't work because of several things that end up in a kind of
chicken-egg problem:

* Jinja2's variables-in-translations setup is different, using %(foo)s variable style rather than ${foo} style we currently use
* Moving templates from one system to another is non-trivial. We're going to need to make sure our templates actually *work* at the same time that we're trying to migrate to the same format. That's not easy to do both.

To fix this, we should use an interim cctrans() function inside the templates, kind of like:

{{ cctrans("logical_key_name", var=foo.bar(), blah=baz) }}

Later on these can be auto-translated into *real* trans tags like:

{% trans var=foo.bar(), blah=baz %}
text content of trans goes here! Figured out by reading from the
logical keys.
{% endtrans %}

=== Metamorphosis tools ===

./gregor.py ? :)

==== template metamorphosis ====

We need to move our templates from {{ cctrans() }}->{% trans %}, as
described above. The tools should be smart enough to make the ${foo}
to %(foo)s transformation as described below also.

==== ${foo} to %(foo)s metamorphosis ====

We'll also need to convert all ${foo} to %(foo)s in the .po files and
alert translators that this is the new format. (Also, will
translators be okay with this confusing "s" after %(foo) in %(foo)s?
Will that confuse them?)

=== Move our other programs over. ===

Probably cc.license, cc.api, cc.i18n, cc.deedscraper scraper might all
need some (comparatively small) adjustments for this format.

=== Write script to auto-extract everything ===

Not only do we need to auto-extract things from all projects, we need
to combine them into one big file. We should run a check to make sure
we aren't "missing" anything and if we are if it's still a string in
use.

=== Moving files and Transifex considerations? ===

We'll also be moving the structure of files around, so maybe we'll
need to change our layout? Or maybe we won't, maybe we can keep the
old layout and just change our programs to expect the new one with the
po-style files in the same place.

Anyway, does this affect Transifex? We'll need to think carefully
about this.

I18n sanity

2011-06-14T22:08:20Z

Christopher Webber: Created page with "== The problem == We use logical keys for our translations for historical reasons (years ago when our tools were written in TCL that's how you did it, and Zope allows for the op..."

Clarity Project

2011-04-25T20:50:44Z

Christopher Webber: Moving "Clarity Project" off of teamspace onto wiki.cc.org at mike's request.

Not too long ago we worked on the "Sanity Overhaul", a rewriting of
the CC website engine and underlying components (cc.i18n, cc.license,
cc.licenserdf, etc). While we all seem to agree that it's been a
massive improvement, it feels like there are a lot of loose ends to
tie up with the project. This page's purpose is to document what
those things are, and how to improve them.

We've made things (a lot more) sane. Now it's time to make them a lot more clear.

== cc.license ==

=== Exceptions suckiness ===

Exceptions suck in cc.license. Everything throws CCLicenseError, no
matter what the kind of error really is. It's impossible to tell what
specific problems have happened.

These exceptions are also abused, thrown when a query returns no
results in various parts of the infrastructure and caught later, where
returning None would have worked just as well or better.

'''Proposed solutions:'''
* Subclass CCLicenseError with more specific errors
* Use None where more appropriate than throwing an exception

=== by_code, by_url, etc monstrosities ===

There are quite a few "by_code" "by_url" and etc functions in
cc.license and they are all convoluted and mind-melting to observe.
The cult of the flying spagetti monster may be great, but not in
regards to our code. We should refactor these to make sense, and many
less tables will be flipped in the process.

=== shouldn't have to pass in model to rdf_helper calls ===

If rdf_helper functions are designed for specific models, shouldn't we
just call those models? Or at least, pass them in as keyword
arguments with default values, such as model=JURI_MODEL. That would
make a lot more sense, assuming we wanted to be able to do dependency
injection for unit testing purposes or something (which we don't
currently do anyway!). Or, you know, we could just call JURI_MODEL in
the code and save ourselves an argument.

=== cc.license._lib contains stuff which is useful to external programs ===

The namespacing of _lib implies that this stuff should be internal but
all sorts of things (okay, cc.engine at least) just imports stuff out
of it.

=== RDFa tests for Public Domain Mark, CC0 formatters ===

http://code.creativecommons.org/issues/issue679

We have string tests which are fragile (kind of useful in its own
way). We should have RDFa tests though.

== cc.engine ==

=== Not enough, not good enough unit tests ===

cc.engine doesn't have the best of coverage currently. We should fix that.

See also
[http://code.creativecommons.org/issues/issue732 Roundup: Add a string test to every page in cc.engine]

=== request.urlgen useless with /ccengine-fcgi/ ===

See [http://code.creativecommons.org/issues/issue669 Issue669]

=== wsgi_cache sometimes writes 0 byte files instead of caching ===

http://code.creativecommons.org/issues/issue698

A good candidate for [http://dustycloud.org/tmp/tableflip.txt table flipping].

I've wondered if we could at least apply a better bandaid so that 0
size cache files aren't written by:

* ''RewriteCond TestString -s'' in apache, which makes sure the file is > 0 bytes
* Upgrading wsgi_cache to see if the file == 0 bytes, if so, overwrite

Confirmation, Nathan thinks this is the way to go.

=== Deployment documentation not good ===

There's kind of some documentation on [[Jurisdiction Management]] but
it's not very good, and that's not really the right place.

Instead we should make clear documentation on
[[cc.engine deployment]] and instead just link to it from
[[Jurisdiction Management]].

=== A script that updates cc.engine for us ===

Now that we have the webadmin user, there's no reason not to just run
something like this on live:

$ ccengine_update

Which does:
* a git pull of cc.engine
* buildout
* reload of apache

And warns if there are any errors.

Maybe with the addition of this argument:

$ ccengine_update --clear-cache

It will also wipe the cache directory.

Also,

$ ccengine_update --clear-cache-only

== license.rdf ==

=== Jurisdiction management doc needs cleanup ===

[[Jurisdiction Management]] mostly has correct information now.

* verify that the info is right
* remove the red/blue/green cruft.

=== cc.licenserdf.tools.* all need tests ===

Some of these things have tests, not much though.

=== Consistent ordering in rdf writing ===

Currently whenever we write out RDF files, they change completely in
their ordering of assertions. This makes git diffs impossible, and
with files as large as index.rdf, bloats our repository unnecessarily
all the time. Even just sorting the assertions somehow alphabetically
would be wonderful.

== cc.i18n ==

=== Document historical reasonings of our .po file formats ===

We have, for example:
* '''cc/i18n/master/cc_org.po:''' The master .po file
* '''cc/i18n/po/es/cc_org.po:''' The transifex-edited translations for es
* '''cc/i18n/i18n/es/cc_org.po:''' The converted (to po-style? cc-style?? I always forget) files for compiling to .mo
* '''cc/i18n/mo/es/cc_org.po:''' The compiled .mo gettext files

How did we end up with our "unusual" gettext file setup? Why are
things this way? I don't even really know these things for sure and I
even rewrote some of the tools that work with them!

=== Do we still need master/cc_org.po ===

nkinkade thinks maybe not, since transifex just works with
po/en/cc_org.po anyway. We should figure this out.

=== Tests for our tools! ===

Can we haz?

== General ==

=== Convert everything to use cc.i18n.util.locale_to_lower_[lower|upper]() ===

http://code.creativecommons.org/issues/issue787

Deployment research

2011-03-24T21:17:09Z

Christopher Webber: /* Puppet */

In the future, deployment will happen at the touch of a button. If you want a new server set up, you will just touch this button, several magical woodland fairies will be sacrificed to the elder gods, and a server will just appear set up for you, completely automagical. When something goes wrong, you just destroy the server, and maybe send apologetic cards to the families of the etherial woodland creatures. This will greatly improve our scalability.

However we have no idea how this will happen yet. Watch here for details as this is researched.

== Goals ==

In short:

* Failover / load balancing.
** If a server goes down, another should pick it up.
** If things are slow, another server should be able to pick things up.
* Boot and shoot approach
** Quick and mindless spin-up of a new server
** Ability to just take down a server / node if it's not working well
** Still have the ability to step in and debug things as much as we like
* An approach for spinning up live & devel servers using mostly the same setup

The cc.engine stack has some advantages. For the most part, there
simply is no "changing database"... everything is stored in RDF files
that are in a git repository / in python packages.

We also need to support CC Wordpress, but this can also be checked out
of an svn repository on the fly. Assuming we do edits somewhere else
and just push to the server, no need to do backups of these "node"
servers, even!

(However maybe we will eventually want to use this setup with things
that *do* have a database that matters, like cc network?)

Cleanness is also a goal. It should be clear enough what's happening
in the deployment setup and how to adjust / reproduce things. From the talk
[http://pycon.blip.tv/file/4881000/ Continuous Deployment, by Laurens Van Houtven],
he talks about a setup wherein anything goes, and perl scripts wrap
scheme scripts alongside erlang alongside java and PHP...:

''"And developers' sense of decency and morals just completely falter, and they start implementing just completely anything, and then you have some giant shambling lovecraftian horror of a deployment system..."''

That's the deployment setup we ''don't'' want :)

== Deployment ==

Deployment covers:
* Server creation (spinning up a new server with our setup)
* Server management (which stuff is on which machine?)
* Server updating (update software / data on server)

The following tools are being considered:

=== plain ol' ssh and bash ===

Of course, we could always just have ssh commands that run remote commands, like:

<pre>
$ ssh webadmin@someserver run_command.sh
</pre>

or even

<pre>
$ ssh webadmin@someserver run_command.py
</pre>

... this is the most minimalist solution! :) But also, maybe the least
"powerful".

=== Fabric ===

I really like the the idea of Fabric because it doesn't do "too much".
It's just a system for running a lot of remote commands from your
machine. Combine this with being able to run local commands on your
machine, and maybe you have a good system for checking some local
information and pushing a lot of updates at once to a number of
machines? In this way, it's kind of like a python-wrapped "plain ol'
ssh and bash" solution. Not a bad thing, we can combine the power of
python's functions / etc with remote script execution, and nice
output, etc.

On the other hand, the downside is that Fabric doesn't do too much.
Unlike Puppet, there's no "description" of what our remote systems
should be, so if we start changing things manually on servers there's
no way to automagically propagate that setup to all our running
servers.

But back to the first hand, automagic is sometimes just not nice, and
generally confusing and hard to debug anyway!

=== Silver Lining ===

http://cloudsilverlining.org/

I really like the approach that Silver Lining takes in many ways. The
idea of being able to just take a virtualenv and push it to a new
server is quite appealing. It's also fairly declarative and uses a
config file format that's like paste deploy.

However, we need some very custom stuff. Our apache config files are
large and bloated. Maybe they could be a little bit less bloated, but
there is a ton of stuff in there like all the rewriting and static
file serving we're doing that Silver Lining doesn't support and
doesn't want to support. So for cc.engine at least, silver lining is
right out.

=== Puppet ===

http://www.puppetlabs.com/

[http://pycon.blip.tv/file/4879368/ A decent PyCon talk on Puppet]

Puppet seems similar to Silver Lining in the sense that it has an
abstracted config file setup that "describes" the server and you use
that to push to a bunch of slave nodes. Unlike Silver Lining though it
appears to be a lot less "simple" and allows things like having your
own apache configs.

As I understand it, Puppet kind of has its own config "language" to
describe the server setup. It also has a full node management system,
which would be useful.

There are some advantages of this in that, as I understand it, you can
have some existing nodes running, and if you change the description of
the server, it can reconfigure the server for you to match the new
"described" setup.

Or so I think.

Anyway that all seems pretty cool but also pretty complicated and
abstract, maybe a lot more than we need initially.

Oh yeah, and something cool... apparently [http://devstructure.com/ blueprint] is great for reverse-engineering a puppet setup.

==== puppet advice from the FSF ====

<pre>
<cure> paroneayea: yes, it's awesome
<cure> if you keep a few things in mind, that is
<cure> 1. don't run it as a daemon, run it in cron
<cure> (on the managed hosts)
<cure> 2. run the server with passenger
<cure> 3. enable stored config mode from the start
<cure> 4. build your config out gradually
<cure> 5. set up a test environment from day one
<cure> that last one is really important
<paroneayea> cure: cool, thanks, noted! :)
<cure> that way you can test on one node (puppetd -t
--environment=name-of-your-test-env)
<cure> without risking having faulty rules being pushed out to a lot of
machines
</pre>

=== Chef ===

I don't know much about Chef except that it's apparently a lot closer
to Puppet. But insted of its abstracted config system and etc you
write a lot of ruby.

For now, that makes me pretty disinterested in Chef. I don't
understand yet how it could be better than Fabric on that end.

=== bcfg2 ===

Looks a lot like puppet/chef except it uses Python? You describe goals for what your server should look like, it installs to those goals, upgrades when not matching those goals, validates on server goals.

http://trac.mcs.anl.gov/projects/bcfg2/

Also apparently not as many users, way less hip, less people running it also riding fixie bikes.

The ChiPy video on this page is pretty good:
http://trac.mcs.anl.gov/projects/bcfg2/wiki/AudioVideo

=== openstack ===

Rackspace Cloud, for example, runs this.

Actually, OpenStack isn't a technology, it's a bunch of technologies.
And much in the way that "cloud computing" is confusing because it
seems to encapsulate so many ideas, OpenStack encapsulates a whole
bunch of technologies in a way that I look at it and am currently
confused. But I don't think it's actually a deployment technology, so
maybe it doesn't belong here, though it has some deployment
technologies in it.

I think I feel about OpenStack the way I felt about Pylons'
documentation the first time I looked at it. Holy cow, there are a lot
of things going on here, and as a complete newbie I have no idea what
is going on or how all this stuff relates together. Also the
documentation seems all at once congealed and fragmented. What?

Maybe also like Pylons I will eventually look back at the
documentation after I come to understand a lot of components
individually and think, "Oh this isn't so confusing, but also no
wonder I was confused."

=== libcloud ===

[http://incubator.apache.org/libcloud/ libcloud] seems pretty general
and great for spinning up nodes on the fly in a standardized way.

[http://incubator.apache.org/libcloud/getting-started.html This page]
even shows an example at the bottom of starting a new server and
pushing your puppet setup over to it.

=== Amazon Cloudformation ===

I'm not super enthused about this idea. It looks like a less
flexible, vendor-specific verion of puppet, and I think that maybe
libcloud + puppet should get us the same thing, but here it is anyway.

http://aws.amazon.com/cloudformation/

== Where to deploy to ==

This section is about what we might end up deploying to in the end.

Originally I was going to flesh this out with more detail, but since
then I think that really our system should be capable of deploying to
any system running the latest Debian stable.

== load balancing ==

I'm not sure what load balancing system we'll use exactly.

[http://wiki.nginx.org/LoadBalanceExample nginx, maybe?]

== Summary ==

It seems to me that stuff like Puppet / bcfg2 are really great ideas
in that they can auto-detect the state of a machine and adjust it from
there, etc, but that also seems heavily abstracted and I don't think
we even really know what the states of our machines are yet.

So I think we should start out with fabric, which is the simplest
setup, and from there get automatic site updating commands, then
automatic machine setup, and after all that we can consider an
abstracted sever deployment system, possibly using something like
Puppet / bcfg2, or possibly iterating on the tools we will have
already built with fabric.

== Milestones ==

Here are the steps I think we should take towards getting to a sane
deployment strategy. I've broken them up into milestones. Since
Mike Linksvayer has indicated that
[http://identi.ca/conversation/66181050#notice-67009981 abstract release names are his favorite]
I've decided to take a hint from Debian and use characters from 3d
animated films as milestone names. Since this is Creative Commons
though, I'll restrict myself to stuff the Blender Institute puts out.

=== Emo ===

''From the film Elephants Dream, Emo is a young man stumbling into a possibly imaginary (and possibly someone else's...) world of automations and magic.''

Step one is to make it so that all of our existing "updating the
remote installs" tools are done by automated fabric commands.

EG:

<pre>
$ fab update_ccengine
$ fab clear_cache
$ fab update_images
$ fab update_all # maybe does all of these?
</pre>

... maybe some of these commands will execute multiple subcommands at
once for convenience, like fab update_all here?

Working on these tools first means a few positive things, I think:
* We'll still be able to use these tools later when we branch out to having multiple machines with appropriate load-balanced failover
* We'll develop a good idea of what working with fabric is like before we jump into the next big step

=== Proog ===

''Also from Elephants Dream, Proog is an older and possibly experienced man claiming to lead Emo through this same world of automations and magic. The world appears to form to his whims. Is it all in his head?''

The next step is new server installs that can be completely updated to
a creativecommons.org setup at the flip of a switch (or execution of a
command). Something like:

<pre>
$ fab install_ccorg -H newnode.creativecommons.org
</pre>

At this point we would never have to (and never would) do work on the
live server like is done with wordpress and etc currently on
creativecommons.org, we could do it on another server installed in
this pattern, and then just pushed with our update scripts (from the
Emo milestone) over to the live site.

We'll have some experience with working with fabric from the previous
milestone. Part of the reason I am thinking of using fabric rather
than puppet for this step is because I'm not really sure we know what
our server setup looks like, so abstractly describing it seems like it
may be a bit hard? Using fabric seems like a more logical step, since
we'll have to figure out what commands to run to reproduce our server.
But maybe not, because maybe something like blueprint could help us
get past the initial confusing steps anyway.

Regardless, if we do this milestone in this way, this step should help
us understand how our server works enough to move onto the next
milestone...

=== Kirjuri (self-typing typewriter) ===

''Also from Elephants Dream, Kirjuri is a typewriter that types itself. Automatically automate the automation!''

After we have general service updating and server install done, what's
left? Maybe this step is not so necessary in a world where we really
do boot-and-shoot style deployment, but maybe it would still also be
nice: the ability to more abstractly describe the setup of the server,
and existing servers that *are* installed can be updated to match the
new described setup.

Maybe we would:
* use puppet or bcfg2 and abstractly describe our system in their language / config file setups
* grow our existing fabric system into something that better handles these needs

It's not clear exactly what this milestone will look like. I think
we'll have a better idea of it after we finish Proog (assuming we take
this route).