Licensing again.

[dion]

Sam Ruby <[EMAIL PROTECTED]> wrote on 06/02/2003 03:53:47 AM:

[snip] 
> Code under the ASF License is clearly OK.  As is the IBM Public License
> (the pre-Jakarta BSF, for example) and the MPL (Rhino).  The following
> public domain components are also approved: Antlr and Doug Lea's
> concurrency package.
> 
> Licenses clearly not conforming to the ASF's policies for distribution:
> LGPL, GPL, Sun's Binary Code License.

Could you please explain why ibiblio cannot distribute L/GPL and other 
opensource binaries as long as the license conditions are met?

--
dIon Gillard, Multitask Consulting
Blog:  http://www.freeroller.net/page/dion/Weblog
Work:  http://www.multitask.com.au



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Licensing questions

[dion]

For each ASF jar file distributed, we need to distribute the 
license/copyright and conditions from the source of that jar.

e.g. for ant, we need ants LICENSE, for jelly Jelly's license.

Until ASL v2, when all the licenses become the same text, I understand 
that we need a license for each binary distribution of ASF code. Is this 
correct?
--
dIon Gillard, Multitask Consulting
Blog:  http://www.freeroller.net/page/dion/Weblog
Work:  http://www.multitask.com.au


Sam Ruby <[EMAIL PROTECTED]> wrote on 06/02/2003 03:53:47 AM:

> Rodent of Unusual Size wrote:
> > 
> >>Roy T. Fielding wrote:
> >>
> >>>In short, the answer is no, and this applies to any software with
> >>>copyright of The Apache Software Foundation. 
> >>
> >>which brings up a very good point that may have been overlooked:
> >>this applies to anything on ibiblio or elsewhere that is copyright
> >>the asf.  it does not apply strictly to the repositories on the asf
> >>machines, but to the asf *code*.
> 
> This issue has come up before.  This time, let's flatten it.
> 
> In two weeks, there is a board meeting.  At that time, I would like to
> be able to report that the contents of the Maven repository conforms to
> the policies of the Apache Software Foundation.
> 
> Code under the ASF License is clearly OK.  As is the IBM Public License
> (the pre-Jakarta BSF, for example) and the MPL (Rhino).  The following
> public domain components are also approved: Antlr and Doug Lea's
> concurrency package.
> 
> Licenses clearly not conforming to the ASF's policies for distribution:
> LGPL, GPL, Sun's Binary Code License.
> 
> Please direct any questions or comments (including new licenses to be
> considered) to [EMAIL PROTECTED]  Some we can resolve for
> ourselves (e.g., the specific public domain packages above).  Others
> I'll batch up and forward to the board and/or licensing folk.
> 
> By the board meeting after that (3rd week in March), I'd like to have
> the infrastructure issues resolved (where should this data should be
> hosted, mirrored, etc).
> 
> - Sam Ruby
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: 
[EMAIL PROTECTED]
> 

> ForwardSourceID:NT000AD6BE 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [DRAFT1] Jakarta Newsletter - January 2003

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, "Daniel F. Savarese
" writes:
>Although the newsletter is for January, here's another item for
>Jakarta Commons from February (Commons committers feel free to
>ammend this entry):

Looks like I made some typing turds.  Here's a corrected version:

Near the end of January, Robert Donkin jumpstarted Commons Net
by calling for a vote to promote it from the Commons Sandbox
after a flurry of interest in releasing the current stable
code base.

http://marc.theaimsgroup.com/?t=10437764903&r=1&w=2

The vote concluded in February, with the minimum number of +1's,
an equal number of +0', and no -0's or -1's.

http://marc.theaimsgroup.com/?t=10443842365&r=1&w=2

The Jakarta Commons Team is pleased to announce that Commons Net
(formerly NetComponents) has been promoted out of the sandbox into
the Commons proper.  Commons Net is best known for its FTP package,
but it also implements a number of other Internet client protocols
such as Finger, Whois, TFTP, Telnet, POP3, NNTP, SMTP, and some
miscellaneous protocols like Time and Echo as well as BSD R command
support.

The first order of business for Commons Net is to freeze
the code and make a formal release that projects using earlier
incarnations of the code, such as Ant, can migrate to.  After
this first release, further development will continue, adding
new features, performance improvements, a test harness, and a
programming guide to supplement the API documentation.  Anyone
interested in helping out is encouraged to contribute.





