cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Butler, Mark" <Mark_But...@hplb.hpl.hp.com>
Subject RE: xml-cocoon2 status, RE: Hailing all committers.
Date Wed, 30 Jan 2002 16:14:56 GMT
Hi Vadim

Just a quick confirmation that rdffilter is public domain and there is no
license available. It is written by Dave Megginson -
http://www.megginson.com/index.html - but this just links to the sourceforge
site you've already seen. 

Also the HP license we are using for DELI / Jena is a BSD license - hope
this is okay.

Mark

> -----Original Message-----
> From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
> Sent: 30 January 2002 16:04
> 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


Mime
View raw message