Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: domain of ralph.goers@dslextreme.com
 designates 66.51.199.81 as permitted sender)
Message-ID: <43FC73FC.2040402@dslextreme.com>
Date: Wed, 22 Feb 2006 06:23:56 -0800
From: Ralph Goers <Ralph.Goers@dslextreme.com>
Reply-To: rgoers@apache.org
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [VOTE] Release 2.1.9
References: <43FA3070.90400@dslextreme.com> <43FA4012.80804@apache.org>
 <43FA52B6.30808@dslextreme.com> <43FA6CC9.3030804@apache.org>
 <43FC2E3A.8040908@apache.org>
In-Reply-To: <43FC2E3A.8040908@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
>   
>>> I believe the alternatives that were mentioned were to either get the 
>>> OK from legal or not deliver the jcr block as part of the release.  If 
>>> the answer above means you don't feel we have permission than the 
>>> release should go out without JCR.
>>>       
>> The API can be redistributed with an implementation, and we do 
>> redistribute the implementation. Does this give use the permission to 
>> redistribute the API with the implementation? IANAL and I don't know...
>>
>>     
> Ok, so how do we solve this issue? I understand the comment from Roy
> that we are not allowed to ship the jar right now. I personally would go
> the easiest way: remove the jcr api from the repo, disable the block by
> default, add a readme that people have to download the jar and put it
> into local libs to build the block.
>
>   
+1
Ralph