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:[EMAIL PROTECTED]] > Sent: 30 January 2002 16:04 > To: 'Dirk-Willem van Gulik' > Cc: [EMAIL PROTECTED]; 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 [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > 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 [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. > > <snip list of jars/> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
