“There are many different reasons for contributing to open-source software, and these reasons should be respected to the largest extend possible.” -From Article linked below

Link

If you are thinking about providing consulting, then the primary way to build your business with software is to get the software popular. If the software is popular and respected, you might be able to get consulting gigs to extend it, or more likely it will be a way of building business associations and justifying a higher rate. You can also basically charge for “solutions”, where you charge based on the value of the work to the customer, not on the amount of work you put in. This is kind of what licensing fees are meant to do, but the customer probably doesn’t care about that. So long as you are charging a competitive rate and providing good value, the justification for your rate is less important. Consulting companies around Plone tend to work like this. It’s up to you to invest in your own infrastructure — and it’s an investment, as it’ll be a resource sink to start, and might pay off later if your software infrastructure really does help you do development.

There’s a small number of companies that make monkey with extensible GPL software where they sell a proprietary-compatible license. It never seems to work all that well, and for many domains I don’t see how it would work at all.

So… those are my general thoughts. I don’t think licensing factors in that much.

As to how I do it, I have the fortune to work for a non-profit, The Open Planning Project, who has as part of its mission the production of open source software. Before that I did most of my work basically as a hobbyist, without any particular mind to making it profitable.

How do you think about these things? Sorry for the indiscreet question, but Ian how do you finance the work on your wonderful software projects?

At first the only communication from Apple after they forked KHTML was in the form of tarball dumps. This was mostly ignored for a while, then (sometime around Acid2) the bad blood got aired in the KDE community and gained a bit of blog publicity.

After some discussion Apple was sort of willing to open up its bug tracker, then they took the plunge and today’s webkit seems an open and healthy project.

While the LGPL wasn’t enough to get this result, it certainly wouldn’t have happened without it, either.

As an example, someone expressed concern that maybe a build tool I was working on might be GPL, and then they wouldn’t want to use it. This wasn’t based on any rational reason, as there’s nothing particularly proprietary about how people use build tools. And build tools should be open source simply out of respect to the people deploying the software, who might need to debug your code.

If you build a proprietary application with a GPL’d tool, that doesn’t extend the GPL to your application, and no one is trying to assert that kind of control over other people’s code. At least no open source developers — this does come up from time to time in proprietary development, but as I said, if you are looking for someone to distrust it’s the proprietary environments that deserve it.

Another unfounded fear is that a little GPL code will have a viral effect on a proprietary codebase. This fear is also unfounded. If you accidentally include some GPL code in some section of your application you’ll have the opportunity to just remove it, reimplement it, no one is going to relicense your code without your permission because of that. I say this not as a lawyer, but because this is what happens in practice. There simply aren’t cases of the GPL being viral like this, except when GPL code forms a substantial portion of the codebase in question. In all cases GPL licensing issues have been resolved through negotiation, not through court cases.

People make a hard line about the GPL that is totally unjustified, and that’s what bothers me. Mostly I think it’s either based on ignorance or it’s part of a hidden ideological agenda. Or it’s stupid legal departments that want to assert their importance by being obstructionist. Well, that and a tendency of programmers to make specious logical arguments about the law, because programmers tend to think that the law is based on logic instead of reason.

Making your source available is the norm in python world, and you can freely mix licenses due to the fact that the files are kept separate.

However for C/C++ programs the situation is quite different. If you include headers of any GPL’ed libraries, the preprocessor effectively writes gpl’ed code into the top of your source code. Therefore, you have to license your code as GPL, which is why LGPL exists. My big problem with this is simply, I want to have the choice of my own license with an app and have a big issue with being forced to use someone elses license.

What to use, then? Well, at 20 lines, the MIT license has much better chances to actually get read and understood by people, and can be easily included in full at the top of every source file. The BSD license has similar qualities - it’s a matter of taste as far as I can tell - and for one project I even adopted the Mu license:

> If you are asking what license this software is released under, you are asking the wrong question.

which, I think, makes for a great moral statement, though it’s probably worthless as legal protection. Or precisely because of that?

All in all, I’m for a laid back attitude regarding “intellectual property”.