[hydra-dev] Project Hydra update

[John Todd]

Time to poke people in the eye here about this.

We'd love to get some feedback on if people think this is OK.  I think  
that it's the same license as we've used in the past, but the  
interpretation of where the API boundaries are would be the only issue  
that I would expect would create some closer looks from everyone on  
the list.

Hurrah?  Boo?  What's the thought here?

JT


On May 26, 2010, at 12:46 PM, Kevin P. Fleming wrote:

> 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.
> <LICENSE_v3.txt>_______________________________________________
> Project Hydra Development Discussion List
> NOTE: All content you receive from this list is should be treated as  
> confidential.
>
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/hydra-dev

---
John Todd                       email:jtodd at digium.com
Digium, Inc. | Asterisk Open Source Community Director
445 Jan Davis Drive NW -  Huntsville AL 35806  -   USA
direct: +1-256-428-6083         http://www.digium.com/