Supported Source – Great Software Projects Deserve Great Support
supportedsource.org
supportedsource.org
Except for being completely incompatible with both the Open Source Definition and Free Software definition, incompatible with any copyleft license, and otherwise incompatible with the entire FOSS ecosystem.
OSD #5 and DFSG #6 specifically prohibit restrictions on commercial/business use, as does the FSF's Free Software Definition ('“Free software” does not mean “noncommercial”.')
I've seen many attempts at this come and go, and they all have this same fundamental problem.
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.
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.
- 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.
Distributing free software is an opportunity to raise
funds for development. Don't waste it!
Just because it's free doesn't mean you have to put it on a public server for anyone to download. It's perfectly within the definitions of the open source and free software licenses to only distribute the software to paying customers.
Or maybe it's impossible to do this now because the internet has made it trivial to redistribute software, I don't know.
I've seen some projects which receive some funding by charging for compiled binaries, but that revenue is for the additional service of compiling/supporting the use of pre-compiled binaries IMO.
Everyone nowadays just puts up all of their source code online without asking money for it. Nobody even tries to sell it. I also think perhaps buying software in general is becoming a bit of an outdated idea. Everyone wants to sell subscriptions now.
I personally don't have a problem with a license that allows a user to modify source code, and run modified source code, but only after paying a fee. It seems to me DOOM mods work like this already, the code is free, but the game resources like textures etc can only be used after paying for a license. Id software gets paid, people can hack all day on the game, seems like win win to me.
Commercial open source tends to be done for two reasons:
1. Common goal development. Several companies needs a UNIX. Rather than do all the development themselves, they work together. That's how Linux works. 2. Backup if original company's strategic goals move from your goal.
Here, neither work as you can't cooperate with others due to licensing issues.
But you also can't just take parts of the code and redistribute it for free, because "Restricted Uses. The license should include restricted uses, such as disallowing resale or sublicensing."
The point isn't to prevent people from customizing their use of the software. The point is to create a system where developers get paid and projects are financially sustainable, instead of being abandoned or barely maintained.
The problem is that's actually one of the main powers of Open Source - the ability to fork it past the desires of upstream.
For example, I use Windows, which is "supported source". OK. Microsoft decides to put spyware. Now I need to rip it out. OK. Did so.
Now, one day later, Windows gets updated.
I have to go through the code again.
If it would be "Open Source", I'd just fork it. But now, I can't even share modifications (is it a derivative work?).Now every user would have to go through the code, find the privacy violations, and re-compile it.
Also, what happens Microsoft get's fed up and fully closes source (no more updates to "Supported Source", and they drop out of the program)? Each user has to keep up his version of Windows?
Not too useful.
If you think about it, how are there commercial communities around Apache/MIT/BSD?
Because no one wants to upkeep his fork, so they contribute code back so others can help maintain it.
That freedom can only be maintained by the ability to fork.
(Note: I'm not going to talk about software freedom here, which is a subtly different perspective. I just want to talk about open source). The idea behind open source is that when I decide to use the software, I am not locked in to a single vendor. Not only do I have access to the source code, but I have permission to modify it and distribute it for any reason that I want.
It's that advance permission for modification and distribution that de-risks your project. If, in the future, I want to do something differently than the original author, I can. For example, imagine that I tie my infrastructure in to version 2 of the software, but they release version 3, removing most of the functionality that I depend on. I want to use version 2 and backport security changes from version 3 into version 2. Similarly, I want to distribute my changes so that anybody else that's in the same boat can pitch in on the backporting effort.
So, as an author, you give up some control of the ultimate destiny of your code. There are some advantages as well, though. If your customers take advantage of their ability to add features of their own choosing, you have turned customers into collaborators. In that way, you have a kind of consortium effect. However, you are in a privileged position, because you still own all the trademarks wrt to the project. So even if someone starts to compete against you, they can't piggy back on your marketing and sales efforts. Not only that, but if you choose a copy-left style license, they can't effectively compete unfairly against you because all of their modifications are also usable by you.
So it's a kind of balancing act. You get this low barrier of entry for participation of your customers and they get a substantially de-risked product.
There are lots and lots of licenses out there which permit the viewing of source code. It has been very popular with game engines for a long time now. Microsoft made the attempt (now abandoned, I think) of have the "Shared Source" license. Even back before free and open source was a thing, source code was often available, though there was no explicit license to use it.
This is not a "better" open source. It is objectively much worse at fulfilling the goals of open source software. Like I said, I don't care if they want to use licenses like that. I won't use their software, nor will I recommend that people accept a license like that. But I don't have a problem with them existing. I do have a problem with them pretending that what they have is an improvement on free and open source software.
> Open source is public source that's monetarily free
This isn't really true, as you really can charge for free software as much as you want, but you also can't forbid people from redistributing it without paying for it. This is why you can't download from RedHat's repos without paying for access, but also why CentOS can exist. (I have also heard that RedHat threatens to terminate your access if you exercise your redistribution rights, but I am not sure this is true.)
I guess "supported source" is a statement that there is only room for one Red Hat in this world, and everyone else must restrict redistribution.
Great question. We just consider ourselves to be a normal company that happens to build open source tools. We also try to make money in ways that don't interfere with the open nature of what we build.
There are lots of different kinds of companies whose engineers primarily work on open source projects. In most cases where their core "product" is an open source technology they also sell commercial support, usually to large companies who need an SLA. Others (like us) sell managed services as well.
We made the decision before we started the company to make anything we ever asked users to run on their own machines permissively licensed open source and just be careful with our trademark (like Mozilla is[1]). That leaves the door open for closed-source SaaS in the future but gives our users (and investors) a clear set of expectations about how and what we'll build.
I think it's important for companies to be as clear as possible about how and why they license their code, what choices they'll make in the future, and what happens when the company changes hands. It would be great to see something like an "open source pledge" where founders/the company could contractually commit to either a final open source release before closing (like Parse did[2]) or staying open after being acquired (like Sun didn't after being acquired by Oracle [3]).
[1] https://www.mozilla.org/en-US/foundation/trademarks/policy/ [2] http://blog.parse.com/announcements/introducing-parse-server... [3] https://en.wikipedia.org/wiki/Solaris_(operating_system)#Pos...
edit: We tend to avoid calling ourselves an "open source company" which can get confused with the "open company" movement[4].
I like the idea, strongly. But I am a bit apprehensive about how the projects that sign up for this may exploit it; especially considering how some projects put up a facade of being open while important bits and portions remain closed.
On the other hand, if such a project becomes used to being paid for its visible-source bits, and paid a bit more for the hidden-source bits, I suspect they'd see little incentive to remain on the Supported Source platform and instead move entirely to hidden-source. "They're paying for it anyway. Why give away our code for cheaper, when we can keep it and charge more!"
Other people have talked about the developer side, but not-quite Open Source doesn't necessarily work for users, either. Open Source is often less about money than convenience: the difference between totally free and $1 is sometimes all the difference. If Product A is FOSS under a OSI-approved license you can use it everywhere: you can try it out at home and on personal projects, install it on your machines at work, perhaps try and get your company to standardize on it, and work with third-party services that use exactly the same software. Once there's a form or a fee then there's meetings, and paperwork, and hassle.
Looks just like an intermediary to sell licenses.
Can anyone explain how pull requests would work in this situation?
Does part of the pull request sign the contribution over to the original license holder? How iron-clad is that? I can just imagine how much legal headache that could cause if a contributor decided that they owned part of the software.
I'm also curious about accepting pull requests in this way. Implicitly, the project owner takes over responsibility. In this respect, regular open source projects benefit from a lack of "official" support to begin with: if the PR does something that causes a complete breakage at some point, it's considered par for the course and fixed in due time. If however, something breaks with commercial software, there is a pretty high burden on the vendor to fix it.
I have worked in commercial software for years. It's a constant struggle as it is to say No to feature requests (for various reasons: not worthwhile, very hard to support, going in opposite direction of roadmap, etc). The worst are from the technical customers who say things like "why don't you just.." but don't understand the other ways the software is used (maybe by their competitors) with which their change is incompatible.
I imagine it would be an order of magnitude harder to say No to a full fledged pull request, and there would be immense pressure to accept it, since after all, the work is already done.. except that also means taking on the burden of maintaining and supporting it.
Anyone have experience accepting contributions from customers for commercial software?
The ongoing maintenance of the contribution is definitely an interesting question. That is the same with classic OSS projects too, though. I know a number of projects that are going towards making a pluggable core with plugins maintained externally to reduce this burden.
I've had a related idea for a while, setting up SaaS for FOSS maintainers to charge for a SLA (license/source is still open, corps essentially have some security that the project won't be abandoned). Is there anything out there like that?
I like the idea of a paid-source licensing program. I just don't know how it could work, long-term.
Next time you're thinking of releasing some code under an all-permissive license, consider using a copyleft license instead, which leaves you with options in the future.
My personal view is that governments should take the lead in paying for development of OSS (http://www.oss4gov.org/manifesto - full disclosure I run this site (badly))
I remember seeing an interview with Karl Lagerfeld. As many people know, there is no copyright on fashion designs. That means that when he makes a design and sells it, virtually the next day there are knockoffs in the market. They asked him if this upset him. He said (and I paraphrase), "No. People who would buy those knockoffs are not my customers".
In other words, if you don't care about the Karl Lagerfeld brand, or if you don't have enough money to afford his brand, you might buy a knock off bag. This doesn't really affect his sales because you wouldn't have bought his bag anyway. Similarly, people who want to buy his bag, will not buy a knockoff -- no matter how cheap it is. They are his customers.
In the same way, as a software author, it is not actually difficult to get paid for free software. The main thing is you have to ask to get paid. If you are the author of a major piece of software, people will pay you for that work. Those people are your customers.
The main thing (very much like fashion) is that only some software will attract paying customers. This isn't really a problem with the license. As a programmer, locking your customers in so that they can only turn to you for help is not necessarily going to increase your sales. What you really need is exposure. You need to be popular. This is where open source works well.
With open source, you have a very low barrier of entry for your potential customers. They also have a very low risk profile. They can use your code, or even parts of your code and if it doesn't work out, they can replace it cheaply. Again, as a programmer without access to lots of marketing money to bring in customers, I think this is going to help you out a lot better than locking your customers in to your platform.
The key here is that once you have exposure and your project is popular, then you can ask your customers to pay for new work. Experience has shown that people who can afford to pay, and who value your work will actually pay. Just like the fashion industry.
Where things diverge is when you are not a programmer. Let's say, you do not want to make money from writing code. Instead you want to make money from code as an asset. You have a bunch of source code that is already written and you want to treat it like it was a bushel of apples (err... a kind of endless bushel of apples, since you can sell it over and over again). In that case, you absolutely do not want to allow competition -- because anybody can sell a bushel of apples (endless bushel's of apples are especially appealing, it seems).
So, if you are saying to yourself, "How do I get paid for writing free software", I really don't think this is going to work (especially since it isn't free software!) You are raising the barrier to entry for your customers. This is going to make your project less attractive, not more. The only people this can potentially help are non-programmers who want to reduce competition with their proprietary software.
When the change to a funding model happens, who is specifying what is being worked on? who is benefiting from the new work? who would be expected to pay? What about backlash from the change in how the project evolves?
In fashion people expect to pay for things and pay quite a lot to get what they consider to be quality. Do you think a similar attitude exists in the average user of open source software?
As for the tail of your post, I'm confused. Are you trying to argue that the code is what is of value here or are you trying to argue that the work the developer can put into it is valuable? (from a funding standpoint)