Re: Clarifying some licensing issues for Apache developers

[Brian Behlendorf]

On Thu, 11 Mar 2004, J Aaron Farr wrote:
> However, mx4j is a good example because apparently it includes code licensed
> under the Jetty and Jython licenses [2].  While I am not intimately familiar
> with mx4j, this may mean that the total legal effect of using mx4j is not
> contained within the mx4j license alone, but is in fact a combination of the
> terms of the three licenses.  Since this combination may in fact be more
> restrictive than the terms in the mx4j license alone, the library may not be 
> in
> the clear to be used by ASF projects.  To confirm this, one would need to
> investigate all three licenses, understand which parts of mx4j fall outside of
> its own license, and then come to a decision on how the library can be used in
> the ASF.
>
> It is exactly this sort of confusion the ASF would like to avoid.

Thank you, jaaron, for articulating this.  Indeed, this is what we'd like
to avoid - confusion and surprises for ourselves, as well as confusion and
surprises for those who use and redistribute Apache software.

Brian


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

Re: Clarifying some licensing issues for Apache developers

[J Aaron Farr]

Quoting Henri Gomez <[EMAIL PROTECTED]>:
> 
> Should I understand that we could no more include third-party jars in
> ASF products, for example mx4j jars in Tomcat ?

This is not a complete prohibition on all third-party jars or libraries, but
only on those third-party libraries which are licensed under terms more
restrictive than the ASL.

In the case of mx4j, the code is licenced under the mx4j 1.0 License [1], which
is a derivative of the ASL 1.1 license and therefore may potentially be included
in ASF works.

However, mx4j is a good example because apparently it includes code licensed
under the Jetty and Jython licenses [2].  While I am not intimately familiar
with mx4j, this may mean that the total legal effect of using mx4j is not
contained within the mx4j license alone, but is in fact a combination of the
terms of the three licenses.  Since this combination may in fact be more
restrictive than the terms in the mx4j license alone, the library may not be in
the clear to be used by ASF projects.  To confirm this, one would need to
investigate all three licenses, understand which parts of mx4j fall outside of
its own license, and then come to a decision on how the library can be used in
the ASF.

It is exactly this sort of confusion the ASF would like to avoid.  While the
mx4j developers may in fact be perfectly in compliance with using the Jetty and
Jython licenses, users of mx4j will have to take into consideration not one, but
_three_ licenses in order to determine how to legally use the library. 
Therefore,  for the sake of our users it is best if an ASF product as a whole is
licensed under terms no more restrictive than those set out in the ASL 2.0.

For further inquries (including a specific resolution to the mx4j issue), I
would suggest subscribing to the [EMAIL PROTECTED] list.

---
  jaaron  

[1]
http://cvs.sourceforge.net/viewcvs.py/*checkout*/mx4j/mx4j/src/etc/LICENSE?content-type=text%2Fplain&rev=1.3
[2] http://cvs.sourceforge.net/viewcvs.py/mx4j/mx4j/src/etc/

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

Re: Clarifying some licensing issues for Apache developers

[Henri Gomez]

Brian Behlendorf wrote:
> It seems worthwhile to state something that probably most people are 
aware
> of, but a few recent incidents suggest is worth repeating.  Followups are
> being directed to [EMAIL PROTECTED], a list that is private to Apache
> committers, where legal issues are discussed.  Please subscribe to that
> list (requires approval) before posting to it.
>
> First off, thank you to everyone who has transitioned to the new Apache
> License 2.0.  It is a board mandate that *all* software distributed 
by the
> Apache Software Foundation be under this new license.  This has some
> subtle and not-so-subtle ramifications people should be aware of.
>
> *) Only software packages created by the Apache Software Foundation 
may be
> redistributed from Apache's servers and mirrors.  This means no tarballs
> or binaries from other authors or organizations.  We realize that 
many ASF
> projects depend upon other software, and that these dependencies may make
> it difficult for new users to bootstrap quickly.  There are solutions to
> that problem outside of the ASF: ibiblio, sourceforge, CPAN, etc.  The
> board might grant exceptions to this rule - bring it to us if you'd like
> us to consider it.

Should I understand that we could no more include third-party jars in
ASF products, for example mx4j jars in Tomcat ?
If it's the case this decision will put many, many users in big trouble
since they couldn't use anymore ready-to-run package (zip or tarball
containing everything needed for run).
As one of the founder of the JPackage Projet, www.jpackage.org, which
try to maintain a repository of java applications and libs, let me say
that the task is not so easy, and for now works only on RPM based boxes,
mostly Linux.
What should do non-RPM users ?
I could understand the board concern about incompatible license, but
when developpers select third-party software to make ASF products,
they take care of it isn't it ?
So I strongly suggest board to reconsider this point or we may see in
a near future ASF products distribution, containing both ASF and
required third party software, outside Apache servers and it will
not help users to find their way.
Am I exact in thinking that the original ASF goal is to provide real
products for real users, and that we should take care of users as much
as we take care of performance, stability ?
Regards


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