Dirk,
I've checked those used by Xerces-C++ (xml-xerces/c/), and now only
style-apachexml.jar,
stylebook-1.0-b2.jar
xalan.jar, and xerces.jar are left which I believe are under ASF license.
Thanks!
Tinny
Dirk-Willem van Gulik wrote:
> Folks,
>
> We've been a little to slack in letting Jar's creep into our repository.
>
> While pure source code is typically vetted - and on mass ingestion covered
> by the various contributors and ASF licenses - the jar's have escaped this
> scrutiny.
>
> Or in other words - we have some 50 odd jar's in an ASF repository which
> are *not* under the ASF license - or where the license is unclear. See the
> end of this message for more details.
>
> Worse: some have a license which may actually expressly *forbids* them to
> be distrubuted by the ASF in such a way.
>
> OK - now that we are aware of that - we'd better fix it. And we'd better
> be seen to do this swiftly.
>
> So no matter what - we need to have the jar's with licenses which
> prohibits the ASF of having them there in CVS zapped ASAP - i.e. within
> days - even if this is at the expense of zapping a bit too much.
>
> Inaction is not an option - in cases like this we will always act to be
> rather safe than sorry.
>
> I see two parts to this - and several paths.
>
> Could you folks get me an opinion ?
>
> 1. Fixing the problem
>
> Option 1.1
> find . -name '*.jar' -exec rm {} \;
> in the next72 hours.
>
> Option 1.2
> Within the next 72 hours - each projects
> makes sure it's jar's adhere to the guidelines
> below. All others are zapped.
>
> Option 1.3
> If we feel we need more time:
> Access to CVS is closed for the public while
> we discuss how to solve it - and is only
> reopened when it is clean
>
> This step one need to happen in the next few days - if not sooner.
> Unless we simply close access for the time beeing. (IMHO a bad idea).
>
> The next step - fixing things can take more time:
>
> 2. Getting our code to work again.
>
> Option 1.1
> Each project put's their jar's back in - but
> according to the guidelines below.
>
> Option 2.2
> We create a 'xml-third-party' repository for
> all the third party jar's. Following the
> guide lines below.
>
> So we keep all 3rd party and alien code in
> one place.
>
> What exactly those guide lines are to be - I am not sure.
>
> But the aim is to prevent .jar's to creep into the tree too easily - and
> to be able to fairly quickly scan for non compliance.
>
> Proposed guidelines for jar import
> - and feel free to comment/fix - this is not so urgent.
>
> - Each import is reviewed and under the ASF license.
>
> - If this is not the case; i.e an alien license: it needs
> to be under an ASF compatible license. In this case - you
> must Cc: the [EMAIL PROTECTED] in on the fact that you are
> importing alien code. (Note Cc: - not get permission - that
> you get by getting +1's from the other commiters).
>
> - 3rd party jars are to live in:
>
> <xml-project-name>/lib/foem.jar
>
> And there MUST be a file:
>
> <xml-project-name>/lib/README.foem.txt
>
> Containing information as to where this jar was sourced. If
> the license contained special clauses; such as an advertizing
> clause, etc - this document details how that clause was met.
> I.e.
> The Foem Jar converts Bayer patterns
>
> Sourced from http://www.webweaving.org -> foem
> on 2002-31-02 by [EMAIL PROTECTED]
>
> Note that there is also an advert/link in the
> docs (see docs/dependencies.html) to the site.
>
> See LICENSE.foem.txt and the web site for
> more information.
>
> And there MUST be a file with the license:
>
> <xml-project-name>/lib/LICENSE.foem.txt
>
> With the relevant name. I.e. they should match:
>
> xml-([\w\-\_]+)/lib/([\w\_\-\.]+).jar
> xml-([\w\-\_]+)/lib/README.([\w\_\-\.]+).txt
> xml-([\w\-\_]+)/lib/LICENSE.([\w\_\-\.]+).txt
>
> Again - the above is just a proposal.
>
> And I do not really knwo what the right approach is. It is so easy to make
> this into a 'bigger' thing than really is needed.
>
> Anyway - the final aim should be:
>
> - Track the origin of jar's as well as we are able
> now to connect sections of code with the coder who
> wrote it through cvs commits.
>
> Then we/the ASF is happy again.
>
> Ok - the cat is out of the back - and the clock is ticking.....
>
> Dw.
>
> Below is a list of jar's.
>
> Syntax:
> <jar-name> <version's (. means no version)>
> <projects it is used in>
>
> Part I
>
> Third party JAR's - which do not seem to be ASF originated (according to
> my judgment/cursory scanning - I am going to be wrong !)
>
> openorb 1.2.0
> xml-xindice
> runtime .
> xml-xalan
> js .
> xml-batik
> jaxp .
> xml-batik
> bsf . 2.2 . . .
> xml-cocoon xml-cocoon2 xml-fop xml-stylebook xml-xalan
> wsdlj 4
> xml-axis
> rdffilter .
> xml-cocoon2
> junit . 3.7 .
> xml-cocoon2 xml-security xml-xerces
> jstyle .
> xml-cocoon2
> rhinor2 1.5
> xml-cocoon2
> jisp0_2 1
> xml-cocoon2
> maybeupload0-5pre3 1
> xml-cocoon2
> jimi 1.0 1.0
> xml-cocoon2 xml-fop
> bsfengines . .
> xml-cocoon xml-stylebook
> w3c .
> xml-cocoon xml-xerces
> hellobean .
> xml-soap
> dom-2-cr .
> xml-contrib
> jena .
> xml-cocoon2
> openorb_tools 1.2.0
> xml-xindice
> junit7 3
> xml-xindice
> xmldb 20010924 .
> xml-cocoon2 xml-xindice
> lucenerc2 1.2
> xml-cocoon2
> idb .
> xml-xalan
> sax-bugfix .
> xml-cocoon
> java_cup .
> xml-xalan
> jaxp-javadoc .
> xml-crimson
> sisc .
> xml-cocoon2
> sax 2.0
> xml-contrib
> buildtools .
> xml-fop
> dom 2
> xml-cocoon
> foprc 0.20.3
> xml-cocoon2
> velocity 1.2
> xml-cocoon2
> xt 19991105
> xml-cocoon2
> deli 20020114
> xml-cocoon2
> jtidyaug2000r7-dev 04
> xml-cocoon2
> BCEL .
> xml-xalan
> clutil .
> xml-axis
> hsqldb 1.61
> xml-cocoon2
> xmldb-xupdate .
> xml-xindice
> JLex .
> xml-xalan
> resolver .
> xml-cocoon2
> optional .
> xml-xerces
> infozone-tools .
> xml-xindice
>
> Part II
>
> Jars which I ignored - as I am fairly sure they are 100% ASF. Please
> correct me if I am wrong :-)
>
> stylebookb1 1.0
> xml-stylebook
> xalan D11,D13,D14 2.2 2
> xml-fop
> xml-cocoon2
> xml-security
> xerces . 1.4.4 3.1 4.4.1
> xml-cocoon2 xml-fop xml-stylebook xml-xalan xml-xerces xml-xerces xml-xindice
> xml-security
> xml-batik
> servlet .
> xml-xindice
> xmldb-sdk .
> xml-xindice
> xalanjdoc 2
> xml-xalan
> avalon-framework 20020114
> xml-cocoon2
> xercesImpl .
> xml-xalan
> xml-apis . . 1.0
> xml-cocoon2 xml-xalan xml-xindice
> ant 3 1.1 4_1 . 1 1.4.1 .
> xml-cocoon2 xml-fop xml-xalan xml-xalan xml-xerces
> xml-batik
> xml-cocoon xml-xindice
> axis .
> xml-cocoon2
> xalan2_2 1
> xml-cocoon
> batik .
> xml-fop
> jakarta-regexp 1.2
> xml-cocoon2
> avalon-excalibur 20020114
> xml-cocoon2
> jakarta-oro 2.0.4
> xml-cocoon2
> fop15_0 0
> xml-cocoon
> commons-httpclient 20011012
> xml-cocoon2
> turbine-pool .
> xml-cocoon
> jakarta-logj-1.2alpha5 4
> xml-security
> stylebook .
> xml-fop
> servlet2 2 2
> xml-cocoon xml-cocoon2
> fop .
> xml-xerces
> antoptional 1.4.1
> xml-cocoon2
> style-apachexml .
> xml-xerces
> createPDF .
> xml-xerces
> logkit 20011212 1.0
> xml-cocoon2 xml-fop
> crimson-parser .
> xml-batik
> crimson-ant .
> xml-batik
> xalan 2.0.1 . . . 2.0.1
> xml-batik xml-stylebook xml-xerces xml-xerces xml-xindice
> batik-libs . 1.1.1
> xml-cocoon xml-cocoon2
> commons-collections 1.0
> xml-cocoon2
> stylebookb_xalan-2 1.0 1.0 3
> xml-batik xml-xalan
> stylebookb 2
> xml-cocoon xml-stylebook xml-xerces xml-xerces
>
> -----------------------
>
> ---------------------------------------------------------------------
> In case of troubles, e-mail: [EMAIL PROTECTED]
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
