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.gnuc...@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 > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
