6 ms·

I highly recommend you go for an open core model: gpl core + commercial proprietary add-ons. From direct experience, selling GPL code rarely works. And when it

I highly recommend you go for an open core model: gpl core + commercial proprietary add-ons. From direct experience, selling GPL code rarely works. And when it does, you know you're leaving a ton of money on the table (for no reason).

jacobmartin 5y ago
Honest question (I am totally ignorant about these things): If you did this, would you be able to accept patches from the community on the open core? Or would releasing your proprietary code violate the GPL of the coder who sent the patch?
- orangeshark 5y ago
  You usually require them to assign copyright back to you so you can still use it in your proprietary version.
  - jacobmartin 5y ago
    Ah, makes sense. Thanks!
- heavyset_go 5y ago
  You'd only accept contributions under a CLA that assigns copyright to you or your company, allowing you to distribute the code and its derivatives in any manner, and under any license, you want.
  - jacobmartin 5y ago
    That makes sense. Thanks!
  - hakre 5y ago
    Only to yourself with all rights reserved to yourself, too. You then transfer the license to an oversea entity that then licenses back to your majority owned company. This is the professional business with software licenses as there is no physical good to ship, it is in principle a good way to transfer money accepted as a common business transaction (paying licensing fees), supported by tax laws for international trade (e.g. often various tax exemptions).
- vegetablepotpie 5y ago
  I would say that it depends on how the core and addons are attached and how the core is licensed. If the core is a library, and licensed under LGPL, the proprietary add ons can dynamically link to it without issue. You could take community contributions. This would not be true if the library was GPL. Anything that links to GPL has to be GPL compatible (make source code available). If the proprietary addons are libraries and the core links to the addons, the users could violate the GPL when they link to them, unless you as the original author of the core, specifically enumerate the addons in the license you distribute to them. You would not be able to take community contributions in this case. If the core communicates to the addons without adding the addons to its assessable region, such as talking over pipes or sockets, you would have no licensing issues even if the core is GPL and has taken community contributions.
  - J-Kuhn 5y ago
    You can also ask for joint copyright ownership for community patches. In this case, you can choose the license for your own binary distribution. And you can change the license if/when it becomes necessary.
    - vegetablepotpie 5y ago
      I’m not familiar with how that works. Would you ask contributors to give you a traditional copyright license to their code (world wide, royalty free, non-expiring, right to redistribute, modify and sub license)?
