taskSavannah Administration - Tasks: task #16596, Submission of simphone

 
 

task #16596: Submission of simphone

Submitter:  simphone <simphone>
Submitted:  Thu 24 Oct 2024 04:01:46 AM UTC
   
 
Should Start On:  Thu 24 Oct 2024 12:00:00 AM UTC Should be Finished on:  Sun 03 Nov 2024 12:00:00 AM UTC
Category:  Project Approval Priority:  * 5 - Normal
Status:  In Progress Privacy:  Public
Assigned to:  ineiev Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 11 Jan 2025 09:48:28 PM UTC, comment #23: 

Thank you!

Generally, the exact forms of copyright notices may depend on the country; for example, the the copyright sign may be used instead of the word "Copyright," and the copyright years may follow the names of the copyright holders.  Moreover, when someone showed me a copyright notice from a book printed in Iran, it was written completely with the Arabic script.  I couldn't see neither the word "Copyright" nor the copyright sign, even in the form of a parenthesized "C."

The GNU Project and Savannah use the conventions established in the US, as explained in our guidelines.

Now, files like speex/libspeex/lsp.c have no valid copyright notice.

Then, the notice in files like simcore/icftypes.h is unclear: it doesn't tell the origin of the file and why it's in the public domain.  To tell the truth, I don't understand what 'has no copyright assigned' mean.  It refers to DISCLAIMER.txt, but that file essentially provides no further details, and the relevant information should be in the covered file, in the first place.

When fixing these issues, please check for other such files in your tarball.

Ineiev <ineiev>
Site Administrator
Tue 24 Dec 2024 07:44:38 PM UTC, comment #22: 


> A copy of full text of used licenses should be included; qsimphone/translations/LICENSE.LGPLv3 refers to a missing LICENSE.GPLv3.


Added from qttranslations.

> When some files can't include copyright and license notices, a README file should include them; qsimphone/icons/README.txt includes no license notice for files icons/qdarkstyle/branch_closed-on.png.
>
> qsimphone/flags/README.txt doesn't explicitly list the files the notices apply to.


Assumed qsimphone/resources/README.txt was ok with the previous version and made no changes no it.

Added the missing license text to qsimphone/icons/README.txt and all file names to qsimphone/flags/README.txt.

Removed build/config-win32/README.txt as it seemed useless at this point (referred only to text files).

> Please check for other similar problems in your tarball.


The check revealed that openssl source files were mistakenly referring to the openssl LICENSE.txt file as LICENSE, so renamed LICENSE.txt back to LICENSE to avoid the problem. Could not find any other references to missing or misnamed license files, and there weren't any binary files in the tarball outside of the three subdirectories of qsimphone/, so no other README files either. But a few other minor problems have been found, and are now fixed.

Additionally, re-added diff files in patches/ that were temporarily removed in 0.9.3-a4. It's still good for users to know what changes have been made to the external libraries, most of which are very well known. Also, added a new text file build/installer_files, used by build/make_installer.sh.

Please find the new tarball at:

https://osdn.dl.osdn.net/simphone/79652/simphone-src-0.9.3-a7.tar.gz
http://osdn.dl.osdn.net/simphone/79652/simphone-src-0.9.3-a7.tar.gz

simphone <simphone>
Sun 22 Dec 2024 06:06:02 PM UTC, comment #21: 

Thank you!

A copy of full text of used licenses should be included; qsimphone/translations/LICENSE.LGPLv3 refers to a missing LICENSE.GPLv3.

When some files can't include copyright and license notices, a README file should include them; qsimphone/icons/README.txt includes no license notice for files icons/qdarkstyle/branch_closed-on.png.

qsimphone/flags/README.txt doesn't explicitly list the files the notices apply to.

Please check for other similar problems in your tarball.

Ineiev <ineiev>
Site Administrator
Sat 14 Dec 2024 08:55:32 AM UTC, comment #20: 


> * README.txt says 'copyright holders' even for public domain files; when a file is in the public domain, it has no copyright holders.
> * README.txt includes no copyright and license notices for files like ip0.bin.
> * 'None' license means that any actions prohibited that the copyright law doesn't allows, whereas in fact empty files are uncopyrightable, so copyright doesn't restrict them in any way.
> * No need to mention files like country.txt in README.txt, such files should include copyright and license notices in themselves.
> * The notices in country.txt are confusing: both public domain dedication and LGPL license notice is included.


Tried to solve these problems, please find the new tarball at:

https://osdn.dl.osdn.net/simphone/79652/simphone-src-0.9.3-a6.tar.gz
http://osdn.dl.osdn.net/simphone/79652/simphone-src-0.9.3-a6.tar.gz

simphone <simphone>
Thu 12 Dec 2024 05:01:59 PM UTC, comment #19: 

qsimphone/resources/ still has some issues,

  • README.txt says 'copyright holders' even for public domain files; when a file is in the public domain, it has no copyright holders.
  • README.txt includes no copyright and license notices for files like ip0.bin.
  • 'None' license means that any actions prohibited that the copyright law doesn't allows, whereas in fact empty files are uncopyrightable, so copyright doesn't restrict them in any way.
  • No need to mention files like country.txt in README.txt, such files should include copyright and license notices in themselves.
  • The notices in country.txt are confusing: both public domain dedication and LGPL license notice is included.
