I like your list of most useful pay-backs to an open source project. Here’s mine

1) Share my passion with friends; if I don’t share then I don’t enjoy as much.
2) Nobody gets hurt (that’s why you need a license– no warranty and no liability)
3) Code review and feedback.
4) Archival; Let my code see the light of day. So myself and others can google it at some point in the future.

Don’t need license restrictions for that. In fact, they prevent use on my future paid work.

Ta

Explain how, precisely. None of the cases you’ve cited support that view at all. The “Look ‘n’ Feel” cases were basically just an attempt in the early days to apply a patent mindset to UI design. They make no difference to us because we don’t have a Look ‘n’ Feel, and even if we did the situation is just like patents – what license we used make no difference to this sort of challenge.

The conditions under which copyright and patent lawsuits can be entered into on code are the same regardless of what license an open source product uses. Which is to say, if I copy someone elses source code, I’m in violation of copyright. If I copy their patented techniques, I’m potentially in breach of that. What open source license I used is absolutely irrelevant.

The *only* situation where LGPL has any additional traction is if someone modified the core of OGRE, and I wanted to copy those changes direct from their source code. Their changes would have to be released *to the recipient of their app* (not to me), but would still be LGPL so if I managed to get hold of them, I’d be able to use them – in theory.

But my whole argument points out that in 8 years, that has *never happened*. The only time I get useful contributions is when people volunteer them. I don’t go foraging in other people’s LGPL forks of OGRE, because largely they don’t exist, and even when they do, they’re not very useful. Volunteer contributions are consistently far more valuable than any coerced or externally ‘mined’ contributions.

If I chose to reimplement something (rather than copy the actual code) then we’re on patent ground, and in that case license (again) is irrlevant.

So I think you’re clutching at straws a bit here, citing cases that while valid in themselves, have no correlation with what license is used. It’s a bit of a smoke-and-mirrors argument to claim that somehow the (L)GPL licenses are less likely to be attacked in this way – I see no evidence of that at all. In fact, I’ve heard of far more threats against GPL software than anything else, although that may be just because of its popularity.

Neither copyright conflict went to court. DRI chose to go into hiding, MIcroSofT had something to barter and thus was able to achieve an agreement. The AFAIK first court cases about the Look-and-Feel of software that had serious publicity were those about Lotus 1-2-3 and its lookalikes. Lotus lost some of these conflicts, so as a result not everything about Look-and-Feel is considered copyrightable. Still, all these famous cases (and their less known siblings) show clearly that you don’t need patents; you can easily sue or threaten to sue about the copyright issues of a reimplemented feature — and copyright is exactly what open source licenses are about.

So, while the (L)GPL doesn’t protect against patent lawsuits, it at least raises the effort a bit — quite a bit more in countries that don’t accept patents on software and have some measures against trivial patents. Copyright comes for free with the creation of software; a patent must be granted, which requires a serious amount of money, additional work (describing the patent) and legal effort.

Firstly, copyright. Even assuming that I would choose to reimplement some extension that someone had done, that’s not an issue for copyright. As long as the code was original, even if the concept wasn’t, there are zero copyright issues.

You are correct however that there is a potential for a patent lawsuit, at least in countries that allow software and business methods to be patented (like the good old US of A). Linking that with which open source license was used is incorrect though – this risk is present regardless of what license my software was originally released as. In fact, it’s arguable that, if the patent holder were relying on the Ogre core to begin with, it’s not in their interests to sue the source of potential core updates. It’s also arguable if the software is an extension to existing software then that undermines the patent’s case via prior art.

But regardless, whether feature A is subject to patent risk is simply a universal constant, regardless of development model OR license. I’m under greater risk of being sued by random company A that has never even touched Ogre, but who implements similar features, than from someone who has extended my software. Precisely which license software is released under is in fact entirely irrelevant when it comes to patent risk for the originator.

The Linux patent situation demonstrates that in fact. Linux is licensed under the ’strongest’ open source license there is, the GPL, and yet that is largely seen as irrelevant when it comes to patent risk. That’s why Novell signed a deal with Microsoft over it, and why they keep rattling the sabres. You raise the SCO issue, but that was about something else entirely – transfer of Unix copyright ownership back in the day.

So I appreciate the thoughts, but I think you’re making a connection between what are actually entirely different issues.

Steve, imagine Initrode Ltd. enhancing OGRE with some essential feature, maybe support for a new input format that is about to become the new standard for 3D description. Or Undo/Redo.Now they distribute the result as closed source. So far no problem to you, if I take you right.

You like the new feature, implement it yourself and present OGRE+ … only to receive a not-so-friendly letter from Initrodes lawyer threatening you with a copyright lawsuit about the new feature.

If you consider this scenario far-fetched, you must be young. Remember Apple vs. DRI? Look up “Graphical Environment Manager” in Wikipedia and read the section “Later versions”. I also found a good summary at http://www.roughlydrafted.com/RD/Q4.06/F68E528C-DC9A-4B12-A064-143924EBD3F1.html in the sections “Patent vs. Copyright” and “Problems with Litigation”.

Apple vs. DRI clearly shows, that reimplementing features from closed source software carries the risk of legal complications. Of course, not every feature is as invaluable as a real GUI in the age of green-screen applications. But to take OGRE away from you, Initrode Ltd. doesn’t need a particularly valuable feature. If the original OGRE will become obsolete without it, it is enough to prevent the inclusion of this feature in a free OGRE. They have an useful application, you have some lines of code about to fall into the forgotten realms.

Now you are in the lucky position of OGRE being neither a threat nor a potential goldmine to commercial software producers — at least as I can tell. For now, most open source fails to be in either category, thus the low number of lawsuits against FOSS. But wait, wasn’t there some story about SCO vs. IBM. Something with Linux?

So, in a nutshell, as long as a piece of FOSS is relatively uninteresting to interested and legally armed parties, the strictness of LGPL and GPL may seem an overkill. But as soon as it becomes an object of greed, it is to late to reconsider the license terms: The horse is gone and will be eaten alive, so what do you care about closing the stable door?

Anyway, it’s not that Cedega just took Wine’s source code and sold it. That wouldn’t work. They did add something which was and is evidently worth money to a certain audience. For that purpose they have their own programmers doing work time. Who, btw, now have to compete with the free wine and have to replicate advancements from Wine in their own source tree, because they chose not to contribute. (For what it’s worth, imho they are losing the fight, because Wine is catching up on game support quite quickly, and the amount of AAA titles which are *really* playable with Cedega is not particularly long, either.)