Re: [Swftools-common] basic question on ActionScript 2.0

[John Sullivan]

On Wednesday, October 30, 2013, 8:49:47 AM, Lists wrote:
> On Tue, 29 Oct 2013 20:50:40 +0100
> Pablo Rodríguez <address@hidden> 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