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]
