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

2018-03-28 Thread Markus Koschany 
Am 28.03.2018 um 23:34 schrieb Francesco Poli:
> On Sat, 24 Mar 2018 15:22:12 +0100 Markus Koschany wrote:
> 
>> Am 24.03.2018 um 00:17 schrieb Francesco Poli:
> [...]
>>> Was the debian-legal discussion pointed out to the FTP Masters?
>>> Did they explain the rationale behind their decision? 
>>
>> FYI, debian-legal is a mailing list and not a Debian body that can exert
>> any power over the FTP masters.
> 
> I am well aware of this, as I have participated in debian-legal
> discussions for more than 13 years.

I intend to make this my last reply to Debian bug #893561. However if my
following answer does not satisfy you, there is the last resort of
asking Debian's technical committee (CTTE) for a definite ruling.


> debian-legal is more like a sort of advisory board, where licensing
> issues are discussed and analyzed. The FTP Masters are not bound to
> follow the advice, of course.
> But, whenever an issue was actually discussed on debian-legal, it is
> useful for the FTP Masters to be informed about the discussion, so that
> they can see what was said and pointed out, before making their
> decision.
> Otherwise, what's the point in having a discussion on debian-legal, if
> the FTP Masters are left unaware of it and must analyze the license
> from scratch?

I know your involvement in debian-legal from previous discussions. Like
I said before debian-legal is a mailing list and not an authoritative
body of Debian. Of course everyone is entitled to his/her own opinion
but nevertheless in the end only the FTP masters decide whether a
license is compatible to Debian's Free Software Guidelines. It is at
least questionable why you act now, _nine_ years later.

>> They may or may not have been aware of
>> the discussion but by accepting libtablelayout-java into Debian they
>> clearly made a decision in favor of the license.
> The FTP Masters are humans and may make mistakes, like all of us.
> They could have overlooked some troublesome clause in the license, if
> not informed about the potential issue...

Please note that this package was introduced to Debian by Torsten Werner
who was once a FTP master himself. I know that Torsten was highly
critical of some game licenses that were accepted into Debian and I'm
pretty sure he didn't introduce libtablelayout-java purely on a whim.

> [...]
>>> The issue is not the requirement to modify the package through patch
>>> files. Patch-only clauses are explicitly allowed by DFSG#4, as you
>>> correctly point out.
>>> As I have previously said, the issue is that the license forbids to
>>> create a derived work that uses the info.clearthought namespace/package.
>>>
>>> This goes beyond what is allowed by DFSG#4, which only talks about
>>> patch files and requirements to change the *name* or the *version
>>> number*.
>>
>> No, this is precisely why DFSG 4 mentions patch files explicitly and why
>> DFSG 4 is named "Integrity of The Author's Source Code".
> 
> Once again, patch files are not the freeness issue I am talking about.
> The troublesome clause is the namespace-change restriction.

As I pointed out before the namespace-change is not an issue for Debian.
We are acting according to the license and there is certainly no need to
revert to the original namespace once you have created a derived work?

>> We respect the
>> authors source code and his wish to preserve the info.clearthough
>> namespace. Nevertheless we are allowed to change it for derived works
>> and can rename it to any name we want. This is sufficiently DFSG-free.
>> The name is "info.clearthought" which is the official upstream URL. It
>> is common practice in Java to use a namespace that corresponds to some
>> URL. It is completely fair to reserve info.clearthought because Debian
>> also reserves the rights for debian.org or the name Debian in general.
> 
> Please let me understand, as I am not too familiar with Java.
> Isn't the namespace concept in Java similar to the corresponding
> concept in C++?
> 
> Suppose someone has several Java programs that link with
> libtablelayout-java and use classes from the info.clearthought
> namespace.
> Suppose he/she wants to use a modified version of libtablelayout-java
> (maybe with some bugs fixed, or something like that) where the
> namespace has been changed to a different one.
> Can he/she use the programs with the modified libtablelayout-java,
> without having to modify each one of them?
> 
> 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?

We have already created a derived work of libtablelayout-java. We don't
need to change the namespace ever again. This is similar to license
clauses that say: If you make changes to this program, don't claim it is
the original program, mark them as separate changes. We have accepted
such licenses into Debian and it makes a lot of sense to do so.

> [...]
>>> The thread is the very

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

2018-03-28 Thread Francesco Poli 
On Sat, 24 Mar 2018 15:22:12 +0100 Markus Koschany wrote:

