The law will see it in whatever we can prove it to be.
If we say it is a derived work and present our argument,
and someone else says no it's not.
Then the one who has the most persuasive argument in a
court will win.
> Anthony : Whether you consider them derived works does not matter. It's
> a matter of law, and they are. If you combine a stack and OpenCard the
> resulting program is a derived work of both OpenCard and the program.
> And if we try to say that "standalones are not covered" we run into the
> problems, similar to what I responded to Alain with.
>
> Alain : Which is why you are not in favour of LGPL, and would prefer
> that we use Perl Artistic instead, right Anthony?
The way I see it:
Interpreter = executable program code (or code segment)
Stack/Scripts = program data (or data segment)
The intrpreter loads the data, and executes it's
instructions. Changing the data segment of a program
without changing the executable (i.e. a standalone) could
very easily be proven not to be a derived work.
They are separate components packaged in the same file
for convienence and end user usability.
A derived work could not be separated from it's original
without rendering the derived work useless.
For those of you who are about to say a stack without
an intrepreter is useless you could write another OT
compatible interpreter to execute your stack. For
instance if Hypercard were Open Source, none of those
stacks could be considered derived works because I
could load them into Metacard.
It's almost a mute point because I like the Artistic
License equally as well. So you can count my vote
that way. Actually my vote goes to the majority vote
of any already existening license.
-- Michael --
PS Who makes the final decision anyway, and if it's a
vote then when is that going to happen. If we are
talking about licensing then we aren't talking about
developing. :)
