[hydra-dev] Project Hydra update

[Kevin P. Fleming]

Hello to everyone - I'm sorry we've been so silent the last month.

First, let me give a short summary of WHY things have been quiet.  It
has not been from lack of development activity - we've continued to put
lots of work into Hydra research, and the process of developing the core
infrastructure has gone on unabated.  There has been no loss of momentum
in the actual code or thought that has been happening here at Digium,
but there was a period of time when we decided we were going to have an
internal discussion about licensing, and how (exactly) Digium was going
to make money with Hydra given our license model.

The issue of licensing has been sticky within Digium as well as within
the community in general.  I won't bore you with the details, but we had
to look at how Hydra licensing could work in a way that benefited both
Digium and the community.  This was a purely internal discussion, and in
order to keep from saying the wrong thing (or even just the "less than
accurate" thing) we decided to keep our heads down during that
introspection.  This means that some important things didn't get done
(like forming a steering committee) and we've lost important time having
to keep the project 'on hold' while these discussions occurred.  We're
committed to providing the resources required to meet our goals and
milestones, though, in spite of this delay.

The good news is that after extensive whiteboarding, soul-searching,
lawyer-consulting, and fine-print reading, we have decided that Hydra
will remain GPLv2 which is the exact same license that Asterisk is
distributed under today, which is what we had previously said would be
the case.  So, no change.  Almost.  Read on...

The consensus is that we (Digium) don't want to license Hydra in a way
that is more restrictive than the GPLv2.  It seems that the GPL is
sufficient to protect the project but not commercially biased in a way
that somehow favors Digium to the point where it makes contributions
difficult. (1)

Our goal is to make the software open and freely accessible.  We're
creating with Hydra a new architecture that is going to be even more
API-enabled than Asterisk 1.x has been in the past.  This made us a  bit
worried - what if there was no work contributed to Hydra, because the
API was so rich that software developed "around" Hydra was under no
obligation to be licensed under GPLv2 (or any open source license, for
that matter)?  This wouldn't serve anyone well - the tragedy of the
commons might skew the development effort such that no value was put
towards Hydra, and all the effort went into proprietary components that
got distributed outside of the GPLv2.

So we've looked at the GPLv2 more completely, and we're going to be
making some assertions that we believe are true in regards to how API
boundaries work with the new software.  The short form is: if the
program being developed uses the Hydra APIs to accomplish its intended
function, and couldn't accomplish that function without using those
APIs, then we will consider that program to be a derivative work of
Hydra and if it is distributed, that distribution must occur under the
GPLv2.  APIs aren't meant to exist in order to "cheat" the GPL. They're
meant to make applications work better across some types of
communications boundaries (sockets, for instance) and also to make code
re-usable between different applications.  If Hydra components are the
primary means an program uses to accomplish its intended functions, then
we see little difference between a linked-in option that shares
libraries (the "classical" sense of GPLv2 inclusion) and code that uses
the Hydra APIs over sockets or network connections.

We expect this will create some discussion, and perhaps objections.
We'd be interested in hearing what those are in this forum, so we can
determine if we're on the right track, or to give you our thinking on
the points you raise.  Remember that our goals are to get the best
"value" out of not only Digium's investment in time, but yours.  We
want to encourage (and require) as much development put back into Hydra
as possible, without suffering from some of the failings of the way we
managed the license issues surrounding Asterisk.

I've attached the draft LICENSE_v3.txt file to this message; you'll see
that it is very similar to the one we use with Asterisk, but with some
important changes. Please read it over, think about it, and let us know
your thoughts and feelings on the subject. It's very important that we
get this right as early as possible in the project, and this group is
our best resource to achieve that goal.

Thanks in advance for your time, and hopefully getting this issue
resolved will allow us to proceed full speed ahead on Hydra development,
which is what we'd all prefer to be doing.

=======

(1) Note that this doesn't change the "exception" that we'd like to
maintain, just like today where contributors grant Digium permission to
distribute their code outside the GPLv2.  Digium needs to survive, and
the way that seems most obvious going forward is to manage the value of
the effort that we put into Hydra.  As with Asterisk, we will be putting
(literally) millions of dollars of effort into the code development and
testing process.  We need to have the ability to make that value
available to commercial customers who might have specific legal or
business reasons that they wish to have a non-GPLv2'ed version of the
code.  This is the way it is today with Asterisk, and we see no
significant change in that model and hope that the community continues
to be satisfied with the method.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: LICENSE_v3.txt
Url: http://lists.digium.com/mailman/private/asterisk-scf-dev/attachments/20100526/7b26930e/attachment.txt