No, those two requirements are incompatible.
I'm in favor of the goal here, just not this particular method.
If I under stand you correctly, projects that use a commercial-paid/non-commerial-free project as a dependency would also be required to use a compatible business-paid/personal-free license.
This is what people complain about re: the GPL.
It says that the most important thing is getting paid, and we'll throw the non-commercial people (non-profits, personal projects, etc) a bone, because maybe they'll contribute something back to us.
That's fine to do if someone wants to. But, it's certainly not free software. And, it's not open source either, except that the source is visible.
Like others have said, visible source it's all that helpful if you can't do anything with it.
Business should donate more to free software.
Yes. I think it's possible. I've proposed one here before that had all the advantages of FOSS, including remixes, so long as originator or owner of copyright continued getting paid. The main, remaining risk was rates getting jacked up due to inability to move off the product. An upper limit can be put into the license itself or terms fixed per version w/ perpetual license for that version. BSD or Apache licensed code could be integrated into such projects with contributions going to them under their license if commercial one merely interfaced with OSS subsystem. Finally, there's potential for time limits on how long a release stays proprietary with it going OSS after a period of time.
So, quite a few models can work. It should be noted that FOSS largely didn't work in terms of making good money or long-term maintenance of the software. Those that do are uncommon or rare. Easy with proprietary, shared-source software since you get paid if they really want it. :)
I think the point is that it would break license compatibility. You can't have other projects use it without either giving it away (in which case your own commercial use is broken) or having them switch to your license (their desires are broken).
I'm skeptical. Not sure how this can be useful.
Contribute back to the developer yes but it gets real iffy if they don't accept your patches that you need. Also really depends on the licensing regarding rewriting and fixing portions. Depending on the platform you're using you may need to shove that into a repository for delivery of your customized version; is that type of distribution going to be allowed?
I didn't see an explicit "here's the license all of our stuff uses" unless I missed it but a lot of these use cases could be pretty difficult IMO.
Many people already make a living working on Open Source, for a wide variety of companies. This project, however, doesn't help people make a living via Open Source; it encourages people to release code under a proprietary license with source code available.
I totally agree with the philosophical argument around OSS --but at the end of the day, people need to eat. If you're going to argue that we should all OSS our code, you need to specify a way to make it sustainable (see http://www.fordfoundation.org/library/reports-and-studies/ro... for more on the unsustainability).
I've seen that report; I don't think I'd characterize its description as "unsustainable" so much as "needs further attention".
- License it under a copyleft license. Works the same as what you describe, except s/commercial/proprietary/, and is completely compatible with the FOSS ecosystem. You get paid by any company (or individual) who wants to ship proprietary software built on your code.
- Work for a company that gains revenue by releasing the code, and pays you accordingly. For instance, a company that sells more hardware because of the code.
- As mentioned elsewhere in this thread, charge for compiled binaries, for the convenience of non-developers.
- Provide a paid service based on the code.
- Require payment up front before releasing the software (crowdfunding model). Only works before you write/release the software, and benefits from an established reputation.
I've thought about licensing issues, as I have software I'd like to release when it's ready, but I also would like to be paid for it by anyone who uses it to generate revenue for themselves.
Up until the early 1980s, system software development was paid for by various computer manufacturers, as it could only run on their machines. As a result of generic hardware and open-source software, hardly any similar work exists today.
- supportedsource.org requires you to put your code under proprietary license, which is bad because it's not open-source (If someone wants to fix a bug in your software, they can't do it).
- It is absolutely possible to sell open-source software: https://www.gnu.org/philosophy/selling.html
- The drawback is, people can put your software for free on BitTorrent.
- But companies will pay you because they want the original, genuine copy. They don't want to risk getting an unofficial fork where someone might have introduced a keylogger, and a lot of engineers actually prefer to retribute authors for their software. They actually pay the service that someone has code-reviewed what was merged into the software they get.
- If that's not enough for you, you can put a lock in your code and distribute the binary packages for a price. Yes people can remove the lock, but most companies aren't willing to recompile or even look at the code, and they'll pay. Plus, those that are willing to recompile already have their hands dirty, so they're twice closer to submitting improvements to your code ;) which is the meaning of "open-source".
In conclusion, don't use supportedsource.org, and just sell the packaged copies of your software.
Also true on other platforms where people don't commonly have access to a compiler, such as Windows.