On Wednesday, October 30, 2013, 8:49:47 AM, Lists wrote: > On Tue, 29 Oct 2013 20:50:40 +0100 > Pablo Rodríguez <oi...@web.de> wrote:
>> On 10/28/2013 10:49 PM, John Sullivan wrote: >> > On Monday, October 28, 2013, 8:54:30 PM, Pablo Rodríguez wrote: >> >> But I think Flash is the way to go (at least for now). >> > >> > Write a small perl script (or similar) to convert the source >> > timeline data into ActionScript variable declarations within >> > a .action block in a separate file. >> > >> > Use .include from the main .sc to incorporate those declarations >> > into the final SWF. > That is merely attempted obfuscation of the original time-line data. > It doesn't exactly resolve the licensing issue. Not at all. I think we are agreed that the original timeline data (both data and timing informations) are due copyright protection as a separate work. The output of the transformation script (ie, the same timeline data merely expressed as a set of ActionScript variable declarations) would be a derived work of that, and therefore fall under the same license/restrictions. As a purely mechanical transform with only trivial additions, it is unlikely that it would acquire any additional copyright. (Though if the original license was a use-without- modifications one, that might nix this step.) The transformation script itself however, since it could act on any similarly formatted input file(s) and is not tied to any particular one, would not be a derived work of the original timeline data - it would be its own work and so a license could be chosen to suit the author of that. (Presumably the same as the main .sc file would be most convenient.) The main .sc file, also not being tied to any one particular set of timeline data files, would not count as a derived work of them. If the interface it imports from the modified timeline data is generic (say, one array of text strings called timeline_lines[], one equal sized array of timestamps called timeline_times[]) and available from any output produced by the transformation script. As long as it itself embeds no special knowledge of any particular source input file, it cannot possibly be considered a derived work of any one of them, otherwise you'd end up with the ridiculous situation that it would automatically and silently become a derived work as soon any anyone produced a new timeline source file. So the main .sc, the transformation script, the timeline data (including transformed timeline data) are all three separate works, redistributable under each their own terms, which is what I think Pablo is after here. If all you care about is distributing the main .sc itself and have no concern about what people downstream would be legally allowed to do with it (and I think that *is* worth considering, if they effectively wouldn't be able to actually use it), that is as far as it goes. The final concern is that the final SWF, embedding both the main .sc and the timeline data, becomes a derived work of both, and the GPL at least probably therefore requires anyone distributing the SWF to make available *all* source data required to reproduce the final SWF under terms no more restrictive than the GPL itself. If the licenses of the components do not allow for this, then the SWF itself may not be distributed. Which might include putting it on a webserver to use it normally (unless there was a special license exception for that case). To deal with that you would pretty much have to store the data separately on the server and use URLLoader within the SWF to load it at run time, again with no special built-in knowledge of any one file, to make it clear the timeline data is merely data *input* to the final program, not a component part *of* it. >> > Both the script and the main .sc remain unencumbered, the "end user" >> > will need to provide their own source data to complete compilation. >> >> Thank you very much for this, John (you make my day :-)). > .. and the source data along with the result of the compilation using > it, could be considered someone's artistic endeavour. >> I think this can solve the issue (at least from the perspective of the >> user). > Does it? > Chris. > --------------- > SWFTools-common is a self-managed list. To subscribe/unsubscribe, or amend an > existing subscription, please kindly point your favourite web browser > at:<http://lists.nongnu.org/mailman/listinfo/swftools-common> John -- Dead stars still burn --------------- SWFTools-common is a self-managed list. To subscribe/unsubscribe, or amend an existing subscription, please kindly point your favourite web browser at:<http://lists.nongnu.org/mailman/listinfo/swftools-common>