Ineiev <ineiev>
Site Administrator
Sat 07 Dec 2024 12:25:46 AM UTC, comment #18: 


> This makes little sense: the license is short, and including a reference
> instead of it only makes a possibility for confusion...
>
> Specific instructions are given on our page ValidNotices.  You should have read it.


Sorry, seems we had not properly understood that part of the "ValidNotices" document, due to not having had enough experience with GNU stuff yet. This lack of experience is just what we've been correcting, as long as you bear with us.

> > The uudecode.pl file is from the public domain (usenet), so it looks like it
> > doesn't have any copyright assigned.
>
> Could you elaborate?  What is usenet, and why do you assume public domain?


In order to avoid any doubt, we have chosen to replace that uudecode.pl with a new one created by us from scratch, which implements the same basic functionality. Even though I am quite sure that the "public domain" assumption was correct for the old file, it would still be difficult for me to prove this beyond doubt.

Please find our new tarball, which includes the above change, as well as embedded licenses at:

https://osdn.dl.osdn.net/simphone/79652/simphone-src-0.9.3-a5.tar.gz
http://osdn.dl.osdn.net/simphone/79652/simphone-src-0.9.3-a5.tar.gz

simphone <simphone>
Wed 04 Dec 2024 02:00:28 PM UTC, comment #17: 


> > Thank you!  As far as I can see, though, the license isn't included in
> > miniupnpc/miniupnpcstrings.h.in.
>
> That's because miniupnpcstrings.h.in includes a license notice instead, just
> like the rest of the source files of the miniupnpc third-party library.
> Thought license notices instead of embedded licenses were generally ok?


This makes little sense: the license is short, and including a reference
instead of it only makes a possibility for confusion...

> The only problem I see with this particular library is that some of its
> notices mistakenly refer to its LICENSE file as LICENCE. The file had
> originally been called LICENCE, but the author had renamed it to LICENSE prior
> to version 1.6 and had forgotten to update license notices in his source files
> with his new file name.


...like this one.

> Could you maybe provide some more specific instructions? I'm not sure what
> exactly you expect for miniupnpc or other third party libraries in general. We
> did not edit files that already had copyright and license notices, but if this
> would be necessary, would be glad to oblige, as soon as I know what/how to
> edit.


Specific instructions are given on our page ValidNotices.  You should have read it.

> The uudecode.pl file is from the public domain (usenet), so it looks like it
> doesn't have any copyright assigned.


Could you elaborate?  What is usenet, and why do you assume public domain?

Ineiev <ineiev>
Site Administrator
Mon 02 Dec 2024 12:39:03 AM UTC, comment #16: 


> > The above version also includes a fix for miniupnpcstrings.h as you requested.
>
> Thank you!  As far as I can see, though, the license isn't included in miniupnpc/miniupnpcstrings.h.in.


That's because miniupnpcstrings.h.in includes a license notice instead, just like the rest of the source files of the miniupnpc third-party library. Thought license notices instead of embedded licenses were generally ok?

The only problem I see with this particular library is that some of its notices mistakenly refer to its LICENSE file as LICENCE. The file had originally been called LICENCE, but the author had renamed it to LICENSE prior to version 1.6 and had forgotten to update license notices in his source files with his new file name.

Could you maybe provide some more specific instructions? I'm not sure what exactly you expect for miniupnpc or other third party libraries in general. We did not edit files that already had copyright and license notices, but if this would be necessary, would be glad to oblige, as soon as I know what/how to edit.

> > So how do we proceed from here?
>
> >>>> Please make sure that all copyrightable files include valid copyright and
> >>>> license notices.
>
> Currently, files like build/uudecode.pl don't.  Please check all files, like in


Of course, all files from the last tarball had been checked before the link was posted here. I hope we haven't missed any of the files.

The uudecode.pl file is from the public domain (usenet), so it looks like it doesn't have any copyright assigned. I had mentioned this file in our conversation here early on, when I sent the "list of licenses". The file does have a comment (starting from line 13) that indicates its origin. What more can we add?

simphone <simphone>
Wed 27 Nov 2024 04:55:58 PM UTC, comment #15: 


> Removed some unnecessary files and reviewed the rest; traced the origin of
> files that did not include copyright and license notices and added them
> accordingly. Here's the new tarball:
>
> https://osdn.dl.osdn.net/simphone/79652/simphone-src-0.9.3-a4.tar.gz
> http://osdn.dl.osdn.net/simphone/79652/simphone-src-0.9.3-a4.tar.gz
>
> >>> Thanks!  The file miniupnpc/build/miniupnpcstrings.h refers to a short
> >>> permissive license instead of including it; could you fix that?
>
> The above version also includes a fix for miniupnpcstrings.h as you requested.


Thank you!  As far as I can see, though, the license isn't included in miniupnpc/miniupnpcstrings.h.in.

> So how do we proceed from here?


>>>> Please make sure that all copyrightable files include valid copyright and
>>>> license notices.


Currently, files like build/uudecode.pl don't.  Please check all files, like in


find . -type f -print0 | xargs -o0 $EDITOR


Ineiev <ineiev>
Site Administrator
Tue 26 Nov 2024 01:51:22 AM UTC, comment #14: 


