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 >>> [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... Oh gosh, how many people live on this planet? Everyone has a different opinion about certain topics but in the end we have to make a decision. The decision was in favor of this license. > [...] >>> 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! You are completely wrong if you think it is the responsibility of volunteers to address any _possible_ license violation in any country in the world. If you think a certain library is incompatible with a certain program, then you really, really should talk to the developer of said program first! Discuss with them if this is a real issue for them and if they agree we can package a new upstream release at any time (with the appropriate severity). > [...] >> Feel free to contact all >> upstreams yourself though and discuss any licensing issues with them. > > I may try to contact the upstream developers myself, but on isolated > voice is much less likely to be listened to than the Debian package > maintainers with the backing of the Debian Project... Talk to upstream. Debian is not responsible for that.
signature.asc
Description: OpenPGP digital signature