heavyset_go 5y ago
One model that's worked for me, at least for desktop software, is to release an AGPLv3 core and minimum version that works on Linux, and charge for Windows and macOS versions that are proprietary. If you go the route of using an (A)GPL core, make sure all 3rd party contributions are made under the terms of your CLA, or otherwise reject them.
- newjersey 5y ago
  > If you go the route of using an (A)GPL core, make sure all 3rd party contributions are made under the terms of your CLA, or otherwise reject them. If someone goes down this route, does the rejection have to be automatic? Does looking at a pull request without a CLA "taint" me in a way that I cannot implement it again? I am asking partly because I am curious and partly because I remember Drew DeVault (sircmpwn) used to have a big scary warning saying if I have looked at the official minecraft code, I should not contribute to truecraft (now archived I believe). These are things I never worry about at work. I can look at stack overflow and copy x.filter(x => x.blabla...) and change the bla bla until my javascript works (I don't use filter every day so it is difficult to remember this syntax in my head). Thank you in advance.
  - rascul 5y ago
    Your comment intrigued me so I did a slight bit of digging. > I remember Drew DeVault (sircmpwn) used to have a big scary warning saying if I have looked at the official minecraft code, I should not contribute to truecraft (now archived I believe). The repository is indeed archived, but is still available on GitHub. It was changed in 2015 [0]. The older notice is as you recall: > Pull requests will be rejected from authors who have read any decompiled official Minecraft code. The current notice [1] adds some other ways the formerly rejected developers could get involved: > If you are a developer, you have two paths. If you have not read the Minecraft source code, you are what we call a "clean dev", and you should stay that way. If you have read the source code, you are what we call a "dirty dev", and the way you can contribute is different. If you are a clean dev, you're welcome to contribute to this repository by adding features and functionality from Minecraft Beta 1.7.3, fixing bugs, refactoring, etc - the usual. Send pull requests with your work. > If you are a dirty dev, you are more limited in how you can help. You can work on projects that are related to TrueCraft, but not on TrueCraft itself. Direct contributions that you can participate in includes the website and the artwork. You can also work on things like helping to build a community by spreading the word, participating in IRC or the subreddit, etc. You may also work on reverse engineering Minecraft to provide documentation for clean devs to use - see reverse engineering guidelines on the wiki for details on how you can do this. Under no circumstances may you ever share any code with a clean dev, decompiled or otherwise. [0] https://github.com/ddevault/TrueCraft/commit/fcfd3886746fd1f6f8b5160afbe068f1921221a9#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5 https://github.com/ddevault/TrueCraft/commit/fcfd3886746fd1f... [1] https://github.com/ddevault/TrueCraft#get-involved https://github.com/ddevault/TrueCraft#get-involved
eesmith 5y ago
The author says "I'm a firm believer in free software." I interpret that as someone who has a firm belief that proprietary software is immoral, or at the very least, distasteful. That would include being opposed to the proprietary add-ons of an open core. And that would be a reason to leave money on the table. (Analogously , I have a relative who owned a grocery store and refused to sell tobacco products, believing that doing so was immoral.) In general, I think open core is an advertising model. In broad strokes: "Free software" uses a moral argument against proprietary software. "Open source" uses a cost/benefits argument that open source development is more effective than proprietary. "Open Core" uses the profits from proprietary add-ons to subsidize the open source component, which is the loss-leader marketing the proprietary add-ons.

jacobmartin 5y ago

Honest question (I am totally ignorant about these things): If you did this, would you be able to accept patches from the community on the open core? Or would releasing your proprietary code violate the GPL of the coder who sent the patch?

orangeshark 5y ago
You usually require them to assign copyright back to you so you can still use it in your proprietary version.
- jacobmartin 5y ago
  Ah, makes sense. Thanks!
heavyset_go 5y ago
You'd only accept contributions under a CLA that assigns copyright to you or your company, allowing you to distribute the code and its derivatives in any manner, and under any license, you want.
- jacobmartin 5y ago
  That makes sense. Thanks!
- hakre 5y ago
  Only to yourself with all rights reserved to yourself, too. You then transfer the license to an oversea entity that then licenses back to your majority owned company. This is the professional business with software licenses as there is no physical good to ship, it is in principle a good way to transfer money accepted as a common business transaction (paying licensing fees), supported by tax laws for international trade (e.g. often various tax exemptions).
vegetablepotpie 5y ago
I would say that it depends on how the core and addons are attached and how the core is licensed. If the core is a library, and licensed under LGPL, the proprietary add ons can dynamically link to it without issue. You could take community contributions. This would not be true if the library was GPL. Anything that links to GPL has to be GPL compatible (make source code available). If the proprietary addons are libraries and the core links to the addons, the users could violate the GPL when they link to them, unless you as the original author of the core, specifically enumerate the addons in the license you distribute to them. You would not be able to take community contributions in this case. If the core communicates to the addons without adding the addons to its assessable region, such as talking over pipes or sockets, you would have no licensing issues even if the core is GPL and has taken community contributions.
- J-Kuhn 5y ago
  You can also ask for joint copyright ownership for community patches. In this case, you can choose the license for your own binary distribution. And you can change the license if/when it becomes necessary.
  - vegetablepotpie 5y ago
    I’m not familiar with how that works. Would you ask contributors to give you a traditional copyright license to their code (world wide, royalty free, non-expiring, right to redistribute, modify and sub license)?

heavyset_go 5y ago

One model that's worked for me, at least for desktop software, is to release an AGPLv3 core and minimum version that works on Linux, and charge for Windows and macOS versions that are proprietary. If you go the route of using an (A)GPL core, make sure all 3rd party contributions are made under the terms of your CLA, or otherwise reject them.

newjersey 5y ago
> If you go the route of using an (A)GPL core, make sure all 3rd party contributions are made under the terms of your CLA, or otherwise reject them. If someone goes down this route, does the rejection have to be automatic? Does looking at a pull request without a CLA "taint" me in a way that I cannot implement it again? I am asking partly because I am curious and partly because I remember Drew DeVault (sircmpwn) used to have a big scary warning saying if I have looked at the official minecraft code, I should not contribute to truecraft (now archived I believe). These are things I never worry about at work. I can look at stack overflow and copy x.filter(x => x.blabla...) and change the bla bla until my javascript works (I don't use filter every day so it is difficult to remember this syntax in my head). Thank you in advance.
- rascul 5y ago
  Your comment intrigued me so I did a slight bit of digging. > I remember Drew DeVault (sircmpwn) used to have a big scary warning saying if I have looked at the official minecraft code, I should not contribute to truecraft (now archived I believe). The repository is indeed archived, but is still available on GitHub. It was changed in 2015 [0]. The older notice is as you recall: > Pull requests will be rejected from authors who have read any decompiled official Minecraft code. The current notice [1] adds some other ways the formerly rejected developers could get involved: > If you are a developer, you have two paths. If you have not read the Minecraft source code, you are what we call a "clean dev", and you should stay that way. If you have read the source code, you are what we call a "dirty dev", and the way you can contribute is different. If you are a clean dev, you're welcome to contribute to this repository by adding features and functionality from Minecraft Beta 1.7.3, fixing bugs, refactoring, etc - the usual. Send pull requests with your work. > If you are a dirty dev, you are more limited in how you can help. You can work on projects that are related to TrueCraft, but not on TrueCraft itself. Direct contributions that you can participate in includes the website and the artwork. You can also work on things like helping to build a community by spreading the word, participating in IRC or the subreddit, etc. You may also work on reverse engineering Minecraft to provide documentation for clean devs to use - see reverse engineering guidelines on the wiki for details on how you can do this. Under no circumstances may you ever share any code with a clean dev, decompiled or otherwise. [0] https://github.com/ddevault/TrueCraft/commit/fcfd3886746fd1f6f8b5160afbe068f1921221a9#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5 https://github.com/ddevault/TrueCraft/commit/fcfd3886746fd1f... [1] https://github.com/ddevault/TrueCraft#get-involved https://github.com/ddevault/TrueCraft#get-involved

eesmith 5y ago

The author says "I'm a firm believer in free software." I interpret that as someone who has a firm belief that proprietary software is immoral, or at the very least, distasteful. That would include being opposed to the proprietary add-ons of an open core. And that would be a reason to leave money on the table. (Analogously , I have a relative who owned a grocery store and refused to sell tobacco products, believing that doing so was immoral.) In general, I think open core is an advertising model. In broad strokes: "Free software" uses a moral argument against proprietary software. "Open source" uses a cost/benefits argument that open source development is more effective than proprietary. "Open Core" uses the profits from proprietary add-ons to subsidize the open source component, which is the loss-leader marketing the proprietary add-ons.