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 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.

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.

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)

What the christ does a decentralised, distributed cryptocurrency need its own goddamn lawyer for?

think most here would agree that the technological achievements of Darkcoin are FAR AHEAD of the coin's marketing. I think most will also agree with LimLims that such activity needs a dedicated professional person.

I therefore propose the following - from the next fork, X% of the masternodes proceeds will go into a dedicated multi-sig wallet that will pay a salary to a dedicated full-time professional marketing person.

Hopefully, in time, the price of darkcoin will go up, this fund will be able to employ more than one person, and thus also pay the developers, webmaster, etc.
imho, the time has come to become less bootstrap and more professional.