msg07142/pgp0.pgp
Description: PGP signature

Re: [DRAFT1] Jakarta Newsletter - January 2003

[Daniel F. Savarese]

In message <[EMAIL PROTECTED]>, robert burr
ell donkin writes:
>(here's some bits and pieces from the commons.)
>
>Jakarta Commons
>===

Although the newsletter is for January, here's another item for
Jakarta Commons from February (Commons committers feel free to
ammend this entry):

Near the end of January, Robert Donkin jumpstarted Commons Net
project by calling for a vote to promote it from the Commons Sandbox
after a flurry of recent interest in releasing the current stable
code base.

http://marc.theaimsgroup.com/?t=10437764903&r=1&w=2

The vote concluded in February, with the minimum number of +1's,
an equal number of +0', and no -0's or -1's.

http://marc.theaimsgroup.com/?t=10443842365&r=1&w=2

The Jakarta Commons Team is pleased to announce that Commons Net
(formerly NetComponents) has been promoted out of the sandbox into
the Commons proper.  Commons Net is best known for its FTP package,
but it also implements a number of other Internet client protocols
such as Finger, Whois, TFTP, Telnet, POP3, NNTP, SMTP, and some
miscellaneous protocols like Time and Echo as well as BSD R command
support.

The first order of business for this Commons Net is to freeze
the code and make a formal release that projects using earlier
incarnations of the code, such as Ant, can migrate to.  After
this first release, further development will continue, adding
new features, performance improvements, a test harness, and a
programming guide to supplement the API documentation.  Anyone
interested in helping out is encouraged to contribute.





msg07141/pgp0.pgp
Description: PGP signature

Re: [Fwd: Maven as a top-level apache project]

[Pier Fumagalli]

On 9/2/03 2:05 "Costin Manolache" <[EMAIL PROTECTED]> wrote:

> And why not: DISPLAY the damn license and require the user to type
> "I do understand the terms of this licence" and click somewhere
> ( that may also cover the requirements of some of the packages ).

Click-through is something we always wanted to avoid...

Pier


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Fwd: Maven as a top-level apache project]

[Nick Chalko]

Nick Chalko wrote:



And why not: DISPLAY the damn license and require the user to type
"I do understand the terms of this licence" and click somewhere
( that may also cover the requirements of some of the packages ).

Or even better, if it's a GPL license Ruper should require the user
to type "I understand that all the software I ship that is bundled with
this jar will have to be GPLed". ( and if he types something wrong, 
he'll have to type the whole thing again :-).Adding dependencies 
should not
be easy.

We certainly need a way to indicate to the user that that a jar is
a build-time dependency, a runtime required dependency or an optional
runtime dependency.
 


Actually there are several usecases here to describe.

But this is why we need  a new project  to hash all this out.






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Fwd: Maven as a top-level apache project]

[Nick Chalko]

Costin Manolache wrote:


Nick Chalko wrote:

 

Agree, centipede has the same problem.  Easy to download a jar without
knowing it's liscense.
Sending a license file with a jar is something that the new Jakarta
Ruper project should handle.
   


And why not: DISPLAY the damn license and require the user to type
"I do understand the terms of this licence" and click somewhere
( that may also cover the requirements of some of the packages ).

Or even better, if it's a GPL license Ruper should require the user
to type "I understand that all the software I ship that is bundled with
this jar will have to be GPLed". ( and if he types something wrong, 
he'll have to type the whole thing again :-).Adding dependencies should not
be easy.

We certainly need a way to indicate to the user that that a jar is
a build-time dependency, a runtime required dependency or an optional
runtime dependency.
 

Agree,,  but one step at a time.
Lets get the project in the incubator first.


Costin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Fwd: Maven as a top-level apache project]

[Costin Manolache]

Nick Chalko wrote:

> Agree, centipede has the same problem.  Easy to download a jar without
> knowing it's liscense.
> Sending a license file with a jar is something that the new Jakarta
> Ruper project should handle.

And why not: DISPLAY the damn license and require the user to type
"I do understand the terms of this licence" and click somewhere
( that may also cover the requirements of some of the packages ).

Or even better, if it's a GPL license Ruper should require the user
to type "I understand that all the software I ship that is bundled with
this jar will have to be GPLed". ( and if he types something wrong, 
he'll have to type the whole thing again :-).Adding dependencies should not
be easy.

