Follow-up Comment #6, task #16596 (group administration):
> This is correct; however, using only collective identities is unusual, so I > hope you'll indulge my curiosity. Due to the sensitive nature of any product deeply connected to encryption and the reaction of officials worldwide towards it, we have no interest in seeing our names mentioned and ask you to respect our privacy. We are committed to maintaining Simphone as we have already done in the last four years, and of course if we get contributions from third parties that we want to accept, we are going to have to ask them to sign these legal statements that you require. > I'm not a lawyer, too; still I believe that in order for an entity to be > copyright holder it should be formally established, and appropriate papers > signed by people who make the works in question. This is as opposed to using > a collective pseudonym in the copyright notice when the copyright holders are > the individuals referred to by that pseudonym. In any case, decisions about > changes in the licensing terms need an approval from all copyright holders, > but the details will depend on the arrangements. > > What procedures do you practice? We discuss licensing and copyright issues among ourselves and all decisions on the matter are taken unanimously. This is a joint work and there are no separate parts to which any of us claims individual copyright. > In the unified diff format, anything before the first line starting with > '---' is ignored when patching. In fact, your patches already contain such > comments. Yes, this is correct. We will add copyright and license notices to all diff files. > At least this would comply with Savannah hosting requirements. Alright, so the above notices will state that we place our changes in the public domain. > You can add a note like, 'This file was written by _name_ [in _year_] who put > it in the public domain'. > > If the notices are in README, they will be lost if someone copies just a few > files from your collection. It's more convenient for the users to have > notices in files, and I see no good reason not to have them there. Ok then, will do. >>>> qsimphone/flags, >> >> We created the files in qsimphone/flags. But how can anyone claim copyright >> over flags or names of all the world's countries? > > This is evident for you, but you shouldn't assume that this will be evident > for your users. You can add a note explaining the origin of the files and > the issue, possibly with some references. Will add a more detailed explanation to qsimphone/flags/README.txt. >> countries.txt is machine-processed (by qsimphone) with a fixed format that >> currently allows no comments. > > The same machine that processes this file can easily remove comments at an > early stage, can't it? > >> The line number where each country name is >> placed must match that country number in ip0.bin. Would it be acceptable to >> add a legal notice at the end of the txt file? > > Yes. For example, web pages and changelogs typically have legal notices at > the bottom. Of course qsimphone should be able to remove comments. Will add the notice to the end of countries.txt and check if any changes to the code are necessary in order to process it. >> creative-commons.txt is the text of the "CC BY 4.0" license and if it does >> not >> include a legal notice, I don't think it would be a good idea for us to >> modify >> the text and add one. > > I'm not aware of any better solution yet. > >> So maybe just replace it with a link to the file on >> creativecommons.org? Of course in that case we run the risk of the link >> becoming invalid some day. > > You shouldn't assume that the user can easily access any particular web page. > You may assume is that the user has the complete tarball, and it should > contain anything needed to understand the licensing terms of the files > included. This is exactly the reason why we added creative-commons.txt to the tarball. But adding our own notice inside the text file may be misinterpreted as modifying the license text. Are you sure it's necessary? The text file does contain a notice (near the end) saying "The text of the Creative Commons public licenses is dedicated to the public domain..." and then goes on to say something about "unauthorized modifications" to the text. >>>> and build/config-win32. >>> > > I don't think I understand the technical side. The point of the configure > script is to gather information about user's system and preferences, so it > should run on user's computer and generate those files; they are not supposed > to be distributed to user. This is exactly what happens on unix-like systems. On windows, mingw as provided by Qt does not include /bin/sh, so configure scripts cannot run without access to other software. We want to make it easy for users to produce the same binaries we compile and distribute for all target systems. Binary reproduction is important for security reasons as a much better way of ensuring integrity, rather than a signature that identifies the origin but still leaves the content of the binary unknown. Cross-compilation is not implemented yet, so what we offer for the windows version is a batch file that compiles the source code on the native system, using only Qt/mingw. Fortunately, the configuration is fixed (for a fixed version of mingw), so it was enough for us to run all configure scripts and store their output files under the above directory. Then the batch file simply copies these files to the original directories of the external libraries (which require those output files) before it starts compiling. Of course it's also possible for users to run the top-level configure script on windows on their own, after having installed additional free software (usually msys), but this would not produce the same exact binary, unless the same exact version of mingw was used. > OpenSSL license is GPL-incompatible. The LGPL allows to link with such > software, but if the users want to combine your package with some third-party > software under the GPL, that will be forbidden; in other words, such > combination of software under the LGPL with OpenSSL license isn't > GPL-compatible. I think the solution may be to only support OpenSSL versions > released under the Apache License 2.0. We are currently updating openssl in our source tree to version 3.0, and will send a link to the new tarball here, which will also include all other changes discussed so far, in a few days. > I think the tarball shouldn't include files that are not useful for the > package, generally. Fully agree. makedepend is a leftover from the initial release of Simphone, where it was useful and used. Will remove from the tarball. > GPLv2 and GPLv3 are copyleft licenses, which means that they make the covered > program free and require that the derived works be distributed under the > terms; therefore, when in order to combine work A under the GPLv2 with work B > under the GPLv3, one would have to distribte the combination under the GPLv2 > as the license of work A requires, and at the same time the combination must > be under the GPLv3 bacause the license of work B requires that. Since GPLv2 > and GPLv3 are different licenses and they have no special compatibility > provisions, that is impossible. Thank you for explaining that. >>> The Qt Company supports the free software concept by providing the Qt Open >> Source Edition, which is licensed under the GNU Lesser General Public >> License >> (LGPL) version 3 and the GNU LGPL version 2.1. You can use this edition of >> Qt >> to create and distribute software with licenses that are compatible with >> these >> free software licenses. > > This may be interpreted in various ways. Are some modules released under > LGPLv3 while other under LGPLv21? Can the user choose any combination of > LGPLv3 and LGPLv2.1 for any module? If the former, the LGPLv3-only modules > shouldn't be included in your tarball. > > Do I miss anything? Qt source code is not part of our tarball at all. To compile Simphone and produce a binary, a user needs both our tarball and the Qt source code (or alternatively, the Simphone shar installer). For Qt-copyrighted code, their documentation sounds pretty clear to me - the user can choose either LGPLv2.1 or LGPLv3 or GPL3 for all modules. Quote: > Qt is available under different licensing options designed to accommodate the > needs of our various users. > * Enterprise, Professional, and Indie Mobile licenses. > * Community license (GPL or LGPL versions 3 and 2.1). > > Qt licensed under Enterprise, Professional and Indie Mobile licenses are > appropriate for development of proprietary/commercial software where you do > not want to share any source code with third parties or otherwise cannot > comply with the terms of the GNU LGPL version 3 or the GNU LGPL version 2.1. > > Qt licensed under the GNU Lesser General Public License (LGPL) version 3 is > appropriate for the development of Qt applications provided you can comply > with the terms and conditions of the GNU LGPL version 3 (or GNU GPL version > 3). > > Qt licensed under the GNU Lesser General Public License (LGPL) version 2.1 is > appropriate for the development of Qt applications provided you can comply > with the terms and conditions of the GNU LGPL version 2.1. > > Note: Some specific parts (modules) of the Qt framework are not available > under the GNU LGPL version 2.1. See Licenses Used in Qt for details. The latter note refers to external modules that are part of Qt, and a recent list of their licenses is provided here: https://doc.qt.io/qt-5/licenses-used-in-qt.html qsimphone.pro uses (links to) the following Qt libraries: core, dbus, gui, widgets, network (widgets and network do not include external modules). I spent some time checking if Simphone links to any of these Qt modules with licenses from the above link that look "suspicious" in that they are either not listed on gnu.org, or listed there as GPL-incompatible. The result of this investigation is: * qtbase/lib/fonts: not linked to Simphone * qtbase/src/3rdparty/sha3: the version included with qt 5.6.3 has a 3-clause BSD license; the above link I sent refers to a later Qt version * qtbase/src/3rdparty/libJPEG: not linked to Simphone * qtbase/src/3rdparty/libpng: linked in. Please check: https://directory.fsf.org/wiki/Libpng#Details * qtbase/src/3rdparty/wintab: these are a couple of windows h files, but the modules that use them are not linked to Simphone on windows * qtbase/src/3rdparty/icc: not linked to Simphone * licenses of all other external modules from the core, dbus and gui Qt libraries at the above qt.io link looked ok to me. You can verify the above results by inspecting our shar installer, which includes only source code that we really use. Any Qt source files that are not part of the installer, are also not part of compiled Simphone binaries (regardless of whether one used the shar installer or the tarball to generate them) on free operating systems. >>>> udev/libudev/: LGPL 2.1 >>> >>> The note on efence/ applies to the GPLv2-only part; the LGPLv2.1 includes >>> a >> permission for relicensing under the GPLv2+, so it's compatible with >> Savannah >> hosting requirements. >> >> Not sure if there is a GPLv2-only part (as opposed to "GPLv2 or later") > > Indeed; these files are under LGPLv2.1+ and GPLv2+; I assumed *-only when you > said, 'GPL2' and 'LGPL 2.1'. So am I to understand that we can also keep the code in udev/ (autoconf script etc.) in addition to the really needed code in udev/libudev/? > As far as I understand, RPSL section 4.2 allows to link to the works under a > set of licenses, but it says nothing about whether those licenses allow > linking with code under RPSL. On www.gnu.org, it is listed as > GPL-incompatible, > > https://www.gnu.org/licenses/license-list.html#RPSL Fine, build/rlink/ will also be removed from the source tree. > Probably I needn't. If they come with a major OS component like compiler, > they qualify as the system libraries in terms of the GPL. What you should > make sure is that your package gives the free software at least as good > support as it gives to nonfree counterparts. Of course, Simphone provides the same functionality with all operating systems it can run on. _______________________________________________________ Reply to this item at: <https://savannah.nongnu.org/task/?16596> _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/
signature.asc
Description: PGP signature
