[hydra-dev] Project Hydra update

Wed Jun 2 16:06:52 CDT 2010

Ah, breaking out the old red rider BB gun again, JT?

This license scares me a bit and it may limit development in the area
which it enables so well.
If I were developing a proprietary program within hydra, I would be
forced to add
an isolation layer to maintain the license separation.  Although this is
not a hard thing to do,
it is a bit arbitrary and a waste of resources. 

David Johnson wrote some time ago:
http://www.mail-archive.com/license-discuss@opensource.org/msg06498.html

"Free Software should not be afraid of competition. If someone comes
along and "serverizes" the software, we should not be wringing our
hands, but busy writing Free clients instead.
"

/ed

On 6/2/10 12:07 PM, John Todd wrote:
> 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/
>
>
>
>
>
> _______________________________________________
> 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
>   