We certainly need a way to indicate to the user that that a jar is
a build-time dependency, a runtime required dependency or an optional
runtime dependency.

Costin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Fwd: Maven as a top-level apache project]

[Peter Donald]

On Sat, 8 Feb 2003 08:28, Bruce Atherton wrote:
> First, imports of incompatibly-licensed code are verboten but calling out
> externally to Java running a main method is alright, correct?

yep - as long as the class to execute is dynamically loaded.

> Second, can we optionally load incompatibly-licensed code dynamically at
> runtime? So long as it is not required, and would only occur if the user
> already had the package locally? For example, we might have an abstract
> factory that dynamically finds whatever JAXP-compliant parser you have on
> the classpath. Would it be a license violation to allow it to find an
> LGPL'd parser?

nope. As long as the interface is licensed appropriately then you are fine.

> Third, if the above is allowed, how about optionally compiled code? Ant's
> build.xml already conditionally compiles code based on the classes
> available in the classpath. Would it be a license violation to have code
> that imports LGPL classes but that is compiled only if the classes are on
> the classpath of the user doing the build? I understand that it couldn't be
> in any builds produced by Apache, of course.

The decision not to use LGPL in Apache code is not due to license violations 
but a policy based decision handed down from the board as they dont feel it 
furthers Apaches aims.

In many cases LGPL code can be used without license violation problems but 
because of the nature of java linking and the lack of clarity in LGPL wrt to 
javas notion of linking there is some usages that are grey areas and some I 
would definetly consider violations of the LGPL work. 

> java.* classes. But what about others?

Most (all?) of them are not license violations and the board has not as yet 
declared that they are not furthering Apaches aims.

-- 
Cheers,

Peter Donald

Fools ignore complexity.  Pragmatists suffer it.
Some can avoid it.  Geniuses remove it.
-- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Fwd: Maven as a top-level apache project]

[Nick Chalko]

Steve Downey wrote:


 

-Original Message-
From: news [mailto:[EMAIL PROTECTED]]On Behalf Of Dan Diephouse
Sent: Thursday, February 06, 2003 9:52 PM
To: [EMAIL PROTECTED]
Subject: Re: [Fwd: Maven as a top-level apache project]



It is your responsibility to enforce that policy.  Not maven and not the
ASF's.  When you integrate JAR or any resource into your project you are
doing so delibrately.  You should know where that jar originally comes
from.  If you don't, ask on the developers or user's list.  Someone will
gladly help.  Even better, search google, I'm sure something will turn up.

- Dan Diephouse
   


That's just it. Maven makes it easy to NOT do it deliberately. Jars are
slipstreamed in because they are transitive dependencies. I do have the
expectation that software from the ASF is under the ASF license, with no
other restrictions.

And searching google to find out where a jar came from is just silly. There
should be documentation with the project that downloaded it. If there isn't,
it's probably a license violation, since most licenses require that the
license accompany the software, or at least acknowledge the copyright.


 

Agree, centipede has the same problem.  Easy to download a jar without 
knowing it's liscense.  
Sending a license file with a jar is something that the new Jakarta 
Ruper project should handle.





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [Fwd: Maven as a top-level apache project]

[Steve Downey]

> -Original Message-
> From: news [mailto:[EMAIL PROTECTED]]On Behalf Of Dan Diephouse
> Sent: Thursday, February 06, 2003 9:52 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [Fwd: Maven as a top-level apache project]
>
>
>
> It is your responsibility to enforce that policy.  Not maven and not the
> ASF's.  When you integrate JAR or any resource into your project you are
> doing so delibrately.  You should know where that jar originally comes
> from.  If you don't, ask on the developers or user's list.  Someone will
> gladly help.  Even better, search google, I'm sure something will turn up.
>
> - Dan Diephouse

That's just it. Maven makes it easy to NOT do it deliberately. Jars are
slipstreamed in because they are transitive dependencies. I do have the
expectation that software from the ASF is under the ASF license, with no
other restrictions.

And searching google to find out where a jar came from is just silly. There
should be documentation with the project that downloaded it. If there isn't,
it's probably a license violation, since most licenses require that the
license accompany the software, or at least acknowledge the copyright.






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [Fwd: Maven as a top-level apache project]

