cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <>
Subject xml-cocoon2 status, RE: Hailing all committers.
Date Wed, 30 Jan 2002 16:04:07 GMT

Just want to let you know the status of the xml-cocoon2 CVS module on
this subject.

All libraries (except one - jstyle.jar - still trying to reach the
author) have got license under legal/ folder. These licenses are:

 - The Apache Software License, Version 1.1

     a. Subject to the terms of this Agreement, each Contributor hereby
     grants Recipient a non-exclusive, worldwide, royalty-free copyright
     license to reproduce, prepare derivative works of, publicly
     publicly perform, distribute and sublicense the Contribution of
     Contributor, if any, and such derivative works, in source code and
     object code form.

 - Hewlett Packard License
     2. Redistributions in binary form must reproduce the above
     notice, this list of conditions and the following disclaimer in the
     documentation and/or other materials provided with the

 - 'BSD License' as endorsed by
     Redistributions in binary form must reproduce the above copyright
     notice, this list of conditions and the following disclaimer in the
     documentation and/or other materials provided with the

 - Sun Microsystems, Inc.  Binary Code License Agreement
     b. License to Distribute Runtime. Subject to your
     obligation to indemnify Sun pursuant to Section 3
     below, Sun grants to you a non-exclusive,
     non-transferable limited, royalty-free license to
     reproduce, distribute offer to sell and sell the
     Software provided that you: ..."

 - Copyright (c) 1998-2000 World Wide Web Consortium
     Permission is hereby granted to use, copy, modify, and distribute
     this source code, or portions hereof, documentation and
     for any purpose, without fee, subject to the following

 - Public domain. No license text available.

 - Another one from Sun
    2.2 In addition to the license granted
    in Section 2.1, Sun grants to you, a non-exclusive,
    non-transferable, royalty-free and limited license to
    distribute the Licensed Software modified by you as
    permitted in Section 2.1 ("Modified Software") in source or
    binary form, provided that; ..."


 - Copyright (c) 2000-2001 The XML:DB Initiative
    2. Redistributions in binary form must reproduce the above copyright
    notice, this list of conditions and the following disclaimer in
    the documentation and/or other materials provided with the


<snip header/>

> L.S.
> I apologize if you've seen this message before. But below is a message
> send to with regard to jar distribution which
> your immediate attention.
> You are receiving this message because you have commit access to an
> XML repository -or- because you have in the past commited to code
which is
> now in an XML repository.
> We've got 3rd party jar's in our repository which perhaps should not
> there. This needs action by the committers - and I'd like to see quick
> rough consensus on what path forward you'd prefer. I.e. wack now, talk
> later or quick restructure followed by a carefull wack.
> Bear in mind that in case of too slow an action - the default is to
> all *.jar's from all xml-* project repositories.
> Dw
> Date: Mon, 28 Jan 2002 18:01:58 -0800 (PST)
> From: Dirk-Willem van Gulik <>
> To:
> Subject: URGENT: 3rd Party jar's in apache CVS need immediate action.
> XML Folks,
> We've been a little to slack in letting Jar's creep into our
> While pure source code is typically vetted - and on mass ingestion
> by the various contributors and ASF licenses - the jar's have escaped
> scrutiny.
> Or in other words - we have some 50 odd jar's in an ASF repository
> are *not* under the ASF license - or where the license is unclear. See
> end of this message for more details.
> Worse: some have a license which may actually expressly *forbids* them
> 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
> 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.
> 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
> 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 -
> 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 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 -> foem
> 		on 2002-31-02 by
> 		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
> 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.

<snip list of jars/>

To unsubscribe, e-mail:
For additional commands, email:

View raw message