[asterisk-dev] SCF Licencing

[Kevin P. Fleming]

On 10/28/2010 04:56 PM, Nicolas Gudino wrote:
> I am also interested in this, and particulary how the paragraph starts:
> 
> "It is Digium’s interpretation"

Keeping in mind that none of us in this discussion are attorneys (myself
included), and that even if we were everyone who is a party to a license
agreement should consult their own counsel if they have questions about
it... I will state my opinion here, as I was the one who primarily
drafted the text in question in the Asterisk SCF license.

The GPLv2 is based on copyright law, and thus the notion of 'derivative
works' is fundamental to the protections and obligations of the license
agreement. Copyright law has, to my understanding, some long-standing
definitions of 'derivative works' as they apply to more typical literary
compositions (books, magazines, articles, etc.). In potential copyright
infringement cases involving such works, the rules for determining
whether something is 'derivative' or not are fairly well understood.

This is not (yet) the case for software. There are some aspects of
typical literary 'derivative' determination that do apply... obviously
if someone copies the source code of a piece of software, modifies it
and distributes the result that would pretty clearly be determined to be
a derivative work by most reasonable people.

The GPLv2 goes beyond that, though, and in section 2 defines 'works
based on the Program' to be anything that contains 'any portion of it'
(referring to the Program), and in section 2.b states that any work that
is derived from the Program must be licensed under the same GPLv2 license.

Now leaving the Asterisk SCF specific issues aside for the moment, as
has already been mentioned in this thread the Asterisk SCF APIs consist
of Slice definitions, which can only be practically used by utilizing
the Ice libraries from ZeroC. Most users of Asterisk SCF and Ice will be
using Ice itself under the GPLv2 as well, and as a result any component
written to use these APIs will have to be distributed under the GPLv2
because it will fit into one of the common software definitions of
'derivative work', since the Ice libraries will be linked into the
component's memory space at runtime. This restriction could be avoided,
of course, by licensing the Ice libraries under a non-GPLv2 license if
the component's distributor wished to do so (and such options are
available from ZeroC, and will be available from Digium as well).

Assuming that a component developer has addressed that concern, as the
paragraph in the Asterisk SCF license says, Digium believes that the
component would *also* be a derivative work of the Asterisk SCF
components it interacts with, due to the object-and-function-call nature
of component interaction when using Ice. This paragraph does not
'modify' the GPLv2 as some other posters in this thread have stated; it
just provides what Digium believes is a reasonable definition of
'derivative work' in the specific context of Asterisk SCF. Since the
GPLv2 does not define what it means to be a 'derivative work' (or even
clearly define what it means to be a 'work based on the Program'), it is
not unusual for licensors of software who choose this license to have to
come to their own conclusions as to what does or does not constitute a
'derivative work'. There are hundreds (if not thousands) of cases
already where a GPLv2-licensed program is commonly distributed and
installed as a shared library, loaded into the process space of another
program at run time, and the resulting combination is deemed to be under
the purview of the GPLv2... which results in the program that uses that
library also being distributed under the GPLv2, because it is considered
to be a derivative work of the library. This is commonly referred to as
the 'linking' aspect of the GPLv2, although the GPLv2 does not actually
refer to it using that term. Digium's opinion in the case of the
Asterisk SCF APIs is that usage of them is essentially equivalent to
'linking' to a library at run time, even though the actual process of
invoking functions provided by the library may involve communication
over a network connection of some sort.

As the license text says, this is Digium's opinion. Any other parties to
the license agreement (anyone who wishes to distribute programs that
interact with Asterisk SCF Slice-defined APIs) may have a different
opinion, and their counsel may have yet a third (or fourth) opinion.
None of this is black-and-white, primarily because there are far too
many ways that software can be constructed for a single license
agreement to conclusively and authoritatively define what constitutes a
'derivative work'.

(Note that I've set Followup-To on this message to point to the
asterisk-scf-dev mailing list; that's really a more appropriate forum
for this discussion)

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming at digium.com
Check us out at www.digium.com & www.asterisk.org