[Steve Downey]

> -Original Message-
> From: Martin Poeschl [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, February 06, 2003 9:44 PM
> To: Jakarta General List
> Subject: Re: [Fwd: Maven as a top-level apache project]
>
>
> Steve Downey wrote:
>
> >From: <[EMAIL PROTECTED]>
> >To: "Jakarta General List" <[EMAIL PROTECTED]>
> >Sent: Thursday, February 06, 2003 8:07 PM
> >Subject: Re: [Fwd: Maven as a top-level apache project]
> >
> >
> >
> >
> >>>BTW, given the license discussions it seems unlikely a solution that
> >>>includes all the jars in the same place will work. So the "repository"
> >>>will be not only a storage for jars, but a set of tools to deal with
> >>>downloading from different locations with different methods (
> and mirror
> >>>lists, etc ). Again - I think this part can only be apache-wide.
> >>>
> >>>
> >>Sure, but let's not lose focus of what this is for. Distribution?
> >>Building? A company/individual can set up their own repository
> of jars (we
> >>all do) that they've accepted licenses for. The 'tools' should
> be able to
> >>work with that set up, similar to how Maven does today.
> >>
> >>
> >>
> >
> >One thing that has annoyed me is that Maven will download jars from the
> >ibiblio repository with no regard to the license of them. It's
> an easy way
> >for jars to come into a build without formal review and acceptance of the
> >license. My company's policy is to use only BSD, ASF, or similar
> licenses.
> >No GPL. And based on recent discussions here, we may prohibit LGPL. We do
> >also use commercially licensed software, and review carefully the
> >redistribution clauses. It's particularly troubling that the jars show up
> >without supporting documentation.
> >
>
> why don't you setup your own private repository where you can control
> which jars are stored there ... you don't need to use the ibiblio repo
>
> martin

The real problem with that is that my interest in maven only extends as far
as it's required to build other projects. I've downloaded the beta in order
to use it to build projects that require it. I don't intend to use it myself
(at least at this point) for my projects. So learning about setting up my
own repository is way too much work.

I'm conscientious about reviewing the licenses for software I bring in. Not
everyone in the organization is. That's an internal problem that has to be
addressed by raising awareness of the issue. However, the easier it is for
software to come in without review, the harder it is to manage the problem.
Particularly since when jars come in via maven, there's now a bunch of
detective work to be done to find out where it actually came from and what
the license is.








-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Jakarta Commons Locale] PROPOSAL

[Rodney Waldhoff]

You might want to try this again on the [EMAIL PROTECTED]
list, instead of jakarta-general (see #17 at
) preferably with [VOTE]
in the subject line as well as "PROPOSAL", if your intention is to call a
binding vote right now (as opposed to discussion of the proposal).

(I'll note Robert used the conventional proposal format, so we can
probably assume the to line was accidental.)

On Sat, 8 Feb 2003, Robert Simpson wrote:

> Proposal for Commons Locale component
>
> This is a proposal for creating a Locale component in the Jakarta Commons
> subproject, superseding and encompassing the "Resources" component
> that is currently in the Jakarta Commons sandbox.
>
> An HTML version of this proposal can be found at 
>http://iToolSet.com/locale/PROPOSAL.html
>
>
> 0) Rationale
>
> There are many different types of Java(TM)* objects that may be included in
> Java applications that support internationalization (i18n).  These include
> resources, message strings, formatters, Calendars, Currency objects, TimeZones,
> Exceptions, Collators, and BreakIterators, among others.
>
> There currently is a "Resources" component in the Jakarta Commons sandbox.
> However, there should be a common architecture for internationalization of any
> object, not one that is limited to Resources.  Therefore, a "Locale" component
> should be added to the Jakarta Commons proper.  The functions provided by the
> "Resources" component currently in the sandbox could be provided in a subpackage
> under the package created for the new Locale component.
>
>
> 1) Scope of the Component
>
> The proposal defines a common framework for internationalization of various
> Java classes.  This internationalization typically occurs by localizing
> instances of Java objects to a specific Locale.  The proposed framework would
> facilitate the internationalization of all objects to a single Locale per user,
> in either a single-user or multi-user environment.  For example, when localizing
> messages, both the message patterns and the inserted arguments should be localized
> to the same Locale.  This is a good example of why internationalization should occur
> at a higher level than simply the resources that supply the localized message 
>patterns.
>
> Two interfaces, "Localizable" (used by classes that implement both a get and
> set method for the Locale) and "Localized" (for classes that implement a get method
> only) would be defined.  Other implementers would be encouraged to declare their
> classes with one of these interfaces where appropriate.  Where this occurs, any
> Factory classes which generate localized/localizable (localized/able) versions of
> those objects would be included in that same package, rather than under the Locale
> component.  This is appropriate, since it makes sense to keep the Factory and the
> base class or interface it creates in the same package.  In contrast, for classes
> provided by Sun Microsystems or third parties, where the source code could not be
> modified, a localized/able subclass of the Sun/third party class would be created
> within the Locale component, typically in a subpackage structure that in some way 
>parallels
> the structure in which the base class resides (in the initial code, this has already
> been done for most of the Java SDK classes).  This would allow other Jakarta
> subprojects and components to locate and include such classes in a consistent manner.
>
> 1.5) Interaction With Other Subpackages and Components
>
> In the initial code, there are a number of classes that abstract various classes 
>provided
> in different versions of the Java SDKs that can be used for configuration parameters 
>(Properties,
> Preferences, and the Preferences SPI).  These classes might be most appropriately 
>placed in the
> Jakarta Commons Util component (with specific implementations in "props" and "prefs" 
>subpackages).
> If this was not acceptable, those classes could be placed under the Locale component.
>
> The proposed component will probably contribute only to other components within the 
>Jakarta
> Commons subproject, primarily the "util" (as mentioned above) and possibly "lang" 
>component.
> On the other hand, it is expected that other components and subpackages will make 
>use of the
> Locale component anywhere they need to provide for internationalization of their 
>objects,
> resulting in much heavier interaction inbound rather than outbound, which should be 
>typical
> of the Commons subpackage in general.
>
>
> 2) Initial Source of the Package
>
> The initial source of the package would be obtained from existing code (after the
> addition of comments to meet Apache requirements), which can be found in a .zip file
> that can be downloaded from http://iToolSet.com/locale/CommonsLocale.zip.  This code
> has been revised somewhat to demonstrate how it might appear in the Apache world, and
> to provide a working example.  The example, which simulates the use of

[Jakarta Commons Locale] PROPOSAL

[Robert Simpson]

Proposal for Commons Locale component

This is a proposal for creating a Locale component in the Jakarta Commons
subproject, superseding and encompassing the "Resources" component
that is currently in the Jakarta Commons sandbox.

An HTML version of this proposal can be found at 
http://iToolSet.com/locale/PROPOSAL.html


0) Rationale

There are many different types of Java(TM)* objects that may be included in
Java applications that support internationalization (i18n).  These include
resources, message strings, formatters, Calendars, Currency objects, TimeZones,
Exceptions, Collators, and BreakIterators, among others.

There currently is a "Resources" component in the Jakarta Commons sandbox.
However, there should be a common architecture for internationalization of any
object, not one that is limited to Resources.  Therefore, a "Locale" component
should be added to the Jakarta Commons proper.  The functions provided by the
"Resources" component currently in the sandbox could be provided in a subpackage
under the package created for the new Locale component.


1) Scope of the Component

The proposal defines a common framework for internationalization of various
Java classes.  This internationalization typically occurs by localizing
instances of Java objects to a specific Locale.  The proposed framework would
facilitate the internationalization of all objects to a single Locale per user,
in either a single-user or multi-user environment.  For example, when localizing
messages, both the message patterns and the inserted arguments should be localized
to the same Locale.  This is a good example of why internationalization should occur
at a higher level than simply the resources that supply the localized message patterns.

Two interfaces, "Localizable" (used by classes that implement both a get and
set method for the Locale) and "Localized" (for classes that implement a get method
only) would be defined.  Other implementers would be encouraged to declare their
classes with one of these interfaces where appropriate.  Where this occurs, any
Factory classes which generate localized/localizable (localized/able) versions of
those objects would be included in that same package, rather than under the Locale
component.  This is appropriate, since it makes sense to keep the Factory and the
base class or interface it creates in the same package.  In contrast, for classes
provided by Sun Microsystems or third parties, where the source code could not be
modified, a localized/able subclass of the Sun/third party class would be created
within the Locale component, typically in a subpackage structure that in some way 
parallels
the structure in which the base class resides (in the initial code, this has already
been done for most of the Java SDK classes).  This would allow other Jakarta
subprojects and components to locate and include such classes in a consistent manner.

