Submitting copyright to FSF, and GPLv3? #23

Closed kaushalmodi closed 5 years ago

Hello,

Recently this discussion came up on Emacs help and Org mode mailing lists: https://lists.gnu.org/r/emacs-orgmode/2018-09/msg00110.html

Currently Org mode suggests users to download your awesome htmlize package from GitHub so that ox-html can export proper syntax highlighted code blocks.

While I don't mind that (and I already use htmlize), there are some people who wouldn't prefer that?

Do you have an objection to assigning your copyright to FSF? With that in place, this package can be a part of Emacs/Org mode, and resolve the issue discussed in that mailing list thread.

If interested, please email assign@gnu.org for instructions with this assignment process (I've done it, and it's very easy).

I'm not sure I understand the context. The mail subject mentions depending on non-free platform, but htmlize is free software. Also, ELPA is not the only place to get htmlize from - one can get it from github directly, and it will work just fine. Reading through the rest of the discussion makes it clear that many other developers are equally mystified with this request.

To respond to the question: I appreciate the offer of incorporating htmlize into Emacs, but I am not interested in donating it at this point. The linked discussion is an excellent example of why I do not want to do that.

If there is anything else I can do to make htmlize more accessible to Org mode users, please let me know and I'll do my best to help.

I appreciate the offer of incorporating htmlize part of Emacs

Thanks for your reply. Just to note, you don't have to make htmlize part of Emacs core. htmlize can be a package in GNU Elpa too, and managing that shouldn't be too different than the pushes you do to this GitHub repo. The GNU Elpa version can mirror the GitHub version.

But you will still need to assign the copyright of this package to FSF to put the package on GNU Elpa.

I am not interested in assigning htmlize copyright to the FSF, thank you.

@hniksic Would you be willing to mirror the git repo onto GNU Savannah, or perhaps nongnu.org? That way it could be accessed from a platform that the FSF would be happy with, and the Org documentation could be adjusted to refer to the mirror.

Thanks for your work on htmlize over the years. It's an essential companion package to Org.

@alphapapa That sounds good, and having an additional mirror is useful in its own right.

Are you volunteering to set up the mirror, or do you need me to take action?

@alphapapa @hniksic As Amin Bandali suggested on that same thread, the new Org mode code organization allows Org packages to be hosted on the same Gogs server where the Org source is hosted.

I think it would be better to mirror this code there. You don't need to assign copyright to submit your code there.

@hniksic you just need to create an account on that Gogs instance: https://code.orgmode.org/.

Create a repo there and push to that new remote too (now your local git repo's config file will contain 2 pushURLs. Let me know if you need more details). You then just push your code to GitHub as you always do, and the code gets pushed to the second pushURL too. So there this initial brief setup, the mirroring will keep on happening without any manual interference.

Create a repo there and push to that new remote too (now your local git repo's config file will contain 2 pushURLs. Let me know if you need more details). You then just push your code to GitHub as you always do, and the code gets pushed to the second pushURL too.

@kaushalmodi Does that mean that my local git client would be responsible for pushing to two different repos at once?

Does that mean that my local git client would be responsible for pushing to two different repos at once?

Yes, the client (or even the CLI git) will do those double pushes based on the config. Do you see that as an issue?

Your git push flow will not change a bit, just that identical pushes will happen to 2 remotes in the background.

Yes, the client (or even the CLI git) will do those double pushes based on the config. Do you see that as an issue?

@kaushalmodi It means every contributor would need to have the exact same setup, or the repos will fall out of sync. I would go for an automatic solution where the master repo is the one at github (or whichever happens to be used for development at the time), and the mirrors are read-only and automatically synchronizing. This kind of setup is fairly standard for mirroring.

I would go for an automatic solution where the master repo is the one at github (or whichever happens to be used for development at the time), and the mirrors are read-only and automatically synchronizing. This kind of setup is fairly standard for mirroring.

Ideally, I think that could be done with a git hook on the server side, but being GitHub, I guess that isn't possible.

I guess all we really need is a cron job running somewhere that fetches this repo and force-pushes to the mirror. I wonder if anything like that is possible on Gogs. I see at https://gogs.io/docs/advanced/configuration_cheat_sheet that there are settings for cron, including "Cron - Update Mirrors: Cron syntax for scheduling update mirrors". I don't know exactly what that is, but maybe it would help.

@alphapapa

Mirroring is another way. Adding additional pushURLs is more like real-time mirroring.

@hniksic

It means every contributor would need to have the exact same setup, or the repos will fall out of sync.

I didn't follow.. Only you would have commit rights on the repo you create on the Org mode Gogs. And about repos falling out of sync, you can choose to accept PR's from only GitHub, or only Gogs, or both. Let's assume that you accept PR's from only GitHub. Then the flow is simple:

Accept PR on GitHub.
Pull from GitHub to your local repo
Push (this will push the pulled commit to GitHub (doesn't matter here as that new commit is already there) and Gogs (that new commit will get added here).

I would go for an automatic solution where the master repo is the one at github (or whichever happens to be used for development at the time), and the mirrors are read-only and automatically synchronizing. This kind of setup is fairly standard for mirroring.

If you consciously don't merge PR's directly on Gogs, the flow is simple as above. If not, things are possible, but you need to manage 2 remotes actively from your local git repo.

At the moment, @aminb has created a mirror on Org mode Gogs: https://code.orgmode.org/aminb/emacs-htmlize. So you can choose to leave it like that, or setup up a mirror remote under your username. If you let Amin's mirror be the "official mirror", we can let the Org mode devel team know about that in that mailing list thread.

@kaushalmodi By other contributors I was referring to possible other people with push access to the htmlize github repo. Even if that were to remain just me, I am not interested in a system that requires me to push to two repos.

However, the mirror you linked to looks great. What do I need to do to make it an "official" mirror?

What do I need to do to make it an "official" mirror?

By "official", I meant to say if you acknowledged and approved that mirror. As that is the case, I'll let this be known in that thread. Thanks.

If the mirror is official, then it probably deserves a mention it in the readme or in htmlize.el itself.

@alphapapa Is the mirror at Gogs of the kind you've been referring to in the last paragraph of your comment ("I guess all we really need is a cron job...")?

@aminb Do you intend to keep the mirror running? If so, is it ok if I mention it in htmlize?

@alphapapa @kaushalmodi Moving the discussion about this to the new issue created to track the creation of a mirror.

Is the mirror at Gogs of the kind you've been referring to in the last paragraph of your comment ("I guess all we really need is a cron job...")?

Yes.

@aminb Do you intend to keep the mirror running? If so, is it ok if I mention it in htmlize?

@hniksic Yes to both :)

hniksic / emacs-htmlize

Submitting copyright to FSF, and GPLv3? #23