taskSavannah Administration - Tasks: task #15583, Submission of Mu (Miscellaneous...

 
 

task #15583: Submission of Mu (Miscellaneous Utilities)

Submitted by:  Asher Gordon <asdago>
Submitted on:  Tue 31 Mar 2020 05:16:12 PM UTC  
 
Should Start On:  Tue 31 Mar 2020 04:00:00 AM UTC Should be Finished on:  Fri 10 Apr 2020 04:00:00 AM UTC
Category:  Project Approval Priority:  5 - Normal
Status:  Done Privacy:  Public
Percent Complete:  0% Assigned to:  Ineiev <ineiev>
Open/Closed:  Closed Effort:  0.00

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Sat 16 May 2020 06:16:57 PM UTC, comment #36: 

Indeed, you make a good point. I've suggested on the mailing list that they update the documentation. In any case, if you have further input, I think you should reply on the mailing list. This isn't the best place to discuss this. :-)

Asher Gordon <asdago>
Fri 15 May 2020 05:21:05 PM UTC, comment #35: 

> It still seems to me that Gnulib should either remove the modules or mention the issues in the documentation...


Definitely not remove: these modules are valid for two of the three approaches described in https://www.gnu.org/software/gnulib/manual/html_node/VCS-Issues.html ("In projects which commit all source files, whether generated or not, into their VCS, the gnulib-tool generated files should all be committed." and "Some projects take a “middle road”: they do commit Gnulib source files as in the first approach, but they do not commit other derived files"). I've also suggested the possibility of committing a set of specific modules.

Ineiev <ineiev>
Site AdministratorIn charge of this item.
Fri 15 May 2020 04:55:45 PM UTC, comment #34: 

comment #33:

> That documentation is evidently incomplete.  Those files are for including in Texinfo documentation.  According to GPL Howto, the package should come with a copy of the license in the text format.


Yes, I guess that makes sense. It still seems to me that Gnulib should either remove the modules or mention the issues in the documentation...

> Yes, https://www.gnu.org/licenses/gpl-faq.html#WhyMustIInclude and https://www.gnu.org/licenses/gpl-faq.html#NoticeInSourceFile


I see. Thanks for the information.

> Thank you, approving.


Great, thanks! Sorry it took so long. :-)

Asher Gordon <asdago>
Fri 15 May 2020 06:02:46 AM UTC, comment #33: 

> It doesn't explicitly mention license texts though. Since license texts rarely change, I don't think the license modules would be useful even for developers that prefer to include generated files in VCS. I think it would be better to simply copy the license files. At the very least, these issues should be mentioned in the documentation. In fact, the Gnulib manual has a section describing the license modules, but it doesn't mention these issues.


That documentation is evidently incomplete.  Those files are for including in Texinfo documentation.  According to GPL Howto, the package should come with a copy of the license in the text format.

> I guess it's to ensure that every developer (and users that check out from git) can get a copy of the license, even if they don't have Gnulib installed?


Yes, https://www.gnu.org/licenses/gpl-faq.html#WhyMustIInclude and https://www.gnu.org/licenses/gpl-faq.html#NoticeInSourceFile

> Well I included the license files in the tarball I attached in my last message.


Thank you, approving.

Ineiev <ineiev>
Site AdministratorIn charge of this item.
Thu 14 May 2020 04:35:39 PM UTC, comment #32: 

comment #31:

> To tell the truth, I didn't see anything in Gnulib documentation that would suggest that a snapshot of the used modules shouldn't be tracked by the VCS of the packages that use them, or that a copy of all modules should be either included or excluded from the VCS at once.


Take a look at (gnulib) VCS Issues. Here's an excerpt:

> In principle, all files created by 'gnulib-tool', except 'gnulib-cache.m4', can be treated like generated source files, like for example a 'parser.c' file generated from 'parser.y'.
> [...]
> In projects which customarily omit from their VCS all files that are generated from other source files, none of these files and directories are added into the VCS.


It doesn't explicitly mention license texts though. Since license texts rarely change, I don't think the license modules would be useful even for developers that prefer to include generated files in VCS. I think it would be better to simply copy the license files. At the very least, these issues should be mentioned in the documentation. In fact, the Gnulib manual has a section describing the license modules, but it doesn't mention these issues.

If you want to continue this discussion, you might want to reply to the message I posted on the Gnulib mailing list. (If you do, you might want to copy this discussion for context.)

> In any case, perhaps that isn't the rightest side to look at, and one would better find out why and when those texts should be included in the first place.


