[GNC-dev] GnuCash and Github

[john]

I don't think the silo effect is a big deal. The main impact is on transferring bugs and we gave that up when Gnome shut down its Bugzilla instance. Cross-project pull/merge requests make no sense, so I guess your complaint is that you can't use your Github account to submit a PR to e.g. Gtk because while there's a Gtk mirror on Github it doesn't take PRs, you have to get a Gnome LDAP account and make your MR (merge request, gitlab's name for pull request).

Based on what I see over at Gnome running a gitlab instance is a lot of work. Plus even with the Gnome Foundation's compute resources it frequently bogs down. I don't think we'd want to do that.

I'd never even heard of gitea or codeberg and I've encountered only one project on sourcehut. I wasn't terribly impressed.

We could switch the git mirror to Sourceforge, which would get us the code-browsing, though not as nice as GitHub's, and the merge requests. I don't know how the edit/discussion flow works there, but I bet it's not as nice as Github's either.

That leaves CI. Sourceforge doesn't provide it, so we'd have to set up our own instance of something; Jenkins used to be popular but I don't know if it's still considered the best. Regardless that's more time spent setting it up, securing, and maintaining it.

Regards,
John Ralls

> On Nov 18, 2022, at 9:15 AM, Geert Janssens <geert.gnucash at kobaltwit.be> wrote:
> 
> That's a good analysis of the situation.
> 
> I agree this is largely a legal issue to be solved by organisations like the SFC.
> 
> At a deeper level though I agree this could only have happened because OSS has allowed github to become such a golden cage for our projects in the first place. And this seems to happen over and over again.
> 
> It has become very hard to leave github because of the network effect. And I agree we can't make others not have a clone of the gnucash repo on github. That doesn't mean we can't make a statement by not hosting our own forks/clones there ourselves if we care enough.
> 
> I don't know if *I* care enough. I am concerned about these developments,  but at the same time I wouldn't want to add more infrastructure maintenance to our already limited time.
> 
> SFC suggested a few alternatives, either hosted (sourcehut, codeberg) or self-hosted (gitea, gitlab CE, sourcehut).
> 
> Codeberg is very similar to github, except for CI (which is currently in closed beta). So it offers much of what our users/contributors are already used to.
> I don't know about the others.
> 
> As a last semi-OT remark/rant, I think all the alternatives are missing a key piece - federation.
> 
> You either have a centrally hosted platform(codeberg.org,...), or you have completely isolated islands that happen to use the same software (think gitlab.gnome.org, gitlab.kitware.com,...)
> 
> The centrally hosted platforms will invariably lead to similar silo effects as github.com or gitlab.com if they become more successful. The islands on the other hand currently have no means of interaction or integration (like tracking an issue issue on another 'island's' tracker, forking to another 'island', creating pull requests across 'islands',...). So in both cases the very distributed nature of git is not brought up to the level of the web interfaces.
> 
> The social media landscape is in the same boat in fact, though federation may very slowly be getting a foot in the door with the recent twitter debacle and a fair number of users now start to experiment with Mastodon.
> 
> Regards,
> 
> Geert
> 
> Op zondag 13 november 2022 20:50:53 CET schreef john:
> > My number one use of GitHub, and IIRC the reason we mirrored it there in the
> > first place, is to refer to and reference code when communicating on these
> > lists, bug reports, and IRC. That's replaceable too by serving the repo
> > ourselves or moving the mirror back to Sourceforge.
> >
> > The fear is that Github's copilot will violate our author's copyrights by
> > copying sufficiently substantial sections of code into a non-GPL project,
> > stripping off the copyright and license in the process. I've seen claims
> > that this has already happened.
> >
> > In my completely non-legal opinion that makes every project that uses
> > CoPilot GPL and the FSF should be suing all of them to publish their source
> > code. But I think that's also true of any project whose developers read
> > Stack Overflow or search on the web for solutions to their coding problems.
> > The world has changed since the GPL was conceived and sharing source code
> > meant sending me a blank DECTape and a paid mailer or downloading a tarball
> > by anonymous FTP and code on the web--regardless of where--is findable by
> > web-searching for a function name, and even if we don't provide web access
> > someone else will. The GPL encourages that.
> >
> > Plus the bird has flown. Sure, we could take down our Github repo. That
> > won't affect the 673 forks, and some of those folks will get our code from
> > somewhere and keep their repos up to date.
> >
> > In fact it seems to me that the Software Freedom Conservancy is missing the
> > point: The problem with Copilot isn't that it's encouraging
> > proprietary-software developers to use open-source code in their projects.
> > Although the GPL requires that using GPL code turns the project into a GPL
> > one, most other FLOSS licenses don't. They require only that copyright
> > statements are preserved and Copilots failure to do so is the real problem.
> >  That's a matter for the courts; in order to get the matter before the
> > courts somebody has to sue Github. Filing those suits on behalf of their
> > client projects is the Software Freedom Conservancy's job, see
> > https://sfconservancy.org/copyleft-compliance/. Since they have a history
> > of suing over GPL compliance the boycott call suggests to me that they
> > think they'd lose, either on merit or just because Microsoft has a bigger
> > badder legal team. It's interesting that the FSF has nothing to say on
> > their own, just a few links to articles:
> > https://www.fsf.org/licensing/copilot.
> >
> > Regards,
> > John Ralls
>