Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
From: "Vadim Gritsenko" <vadim.gritsenko@verizon.net>
To: "'Dirk-Willem van Gulik'" <dirkx@covalent.net>
Cc: <stefano@apache.org>,
	"'Sam Ruby'" <rubys@us.ibm.com>,
	<cocoon-dev@xml.apache.org>
Subject: RE: xml-cocoon2 status, RE: Hailing all committers.
Date: Wed, 30 Jan 2002 12:42:59 -0500
Message-ID: <00f801c1a9b5$8f881740$0a00a8c0@vgritsenkopc>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <00dd01c1a9a7$bf7939b0$0a00a8c0@vgritsenkopc>

Update:

1. I have got license for the jstyle package - the last jar in
xml-cocoon2 CVS module which was without license. Original of the
license text located at: http://astyle.sourceforge.net/license.html

2. Hewlett Packard License mentioned below is the BSD style license.


Vadim

> -----Original Message-----
> From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
> Sent: Wednesday, January 30, 2002 11:04 AM
> To: 'Dirk-Willem van Gulik'
> Cc: stefano@apache.org; Cocoon Developers
> Subject: xml-cocoon2 status, RE: Hailing all committers.
> 
> Hi,
> 
> 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
> 
>  - IBM PUBLIC LICENSE VERSION 1.0
>      "...
>      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
> display,
>      publicly perform, distribute and sublicense the Contribution of
> such
>      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
> copyright
>      notice, this list of conditions and the following disclaimer in
the
>      documentation and/or other materials provided with the
> distribution."
> 
>  - 'BSD License' as endorsed by OpenSource.org
>      "...
>      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
> distribution."
> 
>  - Sun Microsystems, Inc.  Binary Code License Agreement
>      "...
>      JIMI SDK, Version 2.0 SUPPLEMENTAL LICENSE TERMS
>      ....
>      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
> executables,
>      for any purpose, without fee, subject to the following
> restrictions:
>      ..."
> 
>  - 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; ..."
> 
>  - MOZILLA PUBLIC LICENSE 1.1
> 
>  - 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
>     distribution."
> 
> 
> Vadim
> 
> <snip header/>
> 
> > L.S.
> >
> > I apologize if you've seen this message before. But below is a
message
> > send to general@xml.apache.org with regard to jar distribution which
> needs
> > your immediate attention.
> >
> > You are receiving this message because you have commit access to an
> apache
> > 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
> be
> > there. This needs action by the committers - and I'd like to see
quick
> and
> > 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
> wipe
> > all *.jar's from all xml-* project repositories.
> >
> > Dw
> >
> > Date: Mon, 28 Jan 2002 18:01:58 -0800 (PST)
> > From: Dirk-Willem van Gulik <dirkx@covalent.net>
> > To: general@xml.apache.org
> > 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
> 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 pmc@xml.apache.org 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 Peter@duckling.org
> >
> > 		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.
> 
> <snip list of jars/>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org