1.5) Interaction With Other Subpackages and Components

In the initial code, there are a number of classes that abstract various classes 
provided
in different versions of the Java SDKs that can be used for configuration parameters 
(Properties,
Preferences, and the Preferences SPI).  These classes might be most appropriately 
placed in the
Jakarta Commons Util component (with specific implementations in "props" and "prefs" 
subpackages).
If this was not acceptable, those classes could be placed under the Locale component.

The proposed component will probably contribute only to other components within the 
Jakarta
Commons subproject, primarily the "util" (as mentioned above) and possibly "lang" 
component.
On the other hand, it is expected that other components and subpackages will make use 
of the
Locale component anywhere they need to provide for internationalization of their 
objects,
resulting in much heavier interaction inbound rather than outbound, which should be 
typical
of the Commons subpackage in general.


2) Initial Source of the Package

The initial source of the package would be obtained from existing code (after the
addition of comments to meet Apache requirements), which can be found in a .zip file
that can be downloaded from http://iToolSet.com/locale/CommonsLocale.zip.  This code
has been revised somewhat to demonstrate how it might appear in the Apache world, and
to provide a working example.  The example, which simulates the use of localized 
resources
in a multi-user (ex: servlets) environment with both local client-side (multiple users 
with
distinct locales) and remote server-side (single server with it's own locale) 
destinations,
can be run by executing the "test2.bat" batch file or the "test2.sh" shell script.
(The test is currently set up to run under version 1.4).
The JavaDoc for the initial code can be found 
http://iToolSet.com/locale/docs/index.html";.

Code for new classes, such as for Factory classes that could produce Localized 
instances of objects
for third-party classes could be submitted by other developers, most likel

RE: Action items now or after board meeting?

[Noel J. Bergman]

> If you believe that people would reasonably expect to find
> the license in the jar file, then I would say this complies.

No, I don't.  As I said, there is a copy of the license in the James CVS
root.  The question was whether there needed to be copies co-located
elsewhere in the structure where we have jar files.  I thought the
suggestion that the license could be embedded, hence the question.

Serge has spoken with Brian Wellington, and can take care of any remaining
formalities.  The mm.mysql driver is purely optional, distributed only as a
convenience for end users, called indirectly via JDBC, and replaced by
whichever JDBC driver they want to use depending upon the intended database
server, so I don't know if there is any issue with it, but Danny had been
following up with MySQL.

It will help when the Board ratifies its decisions if there is a document
that we can point to on the site explaining to authors what licenses are
acceptable, and what we need from them to be able to use and/or distribute
their code in either source or binary fashion.

--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Action items now or after board meeting?

[Sam Ruby]

Noel J. Bergman wrote:


We do have the ASL license in our CVS.  What we don't have is a copy of it
in the particular directories that contain the builds of Avalon jars that
we're using.  What is the specific requirement?  And is it really true that
if the license is embedded in the jar file, that suffices?  There is no
requirement for it to be visible without someone having to look in the jar?


The Apache Software License paragraph 2 simply states a list of things 
that must be present in the distribution.  If you believe that people 
would reasonably expect to find the license in the jar file, then I 
would say this complies.  It might be prudent to mention this on the 
James website and/or in some README, as inside the jar is not 
necessarily the first place I would have thought to look.

With respect to dnsjava and mm.mysql, my understanding is that we had indeed
received such alternate licensing.  Perhaps this needs to be made more clear
somewhere.


If they issued a separate license for everyone to use, then I see no 
record of this on their website.  If they issues a separate license for 
the ASF, then I would expect the board to have a copy of this and I 
would be very concerned about what limitations it might place on users 
of ASF software.

-Sam Ruby


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Action items now or after board meeting?

[Noel J. Bergman]

Sam,

We do have the ASL license in our CVS.  What we don't have is a copy of it
in the particular directories that contain the builds of Avalon jars that
we're using.  What is the specific requirement?  And is it really true that
if the license is embedded in the jar file, that suffices?  There is no
requirement for it to be visible without someone having to look in the jar?

With respect to dnsjava and mm.mysql, my understanding is that we had indeed
received such alternate licensing.  Perhaps this needs to be made more clear
somewhere.

--- Noel

-Original Message-
From: Sam Ruby [mailto:[EMAIL PROTECTED]]
Sent: Saturday, February 08, 2003 9:11
To: Noel J. Bergman
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: Action items now or after board meeting?


Noel J. Bergman wrote:
> Sam,
>
> We've been discussing the jar licensing, and want to check: do we have an
> action item TODAY, or do we wait for the board meeting to provide formal
> guidance?

If I am correct in presuming that you are looking over James's assets,
then you have no action item from me at this point.  I'm asking every
Jakarta PMC member to do a review of the assets that they are involved
with for license compliance.

I would like to be able to report that this is complete at the next
board meeting.

> At the moment, I am told that we have permissions for dnsjava and mm.mysql
> from their authors, as well as geo-ip from that author.  The other jars
are
> JavaMail and JAF.

Both Dnsjava and mm.mysql are licensed under GPL or LGPL.  I would
strongly recommend that you get the author to provide an alternate
license.  The author might be delighted to have us redistribute his
code, but people who use ASF software might not be so appreciative of this.

As to JavaMail and JAF, the license is clear: you can distribute only
bundled as part of, and for the sole purpose of running, your Programs.

> Dion Gillard also believes that a copy of the ASF License file needs to be
> in every directory of the CVS within which is located a jar, unless the
jar
> has the ASL embedded in it.

I agree.  I note that cocoon has chosen to put the licenses in a
separate directory.  That works too.  The layout is not the important
thing, but complying with the terms of the license is.

> Please advise.  Thanks.  :-)
>
>   --- Noel
>
> P.S.  Since I know that this subject is bound to annoy people, I want to
get
> Dion out of the firing line; people should know that he and the rest of
the
> Maven team were asked to do the audits.