> > > Please make sure that all copyrightable files include valid copyright and
> > > license notices.  Currently, files like npth/npth.spec.in don't.
>
> When a file is included in your tarball, it will be hosted on Savannah, so you are responsible for its compliance with Savannah hosting requirements.


Removed some unnecessary files and reviewed the rest; traced the origin of files that did not include copyright and license notices and added them accordingly. Here's the new tarball:

https://osdn.dl.osdn.net/simphone/79652/simphone-src-0.9.3-a4.tar.gz
http://osdn.dl.osdn.net/simphone/79652/simphone-src-0.9.3-a4.tar.gz

> > > Thanks!  The file miniupnpc/build/miniupnpcstrings.h refers to a short
> > > permissive license instead of including it; could you fix that?


The above version also includes a fix for miniupnpcstrings.h as you requested. So how do we proceed from here?

simphone <simphone>
Fri 22 Nov 2024 04:12:50 AM UTC, comment #13: 


> > Please make sure that all copyrightable files include valid copyright and
> > license notices.  Currently, files like npth/npth.spec.in don't.
>
> Just to make sure I get it right, is this about all copyrightable text files
> of all third-party libraries bundled in the tarball?


When a file is included in your tarball, it will be hosted on Savannah, so you are responsible for its compliance with Savannah hosting requirements.

> You of course realize that if this is so, upgrading external libraries would
> become difficult, as we would always have to fix any and all new files they
> added with each update.


...unless someone convinces those libraries to follow good practices.

> The file you gave as an example is also part of GnuPG, so I wonder, does
> Savannah have stricter hosting requirements than gnupg.org?


To the best of my knowledge, gnupg.org doesn't offer hosting to third-party packages, so the question isn't correct.

> > Thanks!  The file miniupnpc/build/miniupnpcstrings.h refers to a short
> > permissive license instead of including it; could you fix that?
>
> Assuming you meant build/config-win32/miniupnpc/build/miniupnpcstrings.h, it
> won't be a problem to embed the BSD 3-Clause LICENCE file into that h file
> with the next tarball.


Yes; sorry for the mistake.

Ineiev <ineiev>
Site Administrator
Tue 19 Nov 2024 10:04:02 AM UTC, comment #12: 


> Please make sure that all copyrightable files include valid copyright and license notices.  Currently, files like npth/npth.spec.in don't.


Just to make sure I get it right, is this about all copyrightable text files of all third-party libraries bundled in the tarball?

You of course realize that if this is so, upgrading external libraries would become difficult, as we would always have to fix any and all new files they added with each update.

The file you gave as an example is also part of GnuPG, so I wonder, does Savannah have stricter hosting requirements than gnupg.org?

> Thanks!  The file miniupnpc/build/miniupnpcstrings.h refers to a short permissive license instead of including it; could you fix that?


Assuming you meant build/config-win32/miniupnpc/build/miniupnpcstrings.h, it won't be a problem to embed the BSD 3-Clause LICENCE file into that h file with the next tarball.

simphone <simphone>
Mon 18 Nov 2024 05:47:27 PM UTC, comment #11: 


> Sorry, it was in the same directory as all previous tarballs I sent. Don't
> know what happened - maybe the hosting provider changed something. Please try
> the alternative download link:
>
> https://osdn.dl.osdn.net/simphone/79652/simphone-src-0.9.3-a3.tar.gz
> http://osdn.dl.osdn.net/simphone/79652/simphone-src-0.9.3-a3.tar.gz


Thank you!

Please make sure that all copyrightable files include valid copyright and license notices.  Currently, files like npth/npth.spec.in don't.

> I hope this does not send JavaScript but it if does, perhaps you could turn
> JavaScript off in your browser.


Sure.  I rarely turn it on, even when my browser implements it at all.

> > If you require to install a specific image of an OS in order to reproduce,
> > you could as well require to install specific versions of MinGW and other
> > tools like a shell on that platform instead of distributing the generated
> > files the users have to rely on; if it were acceptable to you, that would
> > resolve the issue of the absense of valid legal notices in those files.
>
> We could, but we would always have to check if those specific versions of
> mingw and the rest are still available on the Internet and whether links to
> them that we would include in documentation were still valid. So we added the
> missing legal notices to all files in build/config-win32 by copying them from
> their external libraries instead. Only 10 such files were found. Also copied
> license texts as new files from external libraries to build/config-win32
> subdirectories in cases where the added legal notices did not include license
> texts. This way it will be easier to maintain properly.


Thanks!  The file miniupnpc/build/miniupnpcstrings.h refers to a short permissive license instead of including it; could you fix that?

Ineiev <ineiev>
Site Administrator
Fri 15 Nov 2024 04:32:36 PM UTC, comment #10: 


> > Upgraded openssl to version 3.0, which uses the apache license. Here's the
> > updated tarball:
> >
> > http://www.simphone.org/0.9.3/simphone-src-0.9.3-a2.tar.gz
>
> This URL serves me with a HTML page depending on proprietary JavaScript.


Sorry, it was in the same directory as all previous tarballs I sent. Don't know what happened - maybe the hosting provider changed something. Please try the alternative download link:

