Licence issues after legal review for packaging

[mirabilos]

Hi,

I’m in the process of preparing experimental packaging of your “devel” branch for Debian (for our organisation’s own use at first, though may be shared with the Debian project itself, and thus goes by the same guidelines), and have found a few licence issues (all relative to commit 5788133c4d119b9a57f8cc77dd22c3e73600bc62):

• several files have no explicit copyright and author notice; I assume they come under the “umbrella” Apache 2 licence from the top-level COPYING file (please confirm)

• some manual pages carry only the author information in the descriptive text but no copyright notice; I assume the same for all of them; authors involved: Simone Fedele, Vincent Bernat (please confirm)

• in several places, you use a licence that starts off almost like the Historical Permission Notice and Disclaimer (except it adds an explicit permission to sell, repositions the “without fee” words, and has a redundant reproduction requirement verbatim from the MIT licence and uses the MIT disclaimer except disclaiming liablility by “The Open Group”); this is not a problem, but you may with to change “The Open Group” in the disclaimer to “THE AUTHORS OR COPYRIGHT HOLDERS” like in the original MIT licence, and possibly switch the main licence body to a standardised version (either HPND or MIT) or at least remove the redundant second paragraph (not a problem, but please consider)

• sesman/tools/sestest.c is under no explicit licence, (c) 2008 Simone Fedele ⇒ we absolutely cannot accept the presence of this file in the source tree, unless an explicit licence is added (please contact Simone and ask whether Apache 2 or MIT or so is OK for them)

• common/d3des.{c,h} are proprietary software under no licence, “Copyright (C) 1999 AT&T Laboratories Cambridge. All Rights Reserved.” and “Copyright (c) 1988,1989,1990,1991,1992 by Richard Outerbridge.” ⇒ we absolutely cannot accept the presence of this file in the source tree (please replace by a version under a Free and OSI certified Open Source Software licence; “Public Domain” is not OK in most countries of the earth)

• there are several ELF binaries in the tree: tcutils/tcutils and tests/gtcp_proxy/gtcp-proxy (please “git rm” them)

• there are several appearing-to-be-generated files in the tree (please advice on how they are generated, or “git rm” them): tcutils/moc_mainwindow.cpp, tcutils/qrc_resources.cpp, tcutils/tcutils.pro, tcutils/ui_mainwindow.h, xrdp/rsakeys.ini

• there are several BLOBs in the tree which are probably not eligible for copyright protection (but please advice on them): sesman/chansrv/pcsc/dumps/, sesman/chansrv/wave-format-server.txt

• there are several binaries and images in the tree, the origin and copyright/licence status of which is unclear; in addition, xrdp/sans-10.fv1 appears to be transformed from DejaVu Sans somehow, probably violating its licence (please advice how the transformation is done): Coding_Style.odt, xrdp/xrdp_logo.bmp, xrdp/xrdp24b.bmp, xrdp/xrdp256.bmp (these look self-written/drawn, can we assume Apache 2 from Jay Sorg for these?); xrdp/ad24b.bmp, xrdp/ad256.bmp (these look they come from XFree86, IIRC; please confirm or state the actual origin and licence); tcutils/resources/images/tools.gif, xrdp/cursor0.cur, xrdp/cursor1.cur (they look unproblematic, but please advice); xorg/tests/xdemo/yosemite.bmp (looks like it was taken from somewhere else and may violate copyright? please advice), and xrdp/sans-10.fv1 (see above)

Thanks for making the world a better place, with clear legalities, by responding to the above issues (especially those that are an absolute problem: the files with no licence (sestest, d3des) and the binaries).

[mirabilos]

xrdp-keygen.8 is apparently © 2007, 2008 Vincent Bernat bernat@debian.org and licenced under the GNU GPL version 2 or later.

For the manpages, that leaves Simone Fedele, whom we need to contact anyway because of the sesman/tools/sestest.c file.

[jsorg71]

I think I can help with this. I'll start with the easy one, remove binaries.

[jsorg71]

Thanks for doing this legal review. I removed gtcp-proxy and tcutils. I'll respond to the rest maybe one at a time.

I'm surprised that public domain is not Ok in most countries of the earth. I thought that was the most permissive.

[mirabilos]

Thanks for doing this legal review.

You’re welcome.

I removed gtcp-proxy and tcutils. I'll respond to the rest maybe one at a time.

OK wonderful, thanks.

I'm surprised that public domain is not Ok in most countries of the earth. I thought that was the most permissive.

