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.
FYI, Gumpy (the python version of gump) is currently checking for the existance of the license file in all packages.
It would be possible and rather simple to add a list of identifiers for the various licenses (maybe using the OSI urls as URIs?) to the project metadata descriptors in the gump repository and then write a rule engine that identifies potential legal issues with the combination of those identifiers.
This would allow, for example, the licensing committee to explore policy changes and outline the legal impact of those changes to the various legal dependencies in our tree.
It is also possible to *validate* those legal assertions by matching the license file, therefore understand if a particular project is changing his license overtime (gump deals with CVS directly!) which would trigger not only an alarm of potential future issues for code dependencies but also for legal dependencies.
Food for thought.
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