I guess it's to ensure that every developer (and users that check out from git) can get a copy of the license, even if they don't have Gnulib installed? Well I included the license files in the tarball I attached in my last message.

Asher Gordon <asdago>
Thu 14 May 2020 08:17:21 AM UTC, comment #31: 

To tell the truth, I didn't see anything in Gnulib documentation that would suggest that a snapshot of the used modules shouldn't be tracked by the VCS of the packages that use them, or that a copy of all modules should be either included or excluded from the VCS at once.

In any case, perhaps that isn't the rightest side to look at, and one would better find out why and when those texts should be included in the first place.

Ineiev <ineiev>
Site AdministratorIn charge of this item.
Tue 12 May 2020 05:05:31 PM UTC, comment #30: 

comment #29:

> comment #28:
> > You also haven't told me whether I need to include the documentation licenses in version control, even though I'm using Gnulib for them. I'd be happy to do that, just let me know.
>
> I think you ask a basic question again.  It seems to me that you should be able to answer such questions yourself.  Can't you?


So I do need to include the licenses? The fact that Gnulib provides modules for them seemed to suggest otherwise. But anyway, I have included them; see the attached tarball.

I think I might suggest on the Gnulib mailing list that they remove the license modules, but keep the license files. It seems that the modules should never be used!

(file #49061)

Asher Gordon <asdago>
Tue 12 May 2020 09:41:17 AM UTC, comment #29: 

comment #28:[reordered]

> In the meantime, I've implemented a test suite using Autotest (in the 'tests' subdirectory). I'm fairly certain it complies to Savannah's requirements, but I've attached an updated tarball in case you want to take a look anyway.


Thank you!

> You also haven't told me whether I need to include the documentation licenses in version control, even though I'm using Gnulib for them. I'd be happy to do that, just let me know.


I think you ask a basic question again.  It seems to me that you should be able to answer such questions yourself.  Can't you?

Ineiev <ineiev>
Site AdministratorIn charge of this item.
Sat 09 May 2020 08:43:08 PM UTC, comment #28: 

Hey,

Any chance of this getting accepted soon? I'm pretty sure it complies to Savannah's requirements. If it doesn't, please let me know so I can fix it. You also haven't told me whether I need to include the documentation licenses in version control, even though I'm using Gnulib for them. I'd be happy to do that, just let me know.

In the meantime, I've implemented a test suite using Autotest (in the 'tests' subdirectory). I'm fairly certain it complies to Savannah's requirements, but I've attached an updated tarball in case you want to take a look anyway.

Thanks.

(file #49052)

Asher Gordon <asdago>
Mon 04 May 2020 03:21:12 AM UTC, comment #27: 

I added a feature to automatically capture output from the example programs to be included in the documentation, so I don't have to worry about updating it manually. The scripts to generate the output in Texinfo format are licensed under the GPLv3+. I also added a bit more text to doc/examples/README, so I figured it wouldn't hurt to add a license notice there too. And I also added a bootstrap.sh, under the GPLv3+.

I'm pretty sure all these files conform to Savannah's requirements (although there are some pretty dirty hacks ;-) ), but I attached the updated tarball so you can make sure they actually do conform.

comment #26:

> Since I'm already going to use Gnulib, I thought I might as well use the gpl-3.0 and fdl-1.3 modules (which provide those licenses in Texinfo format). But then I would not put these licenses under version control. Would that be acceptable, or must the licenses be available under version control as well?


You'll notice that the GPLv3 and FDLv1.3 Texinfo files are missing from the updated tarball. That is because, like I said, I am using the Gnulib modules, so it doesn't really make sense to also put them under version control. But if the license files are required to be present, even under version control, then I can put them back under version control.

(file #48995)

Asher Gordon <asdago>
Thu 30 Apr 2020 05:34:19 PM UTC, comment #26: 

I'm currently working on a feature for which I need Gnulib (sig2str). Since I'm already going to use Gnulib, I thought I might as well use the gpl-3.0 and fdl-1.3 modules (which provide those licenses in Texinfo format). But then I would not put these licenses under version control. Would that be acceptable, or must the licenses be available under version control as well? They would still be available in the distribution tarballs.

Also, if the licenses are required to be available under version control, isn't it kind of paradoxical for Gnulib to offer them?

Asher Gordon <asdago>
Wed 29 Apr 2020 02:44:39 AM UTC, comment #25: 

comment #24:

> Now, Savannah Hosting Requirements says explicitly that all source files should include license notices; how can files like doc/examples/format.c comply to that? They contain neither copyright nor license notices.


Ah, I thought that was OK because I had a README in the examples directory. Sorry for that little misunderstanding. The only reason I didn't add license notices is because I was to lazy to implement a way to remove them when the examples are included in the documentation.

But I implemented that now (based on the way GNU Libc does it) and added license notices to each example file. See the attached tarball.

(file #48964)

Asher Gordon <asdago>
Tue 28 Apr 2020 05:52:01 PM UTC, comment #24: 

Yes, Savannah Hosting Requirements https://savannah.gnu.org/maintenance/HowToGetYourProjectApprovedQuickly/ and the texts it links to.

Now, Savannah Hosting Requirements says explicitly that all source files should include license notices; how can files like doc/examples/format.c comply to that? They contain neither copyright nor license notices.

Ineiev <ineiev>
Site AdministratorIn charge of this item.
Tue 28 Apr 2020 02:34:58 AM UTC, comment #23: 

comment #22:

> comment #21:
> > As for my project, is the latest tarball acceptable?
>
> I wonder what passages in our documentation suggest it may be.


You mean the Savannah Hosting Requirements? I believe my project follows those. The only thing that it might not comply to is the Project naming section. But since the full name is "Mu (Miscellaneous Utilities)" I think that's OK?

Asher Gordon <asdago>
Mon 27 Apr 2020 05:41:03 PM UTC, comment #22: 

comment #21:

> comment #20:
> > Please file a bug report against glibc.
> Done.


Thank you!

> As for my project, is the latest tarball acceptable?


I wonder what passages in our documentation suggest it may be.

Ineiev <ineiev>
Site AdministratorIn charge of this item.
Sun 26 Apr 2020 06:25:56 PM UTC, comment #21: 

comment #20:

> Please file a bug report against glibc.

Done.

As for my project, is the latest tarball acceptable?

Asher Gordon <asdago>
Sun 26 Apr 2020 04:40:20 PM UTC, comment #20: 

As far as I understand, the FDL may apply to those examples when they are included in the manual; I admit, though, that this leaves place for ambiguity, and there may be bugs, e.g. some files miss the notices.  Please file a bug report against glibc.

Ineiev <ineiev>
Site AdministratorIn charge of this item.
Sun 26 Apr 2020 01:38:36 AM UTC, comment #19: 

comment #16:

> I've updated the license notice to allow distribution under the GFDL as well.


Actually, I was just looking at the source for the GNU Libc documentation, and it looks to me like the examples are available only under the GPL, not the FDL.

Quoting the README:

> While the manual itself is licensed under the terms of the GNU Free Documentation License, you can use these source files on their own under the terms of the GNU General Public License as published by the Free Software Foundation; version 2 of the License, or (at your option) any later version.


And the license notice in the individual example files only have the GPL license notice, not the FDL one. Surely if GNU Libc licenses them this way, they're compatible with Savannah's requirements? Or am I missing something?

Or perhaps the GNU Libc documentation is incompatible with Savannah and it should be fixed?

Asher Gordon <asdago>
Tue 21 Apr 2020 06:44:48 PM UTC, comment #18: 

comment #17:

> What do you think about them yourself?


Well doc/examples/.dir-locals.el seems pretty trivial, but I guess it doesn't hurt to put a license notice in .gitignore. See the attached tarball.

(file #48896)

Asher Gordon <asdago>
Tue 21 Apr 2020 08:14:01 AM UTC, comment #17: 

comment #16:

>
> Also, does the .gitignore file need a license notice? And how about doc/examples/.dir-locals.el?


What do you think about them yourself?

Ineiev <ineiev>
Site AdministratorIn charge of this item.
Sun 19 Apr 2020 09:00:05 PM UTC, comment #16: 

comment #15:

> In your latest tarball, the examples don't comply.


I've updated the license notice to allow distribution under the GFDL as well.

Also, does the .gitignore file need a license notice? And how about doc/examples/.dir-locals.el?

(file #48878)

Asher Gordon <asdago>
Sun 19 Apr 2020 05:40:33 PM UTC, comment #15: 

In your latest tarball, the examples don't comply.

No, Savannah doesn't support Git web page repositories.

Ineiev <ineiev>
Site AdministratorIn charge of this item.
Sat 18 Apr 2020 07:36:53 PM UTC, comment #14: 

Yes, I will comply. And like I mentioned before, I'd like the .git/description to read: "Mu (Miscellaneous Utilities) -- a general purpose convenience library" (without the quotes, of course). And if possible, I'd like the web pages repository to use git, but I don't know if that's possible yet.

Thanks for accepting my package.

Asher Gordon <asdago>
Sat 18 Apr 2020 05:57:12 PM UTC, comment #13: 

If you are sure you'll comply with Savannah hosting requirements, let us proceed.

Ineiev <ineiev>
Site AdministratorIn charge of this item.
Tue 14 Apr 2020 07:09:24 PM UTC, comment #12: 

Also, just to clarify, when I said "I'd like to prohibit the inclusion of my documentation with non-free documentation [...]" I meant that ideally I would do that, but since it goes against Savannah's requirements I wouldn't. And since the GFDL doesn't allow converting regular sections into invariant ones, I could release under the GPL and GFDL without any changes or special conditions.

So keeping that in mind, you might reconsider hosting my project. But again, if you'd rather not, that's fine, but I thought you might not have understood the situation fully.

Asher Gordon <asdago>
Tue 14 Apr 2020 06:33:52 PM UTC, comment #11: 

OK, thanks for your help.

Asher Gordon <asdago>
Tue 14 Apr 2020 07:38:30 AM UTC, comment #10: 

Indeed, it seems to me that the situation is too complicated to control.

Ineiev <ineiev>
Site AdministratorIn charge of this item.
Tue 14 Apr 2020 12:56:55 AM UTC, comment #9: 

Hello,

It's been a week with no update. Is my new tarball with the dual license acceptable? If you'd rather not host my project on Savannah because of licensing issues, that's fine but please let me know.

Thanks.

Asher Gordon <asdago>
Mon 06 Apr 2020 09:06:13 PM UTC, comment #8: 

Also, I assume it's OK to keep the examples under the GPL only (not GFDL)? Should I add a notice to doc/mu.texi explaining that the examples are only released under the GPL, or is the README in doc/examples/ enough?

Asher Gordon <asdago>
Mon 06 Apr 2020 08:44:39 PM UTC, comment #7: 

comment #6:

> You could consider releasing the documentation under the GPL and the GFDL in parallel.


Well, it's really the invariant sections that make the GFDL non-free. Preferably, I'd like to prohibit the inclusion of my documentation with non-free documentation such as the GFDL with invariant sections. However, I'd be willing to compromise, as long as none of the sections in my documentation can be made invariant when redistributed. I don't believe the GFDL allows this, as stated in Section 4, paragraph 3 (emphasis added):

> If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. [...]


So I have decided to do as you've suggested, and release under a dual license. Please see the attached tarball.

(file #48776)

Asher Gordon <asdago>
Mon 06 Apr 2020 08:52:55 AM UTC, comment #6: 

comment #5:

>
> I want the GNU project to be able to use my software, I just think that the GFDL is too restrictive, and the GPL really seems the only other choice that provides strong copyleft (which, I guess, makes it incompatible with other licenses by its very nature).


You could consider releasing the documentation under the GPL and the GFDL in parallel.

Ineiev <ineiev>
Site AdministratorIn charge of this item.
Sun 05 Apr 2020 08:58:06 PM UTC, comment #5: 

comment #4:

> Thank you; please tell when your packages are ready be removed from Savannah.


Well my other packages aren't currently conflicting with the GNU project, so I'd like to keep them on Savannah for now if you don't mind. Of course, I'll let you know if I ever do decide to write documentation for those projects that is incompatible with the GFDL (in which case I will move them to another hosting site).

I want the GNU project to be able to use my software, I just think that the GFDL is too restrictive, and the GPL really seems the only other choice that provides strong copyleft (which, I guess, makes it incompatible with other licenses by its very nature).

Asher Gordon <asdago>
Sun 05 Apr 2020 07:32:57 PM UTC, comment #4: 

Thank you; please tell when your packages are ready be removed from Savannah.

Ineiev <ineiev>
Site AdministratorIn charge of this item.
Sat 04 Apr 2020 04:51:36 PM UTC, comment #3: 

comment #2:

> The bottom line is: if our licensing policies conflict with your philosophy, you shouldn't host your software on Savannah.


I didn't realize that the GPL was incompatible with the GFDL. I guess I'll use another hosting site.

Thanks anyway for your help.

Asher Gordon <asdago>
Sat 04 Apr 2020 10:56:51 AM UTC, comment #2: 

> One more thing: The manual is licensed under GPLv3+ (because I don't agree with the FDL).


Savannah is a hosting platform for the GNU Project.  The GNU Project offers its resources to other packages in order to be able to copy code and documentation from them.  The GFDL is the license of the GNU Project for documentation, so when some manual is released incompatibly with the GFDL, the GNU Project can't use it.

The bottom line is: if our licensing policies conflict with your philosophy, you shouldn't host your software on Savannah.

Ineiev <ineiev>
Site AdministratorIn charge of this item.
Tue 31 Mar 2020 05:34:35 PM UTC, comment #1: 

Also, I forgot to mention: has there been any progress on sr #109001? Because, if possible, I'd like the web pages repository to use git.

Asher Gordon <asdago>
Tue 31 Mar 2020 05:16:12 PM UTC, original submission:  

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

Registration Administration

While this item will be useful to track the registration process,
approving or discarding the registration must be done using the specific Group Administration page, accessible only to site administrators,
effectively logged as site administrators (superuser):

Registration Details

  • Name: Mu (Miscellaneous Utilities)
  • System Name:  libmu
  • Type: non-GNU software and documentation
  • License: GNU General Public License v3 or later (Although I have checked "All my files include valid copyright notices" and "All my files include a license header", the example programs in doc/examples do not contain license headers. This is because they are included directly in the documentation, and I don't want to clutter the documentation with license notices.

Instead, I put a README in doc/examples which says that all examples are available under GPLv3+. Is that acceptable? I haven't written a license notice for the README itself, because the README is small enough that I don't think it needs one. Also, I want to avoid confusion by having two license notices in the README (one for the examples, one for the README itself).

Also, the ChangeLog is automatically generated from git commit history at distribution time, and the one in version control is just a stub. I don't think this needs a license notice?

One more thing: The manual is licensed under GPLv3+ (because I don't agree with the FDL). Since the manual is not a "program", I have replaced the word "program" with "manual" in the license notice. Since I include a copy of the GPL in the manual, I've also added a cross-reference to the section in which the GPL is included to the license notice. I hope I haven't broken any legal magic by doing these things?)


Description:

Mu is a general purpose convenience library, written in C. It provides functions which are useful for performing common tasks, such as parsing options or formatting text.

It also provides some compatibility functions, for extensions such as asprintf(), strchrnul(), etc. These functions call the ones provided by the system if they are available, since the system ones may be optimized.

Other Comments:

In my other projects I attached a distribution tarball. However, I realize that it's probably more convenient for you without all the generated files, so this time I've attached a 'git archive' tarball (it's also 13% of the size).

Also, the projects name is only two characters long, which is against the recommendations of Savannah. And I did find three other projects named "Mu" (guess I should've checked before I chose the name). However, my project can be distinguished by referring to it as "Mu (Miscellaneous Utilities)" (which is what I entered for the full name). So is that acceptable then?

Assuming that you do accept the name, I'd like the .git/description to read: "Mu (Miscellaneous Utilities) -- a general purpose convenience library" (without the quotes, of course).

Tarball URL:

https://savannah.nongnu.org/submissions_uploads/mu.tar.gz

Asher Gordon <asdago>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #49061:  mu.tar.gz added by asdago (119KiB - application/gzip - Re-add the documentation licenses)
file #49052:  mu.tar.gz added by asdago (100KiB - application/gzip - Implement a test suite using Autotest)
file #48995:  mu.tar.gz added by asdago (84KiB - application/gzip - Automatically capture the output of example programs)
file #48964:  mu.tar.gz added by asdago (88KiB - application/gzip - Add license notices to example files)
file #48896:  mu.tar.gz added by asdago (81KiB - application/gzip - Add a license notice to .gitignore.)
file #48878:  mu.tar.gz added by asdago (81KiB - application/gzip - Add dual license notice to doc/examples/README.)
file #48776:  mu.tar.gz added by asdago (81KiB - application/gzip - Tarball with GPL-GFDL dual licensed documentation.)

 

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 asdago (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-05-15 ineiev StatusIn Progress => Done
        Open/ClosedOpen => Closed
    2020-05-12 asdago Attached File- => Added mu.tar.gz, #49061
    2020-05-09 asdago Attached File- => Added mu.tar.gz, #49052
    2020-05-04 asdago Attached File- => Added mu.tar.gz, #48995
    2020-04-29 asdago Attached File- => Added mu.tar.gz, #48964
    2020-04-21 asdago Attached File- => Added mu.tar.gz, #48896
    2020-04-19 asdago Attached File- => Added mu.tar.gz, #48878
    2020-04-06 asdago Attached File- => Added mu.tar.gz, #48776
    2020-04-04 ineiev StatusNone => In Progress
        Assigned toNone => ineiev

    Back to the top


    Powered by Savane 3.5