https://osdn.dl.osdn.net/simphone/79652/simphone-src-0.9.3-a3.tar.gz
http://osdn.dl.osdn.net/simphone/79652/simphone-src-0.9.3-a3.tar.gz

I hope this does not send JavaScript but it if does, perhaps you could turn JavaScript off in your browser.

> If you require to install a specific image of an OS in order to reproduce, you could as well require to install specific versions of MinGW and other tools like a shell on that platform instead of distributing the generated files the users have to rely on; if it were acceptable to you, that would resolve the issue of the absense of valid legal notices in those files.


We could, but we would always have to check if those specific versions of mingw and the rest are still available on the Internet and whether links to them that we would include in documentation were still valid. So we added the missing legal notices to all files in build/config-win32 by copying them from their external libraries instead. Only 10 such files were found. Also copied license texts as new files from external libraries to build/config-win32 subdirectories in cases where the added legal notices did not include license texts. This way it will be easier to maintain properly.

These changes are included in the newer tarball I sent above.

> > > 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,
>
> By linking I mean making a single combined work.
>
> We were discussing this in the context of RPSL-licensed code included in your tarball, so effectively it was a part of your package, and in order to comply with Savannah hosting requirements it needed to be GPL-compatible.


Clear enough now, thank you. rlink is not coming back and lets hope that some day we can upgrade to a mingw version that supports the --gc-sections option.

simphone <simphone>
Wed 13 Nov 2024 05:05:05 PM UTC, comment #9: 

On Sat, Nov 09, 2024 at 06:01:46AM -0500, simphone wrote:

> Follow-up Comment #8, task #16596 (group administration):
>
> Upgraded openssl to version 3.0, which uses the apache license. Here's the
> updated tarball:
>
> http://www.simphone.org/0.9.3/simphone-src-0.9.3-a2.tar.gz


This URL serves me with a HTML page depending on proprietary JavaScript.

> We care for reprodicibility on all platforms Simphone can run on.

...

> On Mac OS X, Xcode 3.2.6 is to be installed. On
> GNU/Linux, one has to start by installing an ISO image of Debian GNU/Linux
> 6.0.10; in that case, the whole OS is defined as "tools and libraries" for the
> purpose of binary reproduction.


If you require to install a specific image of an OS in order to reproduce, you could as well require to install specific versions of MinGW and other tools like a shell on that platform instead of distributing the generated files the users have to rely on; if it were acceptable to you, that would resolve the issue of the absense of valid legal notices in those files.

> > 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,
>
> Sorry to bring this up again; after rereading I'm not really sure what you
> mean by "linking". So I want to point out that Simphone binaries never did
> contain any RPSL-licensed code. The latter was only called by the build
> scripts (at compile time) in order to bring the binary size down, by removing
> unused machine code. Does that change anything? If so, we would be glad if we
> could re-add rlink; else we keep it removed as already agreed and done.


By linking I mean making a single combined work.

We were discussing this in the context of RPSL-licensed code included in your tarball, so effectively it was a part of your package, and in order to comply with Savannah hosting requirements it needed to be GPL-compatible.

Ineiev <ineiev>
Site Administrator
Sat 09 Nov 2024 11:01:40 AM UTC, comment #8: 

Upgraded openssl to version 3.0, which uses the apache license. Here's the updated tarball:

http://www.simphone.org/0.9.3/simphone-src-0.9.3-a2.tar.gz

Other changes also made with this update:

  • removed build/rlink/, build/makedepend/ and efence/
  • updated public domain notices in all files as you advised
  • added public domain notice to qsimphone/resources/countries.txt
  • explicitly listed all files in qsimphone/resources/README.txt and qsimphone/icons/README.txt
  • added CC0 public domain dedication as qsimphone/resources/cc0-public-domain.txt
  • added public domain notices to all diff files in patches/
  • updated last copyright year to 2024 everywhere
  • renamed doc/DISCLAIMER.PD to doc/DISCLAIMER.txt
  • removed doc/COPYING.txt (GPL2 text)


LGPL 2.1 text is included as doc/COPYING.LESSER.txt, but as I understand GPL2 is not desired, so removed (please correct me if this was wrong).

> "...dedicated to the public domain under the CC0 Public Domain Dedication."
>
> I stand corrected.  Then it's a copy of CC0 that is missing from your tarball.


Now included (as described above).

> But the binary reproduction and possibly even building is broken when mingw version changes.  I'm not sure if you care about the reproducibility specifically on that platform.  From Savannah policies perspective, that might qualify as a feature unsupported on free systems.  I don't think it works, but if a goal is set, it may be achieved some day.


We care for reprodicibility on all platforms Simphone can run on. Procedures for all three platforms are exactly defined in the "Binary Reproduction" chapter in doc/compiling html. To reproduce our binaries, you (or the user) have to use the same exact versions of all tools and libraries involved with the build process. On windows, this means that Qt 5.3.2 and the mingw version included with it must be used. On Mac OS X, Xcode 3.2.6 is to be installed. On GNU/Linux, one has to start by installing an ISO image of Debian GNU/Linux 6.0.10; in that case, the whole OS is defined as "tools and libraries" for the purpose of binary reproduction. This has worked very well so far in that the compiled binary seems to run fine on many if not most current GNU/Linux distributions.

