Follow-up Comment #5, task #16596 (group administration):
> > Generally, who are copyright holders of your package, and how do they > co-ordinate their copyrights? > > We (the creators of Simphone) as a single entity are the copyright holder of > the code and documentation we wrote. That's because no one else has explicitly > contributed any other code to Simphone yet. And as far as we've read on those > links you sent, it's ok to claim copyright without signing legal papers or > even revealing our names. This is correct; however, using only collective identities is unusual, so I hope you'll indulge my curiosity. 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? > > Then, the diff files are text files, they should include copyright and > license notices themselves. > > One problem with this is that (some) diff files are machine-processed, which > does not necessarily allow insertion of comments. The GNU patch utility allows > and ignores this kind of thing, but that's not necessarily true for all other > patch utilities that are out there. So if it's an absolute requirement, we > could add such comments, and leave it to the user to deal with (by using GNU > patch, if need be). In the unified diff format, anything before the first line starting with '---' is ignored when patching. In fact, your patches already contain such comments. > But the second and bigger problem is that we don't know what to write there > exactly. Each of these diff files mostly includes code from one of these > external libraries (to which I have earlier referred as "dependencies"), with > a few bits written by us (lines that start with a "+" sign). So as to the > copyright of these lines, the idea was to rescind any copyright claims to the > copyright holders of the patched libraries. If you say it can't be done > without signing legal papers, perhaps placing our "contributions" to their > libraries in the public domain would be a good solution? At least this would comply with Savannah hosting requirements. > Please advise as to what to write in these copyright/license notices You can add a note like, 'This file was written by _name_ [in _year_] who put it in the public domain'. > and whether you insist on inserting a notice in each diff file, or perhaps > putting them in a single README file would suffice. 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. > > > qsimphone/flags, > > > > When files are in public domain, a brief note recording the authors, and > anything else relevant is desirable, > > 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. > > > qsimphone/resources > > > > countries.txt and creative-commons.txt are text files; they should include > legal notices themselves. > > 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. > 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. > > > and build/config-win32. > > > > Some of these files do contain copyright and license notices, and I don't > think I see any good reason for the rest to not contain them. > > The reason is that those files were output (automatically generated) by > configure scripts of external libraries, and most of them didn't include a > legal notice (for those that did, you have already seen that it is there). But > I believe all generated files do include notices as to which originals they > were generated from. And if you review the source code of these libraries > within our source tree, you will find that in addition to these originals, > some of their other text files (which probably do not include source code, > like Makefiles etc.) also do not include legal notices. This is true even for > GNU libraries, such as npth. What can we do about it? It's all third-party > code. > > Now the only reason why these particular files are under build/config-win32/ > instead of under each of the external library subdirectories as patches, was > to provide a "clean" source code structure and compilation process. We can > move them, but that won't change the contents of the files and will only > pollute the source tree with some windows config files, which are not needed > on free operating systems nor on Mac OS. 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. > > > cares/: MIT license ... > There is also no exact match of this license to any of the licenses listed on > gnu.org. Please check the text of their license at the provided link: > > https://c-ares.org/license.html > https://directory.fsf.org/wiki/C-ares#tab=Details Thank you, this is sufficient. > cryptopp/: #boost ... > openssl/: #OpenSSL (current version), #apache2 (next version) 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. > Note for build/makedepend/ it is simpler to remove the whole subdirectory from > the source tree, rather than trying to match the multiple licenses of this no > longer used utility to the list of licenses on gnu.org. I think the tarball shouldn't include files that are not useful for the package, generally. > ...I'm not sure why GPL2 isn't compatible with GPL3 but to > make it simple, we will remove efence/ from the source tree. 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. https://www.gnu.org/licenses/copyleft.html https://www.gnu.org/licenses/license-compatibility.html > > > qsimphone/resources/ip*.bin: Creative Commons Attribution 4.0 International ... > So if GPL is compatible with "CC BY 4.0" because it does not prevent whatever, > then LGPL is also compatible with the "CC BY 4.0" because it also does not > prevent the same thing. Conversely, LGPL is less restrictive than GPL, which > means that if "CC BY 4.0" is compatible with the more restrictive GPL, then it > should also be compatible with LGPL. > > What do you think? You are right. > > > qtbase/: LGPL 2.1 ... > > 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? > > > 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'. > > > build/rlink/: RCSL/RPSL/GPL2 > > > > The combination isn't trivial, and to tell the truth, I haven't tried to > analize it; could you explain how this licensing may be compatible with > GPLv3+? > > The way we read the RPSL (section 4.2), combined works released under a > "compatbile license" are exempt from the requirement of releasing the whole > work under the RPSL, as long as they are under the compatible license. Both > GPL and LGPL (with no version numbers) are listed as "compatible licenses" in > the text; there's also a link to a "current" list of compatible licenses, but > it does not work (that company has quit its open source business, as I had > mentioned earlier, so their web site no longer exists). > > If that's not good enough, we could drop rlink from the source tree - the > result being the windows binary size exploding by about 50%, but no changes to > the code (other than linking in a lot of unused junk). GNU/Linux, Mac OS and > other unix-like binaries would not be affected at all. 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 > > Now, it looks like by dependencies you mean what they call 'external > libraries' in the GNU Project: a module borrowed from a different package and > added to the tarball. For our purposes, dependencies mean software the > package uses, including the translators for the source code, the libraries the > program links to and so on. Has Simphone other such dependencies? > > Of course it has. I'll try to provide a list: > > GNU/Linux, at compile time: ... > * libxcb and libxcb-keysyms (used directly only if the user has specifically > so requested, but otherwise used by Qt5) Thank you! > BSD-based systems: same as GNU/Linux except for unavailable libraries such as > libasound, and additionally to GNU/Linux: libexecinfo. > > Mac OS: Apple development tools and libraries collectively known as "Xcode" > are required in order to compile and run any application on Mac OS X. Some of > these are "free", others are not. Please let us know if you need a detailed > list of which parts of Xcode we use directly. 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. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/task/?16596> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature
