{"action":"created","issue":{"url":"https://api.github.com/repos/pybee/paying-the-piper/issues/61","labels_url":"https://api.github.com/repos/pybee/paying-the-piper/issues/61/labels{/name}","comments_url":"https://api.github.com/repos/pybee/paying-the-piper/issues/61/comments","events_url":"https://api.github.com/repos/pybee/paying-the-piper/issues/61/events","html_url":"https://github.com/pybee/paying-the-piper/issues/61","id":120317067,"number":61,"title":"An alternative to \"dual licensing\"?","user":{"login":"freakboy3742","id":37345,"avatar_url":"https://avatars.githubusercontent.com/u/37345?v=3","gravatar_id":"","url":"https://api.github.com/users/freakboy3742","html_url":"https://github.com/freakboy3742","followers_url":"https://api.github.com/users/freakboy3742/followers","following_url":"https://api.github.com/users/freakboy3742/following{/other_user}","gists_url":"https://api.github.com/users/freakboy3742/gists{/gist_id}","starred_url":"https://api.github.com/users/freakboy3742/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/freakboy3742/subscriptions","organizations_url":"https://api.github.com/users/freakboy3742/orgs","repos_url":"https://api.github.com/users/freakboy3742/repos","events_url":"https://api.github.com/users/freakboy3742/events{/privacy}","received_events_url":"https://api.github.com/users/freakboy3742/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":9,"created_at":"2015-12-04T02:17:50Z","updated_at":"2015-12-04T18:47:55Z","closed_at":null,"body":"A frequent refrain for open source's funding problems is [to adopt dual licensing](http://www.mikeperham.com/2015/11/23/how-to-charge-for-your-open-source/). In some situations, this definitely works (Sidekiq is a clear example). The model is usually stated in a way that requires that the \"Free\" version to be GPL'd as an mechanism to make the code impractical to commercial interests, forcing their hand into buying a commercial license.\r\n\r\nThis can definitely work, but the GPL does impose a very specific set of requirements on code that might be incompatible with broader project goals. It also creates (or encourages) a walled garden approach to \"Pro\" content.\r\n\r\nHowever: a software license is granted, not an absolute property of the software that has been developed. While *convention* is that FLOSS licenses are offered to all without restriction, is there any reason that they *have* to be offered unconditionally? \r\n\r\nAs an analog - if I write proprietary software, I'm not *required* to sell it to anybody who asks - I can refuse to sell to certain individuals. This usually happens because they can't afford to pay, but it could also be because I don't like what you're going to do with the software. For example, I've personally been on the receiving end of vendors refusing to sell software to me because they thought that I was going to develop a competing product, and they didn't want to give me an easy way to match their feature set.\r\n\r\nSo - would it be possible to license software under *any* license (GPL, BSD, whatever), but only *grant* that license to companies under certain conditions - for example, \"If you generate revenue > $X/month, you must pay to have this license.\"\r\n\r\nTheoretically, you could also use this as a basis for restricting on ethical grounds.\r\n\r\nThis would seem to appease free software purists who don't want a license restriction preventing redistribution, by tackling the problem at who gets the software in the first place.\r\n\r\nHere are the obvious objections I can see:\r\n\r\n> The free software definition requires that software is usable by all!\r\n\r\nNo, the free software definition says that you have (0) the freedom to run, (1) the freedom to study, (2) the freedom to redistribute, and (3) the freedom to modify. It *doesn't* say that I, as the author, have to give you the software in the first place. This is the the core tenet that makes dual licensing possible - I'm not *required* to give you a license - I just can't restrict your freedoms once I've given you a license.\r\n\r\nI can, however, refuse to give you a license for future versions.\r\n\r\n> What about software redistributors?\r\n\r\nThis is the biggest problem I see with this approach - I can't give my software to Redhat without restricting their right to redistribute. The two responses to this I can see to this are:\r\n\r\n1. Granting a license to redistributors on the basis that they impose the same restrictions on ownership. This probably wouldn't be plausible in practice - Debian, for example, has a history of rejecting \"creative\" licensing deals and/or requests.\r\n\r\n2. Don't worry about it, and accept that your software won't be packaged with the OS. Depending on the software, this might not be a problem. For example, if you're writing a Python library, \"pip install\" is generally the preferred installation mechanism anyway. It could even work to your advantage, as you know that the OS vendor isn't going to b*gger up your code (Ubuntu packaging of Python, anyone?)\r\n\r\n> What stops a commercial entity from giving away their copy?\r\n\r\nStricly, nothing. But, a large commercial entity that has paid a lot for software is unlikely to start giving away something that they've paid big money for.\r\n\r\n> Why would a commercial entity honour this license? Won't they just play games, get an employee to download the code privately, and get them to provide it internally?\r\n\r\nThe lesson of the RIAA and MPAA over the last 20 years is that if you provide a way for people to do the right thing, they'll do the right thing. Provide a way for people to get access to music and movies legally, and piracy will evaporate to the point nobody cares. \r\n\r\nThis approach isn't about trying to stop all piracy, or stop all freeloading. It's about providing a channel by which it is *possible* to ask someone for money on a basis other than donation. Small companies will probably ignore the license requirement - but they probably also don't have the money to pay. Large companies need to be able to validate to their accountants that there's a reason why they've got an expense on their balance sheet. Huge companies have legal departments who will look at the legal agreements they've got, and panic if they're not completely above board. But it's also the large and huge companies that we want to pay, because they're the ones with the biggest *capacity* to pay.\r\n\r\n> Can't I do an end run around this by setting myself up cloning the repository and giving it away for free?\r\n\r\nWell, sure. But, again, see the previous point - this is about making it easy to do the right thing. \r\n\r\nAs an added enforcement, you could also use the project Trademark - refuse to license the use of the name to anyone redistributing in a way that undermines the revenue stream. This is effectively the approach that Mozilla used leading to Iceweasel (although dispute was over code modifications, not revenue/redistribution).\r\n\r\n> What about code from contributors?\r\n\r\nThat comes down to project contribution guidelines. You could use copyright assignment, CLAs, or tacit agreements that all code contributed to the project comes with a license to redistribute as the project sees fit."},"comment":{"url":"https://api.github.com/repos/pybee/paying-the-piper/issues/comments/162048799","html_url":"https://github.com/pybee/paying-the-piper/issues/61#issuecomment-162048799","issue_url":"https://api.github.com/repos/pybee/paying-the-piper/issues/61","id":162048799,"user":{"login":"ariddell","id":19950,"avatar_url":"https://avatars.githubusercontent.com/u/19950?v=3","gravatar_id":"","url":"https://api.github.com/users/ariddell","html_url":"https://github.com/ariddell","followers_url":"https://api.github.com/users/ariddell/followers","following_url":"https://api.github.com/users/ariddell/following{/other_user}","gists_url":"https://api.github.com/users/ariddell/gists{/gist_id}","starred_url":"https://api.github.com/users/ariddell/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ariddell/subscriptions","organizations_url":"https://api.github.com/users/ariddell/orgs","repos_url":"https://api.github.com/users/ariddell/repos","events_url":"https://api.github.com/users/ariddell/events{/privacy}","received_events_url":"https://api.github.com/users/ariddell/received_events","type":"User","site_admin":false},"created_at":"2015-12-04T18:47:55Z","updated_at":"2015-12-04T18:47:55Z","body":"Whether or not this threatens the \"entire core aspect of Open Source\ndevelopment where existing users can contribute bug fixes etc.\" strikes\nme as an empirical question. How many of Django's bug fixes would likely\nnot have been contributed under this system? I think plenty of the bug\nfixes would have been contributed.\n\nIf the alternative-to-dual-licensing-license  did elicit a lot of\nblowback from the relevant community then one could also revert back to\nthe standard open source license. It seems like the only people who it\nwould piss off would be the *stockholders* of large companies. I'm not\nsure why employees/developers (those who are not stockholders) would\ncare about this provision.\n\np.s. I'm making the assumption here that at some point the code does get\nreleased under a standard open source license (e.g., after 1 year). I\nwould never support using a license that didn't have this kind of\nprovision.\n\nOn 12/04, Aaron Wolf wrote:\n> @ariddell and if \"All large companies using the software who wanted to\n> get bugfixes would have to pay.\" is true, then you threaten the entire\n> core aspect of Open Source development where existing users can\n> contribute bug fixes etc. and have an ecosystem like that. And could\n> end up with a fork like MySQL / MariaDB etc. because the community\n> wants to participate and doesn't want this sort of half-assed\n> situation.\n> \n> --- Reply to this email directly or view it on GitHub:\n> https://github.com/pybee/paying-the-piper/issues/61#issuecomment-162010235\n"}}