Of course, any user is also free to use newer versions of tools and libraries on any platform and indeed the compiled binaries will then change. But in any case, our build scripts ensure that once a binary is compiled, a rerun of the scripts produces the same binary as before, as long as the versions of the used dependencies and the name of the source directory have not been changed since the original run. This means you can take any version of any free OS, produce a binary with it, and then anyone can reproduce it, as long as they use the same OS version. That's unless some sort of a "rolling release" binary distribution is in use, which from our point of view carries a major security risk not only for Simphone, but for all installed software.


> 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,


Sorry to bring this up again; after rereading I'm not really sure what you mean by "linking". So I want to point out that Simphone binaries never did contain any RPSL-licensed code. The latter was only called by the build scripts (at compile time) in order to bring the binary size down, by removing unused machine code. Does that change anything? If so, we would be glad if we could re-add rlink; else we keep it removed as already agreed and done.

simphone <simphone>
Tue 05 Nov 2024 05:18:04 PM UTC, comment #7: 


> 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.


You needn't explain why you want to be pseudonymous; but if you do, you shouldn't blame cryptography, that will smell like snake oil.  Contributors to packages like GnuPG post their signed certificates of origin right on public mailing lists of those packages.

> 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.


In fact, I don't think we require to really sign anything.  What we want is clearly stating copyright status of the entire package.

> > 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.


"...dedicated to the public domain under the CC0 Public Domain Dedication."

I stand corrected.  Then it's a copy of CC0 that is missing from your tarball.

> >>>> 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),


But the binary reproduction and possibly even building is broken when mingw version changes.  I'm not sure if you care about the reproducibility specifically on that platform.  From Savannah policies perspective, that might qualify as a feature unsupported on free systems.  I don't think it works, but if a goal is set, it may be achieved some day.

> 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).

...

> 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.


Thank you!

> > 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/?


Yes, of course.

Ineiev <ineiev>
Site Administrator
Tue 05 Nov 2024 01:20:10 AM UTC, comment #6: 


> 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.

simphone <simphone>
Wed 30 Oct 2024 05:44:25 PM UTC, comment #5: 


> > 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.

Ineiev <ineiev>
Site Administrator
Tue 29 Oct 2024 12:01:34 AM UTC, comment #4: 


> Your package is quite large, and the licensing situation isn't very simple, so a more detailed discussion is needed.


Let me start answering by saying that we have no lawyers on our team. Sorry about misnaming license types in my previous reply. Copyright is indeed complicated, but we hope we can find a complete solution, with your help. We will cooperate and work towards fixing all licensing problems as much as we can.

> My idea of copyright assignment is different.  I believe a copyright assignment is a legal paper where all affected persons and entities are named explicitly and unequivocally, and of course aware of the assignment.
>
> 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.

Our code is in the simcore/ and qsimphone/ subdirectories; html documentation is in doc/ and of course we wrote the configure and build scripts, and some small .txt files, in addition to creating the icons. We claim copyright for all files to which we have added GNU copright/license notices at your request. All else is either third-party or (maybe) non-copyrightable. For the latter files we have added notes that they are placed in the public domain; and will yet add some text to indicate that we created the files, as you requested.

> 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).

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? Please advise as to what to write in these copyright/license notices and whether you insist on inserting a notice in each diff file, or perhaps putting them in a single README file would suffice.

> All files should be listed in README explicitly; if they aren't, it's too easy to get the things wrong when any new files are added.


Right, this is not difficult to do, it places a bit of a maintenance burden, but we will do it.

> > 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? They have been published in a countless number of books and on the Internet. We disclaim any copyright. A note could be added to the already added README.txt, saying that we created the files. Please advise as to what else (if anything) could be written about that.

> > 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 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? Hopefully the code would just ignore it then.

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. 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.

> > 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.

> > cares/: MIT license
>
> There is no 'MIT' license: MIT has released software under various licenses. 


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

> Could you use the names from https://www.gnu.org/license/license-list.html?
>
> [reordered]


cryptopp/: #boost
dht/: #Expat
expat/: #Expat
miniupnpc/: #ModifiedBSD
npth/: #LGPLv2.1
openssl/: #OpenSSL (current version), #apache2 (next version)
portaudio/: #Expat
qsimphone/icons/qdarkstyle.qss, qsimphone/icons/qdarkstyle/: #Expat
qsimphone/resources/ip*.bin: #ccby
qtbase/: #LGPLv2.1
qtsingleapplication/: #ModifiedBSD
speex/, speexdsp/: #ModifiedBSD
udev/libudev/: #LGPLv2.1
build/rlink/: #RPSL / #GPLv2
build/patch.py: #Expat
build/uudecode.pl: #PublicDomain

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.

> > efence/: GPL2
>
> Irrespectively of other possible considerations: if you include it into your tarball, you effectively make it a part of your package, and in any case, you are responsible for it.  At the extreme: we don't want Savannah to distribute tarballs including proprietary software no matter how it's referred to, do we?
>
> So that part is GPLv2-only.  Savannah requirement is, basically, compatibility with GPLv3 and all later versions.


Of course we do not. I'm not sure why GPL2 isn't compatible with GPL3 but to make it simple, we will remove efence/ from the source tree.

