www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Use of proprietary binaries
Date Sun, 23 Nov 2008 15:42:26 GMT

On Nov 23, 2008, at 12:24 AM, William A. Rowe, Jr. wrote:

> Oh it can be used.  If the license isn't appreciated, the  
> implementation
> can be replaced.

Agree.
>
>
> But can it be shipped?

There's no plan to ship this code as part of a release.

> Due to Henri's appropriate interpretation of 1.
> below, the answer looks like a resounding "no".

The only issue that is being raised is whether simply having the code  
in the svn repository constitutes a release. And we have precedent for  
having code in the repository that we don't plan to release (or  
replace).

Craig
>
>
> ralph.goers @dslextreme.com wrote:
>> I agree. I know the question asked wasn't "Can we use the  
>> dependency?".
>> But I think the answer to the question being asked is irrelevant if  
>> the
>> answer is no.
>>
>> Ralph
>>
>> On Sat, Nov 22, 2008 at 1:05 PM, Henri Yandell <bayard@apache.org
>> <mailto:bayard@apache.org>> wrote:
>>
>>    Small license, so pasting in here:
>>
>>    ****
>>    You may use or redistribute the files or modules contained in  
>> this jar
>>    subject to the following terms:
>>
>>    The WebSphere Application Server files or modules contained in  
>> this jar
>>    may be redistrubuted as provided by IBM to you, and only as part  
>> of Your
>>    application distribution.
>>
>>    You may not use IBM's name or trademarks in connection with the
>>    marketing
>>    of Your applications without IBM's prior written consent.
>>
>>    IBM PROVIDES THESE FILES OR MODULES ON AN "AS IS" BASIS AND IBM
>>    DISCLAIMS
>>    ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED  
>> TO, THE
>>    WARRANTY OF NON-INFRINGEMENT AND THE IMPLIED WARRANTIES OF
>>    MERCHANTABILITY
>>    OR FITNESS FOR A PARTICULAR PURPOSE.  IBM SHALL NOT BE LIABLE  
>> FOR ANY
>>    DIRECT, INDIRECT, INCIDENTAL, SPECIAL OR CONSEQUENTIAL DAMAGES
>>    ARISING OUT
>>    OF THE USE OR OPERATION OF THE FILES OR MODULES .  IBM HAS NO  
>> OBLIGATION
>>    TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS OR
>>    MODIFICATIONS TO
>>    THE FILES OR MODULES .
>>    ****
>>
>>    1) I don't think it's an acceptable license for us - I'm concerned
>>    that it doesn't allow our downstream users to redistribute it,  
>> which
>>    is an essential part of an open source distribution + the Apache
>>    promise to users.
>>
>>    2) Whether we're happy with a dependency that does not have a  
>> source
>>    option - I would be but there may be disagreement. I'm not sure  
>> we've
>>    had that use case yet. (may not matter based on the first one).
>>
>>    Hen
>>
>>    On Fri, Nov 21, 2008 at 12:35 PM, Michael Dick
>>    <michael.d.dick@gmail.com <mailto:michael.d.dick@gmail.com>>  
>> wrote:
>>> Hi all,
>>>
>>> I work on the OpenJPA project and we have an issue with a  
>>> compilation
>>> dependency on an API owned by IBM.
>>>
>>> IBM provided the API in binary format with a license that allows  
>>> us to
>>> distribute it with our application (ie OpenJPA). It's my
>>    understanding that
>>> we are not allowed to publish the binary elsewhere though (for
>>    example we
>>> would not be allowed to put it on my home directory on
>>    people.apache.org <http://people.apache.org>).
>>>
>>> I wasn't sure how we could limit the exposure of the API, and the  
>>> best
>>> solution I  came up with was to include it in version control (SVN).
>>>
>>> As a result anyone who extracts the source code from SVN gets a
>>    copy of the
>>> API, and may use it to compile OpenJPA. However we do not
>>    distribute the jar
>>> with the pre-compiled binary distributions of OpenJPA. If the API
>>    is needed
>>> we expect it to be provided by IBM (WebSphere in this case).
>>>
>>> I'm looking for guidance on how where we should include and
>>    document binary
>>> dependencies like this one. Can we include a binary like this is
>>    SVN and
>>> just add the approriate disclaimer to NOTICE.txt? Would it be
>>    better to make
>>> the API available on openjpa.apache.org
>>    <http://openjpa.apache.org> and download it from there as a part
>>> of our build?
>>>
>>> In case it helps the license that the jar was distributed with is
>>    available
>>> on my people.apache.org <http://people.apache.org> page at
>>> http://people.apache.org/~mikedd/ibm-uow-license.txt.
>>>
>>> Thanks in advance,
>>>
>>> -mike
>>>
>>
>>     
>> ---------------------------------------------------------------------
>>    DISCLAIMER: Discussions on this list are informational and  
>> educational
>>    only.  Statements made on this list are not privileged, do not
>>    constitute legal advice, and do not necessarily reflect the  
>> opinions
>>    and policies of the ASF.  See <http://www.apache.org/licenses/>  
>> for
>>    official ASF policies and documents.
>>     
>> ---------------------------------------------------------------------
>>    To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>    <mailto:legal-discuss-unsubscribe@apache.org>
>>    For additional commands, e-mail: legal-discuss-help@apache.org
>>    <mailto:legal-discuss-help@apache.org>
>>
>>
>
> ---------------------------------------------------------------------
> DISCLAIMER: Discussions on this list are informational and educational
> only.  Statements made on this list are not privileged, do not
> constitute legal advice, and do not necessarily reflect the opinions
> and policies of the ASF.  See <http://www.apache.org/licenses/> for
> official ASF policies and documents.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>

Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Mime
View raw message