Earlier this month, there was some talk of the "free software company" and what that might mean.
I work in an interesting variant of this concept, namely in a company (the Danish company Magenta, see magenta.dk) which, according to its mission statement, may only deliver software under an OSI-approved license, practically speaking either GPL or LGPL version 3 or Mozilla Public License version 2.
It's not a "free software company" in the sense that we only *use* free software - new employees are free to choose their operating system and favorite programs, and while most developers use GNU/Linux, some prefer OSX or Windows, and that's completely OK. What matters is that none of the software that we deliver to customers is under a non-free license.
I wrote a blog post about that, and I hope to be able to elaborate on our practical work with free software in future posts:
http://blogs.fsfe.org/agger/2017/01/24/working-with-free-software/
Hi agger,
... may only deliver software under an OSI-approved license, practically speaking either GPL or LGPL version 3 or Mozilla Public License version 2.
I'm wondering about your long-term monetization . I presume that you're charging fee for your software. Let's say that you deliver under MPL 2.0. Are you not concerned/afraid that your competitor might lap it up, use it in their own product and put you out-of-business? Since it is MPL 2, your competitor needn't disclose their source code.
-- Satish Bysany
Hi Satish
Thanks for your response?
... may only deliver software under an OSI-approved license, practically speaking either GPL or LGPL version 3 or Mozilla Public License version 2.
I'm wondering about your long-term monetization . I presume that you're charging fee for your software.
We're not charging fees for our software, i.e. not as such. A customer will approach us and want us to develop some product - which could range from a complex GUI-based custom application to a simple web site in Plone and Drupal, and we'll make them an offer and charge them by the hour. A typical offer might, from our perspective, be "450 hours' work". In that sense, the software is gratis, but our work is not.
If other customers want the same application, once we made it for the first one, we would make them an offer for installation + customizations to fit their own processes, and that might be e.g. 80 hours or even less, since the first customer already paid for the bulk of development.
This does not disadvantage the original customer in any way, since the new project is likely to lead to new features as well as bug fixes which they can get as part of their support contract.
Let's say that you deliver under MPL 2.0. Are you not concerned/afraid that your competitor might lap it up, use it in their own product and put you out-of-business? Since it is MPL 2, your competitor needn't disclose their source code.
First of all, MPL 2.0 is copyleft on a per-file basis. I.e., changes to our source files would have to be shared with the customer. In any case, even if the software was GPL, the competitor would never be required to share the source code *with us* - the requirement only applies to whoever they deliver their software to.
Secondly, many of our products are complex and require considerable domain knowledge, which makes it an expensive proposition; indeed, if another vendor would like to continue work on one of our products, the most logical thing for them would be to ask us about the how and why of various settings and choices. For that, of course, we would (happily) charge them by the hour.
Thirdly, if one of our competitors were to continue work on one of our products, they'd likely have to fix bugs and stress test it in various ways, and that would normally be an advantage for us. And their product would in all likelihood also be free software, and in that case they'd improve the quantity of software available for our customers, hereby also improving our reputation and our chances of selling *new* systems.
So no, even though I can see where you come from, it's never been a problem. Also note that our software is normally specialized and thus not "commodity" software. But I don't know if that actually makes a huge difference. We'd gladly develop and support a commodity program if someone were to pay us for doing that.
Best Carsten