51–60 of 87 posts
The controversy here is described in the following comment: > Unfortunately, they have already merged a version of this code into the private gitea repo and are charging $$ for it. So Gitea Ltd. (owners group) has no incentive to review and merge this in an open source repo, even though the open source community has funded and developed it. > This is a cynical take, but I have raised these concerns in private channel…
The person who made that comment appears to be CTO of a company whose product is a (seemingly closed-source?) fork of Gitea [1]. I mean obviously that's fine legally, it's MIT licensed, and also his company contributes code to Gitea. But, it seems rather hypocritical to complain about the maintainers of Gitea having a private Enterprise repo for profit, when the person complaining does the exact same thing. [1] "AllS…
A recent comment indicates that this outcome was more like a mistake and less line the skulduggery that the title indicates. Public shaming might be a good tool for this kind of thing in general but maybe in this case it was premature.
Also let's please be careful about creating situations that pressure a maintainer to merge a PR before they're fully comfortable with it. That's how ssh got backdoored via xz (no reason to believe that that's what's happening here). If somebody wants to embrace YOLO with their $$ project and be a bit more cautious with their OSS project, that's ok.
So? Why does a business have an obligation to give away their intellectual property for free? When you submit a PR to a business’s intellectual property, it’s still theirs. The years go by and the beggar attitude of open source users gets more and more tiring.
It's hard to distinguish this comment from a troll response. But just to deal with the factual claim: > When you submit a PR to a business’s intellectual property, it’s still theirs. Nope, contributions do not "belong" to the receiving project unless explicitly agreed so. They were created under a license, and are (usually) reciprocally licensed to the project. The owner is and always was the contributor. To call som…
The controversy here is described in the following comment: > Unfortunately, they have already merged a version of this code into the private gitea repo and are charging $$ for it. So Gitea Ltd. (owners group) has no incentive to review and merge this in an open source repo, even though the open source community has funded and developed it. > This is a cynical take, but I have raised these concerns in private channel…
If they've merged that code but refuse to make it available in the community version - when it's been contributed by the community - that's one (very uncool) thing. It's slightly different if they already have the feature from homegrown code and they don't want to merge a second version in the community version which causes additional maintenance headaches for them.
Earlier quoted context omitted.
The person who made that comment appears to be CTO of a company whose product is a (seemingly closed-source?) fork of Gitea [1]. I mean obviously that's fine legally, it's MIT licensed, and also his company contributes code to Gitea. But, it seems rather hypocritical to complain about the maintainers of Gitea having a private Enterprise repo for profit, when the person complaining does the exact same thing. [1] "AllS…
He may be, but also contributes quite heavily to the open source repo and sponsors bounties. It may not absolve him of profit motive, but at least earns the right to critique the Gitea administration.
Gitea's stance regarding why certain features are Enterprise-only is quite reasonable: "Many features, and enhancements are prevented from being included in the Gitea project due to high upfront costs, and lack of resources to maintain them. This leads to them not being developed or accepted into the project. With this offering, we are able to provide a version to paying customers with a support contract, allowing us to develop and maintain these features for the Gitea project." https://docs.gitea.com/enterprise/faq#why-is-this-a-paid-off...
That certainly sounds like it would apply to this particular PR, which is a 4000-line diff affecting 144 files, and with a 350+ comment discussion history spanning over 16 months. Review, cleanup, and long-term maintenance for this sort of PR are faaaaar from free. I can understand 100% why this would be an Enterprise-only feature, and complaints about the maintainers' profit motive in that context seem utterly ridiculous to me. Especially when the commenter is complaining about a "massive conflict of interest" when not mentioning his own extremely similar conflict of interest.
So the evidence here is that the Gitea Enterprise page now advertises an audit feature? Mainly for thoroughness: how sure are we that it's the same code?
The quoted comment does say > Unfortunately, they have already merged a version of this code into the private gitea repo and are charging $$ for it. So if they can be trusted at face value, "a version of this code" means it's the same code, and would be an incorrect way of describing "an analogous feature with an unrelated implementation". But they could be making a mistake, of course.
Earlier quoted context omitted.
He may be, but also contributes quite heavily to the open source repo and sponsors bounties. It may not absolve him of profit motive, but at least earns the right to critique the Gitea administration.
I don't see how it gives him the right to critique the maintainers over this specific topic and situation. He clearly has no qualms about profiting from their work himself. So why does he have a problem with them profiting from other contributors' work? Gitea's stance regarding why certain features are Enterprise-only is quite reasonable: "Many features, and enhancements are prevented from being included in the Gitea…
It may be expensive; that’s why there was a community-funded bounty placed on it.
If the complaint is that Gitea is too complex to maintain for free, then great, start a company around it to fund a private fork. But then you shouldn’t be allowed to stop the community from merging their own crap in their own fork that they maintain and care about. Since Gitea LTD is the gatekeeper of both repos, that is the conflict of interest.
Earlier quoted context omitted.
Also let's please be careful about creating situations that pressure a maintainer to merge a PR before they're fully comfortable with it. That's how ssh got backdoored via xz (no reason to believe that that's what's happening here). If somebody wants to embrace YOLO with their $$ project and be a bit more cautious with their OSS project, that's ok.
Didn’t xz get backdoored through extreme cunning and an exhausted solo maintainer?
I'm just pointing it out because I think it's going to be a tricky balance to strike. How can we, as a community of people who care about free and/or open source software tell the difference between:
- a good faith effort to inform the wider community of a maintainer who is behaving badly
- a bad-faith contributor pressuring an overworked maintainer to include a malicious commit
I think you're the former, but I'm rather worried about the latter. And I'm interested in strategies for telling the two apart.
Earlier quoted context omitted.
Didn’t xz get backdoored through extreme cunning and an exhausted solo maintainer?
Yes but the exhaustion was not 100% organic. There was a bit of social engineering towards wearing the maintainer down even further. I'm just pointing it out because I think it's going to be a tricky balance to strike. How can we, as a community of people who care about free and/or open source software tell the difference between: - a good faith effort to inform the wider community of a maintainer who is behaving bad…
We can’t rely on everyone to follow our schedules, so if there’s a desire we should take the lead on getting it done instead of dragging each other down. As such, I didn’t post this to shame anyone, mostly to provide an onus for switching to a fork. (Or I should say, another onus, since there are already a few reasons to not contribute to Gitea, mostly coming down to size of the project and inertia preventing refactors or redesigns.)