That’s the fallacy. It isn’t, but that’s not widely published yet, as it would cause lots of mayhem, but we’re starting to push for “fallback” licences in a style that says “if PD is not OK for you, choose any OSI-approved licence of your choice”; many authors agree to that, only some (like DJB) actively disagree (but then, DJB has a history of not understanding licencing anyway). The problem with PD is: PD is nothing that transcends country/legislation boundaries. We have copyright, which, since the Berne convention, is automatic(!) and international. That means that, if anyone writes something, it’s automatically protected by copyright in almost 200 countries, and that everyone in those countries needs a licence to be able to do anything with it. Only in some countries can people actively refuse copyright (place things into PD); most of the EU is not in it for example (which makes e.g. SQLite positively illegal, as there are confirmed commits by Germans in it) – the idea is to prevent artists from being abused by forcing them to give up their rights if they don’t want to starve –, and even then, that is questionable (e.g. a USA citizen can say "I release this into PD", but that’s only valid under some circumstances).

An example fallback licence text I’ve gotten upstream authors to agree to is:

.\" In countries where the Public Domain status of the work may not be .\" valid, its primary author hereby grants a copyright licence to the .\" general public to deal in the work without restriction and permis- .\" sion to sublicence derivates under the terms of any (OSI approved) .\" Open Source licence.

The idea here being that OSI does not disapprove licences that once were approved without mistake (which they said they won’t).

In the specific case though, it’s not PD because several people placed © markers on the file, so we need explicit licences from each of them. (You may be able to get rid of the file altogether by leveraging OpenSSL, if I understand what it does correctly.)

[jsorg71]

xrdp/sans-10.fv1 is generated from DejaVu Sans. The font is drawn on a window and the pixels are scrapped to generate the font file. The code to do this is in font_dump directory. Since this file is generated from a screen scrap, it more like a screen shot. Screen shots don't hold the same copyright as the fonts on the screen. Anyway, we can use the DejaVu Sans copyright if we must.

[jsorg71]

sesman/chansrv/pcsc/dumps/and sesman/chansrv/wave-format-server.txt are just info, note, wire dumps.

[jsorg71]

BTW do you know there is already a Debian package for xrdp and a maintainer. There is also https://github.com/scarygliders/X11RDP-o-Matic. Still, I'm glad to get these license technicalities corrected.

[mirabilos]

jsorg71 dixit:

BTW do you know there is already a Debian package for xrdp and a maintainer.

Yes, but that’s positively ancient – probably because xrdp decided to not publish tarballs any more.

Plus, several of these issues are new.

There is also https://github.com/scarygliders/X11RDP-o-Matic.

That’s inacceptable for people who wish to use the package management system for controlling what gets installed and uninstalled. Plus, our package could make it back to Debian.

Still, I'm glad to get these license technicalities corrected.

Meh, that’s required after all.

[mirabilos]

jsorg71 dixit:

xrdp/sans-10.fv1 is generated from DejaVu Sans. The font is drawn on a window and the pixels are scrapped to generate the font file. The code to do this is in font_dump directory.

Ah okay. I was not aware that this was “just” a bitmap.

Since this file is generated from a screen scrap, it more like a screen shot. Screen shots don't hold the same copyright as the fonts on the screen.

In at least Germany and the USA, bitmap fonts are not eligible for copyright at all, so this is no problem.

Thanks for the info!

bye,

//mirabilos

I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt

[mirabilos]

http://fossies.org/linux/xrdp/tests/xdemo/yosemite.bmp is a merger of the two pictures http://www.appstate.edu/~marshallst/photos/boone_photos/yosemite_valley/YosemiteValley-012.jpg and http://www.appstate.edu/~marshallst/photos/boone_photos/yosemite_valley/YosemiteValley-032.jpg found on the page http://www.appstate.edu/~marshallst/photos/boone_photos/yosemite_valley.html by this fellow: http://www.appstate.edu/~marshallst/

Scott T. Marshall

Associate Professor

111 Rankin Science South Department of Geology Appalachian State University 572 Rivers Street Boone, NC 28608

Email :: marshallstappstateedu Phone :: 828-265-8680

Wonder who should approach him about a licence.

[mirabilos]

I believe this leaves us with the following files to consider:

• missing explicit licence (see above) but require one: – common/d3des.{c,h} – sesman/tools/sestest.c – xorg/tests/xdemo/yosemite.bmp

• generated, plaintext, can almost certainly be regenerated: – tcutils/moc_mainwindow.cpp – tcutils/qrc_resources.cpp – tcutils/tcutils.pro – tcutils/ui_mainwindow.h – xrdp/rsakeys.ini (looks like a generated RSA key)

• unclear, probably harmless, clarification can’t hurt: – tcutils/resources/images/tools.gif – xrdp/ad24b.bmp, xrdp/ad256.bmp (IIRC they come from X11) – xrdp/cursor0.cur, xrdp/cursor1.cur (probably also X11) – xrdp/xrdp24b.bmp, xrdp/xrdp256.bmp (project logo, self-drawn?) – xrdp/xrdp_logo.bmp (“connecting…” graphics, self-drawn?) – Coding_Style.odt (self-written?)

[mirabilos]

We have https://github.com/teckids/xrdp/blob/debian/debian/copyright now, and the TODOs such as to contact Simone and Scott are still open.

I do believe I can fully replace D3DES with free code, given a bit of time (concentrating to getting it done (as non-free) first).

Since yosemite.bmp is just a test picture, I can replace that as well. Do you prefer pull requests, so you can merge my improvements to make it free?

I will remove the generated files – we don’t build tcutils anyway (Debian is removing Qt4 at the moment), and we generate the RSA key on postinst (I read up about it now and had quite some laughs).

Can you comment on the “possibly harmless” ones? For each, whether you created it yourself or where it’s from would be a decent start.

Thanks in advance!

[metalefty]

+1 removing rsakeys.ini and generate after install.

For example, in FreeBSD, rsakeys.ini is generated for the first time starting xrdp daemon. https://github.com/neutrinolabs/xrdp/blob/devel/instfiles/rc.d/xrdp#L43

This rc script for FreeBSD is taken from FreeBSD ports. Maybe this also needs copyright and license, right? The script is written by me and FreeBSD licensed. No problem to change other license compatible to FreeBSD license.

[mirabilos]

metalefty dixit:

This rc script for FreeBSD is taken from FreeBSD ports. Maybe this also needs copyright and license, right? The script is written by me

If it is, then yes.

and FreeBSD licensed. No

That's a good licence. Just add the info to the script.

[jsorg71]

I removed these files from the devel branch

tcutils/moc_mainwindow.cpp tcutils/qrc_resources.cpp tcutils/tcutils.pro tcutils/ui_mainwindow.h xrdp/rsakeys.ini

[mirabilos]

jsorg71 dixit:

I removed these files from the devel branch

Thanks. I’ll get back to you wrt. the remaining files.

Do you have any way to contact Simone? I never heard back from her.

[jsorg71]

I tried to contact her too. I did ask her about some license changes in the past, she was OK with it. She usually wanted me to have to copyright and her listed as an author. As you can see from the other files in that directory. If we have to, we can just remove that file.

[jsorg71]

OK, I finally figured out how to use OpenSSL for the VNC 3DES. They use a 3DES in a strange way. Soon we can remove d3des.c/h.

[jsorg71]

d3des.c/h are removed now in devel branch

[mirabilos]

Thanks, wonderful! I merged that, and submitted a pull request (#274) which replaces the remaining must-fix files.

I would appreciate if you could comment on the “unclear, probably harmless, clarification can’t hurt” files, although I don’t consider them showstoppers for Debian main myself. TIA.

[mirabilos]

sestest has at least been distributed under GPLv2+ some time ago according to http://sourceforge.net/p/xrdp/code/ci/078b4d3f4127042b020e78bb9d9762196ff070c3/ so we can probably assume (and note) that.

[metalefty]

@mirabilos done? Is there any TODOs for legal packaging?

[mirabilos]

metalefty dixit:

@mirabilos done? Is there any TODOs for legal packaging?

I’ll have a look when I have a bit more “air” (spare time), sorry.

[mirabilos]

We’ve looked into this, and, as far as I can tell, the current codebase is DFSG-free.

I’ve updated https://github.com/teckids/xrdp to reflect the fact, taking tonight’s source tree (including updating librfxcodec to its 'devel' branch). Natureshadow is, in the meanwhile, working on getting it uploaded into Debian proper (I lost my patience with the people he wants to sponsor his upload, and who want to co-maintain this, due to technical differences).

Please do have a look at the various files in https://github.com/teckids/xrdp/tree/debian/debian/patches because there surely are a lot of patches for you to merge. I don’t really want to split them off into various git branches to do the github dance, because they somewhat depend on each other (hence the 'series' file, which orders the patches), and also, some might not be applicable upstream (such as the move from /tmp/.xrdp/ to /var/run/xrdp/ which is a required security patch (/tmp is world-writable after all) but somewhat distro-specific), or some you simply might not want.

Thanks for autotools-ifying librfxcodec, by the way! We can finally use it!

I’m closing this issue because, as far as I can tell, all legal issues are resolved, considering your Aug 18, 2015, comment about Simone, which was about the last thing still pending.