search

1bardesign / hoop-rfc

Other
10 stars 1 forks source link

Vulnerability to maintainer abuse #7

Open joe-no-body opened 3 years ago

joe-no-body commented 3 years ago

The idea of preventing forks is an interesting one, but I'm a bit nervous about some of the implications. It's true that forking can be a major threat to an open source project, it's also a major check on the maintainers. You've already mentioned the case of a maintainer passing away/disappearing, but there are a couple other cases I can think of where this could be especially important:

  1. What stops a maintainer from making the project closed source? Under the current draft, maintainers can sell the project commercially and have no obligation to maintain free access to the project binaries or code. If the maintainers shut down their GitHub repos, stop accepting contributions, refuse to grant free/discounted licenses, and only offer the software to paying customers, it's not clear to me that contributors would have any recourse to maintain an open source project.
  2. What happens if a maintainer betrays community trust and undermines the project through their behavior? For example, suppose the maintainers steer the project in a direction that a significant part of the community doesn't want. Or, even worse, suppose they subject contributors to abusive or bigoted behavior.

Both of these scenarios can and do happen in existing FOSS projects, but the key difference is that FOSS licenses convey the right to maintain and distribute the software in perpetuity. As a contributor, that's a really reassuring guarantee, because I know that my rights in the software will always be the same.

A few options that initially come to mind here:

  1. Lean in to an explicit source-available model. This doesn't solve either issue I mentioned, but I think it's a reasonable compromise, because it makes clear what exactly is being offered. I think there could be a reasonable use case for a semi-commercial license that tries to strike a balance between community access and maintainer control, especially for certain types of smaller projects (e.g. game engine plugins come to mind). Having a standard license here seems like it would be useful too, because right now it's up to individual creators to figure out what terms they want to offer.
  2. Add some terms under which contributions are licensed to the maintainer that require the maintainer to continue offering non-commercial access to the source. e.g. maybe some GPL-style verbiage stating that, as long as the maintainer provides the software with contributions from the community, they must continue to offer at least access to the source and binaries for the purposes listed at the top of the license. (See #6)
  3. Revert each release to another license after a set period of time. That way, if a maintainer disappears or goes rogue, there's still a possibility of resurrecting the project, but any fork of an active project would be forced to start on an much older and outdated version. There's still a risk, but I think it evens the playing field. Maybe some verbiage like, "2 years after a given revision of the software is publicly released or 2 years after you receive or create a particular version in source or binary form (whichever is earlier), you may use and distribute that revision of this software and any derivative works thereof under the terms of [e.g. the GNU General Public license]."
1bardesign commented 3 years ago

I appreciate these concerns and know that this is an issue in the FOSS, particularly the more personally abusive maintainer stuff.

I think in both of those cases, if there is a single maintainer behaving badly, a project is generally in dire straits. It's a shame that the contributors would be SoL for sure, but it doesn't bode well for the future of the project either way.

For HOOP, the intent is for the maintainer(s) to more or less keep "control" of the project, direction wise and legally.

I know that wont sit well with some folks, but comes from my history maintaining part-way open source games (where you need to maintain the ability to sell it, contributions and all) and smaller libraries where you get 50-50 "excellent" and 50-50 "total rubbish" contributions that you don't necessarily want to include or "pay for" in some way (you already pay in time when respectfully declining/explaining the problems).

Akin to the github tshirt "get a PR accepted and get a tshirt" where everyone was getting spam, I think setting a low-effort low-communication bar is a common mistake. That's why the commercial terms are negotiated. That's why the license in return for contribution is negotiated.

I was literally having thoughts about a rogue maintainer and some sort of timed expiry/relicensing clause in the shower, haha.

I think if it worked on a per-commit basis that could be fine. I would personally probably default to something like the anti-capitalist license to keep defense against time-delay strip mining while remaining fairly permissive :) but I guess other folks using the model could default to something else.

If HOOP became widely adopted it'd be possible to set up a central watchlist of libs and what commit had crossed that threshold.