www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stian Soiland-Reyes <st...@apache.org>
Subject Re: Non OSI approved licenses
Date Sun, 30 Apr 2017 00:58:43 GMT
Btw, I have supported a slight GitHub revival of jai-imageio-core at
https://github.com/jai-imageio/jai-imageio-core

(I split out jpeg2000 support which has dubious patent terms in its license)

It still has the bsd3 license with the nuclear disclaimer:

https://github.com/jai-imageio/jai-imageio-core/blob/master/LICENSE.txt#L37
>
You acknowledge that this software is not designed or intended for
use in the design, construction, operation or maintenance of any
nuclear facility.
It is more of an informational than license term, and I don't think this is
OSI approved, yet I can see ASF being able to accept it as a license (it
does not *prevent* you from using it in a nuclear facility) - and we should
be able to do such discretion ourselves, just like any commercial company
would use such discretion.

But I agree such discretion should be at a minimum, e.g. support historic
licenses rather than accomodate new ImSpecial!! "Open source" Licenses.


Note: seeing what the Pull Requests I have received for jai-imageio-core
had to fix - please don't use it in a nuclear facility.


On 28 Apr 2017 5:41 pm, "Martin Desruisseaux" <
martin.desruisseaux@geomatys.com> wrote:

I have missed the context, but if it was LEGAL-304 for BSD3 with the
nuclear clause, this demand seems to be introduced by TIKA-2338 [1] for
using jai-imageio-core. Given that this package is not maintained anymore
for more than 7 years (this was a library written by Sun Microsystems
before its acquisition by Oracle) and has bugs that remain unfixed, rather
than compromising ASF reputation on licensing for accommodating this
particular library, I can volunteer for checking with TIKA-2338 submitter
if we can find an alternative.

If we have no replacement for TIKA-2338 (or other) needs, what about the
same approach than LEGAL-183 [2]?

   - Put the dependency in an optional module.
   - Create a "non-free" repository by-side of project trunk (SVN) or
   master (GIT) which contains all modules having such non OSI-approved
   dependency.
   - Project releases on http://www.apache.org/dyn/closer.cgi/... do not
   contains the "non-free" modules.
   - However Maven Central repository contains contains those modules, but
   under a "non-free" group ID for making clear the licensing issue.
   Dependency looks like:

<dependency>
  <groupId>org.apache.XXX.non-free</groupId>
  <artifactId>YYY</artifactId>
  <version>1.0</version></dependency>

Martin

[1] https://issues.apache.org/jira/browse/TIKA-2338
[2] https://issues.apache.org/jira/browse/LEGAL-183

Mime
View raw message