> Am 24.03.2018 um 00:17 schrieb Francesco Poli:
[...]
> > Was the debian-legal discussion pointed out to the FTP Masters?
> > Did they explain the rationale behind their decision? 
> 
> FYI, debian-legal is a mailing list and not a Debian body that can exert
> any power over the FTP masters.

I am well aware of this, as I have participated in debian-legal
discussions for more than 13 years.

debian-legal is more like a sort of advisory board, where licensing
issues are discussed and analyzed. The FTP Masters are not bound to
follow the advice, of course.
But, whenever an issue was actually discussed on debian-legal, it is
useful for the FTP Masters to be informed about the discussion, so that
they can see what was said and pointed out, before making their
decision.
Otherwise, what's the point in having a discussion on debian-legal, if
the FTP Masters are left unaware of it and must analyze the license
from scratch?

> They may or may not have been aware of
> the discussion but by accepting libtablelayout-java into Debian they
> clearly made a decision in favor of the license.

The FTP Masters are humans and may make mistakes, like all of us.
They could have overlooked some troublesome clause in the license, if
not informed about the potential issue...

[...]
> > The issue is not the requirement to modify the package through patch
> > files. Patch-only clauses are explicitly allowed by DFSG#4, as you
> > correctly point out.
> > As I have previously said, the issue is that the license forbids to
> > create a derived work that uses the info.clearthought namespace/package.
> > 
> > This goes beyond what is allowed by DFSG#4, which only talks about
> > patch files and requirements to change the *name* or the *version
> > number*.
> 
> No, this is precisely why DFSG 4 mentions patch files explicitly and why
> DFSG 4 is named "Integrity of The Author's Source Code".

Once again, patch files are not the freeness issue I am talking about.
The troublesome clause is the namespace-change restriction.

> We respect the
> authors source code and his wish to preserve the info.clearthough
> namespace. Nevertheless we are allowed to change it for derived works
> and can rename it to any name we want. This is sufficiently DFSG-free.
> The name is "info.clearthought" which is the official upstream URL. It
> is common practice in Java to use a namespace that corresponds to some
> URL. It is completely fair to reserve info.clearthought because Debian
> also reserves the rights for debian.org or the name Debian in general.

Please let me understand, as I am not too familiar with Java.
Isn't the namespace concept in Java similar to the corresponding
concept in C++?

Suppose someone has several Java programs that link with
libtablelayout-java and use classes from the info.clearthought
namespace.
Suppose he/she wants to use a modified version of libtablelayout-java
(maybe with some bugs fixed, or something like that) where the
namespace has been changed to a different one.
Can he/she use the programs with the modified libtablelayout-java,
without having to modify each one of them?

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?

