Bug#893561: libtablelayout-java: license does not seem to meet the DFSG

[tony mancill]

On Sun, Apr 15, 2018 at 11:42:20AM +0200, Francesco Poli wrote:
> On Thu, 29 Mar 2018 00:09:47 +0200 Emmanuel Bourg wrote:
> 
> > Le 28/03/2018 à 23:34, Francesco Poli a écrit :
> > 
> > > In other words, can someone develop a fork of libtablelayout-java (with
> > > the namespace changed to a different one) which works as a drop-in
> > > replacement for the original libtablelayout-java?
> > 
> > If you change the namespace it can't be used as a drop-in replacement.
> > 
> > But since the Debian libtablelayout-java package is already a fork of
> > the upstream TableLayout project using a different namespace (as
> > required by the license for derivative works), there is no need to
> > change again the namespace for anyone modifying the libtablelayout-java
> > package.
> 
> So there's no way to create a modified version of libtablelayout-java
> that can be used as a drop-in replacement for the original upstream
> TableLayout.
> 
> This seems to confirm that the namespace-change clause has functional
> consequences, as I suspected... 

Hello Francesco,

I'm not sure I follow your logic in so far as I don't see any language
either explicit or implicit in the DFSG [1] regarding the need for a
derived work to be a drop-in replacement.  It seems to me that you are
assuming an additional clause to the effect that "the derived work must
function in (all) contexts (including at build-time) exactly as the
original work."  While I think this is desirable goal, as it creates the
absolute minimum of hassle for users of the derived work, I don't see it
as a strict requirement.  

Note that I choose the word "function" because you refer to "functional
consequences."  In the specific case of libtablelayout-java, we're not
even talking about a functional difference - i.e., the library performs
the same function - there is only a difference in naming that affects
the software at build-time.  In my mind, a "functional consequence"
would be something like "derived works cannot include method ${foo} that
implements feature ${bar}."

Finally, it is common practice for Java libraries have their namespaces
changed in the course of day-to-day work within the Java ecosystem.  For
example, during the creation of shadow JARs, to allow multiple versions
of a library to co-exist in the same project, etc...  Doing so to
respect the wishes of the upstream author seems perfectly natural to me.

All that said, it would be simpler for everyone if the upstream author
is willing to relicense the software.  Good luck in your attempt to
contact the author. (I was not able to find a suitable contact address
in my search so far.)

Cheers,
tony

[1] https://www.debian.org/social_contract.html#guidelines
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-java-maintainers/attachments/20180415/4cb8e750/attachment.sig>