Should Bountysource allow committers to delist their projects?
github.com
github.com
It's also worth noting that Bountysource only allows you to unilaterally "tip" projects if a member of that project has signed up on Bountysource, so they're not guilty of tip4commit's transgression.
What do we have to gain by spiting them for a good-faith attempt at dialog?
This is entirely different than someone representing themselves as accepting donations on behalf of someone else.
I can see a case for saying "no" in other ways or about other things, but simply saying "nobody can collect money for this but me or the people I approve" would make your project non-free and non-open-source. And if that's what you want, then pick a different license.
If things get to the point where Bountysource is pointing at the terms of the license to defend what they are doing, it's pretty likely they are also at the point where they are significantly undermining the idea that what they are doing is helping the project.
Attaching the bounties to specific issues does seem less fraught than tipping every commit for a project.
It's a little discouraging that "claiming a bounty" only means you can use it on Bountysource, as the likely reason to do that is for promotion (it sounds a lot better to have a bunch of situations where you can say there is no fee and only one where there is a fee):
Does 100% of the bounty go to the developer?
The developer who solves the issue will receive the full bounty amount in their Bountysource account. These funds can be used to create more bounties, donate to teams, or pledge fundraisers. If a developer wishes to cash out their balance there will be a 10% fee.
What does it cost to claim a bounty?
Nothing. The amount displayed as the bounty total is the exact amount a developer will receive in their Bountysource account upon payout.
Just inverting the order of those makes it seem pretty silly:
What does it cost to claim a bounty?
Nothing. The amount displayed as the bounty total is the exact amount a developer will receive in their Bountysource account upon payout.
Does 100% of the bounty go to the developer?
The developer who solves the issue will receive the full bounty amount in their Bountysource account. These funds can be used to create more bounties, donate to teams, or pledge fundraisers. If a developer wishes to cash out their balance there will be a 10% fee.
No, it is fundamental to why bountysource can even possibly exist, as well as companies like Red Hat or Collabora. We built a system of free licenses since the late 80's that allow this kind of business. If you don't want to allow this sort of business, you need a different license. No Microsoft employee can possibly use bountysource to fund a project to improve Excel, not even if they wanted to. The license terms don't allow it.
> Just inverting the order of those makes it seem pretty silly:
I'm not sure I see the problem here. I suppose you object to the meaning of "claim" not being the same as "cash out"? That does seem a bit problematic.
For "claim" vs "cash out", yes, I was thinking the distinction is rather artificial.
They've got to take their cut at some point. I think forgoing it when the funds are re-used in the system is strictly a positive thing - yes, it benefits them, but it also benefits projects and developers. I don't disagree that the above could be phrased better, but I actually don't have strong objection to the existing language. The act that incurs the fee is withdrawing, not claiming.
They could also make a more substantive change and include a fee in incoming payments. They know how much they take in and how much is cashed out, so the fee could still be benchmarked to ~10% of pay outs.
It's slightly harder to explain and it wouldn't ever be as round a number as 10%, but an advantage is that people setting up a bounty would then see how much would end up in developer hands and how much the fees are, prior to making the payment.
Also, software licenses cover many more situations than merely distribution. Without a free license, you wouldn't even be allowed to use the software, let alone charge money for modifying it.
Nobody is obligated to accept any patches, no matter their provenance, no matter if they were paid for. My two parties above in a mutually beneficial agreement could decide to keep the patches between themselves if upstream rejects them. I suppose that could be called a fork. I don't think every such occasion should warrant a new name like under the traditional definition of "fork", though.
Well, I certainly think it warrants clarity as to who is responsible for issues. That needn't take the form of "a new name" though, I agree.
Maybe, but the lead developer is the one in charge of the software. If the community doesn't like it, they can request a change in leadership or fork the project.
> So if two people want to take "your" free software and enter an economic agreement to improve "your" free software in a way that benefits both of them, why should you have a right to say "no"?
For all the reasons mentioned above (forward-planning, insight, etc.). If someone wishes to make a change to a project, in such a way that benefits them, the project itself is never required to just accept the changes. That someone can fork the project.
Is that always the right answer? No. But it is one possibility.
Think about it: if you're project is running merrily along and Bob the Random Programmer tries to collect a bounty but his patch is denied, what's he going to think?
He may very well think his patch was denied and he won't collect the bounty, thus he starts pressuring the project leader to take his patch.
It introduces potential problems and considerations that some project leaders don't want to have to deal with or even think about, because they aren't technical issues.
And while I completely agree with your point that the project code can be seen as everyone's, how does some third party have the right to define how someone manages his or her own gate?
I'm looking at it more as, it's the maintainer's right to manage the project and it's issues as he or she sees fit. I can see how the maintainer doesn't have the right to manage the code outside of the repo, but telling someone how to manage their own repo...
The point that bountysource is making is that the contributions don't always necessarily go to the project. There are individual drive-by bounty hunters who are unaffiliated with the project. I don't see a reason to discourage that, and I don't see a reason to pressure the project into accepting these drive-by bounty hunters either. I don't think anyone else is, either.
Why is this even civilly discussed? If someone here offered a way to ensure effective delivery of spam email there would be the armed posse showing that guy the door. The same thing needs to happen here. Someone please enlighten me why that isn't taking place.
Because Bountysource isn't "spamming" anyone, to the best of my knowledge. Have you tried to figure out what they do? What is it that you're calling "spam" anyways?
It's a different situation than with tip4commit.
How is either of those "spam"?
(For the record, I've not actually used BountySource, and from what I've heard FreedomSponsors is probably what I'd go with in the space, but the principles involved remain the same).
If you think that people contributing to your project should not be compensated (which is a reasonable thing to think IMO), the burden is on you to make sure they are not, and it is not the responsibility of a third party to make sure that they are not getting paid.
At the end of the day, the project creator gets to say how his or her code is used. If this continues to be an issue, then people are going to start coming up with new licenses that explicitly state their wishes that setting up these types of bug bounty systems are not a right that is granted.
So yes, all free licenses allow you to do something like sell support for the software or charge money for improving it with your own private patches. If they didn't, companies like Red Hat or Collabora couldn't exist.
Except for its copyright, everyone "owns" free software.
[1] This is actually even better than when you buy software under a EULA. Most EULAs say something like "the software is licensed, not sold", explicitly reminding you that you're paying for the permission to use the software and that you don't own it.
http://lwn.net/Articles/201488/
It's every developer's dream to get paid to work on free and open source software. But whenever someone really starts to work towards getting paid, well, the root of all evil steps in.
I commend tip4commit and bountysource and its ilk, not because individually they are ethical or moral about it, but because it is attempting to solve a real problem in the community, and someone is bound to get it right.