[...]
> > The thread is the very
> > [one](https://lists.debian.org/debian-legal/2009/06/msg00050.html)
> > I cited in my bug report.
> > 
> > There were two replies, one by Joe Smith and one by me.
> > Joe said that the license is acceptable and within the spirit of the
> > DFSG.
> > On the other hand, I said that two clauses fail to meet the DFSG.
> > 
> > Now, I respect Joe's opinion, but it's not clear to me why you claim
> > that *his* reply represents the outcome of the debian-legal discussion,
> > while *my* reply is just my personal opinion...
> 
> I have never said that and it is also not relevant.

Well, you said:

"This is your personal opinion. It was already discussed on debian-legal
back in 2009 that the license is still acceptable and in the spirit of
the DFSG."

as if the only reply on debian-legal had been the one from Joe...

[...]
> > The license of libtablelayout-java is *clearly* GPL-incompatible, no
> > doubt about it.
> > 
> > It is a patch-only license and has restrictions on namespace change for
> > derived works.
> > These restrictions (and possibly other ones) are not included in the
> > GNU GPL v2 or v3, nor allowed by them.
> 
> Again, this is _your_ opinion. If it was that easy we wouldn't need any
> lawyers in the world.

Sorry, but that is not just _my_ opinion.
It's a well known fact: patch-only licenses are GPL-incompatible.
Anyone who knows enough about the GNU GPL will tell you so.

We may need lawyers for difficult licensing issues, but not for every
single step during software development!

[...]
> Feel free to contact all
> upstreams yourself though and discuss any

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

2018-03-24 Thread Markus Koschany 
Am 24.03.2018 um 00:17 schrieb Francesco Poli:
> On Thu, 22 Mar 2018 18:30:53 +0100 Markus Koschany wrote:
> 
>> Am 19.03.2018 um 22:28 schrieb Francesco Poli (wintermute):
> [...]
>>> I noticed that the license was
>>> [discussed](https://lists.debian.org/debian-legal/2009/06/msg00050.html)
>>> on debian-legal a long time ago.
>>> My
>>> [opinion](https://lists.debian.org/debian-legal/2009/06/msg00053.html)
>>> was that at least two clauses fail to meet the DFSG.
>>
>> In the end the ftp-team accepted the package into Debian and that is the
>> only thing that counts.
> 
> Was the debian-legal discussion pointed out to the FTP Masters?
> Did they explain the rationale behind their decision? 

FYI, debian-legal is a mailing list and not a Debian body that can exert
any power over the FTP masters. They may or may not have been aware of
the discussion but by accepting libtablelayout-java into Debian they
clearly made a decision in favor of the license.

>>> The debian/copyright file states, in part:
>>>
>>> | The source code has been modified to make the package suitable for main 
>>> (see
>>> | license III. 4.). The package namespace has been changed from
>>> | info.clearthought.layout to org.debian.tablelayout.
>>>
>>> Personally, I don't think that applying a patch that changes the namespace
>>> is enough to make the package suitable for Debian main.
>>
>> This is certainly enough. We change the namespace all the time in Debian
>> Java packages by using maven.rules for example. Also using patch files
>> is explicitly allowed by DFSG 4.
> 
> The issue is not the requirement to modify the package through patch
> files. Patch-only clauses are explicitly allowed by DFSG#4, as you
> correctly point out.
> As I have previously said, the issue is that the license forbids to
> create a derived work that uses the info.clearthought namespace/package.
> 
> This goes beyond what is allowed by DFSG#4, which only talks about
> patch files and requirements to change the *name* or the *version
> number*.

No, this is precisely why DFSG 4 mentions patch files explicitly and why
DFSG 4 is named "Integrity of The Author's Source Code". We respect the
authors source code and his wish to preserve the info.clearthough
namespace. Nevertheless we are allowed to change it for derived works
and can rename it to any name we want. This is sufficiently DFSG-free.
The name is "info.clearthought" which is the official upstream URL. It
is common practice in Java to use a namespace that corresponds to some
URL. It is completely fair to reserve info.clearthought because Debian
also reserves the rights for debian.org or the name Debian in general.

> 
>>
>>> I mean: it's true that it is now possible to create drop-in replacements
>>> for the Debian package (without further changing the namespace), but it is
>>> still forbidden to create a modified version that changes the namespace
>>> back to "info.clearthought".
>>>
>>> I think that this restriction goes beyond what is allowed by DFSG#4.
>>
>> This is your personal opinion. It was already discussed on debian-legal
>> back in 2009 that the license is still acceptable and in the spirit of
>> the DFSG.
> 
> Wait, it was indeed discussed on debian-legal back in 2009.
> 
> The thread is the very
> [one](https://lists.debian.org/debian-legal/2009/06/msg00050.html)
> I cited in my bug report.
> 
> There were two replies, one by Joe Smith and one by me.
> Joe said that the license is acceptable and within the spirit of the
> DFSG.
> On the other hand, I said that two clauses fail to meet the DFSG.
> 
> Now, I respect Joe's opinion, but it's not clear to me why you claim
> that *his* reply represents the outcome of the debian-legal discussion,
> while *my* reply is just my personal opinion...

I have never said that and it is also not relevant.

>>> Additionally, the license is clearly GPL-incompatible, which may
>>> be an issue for other packages that link with this library.
>>>
>>> Is it possible to persuade the upstream copyright holder to
>>> drop clauses III.3 and III.4?
>>> Or, even better, to re-license the library under well-vetted and
>>> clearly DFSG-free terms, such as the
>>> [Expat/MIT license](http://www.jclark.com/xml/copying.txt)
>>> or the
>>> [zlib license](http://www.zlib.net/zlib_license.html)
>>> ?
>>
>> No. We do not need to persuade the upstream copyright holder to change
>> the license as long as the package was accepted by the ftp-team. If you
>> think a package is GPL-incompatible
> 
> The license of libtablelayout-java is *clearly* GPL-incompatible, no
> doubt about it.
> 
> It is a patch-only license and has restrictions on namespace change for
> derived works.
> These restrictions (and possibly other ones) are not included in the
> GNU GPL v2 or v3, nor allowed by them.

Again, this is _your_ opinion. If it was that easy we wouldn't need any
lawyers in the world.

>> and you are not sure whether you can
>> use it together with this library you should seek legal advice

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

2018-03-23 Thread Francesco Poli 
On Thu, 22 Mar 2018 18:30:53 +0100 Markus Koschany wrote:

> Am 19.03.2018 um 22:28 schrieb Francesco Poli (wintermute):
[...]
> > I noticed that the license was
> > [discussed](https://lists.debian.org/debian-legal/2009/06/msg00050.html)
> > on debian-legal a long time ago.
> > My
> > [opinion](https://lists.debian.org/debian-legal/2009/06/msg00053.html)
> > was that at least two clauses fail to meet the DFSG.
> 
> In the end the ftp-team accepted the package into Debian and that is the
> only thing that counts.

Was the debian-legal discussion pointed out to the FTP Masters?
Did they explain the rationale behind their decision? 

> 
> > 
> > The debian/copyright file states, in part:
> > 
> > | The source code has been modified to make the package suitable for main 
> > (see
> > | license III. 4.). The package namespace has been changed from
> > | info.clearthought.layout to org.debian.tablelayout.
> > 
> > Personally, I don't think that applying a patch that changes the namespace
> > is enough to make the package suitable for Debian main.
> 
> This is certainly enough. We change the namespace all the time in Debian
> Java packages by using maven.rules for example. Also using patch files
> is explicitly allowed by DFSG 4.

The issue is not the requirement to modify the package through patch
files. Patch-only clauses are explicitly allowed by DFSG#4, as you
correctly point out.
As I have previously said, the issue is that the license forbids to
create a derived work that uses the info.clearthought namespace/package.

This goes beyond what is allowed by DFSG#4, which only talks about
patch files and requirements to change the *name* or the *version
number*.

> 
> > I mean: it's true that it is now possible to create drop-in replacements
> > for the Debian package (without further changing the namespace), but it is
> > still forbidden to create a modified version that changes the namespace
> > back to "info.clearthought".
> > 
> > I think that this restriction goes beyond what is allowed by DFSG#4.
> 
> This is your personal opinion. It was already discussed on debian-legal
> back in 2009 that the license is still acceptable and in the spirit of
> the DFSG.

Wait, it was indeed discussed on debian-legal back in 2009.

The thread is the very
[one](https://lists.debian.org/debian-legal/2009/06/msg00050.html)
I cited in my bug report.

There were two replies, one by Joe Smith and one by me.
Joe said that the license is acceptable and within the spirit of the
DFSG.
On the other hand, I said that two clauses fail to meet the DFSG.

Now, I respect Joe's opinion, but it's not clear to me why you claim
that *his* reply represents the outcome of the debian-legal discussion,
while *my* reply is just my personal opinion...

> 
> > Additionally, the license is clearly GPL-incompatible, which may
> > be an issue for other packages that link with this library.
> > 
> > Is it possible to persuade the upstream copyright holder to
> > drop clauses III.3 and III.4?
> > Or, even better, to re-license the library under well-vetted and
> > clearly DFSG-free terms, such as the
> > [Expat/MIT license](http://www.jclark.com/xml/copying.txt)
> > or the
> > [zlib license](http://www.zlib.net/zlib_license.html)
> > ?
> 
> No. We do not need to persuade the upstream copyright holder to change
> the license as long as the package was accepted by the ftp-team. If you
> think a package is GPL-incompatible

The license of libtablelayout-java is *clearly* GPL-incompatible, no
doubt about it.

It is a patch-only license and has restrictions on namespace change for
derived works.
These restrictions (and possibly other ones) are not included in the
GNU GPL v2 or v3, nor allowed by them.

> and you are not sure whether you can
> use it together with this library you should seek legal advice in your
> country. This is out-of-scope for Debian and as far as I am and the rest
> of the team are concerned, this is not an issue for us. Closing as
> not-a-bug.

It seems to be an issue for Debian: there are packages in Debian which
are GPL-licensed and link (directly or indirectly) with
libtablelayout-java.

Linking a GPL-licensed program or library with a GPL-incompatible
library requires special permission from the copyright holders of the
GPL-licensed program or library, as explain in the dedicated GPL
[FAQ](https://www.gnu.org/licenses/gpl-faq.html#InterpreterIncompat).

Some examples of GPL-licensed packages which link with
libtablelayout-java:

 • [jfractionlab](https://packages.debian.org/jfractionlab)
   [is 
GPL-v3-licensed](https://tracker.debian.org/media/packages/j/jfractionlab/copyright-0.91-3)
   without any special exception and is linked with libtablelayout-java

 • [sweethome3d](https://packages.debian.org/sweethome3d)
   [is 
GPL-v2-licensed](https://tracker.debian.org/media/packages/s/sweethome3d/copyright-5.7dfsg-2)
   without any special exception and is linked with libtablelayout-java
   (indirectly through

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

2018-03-20 Thread Francesco Poli 
On Tue, 20 Mar 2018 00:41:04 +0200 Adrian Bunk wrote:

[...]
> In https://lists.debian.org/debian-legal/2005/01/msg00142.html you 
> agreed entirely that it is OK when software is made DFSG-free through
> renaming to avoid trademark violations.
> 
> What difference would it make whether our users are forbidden to change
> the namespace back to "info.clearthought" due to
> 1. trademark
> 2. licence
> 3. both

Hello Adrian,
thanks for your prompt followup!

I see an important difference between the case at hand and the Mozilla
case.

One thing is the requirement to change the *name* for the work: this is
just how the work presents itself to the user, not something that
really affects functionality/interoperability/interfaces/...
Even if the name of the executable file of a program is changed, there
are many ways to easily let the user invoke it by another name
(symlinks, wrapper scripts, aliases, and so forth...).

I think the requirement to change *namespace* for library classes
is different: it affects the possibility to create modified drop-in
replacements for the library, without having to adapt all the
programs or other libraries that use the original library.
The namespace looks like a functional aspect.

I think it's not by chance that DFSG#4 accepts the requirements to
change the *name* or the *version number*, but not the requirements
to change other, more functional, labels in a package...


I hope this clarifies.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpuF0F0CFi85.pgp
Description: PGP signature
__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

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

2018-03-19 Thread Adrian Bunk 
On Mon, Mar 19, 2018 at 10:28:13PM +0100, Francesco Poli (wintermute) wrote:
>...
> The debian/copyright file states, in part:
> 
> | The source code has been modified to make the package suitable for main (see
> | license III. 4.). The package namespace has been changed from
> | info.clearthought.layout to org.debian.tablelayout.
> 
> Personally, I don't think that applying a patch that changes the namespace
> is enough to make the package suitable for Debian main.
> I mean: it's true that it is now possible to create drop-in replacements
> for the Debian package (without further changing the namespace), but it is
> still forbidden to create a modified version that changes the namespace
> back to "info.clearthought".
> 
> I think that this restriction goes beyond what is allowed by DFSG#4.
>...

In https://lists.debian.org/debian-legal/2005/01/msg00142.html you 
agreed entirely that it is OK when software is made DFSG-free through
renaming to avoid trademark violations.

What difference would it make whether our users are forbidden to change
the namespace back to "info.clearthought" due to
1. trademark
2. licence
3. both

The precedent of Firefox and Thunderbird in Debian followed your advice 
that it is OK for 1., and I don't see anything in the DFSG that would 
imply that it would matter whether it is 1. or 2. or 3. that prevents 
our users from changing the namespace back to "info.clearthought".

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

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

2018-03-19 Thread Francesco Poli (wintermute) 
Package: libtablelayout-java
Version: 20090826-3
Severity: serious
Justification: Policy 2.2.1

Hello!
Thanks for maintaining this package in Debian.

I noticed that the license was
[discussed](https://lists.debian.org/debian-legal/2009/06/msg00050.html)
on debian-legal a long time ago.
My
[opinion](https://lists.debian.org/debian-legal/2009/06/msg00053.html)
was that at least two clauses fail to meet the DFSG.

The debian/copyright file states, in part:

| The source code has been modified to make the package suitable for main (see
| license III. 4.). The package namespace has been changed from
| info.clearthought.layout to org.debian.tablelayout.

Personally, I don't think that applying a patch that changes the namespace
is enough to make the package suitable for Debian main.
I mean: it's true that it is now possible to create drop-in replacements
for the Debian package (without further changing the namespace), but it is
still forbidden to create a modified version that changes the namespace
back to "info.clearthought".

I think that this restriction goes beyond what is allowed by DFSG#4.

Additionally, the license is clearly GPL-incompatible, which may
be an issue for other packages that link with this library.


Is it possible to persuade the upstream copyright holder to
drop clauses III.3 and III.4?
Or, even better, to re-license the library under well-vetted and
clearly DFSG-free terms, such as the
[Expat/MIT license](http://www.jclark.com/xml/copying.txt)
or the
[zlib license](http://www.zlib.net/zlib_license.html)
?

I hope this can be done.
Thanks for your time and helpfulness!

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.