> > qsimphone/resources/ip*.bin: Creative Commons Attribution 4.0 International
> > License
> > https://db-ip.com/db/lite.php
>
> This needs further discussion: is CC BY 4.0 LGPL-compatible?


First of all, we do not know how and why these people claim copyright over the list of the world's IP addresses, which is public knowledge. But since we got the data from their site, we gave credit for it and added the license we got from them.

As for your question, as non-lawyers we can't really be sure about these things. The license list link you sent shows the "CC BY 4.0" in green and says that it is compatible with all GPL versions. The "CC BY 4.0" itself says:

>          If You Share Adapted Material You produce, the Adapter's
>          License You apply must not prevent recipients of the Adapted
>          Material from complying with this Public License.


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?

> > qtbase/: LGPL 2.1
>
> If it's part of compiled binaries, then it makes a combined work with Simphone.  How that affects Simphone licensing depends on whether the work is a library or not---provided Qt is LGPLv2.1; however, the above URL mentions LGPLv2.1, LGPLv3, and GPLv3 (let alone their 'commercial' license).  Could you comment on this?


Yes, Qt is a library, or at least the parts of Qt which we use are libraries. When you configure and compile Qt5, it asks which license you want to use, or you can choose one by a command-line option, the choices being "commercial edition" and "open source edition". Simphone chooses the "open source" edition through its build scripts. As far as I know, multiple GNU licenses are included there so that the user of the Qt library (in this case, us) can decide which one to take. Here's a quote from the Qt documentation that explains their "open source licensing":

> Free and Open Source Software (FOSS) is software that comes with a license that gives users certain rights. In particular the right to use the software, to modify it, to obtain its source, and to pass it on (under the same terms). Notice that the term "free" is about rights, not money. The Free Software Foundation, the creator of the GNU GPL, speaks of free in this context as in "free speech", not as in "no cost".
>
> 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.
>
> Additionally, the examples included with Qt are provided under the terms of the Modified BSD License.
>
> The support of open source with the Open Source Versions of Qt has enabled large successful software projects like KDE to thrive, with thousands of developers around the world using open source versions of Qt at no cost to themselves.


> > 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") but I understand that to be on the safe side, we need to keep only udev/libudev and get rid of the unused code in udev/.

> > 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.


