Have something to say?

Ready to be published? LXer is read by around 350,000 individuals each month, and is an excellent place for you to publish your ideas, thoughts, reviews, complaints, etc. Do you have something to say to the Linux community?

OpenMFG license is non-compete - Lose freedom if I touch it

The source code license I'd get if I bought into their system would prohibit me from ever participating in the development of a real open source ERP, or any other ERP for that matter.

Still haven't found a good real open source ERP that fits the business model of the company where I work. Closed source vendors tend to be real assholes. They have you over a barrel and are ready to take it to the next level. Got quoted $3000 to fix a credit card processing BUG in our current ERP (not OpenMFG), which should not have required more than a few lines of code. Since we're not big fans of paying $12k per hour for bug fixes, I ended up fixing it myself by writing a proxy to block or modify the bad transactions, which went into production the same afternoon. In this case, OpenMFG would have been a good choice _if_ I was confident that I'd never want to work on any other ERP ever in my lifetime.

Given the going rate for creating bugs and charging customers individually to fix them, this ERP market looks very promising, and I wouldn't want to lock myself out of an opportunity to trick small and medium businesses into reaching over that there barrel towards their goals of improving efficiency, accuracy, and productivity with a solid, mature ERP vendor watching their backs.

I think you're misunderstanding pieces of our license. Sure, it prohibits you from developing another ERP system while you're a licensee of OpenMFG. But it's hardly the case that you couldn't do so "ever in your lifetime." Only while you're actively in business with us - I think that's reasonable.

And we do try to go out of our way to let people know we understand the difference between FOSS and what we do.

Both the EULA and the VAR/SI partner agreement provide for full source code, and the ability for enhancements to come back into the mainline supported product. If you're a VAR, it's a ticket to ongoing customer-paid development work (as well as support and other services), and you've got the vendor standing behind you after the code goes live. Unlike "pure" open source, also, there is a commissionable license fee - so that's additional money in the VAR's pocket.

We think it's a good model for ERP, which is by its nature heavy on customization and services. If you'd like to take a look for yourself, we make a fully functional demo client available for download (Linux, Windows, or Mac OS X client), at http://www.openmfg.com.

"5. Prohibitions
...
5.7. Develop or contribute to the development of a software application that competes with the Software."

So if someone is a developer for a company that uses OpenMFG, and they've seen the OpenMFG source, they're allowed to quit their job and develop their own ERP? Or is there some unwritten waiting period? Or what if they don't quit their job, but are just writing scripts to customize a new competing ERP system they're migrating to?

No, I'm happy to have the debate. Let me say first, IANAL. But I'd re-emphasize the fact that the EULA is a contract between OpenMFG and a company that licenses the use of the software. I don't know how much we'd be able to do about an employee of a licensed customer quitting his job and going off to write his own ERP system.

As someone who's been involved in the writing of an ERP system for more than a few years, of course, I'd counsel him against it ;-)

I'd also point out that our VAR/SI agreement talks in more detail about how that relationship works, including selling services around an OpenMFG implementation, and incorporating larger code contributions than are contemplated by the EULA.

We've had a number of both VARs and end-user customers now submit enhancements under these terms - and it seems to be working pretty well. One of the big headaches in ERP has always been the "customization trap" - particularly with the bigger packages. It's pretty easy to get out of sync with the main vendor package, especially if you're the rare bird that actually got a source code license. Our approach is to kind of mimic an open source development methodology - where customers and partners are contributing members of the community - and we act as the "core team," layering on all the things you'd expect from a commercial vendor (QA, docs, support, etc.)

We frankly don't spend a lot of time worrying about someone stealing the code and running off to build YAMFG. We've tried to build the business around mutually sustainable value propositions (for customers, partners, and us) that would make it silly for someone to even try.

Change your stategies. Instead of trying to sell a complex and disfunctional solution, go with GPL. A totally open source ERP will rock the market. You'll discover that if you give it away, you'll get more users than if you put feet on the street.

You may get contributions otherwise, but nothing like the market coverage from making it free (not as in beer).

Be coachable. Please read my other post.

I had some great mentors in my day. One said good men learn by experience. Great ones learn by the experience of others too.

I want to make my comments a little stronger. Your package looks really good, esp. since it offers such a wide range of modules.

I think you could really clean up if you could harness all those people out there who use home-grown systems like we used to use. My former company had 200 employees and ran about a 1000 parts per day through a repair and remanufacturing operation. As I said, we had a staff of nine full-time IT people.

Just imagine if your product was open source and only a few such companies joined in. You could leverage the power of 100s if not 1000s of programmers. The great thing about ERP is the large volume of transactions that get run through it. An active open source community pounding on your code in production would quicly hone it to a razor's edge. With all that help you would have a shot at owning the category.

I have to admit up front that I'm as ignorant as a stump regarding "ERP".

IIUC, the current model OpenMFG is using is to sell licenses to customers to use code and to accept patches, etc., from those customers to improve the code for the use of which they pay a license fee.

If such code were GPL'd, would a service model be the replacement for the license fee model?

Are there a great many potential "ERP" customers who would need someone to install, integrate and maintain such a system, compared to the number who would be able to be active participants in the GPL project?

Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]