Debian GNU/Linux packaging

Hi @AsamK,

I would like to package libsignal-service-java for Debian GNU/Linux. My primary motivation is because it is a dependency of signal-cli.

A few simple things would greatly help moving forward:

• I assume the license is GPLv3 because https://github.com/Turasa/libsignal-service-java/blob/master/LICENSE contains it. The README however claims it is AGPLv3 and this inconsistency was reported in 2017 upstream but not addressed. It is not a blocking problem: without more information the terms of the license prevail. I wonder if maybe you can shed some light on this specific issue ?

• The latest sources are packaged and downloadable from maven.com. It would be nice to have confirmation these are indeed the best source to download such sources. It looks like releases were made available via GitHub in the past but this is no longer the preferred way to publish them.

Thanks in advance for your help and even more for your persistent work to maintain this library !

[paride]

@dachary Just for your information. I don't know if you intend to package signal-cli or perhaps Signal-Desktop, but keep in mind that @moxie0 opposed the third party distribution of software using the official Signal service and using the OWS/Signal trademarks. This is basically the reason why there is no Signal client on F-Droid.

@parid oh, thanks for the information ! Do you have a reference to a public statement about this trademark enforcement ?

For the record, here are the commits unique to Turasa (i.e. not in the upstream) : signalapp/libsignal-service-java@master...Turasa:master

[paride]

A couple of pointers:

https://cloud.githubusercontent.com/assets/1433926/9705240/83886c9c-54be-11e5-867a-458f24bf9b6a.png

LibreSignal/LibreSignal#37 (comment)

but you'll find very long discussions about the issue here on GitHub. Dig into the closed issues.

@paride thanks, much appreciated 💯 Reading more.

Is there a text version of https://cloud.githubusercontent.com/assets/1433926/9705240/83886c9c-54be-11e5-867a-458f24bf9b6a.png somewhere ? I'd like to quote it and assert the publication date.

So far my understanding is that:

a) moxie threatened in 2016 to enforce the "signal" trademark against some forks but did not actually do it. His motivation was to prevent forks connecting to the servers operated by Open Whisper Signal.
b) there has been no threat since nor any legal action against the numerous forks of the Open Whisper Signal code that are distributed world wide and carry the name "signal"

How far am I from reality ? Thanks for your patience: I'm eager to learn but very new to this old controversy ;-)

For the record, the "intent to package" post in Debian GNU/Linux is at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890915 and some discussion about licenses and trademarks is also likely to happen there.

[paride]

I don't know if you can still get a text version, try digging in moxie's or @xmikos' Twitter accounts. I'm not familiar with Twitter.

I recall, at some point, moxie threatening legal action and xmikos consequently renaming his forked client. But I could be wrong.

What I suggest you is: try to get a statement from moxie. Is him happy with Debian distributing unofficial clients for his service? After all, this is what the Maintainer's Guide suggests:

You should contact the program's author(s) to check if they agree with packaging it and are amicable to Debian. It is important to be able to consult with the author(s) in case of any problems with the program, so don't try to package unmaintained software.

What I suggest you is: try to get a statement from moxie.

This is a wise advice, I'll do that now !

Dear Turasa/libsignal-service-java maintainer(s),

I intend to package libsignal-service-java for Debian GNU/Linux and it would be great if you could let me know how you feel about it. Quoting the maintainer guide:

You should contact the program's author(s) to check if they agree with packaging it and are amicable to Debian. It is important to be able to consult with the author(s) in case of any problems with the program, so don't try to package unmaintained software.

Note that I already asked the maintainer of the signalapp/libsignal-service-java repository the same question. They thanked me for the initiative but were not interested in having that kind of conversation, reason why I'm asking you. You distribute a well maintained fork and have done so consistently over the a long period, you are a good upstream from a packaging point of view. I do not expect to have many questions or request, don't worry :-)

Please kindly let me know what you think and thanks for a great service to the Free Software community

[Trolldemorted]

What are the benefits of distributing it as a debian package?

What are the benefits of distributing it as a debian package?

@Trolldemorted given your nick I feel obliged to ask, is this a troll question ? ;-)

[Trolldemorted]

No, this really is a genuine question.

I understand that compiled shared objects should be placed in the loader's path so that you can save disk and memory space, but does that apply to jars as well?

@Trolldemorted the benefit of distributing this library as a package is that it allows developers to rely on it when developing applications or other libraries. If a package is not available, the developer who wants to use libsignal-service-java needs to rely on other distributions channels to get it. It is the same rationale that drives people to package https://packages.debian.org/stretch/libbcprov-java for instance.

GNU/Linux distributions such as Debian or Ubuntu rely on a form of packaging that is different from gradle (for instance) or pip (for python). It is required when building a Debian package that it does not pull resources from the network, other than the official repositories. That ensures the distribution is self contained and is a stable and controlled environment, with security patches.

Another benefit is that some distributions such as Tails https://tails.boum.org/ welcome packages that are already available in Debian GNU/Linux. It would be much more difficult to propose new software if it was not packaged for Debian GNU/Linux.

Does that answer your question ?

[Trolldemorted]

Thanks for the elaborate response! I am not sure I understand you completely though, but I am far from what you would call an expert on linux' many package managers.

I don't think you can compare libsignal and libbcprov. If I understand libbcprov's rationale correctly, it modifies the installed java runtime environment (so for all processes on your system) to insert its own security provider.

Would you do the same with libsignal, and with all of libsignal's dependencies?
If yes,

• did you ask libsignal's dependencies' authors?
• are you sure you will not break other programs? What happens if a program depends on a different version of libsignal's dependencies, but the jre already contains libsignal's preferred version? Shared objects have sonames, has java anything similar? I thought java intends that each programm has its own classpath where it can maintain its own dependencies, and only the (backwards-compatible) standard library is supplied by the jre

If no,

• what will happen? Will the jars be deployed at a fixed location, and programs will have to adjust their java classpath accordingly?

Will you release a deb package for every libsignal version, and deb packages for every version of every dependency of libsignal, and maintain all of them with security patches and bugfixes?

I hope you don't mind my nagging, but I have seen debian packages being completely broken for months, so I may have a tainted and overly pessimistic view on the ecosystem. But apart from debian otherwise declining signal-cli because of their "thou shalt have use other build tools" requirement I still see no benefit, most if not every developer is going to use maven or gradle.