GitHub - Floorp-Projects/Floorp-private-components: Official components code of Floorp Browser. Used for Floorp Official Build
github.com
Official components code of Floorp Browser. Used for Floorp Official Build - Floorp-Projects/Floorp-private-components

The repository for the previously private submodule is still called Floorp-private-components, though it’s public.

https://blog.ablaze.one/4125/2024-03-11/ is a maintainer’s official response to… Reddit, which crossposted me apparently. Hooray!

  • Aatube@kbin.melroy.orgOP
    1·
    9 months ago

    I also wonder which forks these are (should probably ask maintainers), but I do not get your point about Floorp or the three forks in the screenshot at all.

    why are they still up if they’re breaking license?

    Because they didn’t. Code was previously up under MPL, a permissive license

    Does your answer apply to fediverse server owners (eg Mastodon, Lemmy) whose premise is hosting an opinionated and branded instance

    I haven’t seen an instance that claims it doesn’t use e.g. Lemmy when it’s using it.

    • thesmokingman@programming.dev
      2·
      9 months ago

      If a repo is very popular, it should have a lot of forks. The higher the upstream popularity, the higher the downstream popularity. When a dev makes a claim that there are a ton of malicious forks stealing IP, we can vet that claim by looking at the forks that respect the upstream. Big projects have a big community with big forks with many stars. The popular downstreams drive traffic to the upstream.

      In this case, we have a couple hundred direct forks. That’s not a ton. Out of those, only three have stars. All of them only have one star. At face value, that could imply a few things: the repo is not very popular, the community is centralized around the upstream, or something else along those lines. Comparing this to other open source projects, our initial conclusion is that this is not a hugely popular repo and does not get a lot of development outside of its incredibly niche community.

      Occam’s razor is a tool, not objective truth. Based on the facts as we can see them, this focus on forking from the dev is much more indicative of a burnout spiral, incredibly common in the FOSS community, than nefarious actors. If we see receipts, eg a collection of takedown requests on malicious forks attempting to claim ownership of the code, our analysis falls apart. That’s still a possibility, however remote.