Mailing-List: contact legal-discuss-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: legal-discuss@apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <48FDE8E1.30001@apache.org>
Date: Tue, 21 Oct 2008 16:36:17 +0200
From: Simon Kitching <skitching@apache.org>
User-Agent: Thunderbird 2.0.0.17 (X11/20080922)
MIME-Version: 1.0
To: legal-discuss@apache.org
Subject: Re: Incorporating Jakarta library in my program
References: <48F88D6B.9050504@uni-tuebingen.de>
 <3d4032300810170917x353e9698q243c5d48c1538945@mail.gmail.com>
 <48FDB0C9.6010207@uni-tuebingen.de>
 <08A51DB2-9248-46E2-A9A7-60F06743B892@gbiv.com>
 <48FDDD39.4070008@uni-tuebingen.de>
In-Reply-To: <48FDDD39.4070008@uni-tuebingen.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit


>>> Let me explain my problem again: if I include the jar into my jar, the
>>> jar program takes over the files LICENSE and NOTICE from the META-INF
>>> directory, which are put there by the CLI build system.
>>>       
>> So, don't use the CLI build system.
>>     
>
> You sound like you want to keep people from using Jakarta stuff.  The
> thing about the Apache license is to let others use it, isn’t it?
>   

Hendrik, it sounds to me like you are including the patched CLI code
directly into your app's jarfile as a bunch of .class files. If you were
to build a "commons-cli-hendrik.jar" file then reference that separately
like any other third-party jar then maybe things would get simplified.
If *your* app is GPL but depends on APL-licensed jars, things are a lot
simpler than if you have a single jar where some of the .class files are
APL'd and some are not.


> Actually, the jar is not included in the other jar, but rather its
> contents are copied over.  Both jars are merged, so to say.
>
> And once again, I do not want to modify the license terms, I just want
> to make sure I do nothing wrong.
>   
Mixing all the code up in your build process makes things much more
complicated than they need to be. You could ensure that your build
process moves the license-related files from cli to META-INF/cli in your
final built jar, ie put them in a subdir. The AL requires you to have
the info in your product, but doesn't say specifically where, and that
seems reasonable to me. That then removes possible confusion with the
licensing terms for your overall app. But simply having them in the
meta-inf of a separate "commons-cli-hendrik.jar" seems cleaner.

By the way, the "AL 2.0 improvements" that original wikipedia article
you quoted talks about is related to making things easier for people
(including apache itself) to release their own code under the AL. Don't
mix that up with the requirements for simply *using* AL-licensed code
within some other project; these are separate subjects.

IANAL and am not speaking on behalf of the ASF etc.

Regards,
Simon

-- 
-- Emails in "mixed" posting style will be ignored
-- (http://en.wikipedia.org/wiki/Posting_style)


---------------------------------------------------------------------
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