The Maven team was asked to audit themselves and the resources they
provide to others.

- Sam Ruby


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Development release soon

[Andrew C. Oliver]

Glen Stampoultzis wrote:


We've had a few changes go through lately and I'd like to make a new 
development release soon.

Please vote:
[+1] +1 (Cool - go ahead Glen)

Do it now! :-)


[ ] +0 (Don't care)
[ ] -0 (I'm a bit iffy about this)
[ ] -1 (no way!)

I'm preparation for this build I'd like to request that the committers 
tie up any loose ends and update the change log with anything of 
significance that's gone through since the last build.


All my crapopla is going into the elbrancho at the moment.  Let me make 
sure the DBCELL/INDEX code is in.  If thats in then that is like 
monumental.  You don't know HOW slow a large sheet can load in Excel w/o 
that.  I'll double check.

-Andy

Regards,

Glen Stampoultzis


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]







-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Action items now or after board meeting?

[Sam Ruby]

Noel J. Bergman wrote:

Sam,

We've been discussing the jar licensing, and want to check: do we have an
action item TODAY, or do we wait for the board meeting to provide formal
guidance?


If I am correct in presuming that you are looking over James's assets, 
then you have no action item from me at this point.  I'm asking every 
Jakarta PMC member to do a review of the assets that they are involved 
with for license compliance.

I would like to be able to report that this is complete at the next 
board meeting.

At the moment, I am told that we have permissions for dnsjava and mm.mysql
from their authors, as well as geo-ip from that author.  The other jars are
JavaMail and JAF.


Both Dnsjava and mm.mysql are licensed under GPL or LGPL.  I would 
strongly recommend that you get the author to provide an alternate 
license.  The author might be delighted to have us redistribute his 
code, but people who use ASF software might not be so appreciative of this.

As to JavaMail and JAF, the license is clear: you can distribute only 
bundled as part of, and for the sole purpose of running, your Programs.

Dion Gillard also believes that a copy of the ASF License file needs to be
in every directory of the CVS within which is located a jar, unless the jar
has the ASL embedded in it.


I agree.  I note that cocoon has chosen to put the licenses in a 
separate directory.  That works too.  The layout is not the important 
thing, but complying with the terms of the license is.

Please advise.  Thanks.  :-)

	--- Noel

P.S.  Since I know that this subject is bound to annoy people, I want to get
Dion out of the firing line; people should know that he and the rest of the
Maven team were asked to do the audits.


The Maven team was asked to audit themselves and the resources they 
provide to others.

- Sam Ruby


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]