first clean draft

1 files changed, 44 insertions, 120 deletions

diff --git a/practical-modifiability-of-free-culture-binary-data.md b/practical-modifiability-of-free-culture-binary-data.md
index 1aa900c..d7c2b51 100644
--- a/practical-modifiability-of-free-culture-binary-data.md
+++ b/practical-modifiability-of-free-culture-binary-data.md
@@ -1,156 +1,80 @@
-Proponents of "Free Culture" present the concept as the multimedia equivalent of GPL-licensed "Free Software" in a vacuous attempt to distinguish it from "Open Culture"; but the reality for end-users is far from the same level of freedom provided by the GPL. Practically speaking, the terms: "Free Culture" and "Open Culture" are quite indistinguishable; with both of which being nearly synonymous with: "Creative Commons licensed multimedia". The vast majority of the multimedia labeled as either are individual images or sounds clips; binary blobs by definition, without any reference to the source "layers" that composed the work. This is natural, of course, if the work is very simple (or "flat") such as 2D gaming tiles, textures, and logos; but that is rarely the case for anything elaborate. The "Free Culture" concept is generally presented as the superset of which "Free Software" is one subset; but there is a crucial disjunct, in that the licenses mainly recommended for artistic works by "Free Culture" and "Open Culture" proponents alike are non-copyleft licenses. To be clear: those who walk beneath the banner of "Free Software" would prefer to advocate copyleft licenses; whereas those who would recommend non-copyleft licenses license are more appropriately said to be in the broader "OpenSource" camp. Practically speaking, these are much the same; with the main distinction being philisphical in nature. This article is an attempt to truly unify the philosophy of "Free Culture" with that of "Free Software" and thereby, to distinguish "Free Culture" from "Open Culture" by embracing copyleft as a core principle of "Free Culture".
+Proponents of "Free Culture" present the concept as the multimedia equivalent of "Free Software" in attempt to distinguish it from "Open Culture"; but the reality for end-users is far from the same level of freedom that is the norm for software, and required by the GPL. Practically speaking, the terms: "Free Culture" and "Open Culture" are quite indistinguishable. Both of which are nearly synonymous with: "Creative Commons licensed multimedia". The vast majority of the multimedia labeled as either are individual images or sounds clips; binary blobs by definition, without any reference to the source "layers" that composed the work. This is natural, of course, if the work is very simple (or "flat") such as 2D gaming tiles, textures, and logos; but that is rarely the case for anything elaborate.
 
-The licenses typically recommended by "Free Culture" proponents, such as the "Creative Commons Share-Alike" and the "Free Art License", merely permit the re-use and re-distribution of specific binary artifacts as long as attribution is preserved; but they do not require that the constituent source materials be made available as does the GPL. As such, they do not exhibit even the most basic premise of "Open-Source". Artifacts under such licenses are, in all practicality, more the equivalent of "free-ware" such as the Microsoft DotNet run-time re-distributables; excepting perhaps for the omission of any language discouraging mutations. To be clear though, any such mutations to blobs are crude at best; far from the precise modifications that the GPL affords for software.
+The "Free Culture" concept is generally presented as the superset, of which "Free Software" is one subset; but there is a crucial disjunct, in that the licenses mainly recommended and usually used for artistic works by "Free Culture" and "Open Culture" proponents alike, are non-copyleft licenses. People who walk beneath the banner of "Free Software" generally prefer to advocate copyleft licenses; whereas those who would recommend non-copyleft licenses license are more appropriately said to be in the broader "OpenSource" camp. Practically speaking, these are much the same; with the main distinction being philisphical in nature. That philisphical distinct and the practical differences between the GPL and other licenses, is not as significant for software; because the software is conventionally distributed in source code form. However, multimedia is rarely distributed in source form; which impedes practical modifiability greatly, for all but the simplest works.
 
