It's more nuanced than "your" project. If you're using a free license, that license says it's everyone's project, not just yours. 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"?
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.
Agreed. A project maintainer's job is to accept comments and improvements from the community. It is completely irrelevant if someone is getting paid for their contributions, as long as the quality of their submissions are up to snuff.
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.
Isn't the answer for this to fork the project and then put the bounty on the fork? If the work to earn the bounty is valuable then the forked project can ask to be merged into the main project. If the work isn't valuable then the bounty can still be paid and the code kept on the fork.
Depends what you mean with "fork". The usage used to mean a big and ominous circumstance, like Emacs vs XEmacs or gcc vs egcs. Nowadays people use it to mean any deviation from a project, no matter how tiny, or even simply a server-side git clone, as popularised by github.
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.
There are no nuances here, for change this is black and white. Even if the a project's license is free and permits any use, there is no excuse for abusing that project to promote your own spam. You are arguing to allow spam, and from the example of email we all know about the economic and social costs. Don't enable the equivalent of spam in the Open Source world.
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?
I'm offering money to people who go to BountySource looking for money, in exchange for features I want. Alternatively, I'm asking for money in exchange for my coding, from people who go to BountySource looking to give money for a feature.
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).
There's no software distribution here, so the license doesn't matter. They are collecting money for your work on your behalf but without your permission.
Bountysource is not collecting money "on your behalf", from what I can tell. It's a different situation than tip4commit.
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.
No, the license says everyone can use it, but I'm not aware of anything other than Creative Commons that explicitly transfers ownership in anyway.
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.
The concept of "ownership" is not clear when you're using a free license. The only thing that is clearly owned is the copyright, but a free license gives everyone all the freedom they could possibly want with the software other than put their own copyright on it, so it's almost like they "own" it too.[1]
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.
No, the concept of ownership is quite clear, hence why the FSF requires copyright assignments on GNU projects. Licenses like the GPL do not work without a good understanding that the person with the copyright has ownership of it. Without that ownership, it is impossible to make the demands of the license.
If it's a free license, it allows you to sell the software. In particular, it allows you to charge money for improving it. All of them do this. Otherwise OSI wouldn't approve the license. Neither would the FSF.
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.
Your reply about the license doesn't address the point I made in the next paragraph, that legalistic shenanigans probably aren't going to end up helping any project.
For "claim" vs "cash out", yes, I was thinking the distinction is rather artificial.
'It's a little discouraging that "claiming a bounty" only means you can use it on Bountysource'
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.
I thought about this some, I don't think it is a big deal, and different language would probably fix most of it.
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.
Maybe I'm missing the point of your argument here, but doesn't the maintainer of a project has an intrinsic right to manage the project in his or her own way? They are the gatekeepers to their own projects contributions.
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...
> They are the gatekeepers to their own projects contributions
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.
They are the gatekeepers to their own project's contributions, but one way to look at it is that the result of a bounty is a potential contribution available to their project but also available to anyone who wants to fork (either publicly or privately) which makes the new project their code (in the sense that is relevant here - control over content of the code base).
> If you're using a free license, that license says it's everyone's project, not just yours.
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.
Nobody is saying that anyone is obligated to accept any patches. Nobody wants to be forced to accept patches, nobody is trying to force anyone to accept any patches.
But if you introduce money into the equation, denying someone's patch may be perceived as denying that person income.
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.
Eh, tip4commit was particularly recalcitrant, but this case is different. Bountysource saw what happened to tip4commit, and instead of burying their head in the ground, is attempting to thoughtfully and respectfully engage with the broader F/OSS community.
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?
If I want a piece of FLO software I'm using to be extended, I can do so or I can pay someone to do so. BountySource is facilitating that, in a way that has no intrinsic tie to the original project - they can accept the commits if they want them, ignore them if they don't. The project has no right to get in the way of my agreements with third parties. This directly relates to freedoms 1 and 3.
This is entirely different than someone representing themselves as accepting donations on behalf of someone else.
They are spammers, they talk like spammers, and they need to be treated like the dregs of society they are. For starters, I see tht Bountysource is still on Github. Why didn't they get chucked off already, the scumbags? As of now, Github is enabling spam.
The reason that spam exists is the ability to impose costs on the receivers of the spam while the sender pays far less than the total of those costs. From what I can see, tip4commit (and maybe bountysource, with which I'm not familiar) is exactly the opposite of spam: it introduces a way for those shouldering the costs of open source software to be repaid to some degree by the community.
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.
It is a much worse evil to have software developers who would write free software given the fiscal means to, when those means are available through others, but are not exploited, and they end up either writing proprietary software to eat or not writing software at all.
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.
Bountysource should allow project owners to delist their projects. Not doing so will simply lead to trademark and other infringement actions. Just because the code is licensed as open source doesn't mean you get to use the project's brand for your money making schemes.
There is no infringement, if they are not implying endorsement. Use of trademark to refer to the product is explicitly okay, and there's no other way to refer to that lump of code. If I want to pay someone to add a feature to FLO software I use, that's my right, and the project trying to get in the way of that is in the wrong - morally and possibly legally. The project, of course, has no obligation to accept any patches generated.
Bountysource should invite projects to their program rather than removing them on request. As this discussion and previous ones have shown diffrent communities, diffrent maintainer even diffrent project member have diffrent opinios on introducing financial rewards into their projects and need to firstly discuss it. Afterwards they can approve or reject getting the offer listed on bs.
40 comments
[ 3.3 ms ] story [ 87.0 ms ] threadI 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 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.
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.
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).
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.
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.
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.
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.
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.
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.
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.