> 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:

  • /bin/sh (vary by distrubution)
  • python (if available on the system)
  • GNU autoconf
  • g++ (C and C++ compilers, may also be clang if that's what's installed on the system instead of gcc)
  • any other files the above compiler might use or/and link to without telling us (this usually means libgcc)
  • gmake (GNU Make)
  • patch (GNU Patch)
  • hg (mercurial) if available and if source code has been fetched from mercurial (not from the tarball)
  • perl5 (this isn't a direct dependency, but is used by the generated shar installer, and also by openssl)
  • uuencode, shar and tar (when generating the shar installer)
  • the shar installer also uses the "sudo" and "su" commands and the system's package manager, if necessary


Note the configure scripts use autoconf macros which, in turn, use many "unix" utilities too numerous to list, and furthermore they could change with any new version of autoconf or maybe even vary by distribution.

GNU/Linux, always link to:

  • libc (The GNU C library)
  • libm (part of libc, I believe)
  • libstdc++ (The GNU C++ library)
  • libpthread (GNU portable threads)
  • librt


GNU/Linux, optionally (if available and configured by default or otherwise) link to:

  • libdl
  • libpth, libboundscheck, libefence (these can be used only if the user has specifically so requested)
  • libasound (ALSA sound library)
  • libossaudio (OSS sound library)
  • libXss (X11 screen saver library) and libX11
  • libxcb and libxcb-keysyms (used directly only if the user has specifically so requested, but otherwise used by Qt5)


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.

Windows: mingw-w64 (this includes the GNU Compiler Toolchain, and other libraries and utilities) as provided and used by Qt5 is also used by Simphone directly. This is used mostly at compile-time; we link statically only to libgcc, libc, libstdc++ and additionally use a few DLL files that are part of the OS to call various windows functions, including: ws2_32.dll, gdi32.dll, ole32.dll, oleaut32.dll, shell32.dll, comdlg32.dll, shlwapi.dll, iphlpapi.dll, mpr.dll, winmm.dll. The DLL files are obviously "non-free", along with the rest of the OS.

simphone <simphone>
Sat 26 Oct 2024 05:24:17 PM UTC, comment #3: 


> We have updated the files in our tarball (in the simcore/, qsimphone/, build/
> and doc/ subdirectories, and at the top-level) with copyright and license
> notices to hopefully be compliant with these GNU requirements.


Thank you!

Your package is quite large, and the licensing situation isn't very simple, so a more detailed discussion is needed.

> For the patches/ subdirectory, added an explanation to patches/PATCHES.txt
> that the copyright of the diff files belongs to the original copyright
> holders.


My idea of copyright assignment is different.  I believe a copyright assignment is a legal paper where all affected persons and entities are named explicitly and unequivocally, and of course aware of the assignment.

Generally, who are copyright holders of your package, and how do they co-ordinate their copyrights?

Then, the diff files are text files, they should include copyright and license notices themselves.

> To explain the copyright situation of non-text and automatically generated
> files, added README.txt files to the following subdirectories:
> qsimphone/icons,


All files should be listed in README explicitly; if they aren't, it's too easy to get the things wrong when any new files are added.

> qsimphone/flags,


When files are in public domain, a brief note recording the authors, and anything else relevant is desirable,

https://www.gnu.org/prep/maintain/html_node/Non_002dFSF_002dCopyrighted-Package.html

> qsimphone/resources


countries.txt and creative-commons.txt are text files; they should include legal notices themselves.

> 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.

> cares/: MIT license


There is no 'MIT' license: MIT has released software under various licenses.  Could you use the names from https://www.gnu.org/license/license-list.html?

[reordered]

> miniupnpc/: BSD license

...

> speex/, speexdsp/: BSD-style license


Likewise, there is no "BSD" license (and of course "BSD-style license" is a too vague term for our purposes).  There are several free software licenses with "BSD" in their name; some of them are GPL-compatible, other are not.

https://www.gnu.org/licenses/bsd.html

> efence/: GPL2
> Note this is a windows port of a GNU library. It is not part of Simphone by
> default, neither at compile time nor at any other time. Still it sits in the
> source code archive so that developers can optionally enable memory debugging
> on windows just as they already can on GNU/Linux.


Irrespectively of other possible considerations: if you include it into your tarball, you effectively make it a part of your package, and in any case, you are responsible for it.  At the extreme: we don't want Savannah to distribute tarballs including proprietary software no matter how it's referred to, do we?

So that part is GPLv2-only.  Savannah requirement is, basically, compatibility with GPLv3 and all later versions.

> qsimphone/resources/ip*.bin: Creative Commons Attribution 4.0 International
> License
> https://db-ip.com/db/lite.php


This needs further discussion: is CC BY 4.0 LGPL-compatible?

> qtbase/: LGPL 2.1
> https://www.qt.io/faq/tag/qt-open-source-licensing
>
> Note Qt is not part of the source tree, but is part of compiled Simphone
> binaries.


If it's part of compiled binaries, then it makes a combined work with Simphone.  How that affects Simphone licensing depends on whether the work is a library or not---provided Qt is LGPLv2.1; however, the above URL mentions LGPLv2.1, LGPLv3, and GPLv3 (let alone their 'commercial' license).  Could you comment on this?

> udev/libudev/: LGPL 2.1
> https://github.com/mcatalancid/libudev/blob/1.8.2/src/COPYING
>
> Note this is not the official link. The latest udev/libudev has been
> integrated into systemd. But the version in our source tree has a GPL2 udev
> and an LGPL libudev inside (as the above link also shows), whereas only
> libudev is used by Simphone; the rest of the top-level udev code is there only
> to provide the original source structure for reference. If this would be a
> problem, we could delete everything except for udev/libudev. Libudev is needed
> for audio device hotplug detection under GNU/Linux.


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.

> 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+?

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?

Ineiev <ineiev>
Site Administrator
Sat 26 Oct 2024 02:28:03 AM UTC, comment #2: 

We have updated the files in our tarball (in the simcore/, qsimphone/, build/ and doc/ subdirectories, and at the top-level) with copyright and license notices to hopefully be compliant with these GNU requirements.

For the patches/ subdirectory, added an explanation to patches/PATCHES.txt that the copyright of the diff files belongs to the original copyright holders.

To explain the copyright situation of non-text and automatically generated files, added README.txt files to the following subdirectories: qsimphone/icons, qsimphone/flags, qsimphone/resources and build/config-win32.

Added GFDL.html to the doc/ subdirectory and links to it inside all html files in that directory. Also added copyright/copying notices to all txt "documentation" files.

If there is any omission or misunderstanding, please let us know, so it can be fixed. You can find the new tarball here:

http://www.simphone.org/0.9.3/simphone-src-0.9.3-a1.tar.gz

Following is the list of dependency licenses that you requested:

cares/: MIT license
https://c-ares.org/license.html

cryptopp/: boost license, but all individual files supposed to be in the public domain
https://github.com/weidai11/cryptopp/blob/master/License.txt

dht/: MIT license
https://github.com/jech/dht/blob/master/LICENCE

efence/: GPL2
Note this is a windows port of a GNU library. It is not part of Simphone by default, neither at compile time nor at any other time. Still it sits in the source code archive so that developers can optionally enable memory debugging on windows just as they already can on GNU/Linux. I am unable to provide a link, because the site it used to be hosted on no longer exists on the Internet; the license text is available as efence/COPYING. If any of this is a problem, it can be removed from the source tree and done with.

expat/: MIT (?) license
https://github.com/libexpat/libexpat/blob/master/expat/COPYING

miniupnpc/: BSD license
https://github.com/miniupnp/miniupnp/blob/master/miniupnpc/LICENSE

npth/: LGPL 2.1
https://gnupg.org/ftp/gcrypt/npth/npth-1.7.tar.bz2

openssl/: Apache license
https://github.com/openssl/openssl/blob/master/LICENSE.txt

Note openssl version 1.1.1 in our source tree still uses their old OpenSSL/SSLeay license, but we are going to update to the new openssl version for the next Simphone release, and that one has an Apache license.

portaudio/: MIT (?) license
https://www.portaudio.com/license.html

qsimphone/icons/qdarkstyle.qss, qsimphone/icons/qdarkstyle/: MIT license

Note the file was taken from the Internet, there is no official primary link that we know of, but copyright notice and license text are inside the file.

qsimphone/resources/ip*.bin: Creative Commons Attribution 4.0 International License
https://db-ip.com/db/lite.php

qtbase/: LGPL 2.1
https://www.qt.io/faq/tag/qt-open-source-licensing

Note Qt is not part of the source tree, but is part of compiled Simphone binaries. None of the "third party" Qt components are part of Simphone binaries, so their licenses are irrelevant (only the "qtbase" license might be relevant)

qtsingleapplication/: BSD license (embedded in all source files)
https://github.com/qtproject/qt-solutions/tree/master/LICENSES

speex/, speexdsp/: BSD-style license
https://www.xiph.org/licenses/bsd/speex
https://www.speex.org

udev/libudev/: LGPL 2.1
https://github.com/mcatalancid/libudev/blob/1.8.2/src/COPYING

Note this is not the official link. The latest udev/libudev has been integrated into systemd. But the version in our source tree has a GPL2 udev and an LGPL libudev inside (as the above link also shows), whereas only libudev is used by Simphone; the rest of the top-level udev code is there only to provide the original source structure for reference. If this would be a problem, we could delete everything except for udev/libudev. Libudev is needed for audio device hotplug detection under GNU/Linux.

build/rlink/: RCSL/RPSL/GPL2
Unable to provide a link, because "RealNetworks" has removed the source code from their website. The texts of their licenses are available in the build/rlink directory inside the source tree. The rlink script is used by the simphone compilation process on windows as a substitute for the missing --gc-sections option of GNU ld.

build/makedepend/: X11 license
https://cgit.freedesktop.org/xorg/util/makedepend/tree/COPYING?h=makedepend-1.0.5

build/patch.py: MIT license
https://github.com/techtonik/python-patch/blob/master/doc/LICENSE

build/uudecode.pl: public domain

Note this script was posted to UseNET in the year 1995. The Simphone shar installer calls it to extract uuencoded binary resources (icons).

simphone <simphone>
Thu 24 Oct 2024 06:57:17 AM UTC, comment #1: 

Please list your depedencies in more details, with exact license versions of each dependency, preferably with a link to the page where the licensing conditions are declared.

Please make sure that all copyrightable files in your tarball have valid copyright and license notices. (Note that the documentation should be released in an FDL-compatible way, https://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html#License-Notices-for-Other-Files https://www.gnu.org/prep/maintain/html_node/License-Notices-for-Documentation.html#License-Notices-for-Documentation)

Ineiev <ineiev>
Site Administrator
Thu 24 Oct 2024 04:01:46 AM UTC, original submission:  

A new group has been registered at Savannah.
This group will remain inactive until a site admin approves
or discards the registration.


Registration Administration


Approving or discarding the registration must be done using the specific
Group administration page, accessible only to site
administrators logged in as superusers.

Registration Details


  • Name: simphone
  • System Name:  simphone
  • Type: non-GNU software and documentation
  • License: GNU Lesser General Public License (There aren't any hidden commercial features, and no promotion of non-free software. We chose to also support non-free operating systems only because they are popular and are already supported by the GNU toolchain, so it was easy to do.


But any user who runs Simphone on Windows 10 or newer receives an initial warning that their OS includes spyware.
)




Description:

Simphone is a secure decentralized instant messager, which implements chat messages, file transfer and audio calls.

It compiles and runs on GNU/Linux and other free operating systems, and on a couple of non-free ones, by using GNU tools (g++, gnu make and autoconf). Released binaries are easily reproducible from the source code, so they are provably guaranteed to be backdoor-free. Additionally, there is a self-extracting shar.gz file, which provides one-step compilation on any free operating system.

The implementation supports 256-bit cryptographic security with perfect forward secrecy, double authentication, trust on first use and optional voice verification of contacts. The code is divided into a core library, written in C and a GUI written in C++. The core library has a documented API.

The features of Simphone are too numerous to list in 20 lines, so for further information perhaps you could have a quick look into our documentation (available in the doc subdirectory inside the source code archive).



Other Software Required:

All media files (icons) are original (non-derived) work and subject to LGPL along with the rest of the source code. The only external dependency (other than the GNU compiler toolchain and GNU standard libraries) is Qt5, which is also free (LGPL and other free licenses): www.qt.io

There are a few small libraries as internal dependencies (all LGPL-compatible), which are packaged with the Simphone source code. This is necessary mostly because important security patches to these libraries have been added by us and applied there.



Other Comments:

We have hosted Simphone on OSDN for the last four years, but unfortunately are no longer happy with that site. Would be glad if we could move it to Savannah. A mercurial repository would be needed.

If there are any questions or issues to resolve with the source code, we'd be happy to cooperate. There's a new version of Simphone coming soon and it won't be a problem to update a few more things with the release.



Tarball URL:

http://www.simphone.org/0.9.3/simphone-src-0.9.2.tar.gz


simphone <simphone>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ineiev (Posted a comment)
  • -email is unavailable- added by simphone (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-10-24 ineiev Assigned toNone ineiev
        StatusNone In Progress

    Back to the top

    Powered by Savane 3.14-04e1.
    Corresponding source code