-Although these licenses encourage sharing, they neglect ensuring of the freedom to study, experiment with, and customize the artwork in any but the most superficial ways. Experimentation implies de-composition; and as any artist or software developer knows: non-trivial modifications require access to the original sources and tools used by the author. Without these, even the project maintainers are prevented from customizing the assets beyond the most trivial operations such as cropping and scaling; which is very much mis-aligned with the spirit of "Free Software". Therfore, these multimedia licenses are not at all the natural companions to GPL-licensed software that they are often touted to be. The GPLv3 grants this maximal freedom of expression to a project's artists, developers, and end-users alike; and is, itself, the natural companion license for the artistic binary assets of a GPL-licensed software program, provided that the forms of the relevant source materials are well-defined.
-
-In order to be generally applicable, the GPL itself makes no attempt to specify which specific forms qualify as the "preferred forms" for any type of work; but the "Frequently Asked Questions about the GNU Licenses" (https://www.gnu.org/licenses/gpl-faq.html#GPLOtherThanSoftware) makes it clear that the GPL is intended to be useful for anything that is copyright-able.
-
-    "You can apply the GPL to any kind of work, as long as it is clear what constitutes the “source code” for the work. The GPL defines this as the preferred form of the work for making changes in it."
-
-Although the GPL does not require that the "preferred forms" be specified, much less itemized, and any competent digital artist knows fully well what these would be in their area of expertise; the following addendum (or something similar) can be added to the assets license declaration in order to avoid being vague about this. Feel free to modify this to suit the particular needs of your project.
-
-== GPLv3 Assets Addendum ==
-
-The original multimedia files in the <THE-PROGRAM> assets/ directory are licensed under version 3 of the GNU General Public License (GPLv3). The terminology in section 1 of the GPLv3 (namely: "source code", "preferred form", and "object code") as it relates to the binary assets of this project is explicitly defined below.
-
-The "object code" is explicitly defined here to be the binary files (audio, video, images, 3D models, fonts, etc.) that are loaded by or embedded into the <THE-PROGRAM> program.
-
-The "source code" or "preferred form of the work" is explicitly defined here to be any and all resources (such as binary data, editor project files, meta-data, declarative texts, scripts, and source code of helper programs) that are necessary to accomplish all of the following tasks using only widely-available free software:
-
-* reconstruct the associated "object code" artifacts completely and accurately
-* modify the fully decomposed "preferred form" sources directly and independently
-* compose the original sources along with modified and replacement sources interchangeably
-* generate equivalent modified versions of the associated artifacts
-
-For example:
-
-* "artifacts" such as a composed (mixed-down) .webm, .png, .ogg, .wav, etc
-* "binary data" such are the individual elements that compose the "artifacts" (image layers, sound tracks, etc.)
-* "meta-data" and "declarative texts" such as 3D models, animations, edit decision lists/cue sheets, CSS, etc.
-* "scripts", and "source code of helpers" such as ImageMagick scripts, GIMP plugins, openGL shaders, etc.
-* "editor project files" such as .blend, .xcf, .psd, .aup, .ardour, etc.
-* "widely-available free software" such as Blender, GIMP, Inkscape, Audacity, Ardour, etc.
+This article is an attempt to truly unify the philosophy of "Free Culture" with that of "Free Software" and thereby, to distinguish "Free Culture" from "Open Culture" by embracing copyleft as a core principle of "Free Culture".
 
 
----
-TODO: games and their assets
+== Free Culture Licenses ==
 
-the GPL, as written,
-(either implicitly or explicitly)?
-considers binary assets such as artwork and music as program input data as distinct from the program itself and not subject to the corresponding source requirement so long as they are packaged separately
-???much as C source code files and binary compiler outputs are not inherently subject to the license of the compiler that processes them???
-- this serves primarily to intice the hourdes of game creators with stars in their eyes and the (usually stated, if not boasted) intention to become rich and famous from their creations
-- following this to it's logical conclusion : a game that is 100% functional but silent and with
-every character and all scenery completely black
-
-
-???the implication is that mere data is non-essential, dispensible, and interchangeable - it could as well be absent as present or processed by some other tool instead - much as C code is input to GCC so the license of GCC need not apply to the program outputs or inputs???
-
-this could be argued for a game engine which can process very arbitrary inputs as long as some basic syntax or protocol is followed (much as the compiler)
-
-Game assets however, are not arbitrary configuartion data. A free game with non-free assets is like a free operating system for which only non-free programs are available. In fact, taken into account that the majority of computer users expect a graphical, mouse-centric desktop system, then they are identical from the user's perspective: a blank screen with no controls or sounds. Both are utterly useless to a freedom-minded user until someone writes a free interface and some free programs for that platform or creates some free art to fit that game meaningfully. If question at hand is: "Is it possible to use this program without any proprtietary adronments?", the naiive answer will be: "Yes, it is capable of being used with free assets (if they exist)."; but if no such free assets actually do exist, then that answer does not satisfy the main intention of the question, namely: "Is this actually possible in practice or only in theory". In theory, it is the case that many proprietary games are capable of using free replacement assets; which is indeed the popular practice of so-called: "mods". For this reason, the point of the program being merely capable of using free assets is not an interesting one to make. One can easily make the counter-argument that if the only existing assets that could make the program in any way useful are non-free, then the mere distrubution of that program, at least in compiled form, even without being accompanied by any non-free assets, is either pointless, or constitutes a recommendation to seek out and use those non-free assets. In case that this viewpoint is unfamiliar to the reader, it should be noted that this is the very standard to which Debian has held it's binary packages for many years.
+The licenses typically recommended by "Free Culture" proponents, such as the "Creative Commons Share-Alike" and the "Free Art License", merely permit the re-use and re-distribution of specific binary artifacts as long as attribution is preserved; but they do not require that the constituent source materials be made available as does the GPL. As such, they do not exhibit even the most basic premise of "Open-Source", which tacitly presumes that the sources are available. Artifacts under such licenses are, in all practicality, more the equivalent of "free-ware" such as the traditional Microsoft DotNet run-time re-distributables; excepting perhaps for the omission of any language discouraging mutations. To be clear though, any such mutations to blobs are crude at best; far from the precise modifications that the GPL affords for software.
 
-a game is not at all comperable to a compiler - it is not a general purpose tool - it's sole use-case depends intrinsically on it's data existing and existing in a very precisely prescribed way - not just in terms of valid syntax and encoding but in every facet of it's form and purpose, any analogy to an agnostic data processor is inappropriate
-
-The conventinal meaning of "data" is that of some conformant input flowing through a pipeline for processing or computation in order to produce some output that is otherwise non-essential and unrelated to the intrinsic functionality of the processing program. A clear example would be  source code input to GCC. Clearly, game and GUI assets are not merely that kind of data, isolated from the main program. Most generally, these binary assets are necessarily not candidates for streaming as could be the case for the conventional input data previously described. In most cases, these assets carry very specific semantics related to the program itself where spatial and temporal precision are critical; as such the assets that represent these precise events are fully pre-loaded into the program memory space. This is done in order to make the program itself useful to the user and only for that intrinsic purpose. As such, it can not reasonably be considered as arbitrary transient data but much more akin to specific library loading.
-
-To label programs as "functional" but the art and music that constitutes the interfaces as "non-functional" (with the right to modify them being therefore unimportant) is to say that these binary assets are arbitrary or optional (and any modifications are orthagonal to the functionality of the main program itself). If they are not optional then they serve some purpose; if they are not arbitrary then they serve some specific purpose; and if they serve some specific purpose then modifcations are meaningful and the end user should be able to handle them in the same "preferred" ways as the author would. All of those are true for game/GUI art and sounds. They may not be executable machine instructions but they each play a necessary and specific role for the proper operation of the program as a whole. A game's assets and the game state that triggers them to be displayed are tightly coupled components that serve a single unified "function", namely: that of being an entertaining toy. The same could be said of any other GUI or the error messages of GCC for that matter. Afterall, error messages are just raw, non-executable byte strings; so should they be exempt from the licensing terms of the host program? I think most people would agree that it would be difficult to make a convcincing argument for that, especially not on the grounds that they are arbitrary data. Each and every one of them must align semanticallty with the context in which they are to be triggered and presented. Sure, any properly encoded text string could fit the slot, just as any properly encoded image file could replace any other; but surely, trees the color of the sky and rivers made of leopard skin would be as confusing and disturbing to a game player as it would be to a programmer if GCC error messages were replaced with Chinese cookie fortunes. In both cases, treating binary assets as arbitrary or optional jeopardizes the utility and appeal of their host program greatly; and so they should be considered to be necessary and specific, and as such, deserving of the same freedom as the host software.
+Although these licenses encourage sharing, they neglect to ensure the freedoms to study, experiment with, and customize the work, in any but the most superficial ways. Experimentation implies de-composition; and as any artist or software developer knows: non-trivial modifications require access to the original sources and tools, compatible with those used by the author. Without these, even the project maintainers are prevented from customizing the blobs beyond the most trivial operations such as cropping and scaling; which is very much mis-aligned with the spirit of "Free Software". Therfore, these multimedia licenses are not at all the natural companions to GPL-licensed software that they are often touted to be. The GPLv3 grants this maximal freedom of expression to a project's artists, developers, and end-users alike; and is, itself, the natural companion license for the artistic binary blobs of a GPL-licensed software program, provided that the forms of the relevant source materials are well-defined.
 
+In order to be generally applicable, the GPL itself makes no attempt to specify which specific forms qualify as the "preferred forms" for any type of work; but the "Frequently Asked Questions about the GNU Licenses" (https://www.gnu.org/licenses/gpl-faq.html#GPLOtherThanSoftware) makes it clear that the GPL is intended to be useful for anything that is copyright-able.
 
----
-TODO: quotes from the often quoted "Nonfree DRM'd Games on GNU/Linux: Good or Bad?" article by Richard Stallman https://www.gnu.org/philosophy/nonfree-games.en.html
+  "You can apply the GPL to any kind of work, as long as it is clear what constitutes the “source code” for the work. The GPL defines this as the preferred form of the work for making changes in it."
 
-1* "Since the art in the game is not software, it is not ethically imperative to make the art free ..."
-  => i agree there is no ethical imperative to make the art free but i also contend there likewise is no ethical imperative to make any games free, becuase they are purely recreational, not unlike art or music - to label games as "functional" but their art and music as "non-functional" is ludacris - a game its arworks, and sounds, are all essential, strongly coupled, inter-dependent components, which serve a single unified "function", namely: that of a toy
-  => regardless of any ethical imperative, RMS himself has made contrary statements, insisting that sources are required for "_everything_ we distribute" (the underline is his)
+Although the GPL does not require that the "preferred forms" be specified, much less itemized, and any competent digital artist knows fully well what these would be in their area of expertise; the following addendum (or something similar) can be added to the blobs license declaration in order to avoid being vague about this. Feel free to modify this to suit the particular needs of your project.
 
-from: https://lists.gnu.org/archive/html/emacs-devel/2011-07/msg01184.html
 
-  "Yes, they must [always provide the sources of documentation].
-   That requirement applies to _everything_ we distribute.
+== GPLv3 Free Culture Addendum ==
 
-  "We can distribute non-source files too, ...
-   but the _source_ package must include source for _everything in it_!"
+The original multimedia files in the <THE-PROGRAM> data/ directory are licensed under version 3 of the GNU General Public License (GPLv3). The terminology in section 1 of the GPLv3 (namely: "source code", "preferred form", and "object code"), as it relates to the binary data of this project, is explicitly defined below.
 
-RMS is not known for using inprecise language - that is everything, save only the floppies, the shrink-wrap, and the postage stamps - to be pedandic, that is "_everything_ which is not already in its preferred form for modification", such as plain text READMEs and configuration files - as for artworks, SVG images and MIDI files are rare exceptions, in that they are inherently created and distributed as plain text - the vast majority of digital artwork is both created and distributed as binary - in any case of a composition, sources are required in order to isolate the layers, which were created individually, for the purpose of all but the most shallow modifications - this is nothing different than binary executables, with the exception of being not "for practical use"; but again, games themselves do not meet that criteria either
+The "object code" is explicitly defined here to be the binary files (audio, video, images, 3D models, fonts, etc.), which are loaded by or embedded into the <THE-PROGRAM> program.
 
-2* "You as a freedom-lover won't use the nonfree game if it exists, so you won't lose anything if it does not exist."
-  => of course, the very same could be said of freely licensed games, and as well of a freedom-hater, or anyone else for that matter - there would be nothing lost that is of any practical use if no video games had ever existed - afterall, it's only function is entertainment, an object in the same class as a checker-board, a baseball glove, and a kazoo
+The "source code" or "preferred form of the work" is explicitly defined here, to be any and all resources (such as binary data, editor project files, meta-data, declarative texts, scripts, and source code of helper programs), that are necessary to accomplish all of the following tasks, using only widely-available free software:
 
+* reconstruct the associated "object code" artifacts, completely and accurately
+* modify the fully decomposed "preferred form" sources, directly and independently
+* compose the original sources along with modified and replacement sources, interchangeably
+* generate equivalent modified versions of the associated artifacts
 
----
-TODO: arguments for consistency
+Examples of "source code" or the "preferred form of the work" include:
 
-1* => personally, i consider games AS works of art in their own right, with computation as the medium, as a painting is to it's paint and canvas, or a sculpture to it's clay - works that i would not want to modify any more than i would of an artist's stage performance - one does not attend an art gallery with the expectation or desire of customizing the exhibits - art is best experienced precicely in it's pristine form, as the author intended - its "value" is otherwise diminished
-  => one could argue about the freedom to copy but that is not the most beneficial feature of copyleft - that particular freedom lends itself more to "free as in beer" than freedom - what makes the GPL shine is that is requires access to source materials providing the freedom to modify; but with respect to an artistic expression of another person, modifications are not anything that i would actually want - in fact, any modifications to an artist's work could be considered to be an act of vandalism and an insult to the artist - like drawing a mustache on the mona lisa - i do not intend to suggest that another person should not be allowed to create a similar work from raw material but this "moaning lucy" would be an expression of that artist if it did not draw directly from ("sample") the original -
-???but that hits on the broader issue of so called "intellectual property"???
- ^ (this is actually in line wth the FSF view on art but i simply apply the same terms to games as well as art and music - "for practical use" needs to be interpreted very loosely to describe any video game)
+* "artifacts": such as a composed (mixed-down) .webm, .png, .ogg, .wav, etc
+* "binary data": such are the individual elements that compose the "artifacts" (image layers, sound tracks, etc.)
+* "meta-data" and "declarative texts": such as 3D models, animations, edit decision lists/cue sheets, CSS, etc.
+* "scripts" and "source code of helpers": such as ImageMagick scripts, GIMP plugins, openGL shaders, etc.
+* "editor project files": such as .blend, .xcf, .psd, .aup, .ardour, etc.
+* "widely-available free software": such as Blender, GIMP, Inkscape, Audacity, Ardour, etc.
 
----
-TODO: counter agrument to the above
-2* => the above could be taken as strong arguments for applying the same lack of concern for the freedom of game source code as is recommended by the FSF in regards to game assets; but to be un-biased and for the sake on consistency, i present a counter agrument for applying the same urgency to the freedom of game assets -
-while the others were presented from the perspective of downstream consumers; there is an equally valid argument from the perspective of an upstream maintainer - what they both have in common though is that they suggest that the same consideration for freedom should apply to both game source code as well as to game assets
+The definitions above should not be construed as exhaustive. However, the intention is analogous to the GPL distinction of complete corresponding source code vs. compiled binary executables. Likewise, with any digital art-form, it is assumed to be self-evident to any competent digital artist, which properties generally qualify the prepared end-results, ready for end-user consumption, as distinct from everything else, which would not be particularly interesting to a consumer, but would be significantly helpful or essential to a producer. This addendum explicitly requires that: "everything else".
 
-  => whereas it is not desireable to modify the artistic expression inherent in someone else's work; with regards to your own work in progress, it is not only desireable but imperative that you be able to modify contributed assets to fit the program - a demonstration is hardly necessary - this should be abundantly obvious - an external asset that fits into the program 99% is 100% useless unless it is only a mockup (or sloppiness is acceptable) - it is almost certain that images and sounds will need some conditioning at the very least to suit the environment adequately; and without the full coverage of the GPL copyleft applied to the binary assets, the only option is to implore the original artist to make the otherwise trivial adjustments (perhaps on several occasions)
 
+== Games Blobs ==
 
----
-TODO: functional vs non-functional (works for practical use)
+the GPL, as written,
+(either implicitly or explicitly)?
+considers blobs such as artwork and music as program input data as distinct from the program itself and not subject to the corresponding source requirement. They are not even required to be freely licensed, so long as they are at least re-distributable or packaged separately.
 
-???the (where is this written?) states that fonts are functional works for practical use which require all input sources; but images are not???
+Following this to it's logical conclusion; one could anticipate a GPL-licensed game which is 100% functional (technically), but practically it is silent, and every character and all scenery completely are black/null.
 
-personally, i dont see any difference technically or philosophically between a font and an image - especially if it is a bitmap font - by this definition, a bitmap font would be considered "functional" while an image of the alphabet would be "non-functional"; but either could replace the other in a software program, without changing the program's behavior in any way - what justifies this distinction? is it how or where the bits are displayed or by nature of its encoding of container file format? - for example, is the freedom to modify the AOL "you got mail" sound clip important, only when it is being used to announce incoming email? - what if one merely enjoys triggering that sound for pleasure? - then is the freedom to modify it not as important, because that use case is not "practical"?
+The implication is that mere data is non-essential, dispensable, and interchangeable - it could as well be absent as present, or processed on-the-fly as inputs. C code for example, is arbitrary input to a C compiler, and the comp[iler's own code does not appear in the outputs; so the license of compiler needs not apply to the compiler's outputs or inputs. The same could be argued for a game engine which can process very arbitrary inputs, as long as some basic syntax or protocol is followed (much as the compiler); but game blobs are not that sort of input. They are much more intrinsic to the function of the program itself.
 
-the only important distinction for any copyright-able work is whether or not it is freely licensed - the "functional" or "non-functional" distinction does not seems to add anything useful; and quite frankly, it (projects/expresses) an inconsistent philosophy
+Game blobs are not arbitrary configuration data. A free game with non-free blobs is like a free operating system for which only non-free programs are available. In fact, taken into account that the majority of computer users expect a graphical, mouse-centric desktop system, then they are identical from the user's perspective: a blank screen with no controls or sounds. Both are utterly useless to a freedom-minded user until someone writes a free interface and some free programs for that platform or creates some free art to fit that game meaningfully. If question at hand is: "Is it possible to use this program without any proprietary adornments?", the naive answer will be: "Yes, it is capable of being used with free blobs (if they exist)."; but if no such free blobs actually do exist, then that answer does not satisfy the main intention of the question, namely: "Is this actually possible in practice or only in theory". In theory, it is the case that many proprietary games are capable of using free replacement blobs; which is indeed the popular practice of so-called: "mods". For this reason, the point of the program being merely capable of using free blobs is not an interesting one to make. One can easily make the counter-argument that if the only existing blobs that could make the program in any way useful are non-free, then the mere distribution of that program, at least in compiled form, even without being accompanied by any non-free blobs, is either pointless, or constitutes a recommendation to seek out and use those non-free blobs. In case that this viewpoint is unfamiliar to the reader, it should be noted that this is the very standard to which Debian has held it's binary packages for many years.
 
-FWIW personally, i would not draw the line between functional vs non-functional in any context - its all the same "kind of stuff" to the computer : bits and bytes - it could be intuitively compared to the food you eat - would it be sensible to say that food that is consumed for nutritional (functional) reasons, should be organic and non-toxic; but that junk foods containing no nutrients (non-functional), but instead, a cornocopia of un-pronounceable chemicals, are inherently acceptable because they are not intended to be nutritious?
+A game is not at all comparable to a compiler. It is not a general purpose processing tool. It's sole use-case depends intrinsically on it's data existing, and fitting the main program's non-general purposes. That is not only in terms of valid syntax and encoding but in every facet of it's form and purpose. Any analogy to an agnostic data processor is inappropriate.
 
+The conventional meaning of "data" is that of some conformant input flowing through a pipeline for processing or computation in order to produce some output that is otherwise non-essential and unrelated to the intrinsic functionality of the processing program. A clear example would be  source code input to GCC. Clearly, game and GUI assets are not merely that kind of data, isolated from the main program. Most generally, these binary assets are necessarily not candidates for streaming as could be the case for the conventional input data previously described. In most cases, these assets carry very specific semantics related to the program itself where spatial and temporal precision are critical; as such the assets that represent these precise events are fully pre-loaded into the program memory space. This is done in order to make the program itself useful to the user and only for that intrinsic purpose. As such, it can not reasonably be considered as arbitrary transient data but much more akin to specific library loading.
 
----
-TODO: bits from the "free culture definition"
+To label programs as "functional" but the art and music that constitutes the interfaces as "non-functional" (with the right to modify them being therefore unimportant) is to say that these binary assets are arbitrary or optional (and any modifications are orthogonal to the functionality of the main program itself). If they are not optional then they serve some purpose; if they are not arbitrary then they serve some specific purpose; and if they serve some specific purpose then modifications are meaningful and the end user should be able to handle them in the same "preferred" ways as the author would. All of those are true for game/GUI art and sounds. They may not be executable machine instructions but they each play a necessary and specific role for the proper operation of the program as a whole. A game's assets and the game state that triggers them to be displayed are tightly coupled components that serve a single unified "function", namely: that of being an entertaining toy. The same could be said of any other GUI or the error messages of GCC for that matter. After all, error messages are just raw, non-executable byte strings; so should they be exempt from the licensing terms of the host program? I think most people would agree that it would be difficult to make a convincing argument for that, especially not on the grounds that they are arbitrary data. Each and every one of them must align semantically with the context in which they are to be triggered and presented. Sure, any properly encoded text string could fit the slot, just as any properly encoded image file could replace any other; but surely, trees the color of the sky and rivers made of leopard skin would be as confusing and disturbing to a game player as it would be to a programmer if GCC error messages were replaced with Chinese cookie fortunes. In both cases, treating binary assets as arbitrary or optional jeopardizes the utility and appeal of their host program greatly; and so they should be considered to be necessary and specific, and as such, deserving of the same freedom as the host software.
 
-On 05/16/2018 10:29 AM, Adonay Felipe Nogueira wrote:
-> I must also complement what was said here by noting that the Definition
-> of Free Cultural Works does require complete corresponding source
 
-the fundamental flaw there, is that it is worded as to say that the
-sources must be available in order for the work to be called a "free
-culture work" - the GPL is the only licenses that actually provides that
-stipulation - yet, the section preceding that statement which defines
-the "free culture licenses" does not include that stipulation - so
-practically speaking, taken as a whole, what that document is actually
-saying (and it is expressed literally) is that a "free culture license"
-does not qualify the work to be a "free culture work" and it fails to
-mention that only the GPL would satisfy the latter - which brings
-squarely into question: which they consider to be the primary definition
-of "free culture" - if it is the former, then any work using a "free
-culture license" can call itself "free culture"; but most such works are
-definitively not "free culture works" - which is of course
-double-talking nonsense
+== The Free Culture Definition ==
 
+The Free Culture Definition is unfortunately not precise enough to "define" itself adequately. It is worded such that the sources of the work must be available in order for the work to be called a "Free Culture work". The GPL is the only licenses that actually provides that stipulation. Yet, the section preceding that statement, which defines the "Free Culture Licenses" does not include that stipulation. So practically speaking, taken as a whole, what that document is actually suggesting (and it is expressed literally), is that a "Free Culture License" does not qualify the work to be a "Free Culture Work"; and it fails to mention that only the GPL would satisfy the latter. This raises the crucial question: which do they consider to be "the definition" of "Free Culture". If it is the former, then any work using a "Free
+Culture License" can call itself "Free Culture"; but most such works are definitively not "Free Culture Works"; which is of course, double-talking nonsense.
 
-On 05/16/2018 10:29 AM, Adonay Felipe Nogueira wrote:
-> Although I'm not discarding the possibility that some
-> activists of "free culture" might not know of such requirement.
+It quite appears that the Free Culture Definition was intentionally worded in such a wishy-washy way; as to satisfy both the "open" and "libre" camps; so that anyone is free to choose either interpretation. For example, the list of "free culture licenses" has a categorization of "practical modifiability", which is described as:
 
-indeed from my experience, for the most part they do not - and as i
-noted above it is only a requirement for a "free culture work" - but it
-is not a requirement for a work of "free culture" - it quite seems that
-it was worded is such a wishy-washy way as to satisfy both the "open"
-and "libre" camps; so that anyone is free to choose either interpretation
+  "The licenses which require practical modifiability usually define a notion of source code, source data or similar."
 
-the list of "free culture licenses" has a categorization of "practical
-modifiability" which is describes as so:
+Yet, it denotes the "MIT" license as having this characteristic, which it is not. The license text itself explicitly excludes it's applicability to artworks. The MIT-style licenses
+explicitly cover "software and associated documentation files"; neither of which are consider to be artworks, literature, or any other sort of "cultural works".
 
-  "The licenses which require practical modifiability usually define a
-notion of source code, source data or similar."
+Is it any wonder why people may get the wrong impression?
 
-yet, it denotes the "MIT" license as having this characteristic - it
-does not - and as i mentioned before, the license text itself explicitly
-excludes it's applicability to artworks - the MIT-style licenses
-explicitly cover "software and associated documentation files"; neither
-of which are consider to be artworks, literature, or any other sort
-"cultural works"
 
-is it any wonder why people may get the wrong impression
+TODO: more to come