Topic: [ANN][DASH] Dash (dash.org) | First Self-Funding Self-Governing Crypto Currency - page 6279. (Read 9723733 times)
April 21, 2014, 09:57:21 AM
*brainstorming*
April 21, 2014, 09:53:16 AM
This assumes the philosophy of intellectual property is compatible with the world of cryptocurrency with a focus on anonymity.
Pure anarchy tends not to work well.
Copycoins would have a choice:
1. Licence DarkSend, benefit from the hard work being done for them and existing market recognition.
2. Use DarkSend unlicenced, good luck getting any serious investment due to the blatant illegality of it
3. Come up with something themselves, ie hard work
Works just fine actually. You going to have the state enforce this IP model? I don't think so.
Actually if I understand what he's saying there's no need for the state, but the community. If a dev blatantly copy DarkSend and use it / rebrand it without authorization, can the community trust is project ? Use the trust of the community as an incentive maybe ?
Exactly. Ultimately you cannot stop anyone from ripping off DarkSend, but in the information age how far are they going to get with it? Not too far I suspect.
April 21, 2014, 09:52:40 AM
Give me some examples of functional anarchistic societies that involve more than three hippies living in a commune...
I'm no fan of "the state", but if we can play the system to our advantage at close to zero cost then why not?
In your anarchistic utopia the only currencies that matter will be ammo, water, food, medicine... same as it ever was.
1. Russia
2. China
3. Brussels
April 21, 2014, 09:49:43 AM
This assumes the philosophy of intellectual property is compatible with the world of cryptocurrency with a focus on anonymity.
Pure anarchy tends not to work well.
Copycoins would have a choice:
1. Licence DarkSend, benefit from the hard work being done for them and existing market recognition.
2. Use DarkSend unlicenced, good luck getting any serious investment due to the blatant illegality of it
3. Come up with something themselves, ie hard work
Works just fine actually. You going to have the state enforce this IP model? I don't think so.
Actually
April 21, 2014, 09:46:20 AM
This assumes the philosophy of intellectual property is compatible with the world of cryptocurrency with a focus on anonymity.
Pure anarchy tends not to work well.
Copycoins would have a choice:
1. Licence DarkSend, benefit from the hard work being done for them and existing market recognition.
2. Use DarkSend unlicenced, good luck getting any serious investment due to the blatant illegality of it
3. Come up with something themselves, ie hard work
Works just fine actually. You going to have the state enforce this IP model? I don't think so.
Give me some examples of functional anarchistic societies that involve more than three hippies living in a commune...
I'm no fan of "the state", but if we can play the system to our advantage at close to zero cost then why not?
In your anarchistic utopia the only currencies that matter will be ammo, water, food, medicine... same as it ever was.
April 21, 2014, 09:39:43 AM
This assumes the philosophy of intellectual property is compatible with the world of cryptocurrency with a focus on anonymity.
Pure anarchy tends not to work well.
Copycoins would have a choice:
1. Licence DarkSend, benefit from the hard work being done for them and existing market recognition.
2. Use DarkSend unlicenced, good luck getting any serious investment due to the blatant illegality of it
3. Come up with something themselves, ie hard work
Works just fine actually. You going to have the state enforce this IP model? I don't think so.
April 21, 2014, 09:34:47 AM
Combine and conquer
What do you think about working with the other anonymous coins?
We are about to enter into serious competition with them. That will see a them and us feud. That's all well and good, and healthy, in a competitive landscape.
But.
Why don't we join marketing forces to promote anonymity and eCash. Once the concept is established, we can revert back to a competitive landscape.
This temporary alliance would see ~5 anonymity coins vs. 200 alt-coins.
If we as an alliance could get 50% of the alt-coin supporters switching over, that's $300m split between a small group to kick things off.
I think this is a real application of the Prisoner's Dilemma. If we fight, we all lose; if we cooperate, we all win.
What do you think about working with the other anonymous coins?
We are about to enter into serious competition with them. That will see a them and us feud. That's all well and good, and healthy, in a competitive landscape.
But.
Why don't we join marketing forces to promote anonymity and eCash. Once the concept is established, we can revert back to a competitive landscape.
This temporary alliance would see ~5 anonymity coins vs. 200 alt-coins.
If we as an alliance could get 50% of the alt-coin supporters switching over, that's $300m split between a small group to kick things off.
I think this is a real application of the Prisoner's Dilemma. If we fight, we all lose; if we cooperate, we all win.
April 21, 2014, 09:34:28 AM
I'm sure I could find a post I made a few hundred pages back about DarkSend being released under some sort of royalty model if used for commercial purposes, but free for general use.
The problem with this type of approach is that most crypto is put to commercial use. They nearly all seek to create some element of profit. That would mean everyone who uses DarkSend would be liable to pay a royalty. That's great, but Darkcoin relies on Bitcoin source code.
I think I got to the point where it would set double standards to freely use open source software for commercial purposes and then release open source updates, DarkSend, with a royalty element.
Nice work if you can get it, but not sure it would fly.
The problem with this type of approach is that most crypto is put to commercial use. They nearly all seek to create some element of profit. That would mean everyone who uses DarkSend would be liable to pay a royalty. That's great, but Darkcoin relies on Bitcoin source code.
I think I got to the point where it would set double standards to freely use open source software for commercial purposes and then release open source updates, DarkSend, with a royalty element.
Nice work if you can get it, but not sure it would fly.
We talk about DarkSend
The code of Darkcoin is already used by some clones.However, the fact that they may have to pay a fee in DRK to use DarkSend : Darkcoin = a pivot currency. The cap of Darkcoin increases as new or existing coins use DarkSend.
April 21, 2014, 09:34:17 AM
I'm sure I could find a post I made a few hundred pages back about DarkSend being released under some sort of royalty model if used for commercial purposes, but free for general use.
The problem with this type of approach is that most crypto is put to commercial use. They nearly all seek to create some element of profit. That would mean everyone who uses DarkSend would be liable to pay a royalty. That's great, but Darkcoin relies on Bitcoin source code.
I think I got to the point where it would set double standards to freely use open source software for commercial purposes and then release open source updates, DarkSend, with a royalty element.
Nice work if you can get it, but not sure it would fly.
The problem with this type of approach is that most crypto is put to commercial use. They nearly all seek to create some element of profit. That would mean everyone who uses DarkSend would be liable to pay a royalty. That's great, but Darkcoin relies on Bitcoin source code.
I think I got to the point where it would set double standards to freely use open source software for commercial purposes and then release open source updates, DarkSend, with a royalty element.
Nice work if you can get it, but not sure it would fly.
Darkcoin relies on Bitcoin code, but that may not apply to Darksend. At this point only the dev knows. If it isn't derivative, he can licence it however he likes.
April 21, 2014, 09:26:01 AM
I'm sure I could find a post I made a few hundred pages back about DarkSend being released under some sort of royalty model if used for commercial purposes, but free for general use.
The problem with this type of approach is that most crypto is put to commercial use. They nearly all seek to create some element of profit. That would mean everyone who uses DarkSend would be liable to pay a royalty. That's great, but Darkcoin relies on Bitcoin source code.
I think I got to the point where it would set double standards to freely use open source software for commercial purposes and then release open source updates, DarkSend, with a royalty element.
Nice work if you can get it, but not sure it would fly.
The problem with this type of approach is that most crypto is put to commercial use. They nearly all seek to create some element of profit. That would mean everyone who uses DarkSend would be liable to pay a royalty. That's great, but Darkcoin relies on Bitcoin source code.
I think I got to the point where it would set double standards to freely use open source software for commercial purposes and then release open source updates, DarkSend, with a royalty element.
Nice work if you can get it, but not sure it would fly.
April 21, 2014, 09:16:27 AM
This assumes the philosophy of intellectual property is compatible with the world of cryptocurrency with a focus on anonymity.
Pure anarchy tends not to work well.
Copycoins would have a choice:
1. Licence DarkSend, benefit from the hard work being done for them and existing market recognition.
2. Use DarkSend unlicenced, good luck getting any serious investment due to the blatant illegality of it
3. Come up with something themselves, ie hard work
April 21, 2014, 08:52:33 AM
Moreover that foundation could have a patent on DarkSend and other coins would have to pay a fee in DRK to use it. (fee redistributed to the network or bounty)
I don't think that's possible with open source software. I could be wrong, not sure.
Open source code can be released under a variety of licences. But I'm no expert either. If there was a way of licencing Darksend with minimum fuss then that would certainly ease a lot of minds re: copycat coins. It wouldn't eliminate competition, but it would be a help.
Someone needs to look into it. Maybe the EFF or someone could offer advice?
Dual licensing like MySQL
Quote
Dual Licensing Schemes
Some projects try to fund themselves by using a dual licensing scheme, in which proprietary derivative works may pay the copyright holder for the right to use the code, but the code still remains free for use by open source projects. This tends to work better with code libraries than with standalone applications, naturally. The exact terms differ from case to case. Usually the license for the free side is the GNU GPL, since it already bars others from incorporating the covered code into their proprietary product without permission from the copyright holder. An example is the MySQL license, described at mysql.com/company/legal/licensing.
15 June 2013: If you're reading this note, then you've encountered this section while it's undergoing substantial revision; see producingoss.com/v2.html for details.
poss2 todo: Note how that page, and so many other dual-licensing pages, refer to the proprietary license as "commercial". Need a subsection here about why it's important not to call it that.
You might be wondering: how can the copyright holder offer proprietary licensing for a mandatory fee if the terms of the GNU GPL stipulate that the code must be available under less restrictive terms? The answer is that the GPL's terms are something the copyright holder imposes on everyone else; the owner is therefore free to decide not to apply those terms to itself. A good way to think of it is to imagine that the copyright owner has an infinite number of copies of the software stored in a bucket. Each time it takes one out of the bucket to send into the world, it can decide what license to put on it: GPL, proprietary, or something else. Its right to do this is not tied to the GPL or any other open source license; it is simply a power granted by copyright law.
The attractiveness of dual licensing is that, at its best, it provides a way for a free software project to get a reliable income stream. Unfortunately, it can also interfere with the normal dynamics of open source projects. The problem is that any volunteer who makes a code contribution is now contributing to two distinct entities: the free version of the code and the proprietary version. While the contributor will be comfortable contributing to the free version, since that's the norm in open source projects, she may feel funny about contributing to someone else's semi-proprietary revenue stream. The awkwardness is exacerbated by the fact that in dual licensing, the copyright owner really needs to gather formal, signed copyright assignments from all contributors, in order to protect itself from a disgruntled contributor later claiming a percentage of royalties from the proprietary stream. The process of collecting these assignment papers means that contributors are starkly confronted with the fact that they are doing work that makes money for someone else.
Not all volunteers will be bothered by this; after all, their contributions go into the open source edition as well, and that may be where their main interest lies. Nevertheless, dual licensing is an instance of the copyright holder assigning itself a special right that others in the project do not have, and is thus bound to raise tensions at some point, at least with some volunteers.
What seems to happen in practice is that companies based on dual licensed software do not have truly egalitarian development communities. They get small-scale bug fixes and cleanup patches from external sources, but end up doing most of the hard work with internal resources. For example, Zack Urlocker, then vice president of marketing at MySQL, told me that the company generally ends up hiring the most active volunteers anyway. Thus, although the product itself is open source, licensed under the GPL, its development is more or less controlled by the company, albeit with the (extremely unlikely) possibility that someone truly dissatisfied with the company's handling of the software could fork the project. To what degree this threat preëmptively shapes the company's policies I don't know, but at any rate, MySQL does not seem to be having acceptance problems either in the open source world or beyond.
Some projects try to fund themselves by using a dual licensing scheme, in which proprietary derivative works may pay the copyright holder for the right to use the code, but the code still remains free for use by open source projects. This tends to work better with code libraries than with standalone applications, naturally. The exact terms differ from case to case. Usually the license for the free side is the GNU GPL, since it already bars others from incorporating the covered code into their proprietary product without permission from the copyright holder. An example is the MySQL license, described at mysql.com/company/legal/licensing.
15 June 2013: If you're reading this note, then you've encountered this section while it's undergoing substantial revision; see producingoss.com/v2.html for details.
poss2 todo: Note how that page, and so many other dual-licensing pages, refer to the proprietary license as "commercial". Need a subsection here about why it's important not to call it that.
You might be wondering: how can the copyright holder offer proprietary licensing for a mandatory fee if the terms of the GNU GPL stipulate that the code must be available under less restrictive terms? The answer is that the GPL's terms are something the copyright holder imposes on everyone else; the owner is therefore free to decide not to apply those terms to itself. A good way to think of it is to imagine that the copyright owner has an infinite number of copies of the software stored in a bucket. Each time it takes one out of the bucket to send into the world, it can decide what license to put on it: GPL, proprietary, or something else. Its right to do this is not tied to the GPL or any other open source license; it is simply a power granted by copyright law.
The attractiveness of dual licensing is that, at its best, it provides a way for a free software project to get a reliable income stream. Unfortunately, it can also interfere with the normal dynamics of open source projects. The problem is that any volunteer who makes a code contribution is now contributing to two distinct entities: the free version of the code and the proprietary version. While the contributor will be comfortable contributing to the free version, since that's the norm in open source projects, she may feel funny about contributing to someone else's semi-proprietary revenue stream. The awkwardness is exacerbated by the fact that in dual licensing, the copyright owner really needs to gather formal, signed copyright assignments from all contributors, in order to protect itself from a disgruntled contributor later claiming a percentage of royalties from the proprietary stream. The process of collecting these assignment papers means that contributors are starkly confronted with the fact that they are doing work that makes money for someone else.
Not all volunteers will be bothered by this; after all, their contributions go into the open source edition as well, and that may be where their main interest lies. Nevertheless, dual licensing is an instance of the copyright holder assigning itself a special right that others in the project do not have, and is thus bound to raise tensions at some point, at least with some volunteers.
What seems to happen in practice is that companies based on dual licensed software do not have truly egalitarian development communities. They get small-scale bug fixes and cleanup patches from external sources, but end up doing most of the hard work with internal resources. For example, Zack Urlocker, then vice president of marketing at MySQL, told me that the company generally ends up hiring the most active volunteers anyway. Thus, although the product itself is open source, licensed under the GPL, its development is more or less controlled by the company, albeit with the (extremely unlikely) possibility that someone truly dissatisfied with the company's handling of the software could fork the project. To what degree this threat preëmptively shapes the company's policies I don't know, but at any rate, MySQL does not seem to be having acceptance problems either in the open source world or beyond.
Source : http://producingoss.com/en/dual-licensing.html
Quote
Dual Licensing - Under dual licensing, one software program is made available under the two different distribution mechanisms described above. Under the open source/publication mechanism, source code for the software is made available at no cost under license terms that allow third parties to study the software and use it for research purposes, but contain restrictions on use or distribution that may make commercial use unfeasible. Under the commercial licensing mechanism, the software is licensed for a fee on licensing terms that permit the use of the software for commercial purposes. Examples of UT software that have been distributed under dual licensing include GotoBLAS and HOARD.
Source : http://www.otc.utexas.edu/licensing.jsp
If DarkSend was released as open source but with a licencing fee for commercial use (ie. any other coin using it) that would be a coup... copycoins would have to pay DarkFoundation a fee and the more that did so, the stronger the market position of DarkSend would be.
This assumes the philosophy of intellectual property is compatible with the world of cryptocurrency with a focus on anonymity.
April 21, 2014, 08:52:11 AM
24 Hours Left
3. april 2014 - goin2mars Amount won 32.19458 DRK - txid: ee1e6705d819a9ac05c498105d129001361b8b4ce24dcf4db9e64f187fcf1dd7
This was the last lottery...
Lotteryminning is closing down the pool - we are getting too small, and people seem to only want to mine at the big pools...
The pool will be turned of 22nd of april - Please withdraw your funds.. any funds left on that date will be considered pools property.. and used for happenings at a later date
BUT
we will return with something completly different, and its going to be awesome...
This was the last lottery...
Lotteryminning is closing down the pool - we are getting too small, and people seem to only want to mine at the big pools...
The pool will be turned of 22nd of april - Please withdraw your funds.. any funds left on that date will be considered pools property.. and used for happenings at a later date
BUT
we will return with something completly different, and its going to be awesome...
I would suggest to those still mining at lotterymining.com to start thinking on changing pools, since the fewer miners, the fewer blocks will be found
- CHAOSiTEC
Why not turn over left over funds to the bounty pool? If you are going to keep the funds, then you should be able to keep a tally of who owns how much and be able to return them even after the pool shuts down. But if you turn funds over to the bounty pool, I am sure folks won't be disappointed as much and you won't look greedy
April 21, 2014, 08:47:29 AM
Moreover that foundation could have a patent on DarkSend and other coins would have to pay a fee in DRK to use it. (fee redistributed to the network or bounty)
I don't think that's possible with open source software. I could be wrong, not sure.
Open source code can be released under a variety of licences. But I'm no expert either. If there was a way of licencing Darksend with minimum fuss then that would certainly ease a lot of minds re: copycat coins. It wouldn't eliminate competition, but it would be a help.
Someone needs to look into it. Maybe the EFF or someone could offer advice?
Dual licensing like MySQL
Quote
Dual Licensing Schemes
Some projects try to fund themselves by using a dual licensing scheme, in which proprietary derivative works may pay the copyright holder for the right to use the code, but the code still remains free for use by open source projects. This tends to work better with code libraries than with standalone applications, naturally. The exact terms differ from case to case. Usually the license for the free side is the GNU GPL, since it already bars others from incorporating the covered code into their proprietary product without permission from the copyright holder. An example is the MySQL license, described at mysql.com/company/legal/licensing.
15 June 2013: If you're reading this note, then you've encountered this section while it's undergoing substantial revision; see producingoss.com/v2.html for details.
poss2 todo: Note how that page, and so many other dual-licensing pages, refer to the proprietary license as "commercial". Need a subsection here about why it's important not to call it that.
You might be wondering: how can the copyright holder offer proprietary licensing for a mandatory fee if the terms of the GNU GPL stipulate that the code must be available under less restrictive terms? The answer is that the GPL's terms are something the copyright holder imposes on everyone else; the owner is therefore free to decide not to apply those terms to itself. A good way to think of it is to imagine that the copyright owner has an infinite number of copies of the software stored in a bucket. Each time it takes one out of the bucket to send into the world, it can decide what license to put on it: GPL, proprietary, or something else. Its right to do this is not tied to the GPL or any other open source license; it is simply a power granted by copyright law.
The attractiveness of dual licensing is that, at its best, it provides a way for a free software project to get a reliable income stream. Unfortunately, it can also interfere with the normal dynamics of open source projects. The problem is that any volunteer who makes a code contribution is now contributing to two distinct entities: the free version of the code and the proprietary version. While the contributor will be comfortable contributing to the free version, since that's the norm in open source projects, she may feel funny about contributing to someone else's semi-proprietary revenue stream. The awkwardness is exacerbated by the fact that in dual licensing, the copyright owner really needs to gather formal, signed copyright assignments from all contributors, in order to protect itself from a disgruntled contributor later claiming a percentage of royalties from the proprietary stream. The process of collecting these assignment papers means that contributors are starkly confronted with the fact that they are doing work that makes money for someone else.
Not all volunteers will be bothered by this; after all, their contributions go into the open source edition as well, and that may be where their main interest lies. Nevertheless, dual licensing is an instance of the copyright holder assigning itself a special right that others in the project do not have, and is thus bound to raise tensions at some point, at least with some volunteers.
What seems to happen in practice is that companies based on dual licensed software do not have truly egalitarian development communities. They get small-scale bug fixes and cleanup patches from external sources, but end up doing most of the hard work with internal resources. For example, Zack Urlocker, then vice president of marketing at MySQL, told me that the company generally ends up hiring the most active volunteers anyway. Thus, although the product itself is open source, licensed under the GPL, its development is more or less controlled by the company, albeit with the (extremely unlikely) possibility that someone truly dissatisfied with the company's handling of the software could fork the project. To what degree this threat preëmptively shapes the company's policies I don't know, but at any rate, MySQL does not seem to be having acceptance problems either in the open source world or beyond.
Some projects try to fund themselves by using a dual licensing scheme, in which proprietary derivative works may pay the copyright holder for the right to use the code, but the code still remains free for use by open source projects. This tends to work better with code libraries than with standalone applications, naturally. The exact terms differ from case to case. Usually the license for the free side is the GNU GPL, since it already bars others from incorporating the covered code into their proprietary product without permission from the copyright holder. An example is the MySQL license, described at mysql.com/company/legal/licensing.
15 June 2013: If you're reading this note, then you've encountered this section while it's undergoing substantial revision; see producingoss.com/v2.html for details.
poss2 todo: Note how that page, and so many other dual-licensing pages, refer to the proprietary license as "commercial". Need a subsection here about why it's important not to call it that.
You might be wondering: how can the copyright holder offer proprietary licensing for a mandatory fee if the terms of the GNU GPL stipulate that the code must be available under less restrictive terms? The answer is that the GPL's terms are something the copyright holder imposes on everyone else; the owner is therefore free to decide not to apply those terms to itself. A good way to think of it is to imagine that the copyright owner has an infinite number of copies of the software stored in a bucket. Each time it takes one out of the bucket to send into the world, it can decide what license to put on it: GPL, proprietary, or something else. Its right to do this is not tied to the GPL or any other open source license; it is simply a power granted by copyright law.
The attractiveness of dual licensing is that, at its best, it provides a way for a free software project to get a reliable income stream. Unfortunately, it can also interfere with the normal dynamics of open source projects. The problem is that any volunteer who makes a code contribution is now contributing to two distinct entities: the free version of the code and the proprietary version. While the contributor will be comfortable contributing to the free version, since that's the norm in open source projects, she may feel funny about contributing to someone else's semi-proprietary revenue stream. The awkwardness is exacerbated by the fact that in dual licensing, the copyright owner really needs to gather formal, signed copyright assignments from all contributors, in order to protect itself from a disgruntled contributor later claiming a percentage of royalties from the proprietary stream. The process of collecting these assignment papers means that contributors are starkly confronted with the fact that they are doing work that makes money for someone else.
Not all volunteers will be bothered by this; after all, their contributions go into the open source edition as well, and that may be where their main interest lies. Nevertheless, dual licensing is an instance of the copyright holder assigning itself a special right that others in the project do not have, and is thus bound to raise tensions at some point, at least with some volunteers.
What seems to happen in practice is that companies based on dual licensed software do not have truly egalitarian development communities. They get small-scale bug fixes and cleanup patches from external sources, but end up doing most of the hard work with internal resources. For example, Zack Urlocker, then vice president of marketing at MySQL, told me that the company generally ends up hiring the most active volunteers anyway. Thus, although the product itself is open source, licensed under the GPL, its development is more or less controlled by the company, albeit with the (extremely unlikely) possibility that someone truly dissatisfied with the company's handling of the software could fork the project. To what degree this threat preëmptively shapes the company's policies I don't know, but at any rate, MySQL does not seem to be having acceptance problems either in the open source world or beyond.
Source : http://producingoss.com/en/dual-licensing.html
Quote
Dual Licensing - Under dual licensing, one software program is made available under the two different distribution mechanisms described above. Under the open source/publication mechanism, source code for the software is made available at no cost under license terms that allow third parties to study the software and use it for research purposes, but contain restrictions on use or distribution that may make commercial use unfeasible. Under the commercial licensing mechanism, the software is licensed for a fee on licensing terms that permit the use of the software for commercial purposes. Examples of UT software that have been distributed under dual licensing include GotoBLAS and HOARD.
Source : http://www.otc.utexas.edu/licensing.jsp
If DarkSend was released as open source but with a licencing fee for commercial use (ie. any other coin using it) that would be a coup... copycoins would have to pay DarkFoundation a fee and the more that did so, the stronger the market position of DarkSend would be.
April 21, 2014, 08:11:27 AM
Moreover that foundation could have a patent on DarkSend and other coins would have to pay a fee in DRK to use it. (fee redistributed to the network or bounty)
I don't think that's possible with open source software. I could be wrong, not sure.
Open source code can be released under a variety of licences. But I'm no expert either. If there was a way of licencing Darksend with minimum fuss then that would certainly ease a lot of minds re: copycat coins. It wouldn't eliminate competition, but it would be a help.
Someone needs to look into it. Maybe the EFF or someone could offer advice?
Dual licensing like MySQL
Quote
Dual Licensing Schemes
Some projects try to fund themselves by using a dual licensing scheme, in which proprietary derivative works may pay the copyright holder for the right to use the code, but the code still remains free for use by open source projects. This tends to work better with code libraries than with standalone applications, naturally. The exact terms differ from case to case. Usually the license for the free side is the GNU GPL, since it already bars others from incorporating the covered code into their proprietary product without permission from the copyright holder. An example is the MySQL license, described at mysql.com/company/legal/licensing.
15 June 2013: If you're reading this note, then you've encountered this section while it's undergoing substantial revision; see producingoss.com/v2.html for details.
poss2 todo: Note how that page, and so many other dual-licensing pages, refer to the proprietary license as "commercial". Need a subsection here about why it's important not to call it that.
You might be wondering: how can the copyright holder offer proprietary licensing for a mandatory fee if the terms of the GNU GPL stipulate that the code must be available under less restrictive terms? The answer is that the GPL's terms are something the copyright holder imposes on everyone else; the owner is therefore free to decide not to apply those terms to itself. A good way to think of it is to imagine that the copyright owner has an infinite number of copies of the software stored in a bucket. Each time it takes one out of the bucket to send into the world, it can decide what license to put on it: GPL, proprietary, or something else. Its right to do this is not tied to the GPL or any other open source license; it is simply a power granted by copyright law.
The attractiveness of dual licensing is that, at its best, it provides a way for a free software project to get a reliable income stream. Unfortunately, it can also interfere with the normal dynamics of open source projects. The problem is that any volunteer who makes a code contribution is now contributing to two distinct entities: the free version of the code and the proprietary version. While the contributor will be comfortable contributing to the free version, since that's the norm in open source projects, she may feel funny about contributing to someone else's semi-proprietary revenue stream. The awkwardness is exacerbated by the fact that in dual licensing, the copyright owner really needs to gather formal, signed copyright assignments from all contributors, in order to protect itself from a disgruntled contributor later claiming a percentage of royalties from the proprietary stream. The process of collecting these assignment papers means that contributors are starkly confronted with the fact that they are doing work that makes money for someone else.
Not all volunteers will be bothered by this; after all, their contributions go into the open source edition as well, and that may be where their main interest lies. Nevertheless, dual licensing is an instance of the copyright holder assigning itself a special right that others in the project do not have, and is thus bound to raise tensions at some point, at least with some volunteers.
What seems to happen in practice is that companies based on dual licensed software do not have truly egalitarian development communities. They get small-scale bug fixes and cleanup patches from external sources, but end up doing most of the hard work with internal resources. For example, Zack Urlocker, then vice president of marketing at MySQL, told me that the company generally ends up hiring the most active volunteers anyway. Thus, although the product itself is open source, licensed under the GPL, its development is more or less controlled by the company, albeit with the (extremely unlikely) possibility that someone truly dissatisfied with the company's handling of the software could fork the project. To what degree this threat preëmptively shapes the company's policies I don't know, but at any rate, MySQL does not seem to be having acceptance problems either in the open source world or beyond.
Some projects try to fund themselves by using a dual licensing scheme, in which proprietary derivative works may pay the copyright holder for the right to use the code, but the code still remains free for use by open source projects. This tends to work better with code libraries than with standalone applications, naturally. The exact terms differ from case to case. Usually the license for the free side is the GNU GPL, since it already bars others from incorporating the covered code into their proprietary product without permission from the copyright holder. An example is the MySQL license, described at mysql.com/company/legal/licensing.
15 June 2013: If you're reading this note, then you've encountered this section while it's undergoing substantial revision; see producingoss.com/v2.html for details.
poss2 todo: Note how that page, and so many other dual-licensing pages, refer to the proprietary license as "commercial". Need a subsection here about why it's important not to call it that.
You might be wondering: how can the copyright holder offer proprietary licensing for a mandatory fee if the terms of the GNU GPL stipulate that the code must be available under less restrictive terms? The answer is that the GPL's terms are something the copyright holder imposes on everyone else; the owner is therefore free to decide not to apply those terms to itself. A good way to think of it is to imagine that the copyright owner has an infinite number of copies of the software stored in a bucket. Each time it takes one out of the bucket to send into the world, it can decide what license to put on it: GPL, proprietary, or something else. Its right to do this is not tied to the GPL or any other open source license; it is simply a power granted by copyright law.
The attractiveness of dual licensing is that, at its best, it provides a way for a free software project to get a reliable income stream. Unfortunately, it can also interfere with the normal dynamics of open source projects. The problem is that any volunteer who makes a code contribution is now contributing to two distinct entities: the free version of the code and the proprietary version. While the contributor will be comfortable contributing to the free version, since that's the norm in open source projects, she may feel funny about contributing to someone else's semi-proprietary revenue stream. The awkwardness is exacerbated by the fact that in dual licensing, the copyright owner really needs to gather formal, signed copyright assignments from all contributors, in order to protect itself from a disgruntled contributor later claiming a percentage of royalties from the proprietary stream. The process of collecting these assignment papers means that contributors are starkly confronted with the fact that they are doing work that makes money for someone else.
Not all volunteers will be bothered by this; after all, their contributions go into the open source edition as well, and that may be where their main interest lies. Nevertheless, dual licensing is an instance of the copyright holder assigning itself a special right that others in the project do not have, and is thus bound to raise tensions at some point, at least with some volunteers.
What seems to happen in practice is that companies based on dual licensed software do not have truly egalitarian development communities. They get small-scale bug fixes and cleanup patches from external sources, but end up doing most of the hard work with internal resources. For example, Zack Urlocker, then vice president of marketing at MySQL, told me that the company generally ends up hiring the most active volunteers anyway. Thus, although the product itself is open source, licensed under the GPL, its development is more or less controlled by the company, albeit with the (extremely unlikely) possibility that someone truly dissatisfied with the company's handling of the software could fork the project. To what degree this threat preëmptively shapes the company's policies I don't know, but at any rate, MySQL does not seem to be having acceptance problems either in the open source world or beyond.
Source : http://producingoss.com/en/dual-licensing.html
Quote
Dual Licensing - Under dual licensing, one software program is made available under the two different distribution mechanisms described above. Under the open source/publication mechanism, source code for the software is made available at no cost under license terms that allow third parties to study the software and use it for research purposes, but contain restrictions on use or distribution that may make commercial use unfeasible. Under the commercial licensing mechanism, the software is licensed for a fee on licensing terms that permit the use of the software for commercial purposes. Examples of UT software that have been distributed under dual licensing include GotoBLAS and HOARD.
Source : http://www.otc.utexas.edu/licensing.jsp
April 21, 2014, 08:06:30 AM
Please come to Darkcoin Mining Pool Hub
http://darkcoin.miningpoolhub.com
- Blocks fake hashes perfectly!
- US / Asia servers
- DDoS protected
- 1% Fee
- You can mine other coins by single sign up
Come and mine together!
http://darkcoin.miningpoolhub.com
- Blocks fake hashes perfectly!
- US / Asia servers
- DDoS protected
- 1% Fee
- You can mine other coins by single sign up
Come and mine together!
Can we perhaps persuade you to do as other several other pools are doing and donate 10% of mining fees to the bounty pool? In exchange you will get a special note next to the pool name on the darkcoin website, this thread, and the reddit wiki http://www.reddit.com/r/DRKCoin/wiki/index.
April 21, 2014, 06:38:54 AM
Just realised DRK is not on BTER 
Why we are not added there already ?
Why we are not added there already ? April 21, 2014, 06:36:00 AM
24 Hours Left
3. april 2014 - goin2mars Amount won 32.19458 DRK - txid: ee1e6705d819a9ac05c498105d129001361b8b4ce24dcf4db9e64f187fcf1dd7
This was the last lottery...
Lotteryminning is closing down the pool - we are getting too small, and people seem to only want to mine at the big pools...
The pool will be turned of 22nd of april - Please withdraw your funds.. any funds left on that date will be considered pools property.. and used for happenings at a later date
BUT
we will return with something completly different, and its going to be awesome...
This was the last lottery...
Lotteryminning is closing down the pool - we are getting too small, and people seem to only want to mine at the big pools...
The pool will be turned of 22nd of april - Please withdraw your funds.. any funds left on that date will be considered pools property.. and used for happenings at a later date
BUT
we will return with something completly different, and its going to be awesome...
I would suggest to those still mining at lotterymining.com to start thinking on changing pools, since the fewer miners, the fewer blocks will be found
- CHAOSiTEC
Please come to Darkcoin Mining Pool Hub
http://darkcoin.miningpoolhub.com
- Blocks fake hashes perfectly!
- US / Asia servers
- DDoS protected
- 1% Fee
- You can mine other coins by single sign up
Come and mine together!
April 21, 2014, 06:11:41 AM
Can you add BitMonero? The first clone of ByteCoin, fully anonymous and no need for masternodes (so 100% decentralised)
https://bitcointalksearch.org/topic/annbmr-bitmonero-a-new-coin-based-on-cryptonote-technology-launched-563821
https://bitcointalksearch.org/topic/annbmr-bitmonero-a-new-coin-based-on-cryptonote-technology-launched-563821
Added
+ I will not lock the voting, instead i will post printscreen here when we reach 200 votes so anybody can look back into poll history.
+ I want also new coins added to poll to have a chance
Clones of a dead coin.
I guess the Dark bounce has woken up a few people to the $$$ possibilities.
Expect to see more copies and clones.
April 21, 2014, 05:58:43 AM
Android wallet ASAP souds like an excellent idea. It will be a bit more than just a simple rebranding job though to incorporate Darksend.
Devs should put up a decent bounty on it!
edit: I have no clue whether he would be interested, but the guy who did the VTC Android wallet is talented and (I speak from personal experience, and others can back it up) completely trustworthy. http://www.reddit.com/user/18pct - just a suggestion.
Devs should put up a decent bounty on it!
edit: I have no clue whether he would be interested, but the guy who did the VTC Android wallet is talented and (I speak from personal experience, and others can back it up) completely trustworthy. http://www.reddit.com/user/18pct - just a suggestion.
Jump to: