But if you do this "supported source" thing, you wouldn't be making a living off of open source, you'd be making a living off of proprietary software, which changes nothing.
But you'd be making a living, if companies want your software enough to buy it. If it's FOSS, companies could and often would profit from its use without paying you for it. Sometimes they even demand support without paying for that: http://www.coglib.com/~icordasc/blog/2015/11/corporations-an...
Couldn't there theoretically be a license that allows open source projects to use it and remix it, but business usage must be sub-licensed? There are some downsides, but I'd be willing to consider that if it meant more sustainable funding sources for those contributing the most to maintenance.
I don't think that's possible in the spirit of open source or free software.
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.
"Couldn't there theoretically be a license that allows open source projects to use it and remix it, but business usage must be sub-licensed? "
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).
Of course they can do things with it. Non-commercial users could run it for free. Commercial users could run it after paying the licence fee. Programmers could contribute to the project and be paid a share of the revenue.
You could rewrite portions, fix portions, do extensions, and contribute back any of these to developer. These are quite advantageous esp if it's small enough for customers to understand. One of the first systems to send the source to customers and accept good contributions into next release was Burroughs B5000: a 1961 mainframe that cost more than a house.
> You could rewrite portions, fix portions, do extensions, and contribute back any of these to developer.
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.
Oh, Im not talking about this license. Im talking about how to do a hypothetical license combining payment and OSS-like advantages. In terms of what you asked, you could word license as such that they could do about anything they wanted to it... from applying local mods to distributing them... so long as the users are paying customers. Optionally, getting perpetual use of each year's release if longevity is an issue.
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.
Is that not better than adopting a more classic proprietary model where the source code isn't 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).
If it's not Open Source, better that it not look Open Source and cause confusion. See also the various "Shared Source" schemes over the years, which caused similar confusion.
I've seen that report; I don't think I'd characterize its description as "unsustainable" so much as "needs further attention".
OK, suppose I have some software which is well written, works straight out of the box, and doesn't require any support. I'm quite happy for people to use it, but would like a share of any revenue commercial users gain through its use. With FOSS, if I give it away, I won't get any. If I sell it, there's nothing to stop the purchaser from giving it away, so I get paid once before seeing my work being given away.
Various common models, in order of simplicity and effectiveness:
- 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 don't see any way of legally enforcing payment for the use of software released under the terms of the GNU GPL. Points 2 and 3 have the risk of being undercut, though they might work in some cases. Point 4 might be valid, but once its released there's no further guarantee you'll be paid.
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.
In a similar discussion, someone working for OpenSUSE pointed out that their business model is selling FOSS. They make about $20+ million a year. Red Hat even more despite the fact that CentOS is basically Red Hat for free. You have a potential advantage in the enterprise market where companies are hesitant to take free software since they want someone to be responsible for it. They'll pay you for GPL stuff if they can call you for improvements or fixes.
For the first point, it applies when releasing code other people will want to link to, such that the GPL would apply. It doesn't help with a standalone program that nobody wants to build on or derive from; you'd need the other cases for that.
I'd say a lot of it varies on who the audience is. Many FOSS projects try some form of crowdfunding at some point and I think a good detailed summary of the methods that they try are documented at: https://snowdrift.coop/p/snowdrift/w/en/othercrowdfunding
- 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).
- 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.
This is especially true with "app stores"; it's sufficiently difficult to get apps into the Apple and Android stores, and sufficiently common to have adware-laden variants, that people will pay for an official version linked from the main project site.
Also true on other platforms where people don't commonly have access to a compiler, such as Windows.