My evolving view of open source licenses

smallprintI’ve been involved in open source for a long time – probably what might be considered a ‘generation’ in this industry. I was a fan of open source before I even knew the term existed – during my formative coding years in the early 90’s I was always releasing code for free and encouraging people to tell me why it sucked, and doing the same for them. Of course, most of the discussion went on over FidoNet, BBS-relayed emails, the very early (pre-WWW) internet and code on FTP sites, but the principle was much the same.

It was only when I needed a host for an increasingly large 3D engine I’d been writing in 2000 (which later became the earliest version of OGRE) that I discovered Sourceforge and open-source licenses. At that stage, I didn’t really care much about the minutae and just went with what seemed the most popular choice – the GPL. Fairly soon after this was revised to LGPL because it was clear GPL wasn’t a flexible choice for a library. Over the years I formed the opinion that the LGPL was a good balance for what I was doing – it allowed use in proprietary applications but required that modifications to the open-source part were passed on; and this also, I thought, encouraged contributions back to the core since it’s simpler to have your changes promoted. The downside was that the license is pretty long and full of legalese, and frequently needed explaining & clarifying. Still, I considered that a necessary cost of a license that ‘protected the interests’ of the open source project. I had considered more permissive licenses like zlib and MIT to be too weak –  giving everything away with no conditions encouraging reciprocal contributions or participation.

I only really started to seriously question this long-held opinion recently, shortly after I had to deal with a license violation issue. The details of this are irrelevant (and will not be discussed here), the important thing is that after all the dust had settled, it really made me sit down and take a long, hard look at what open source licenses actually achieve in practice, and which bits I felt were the most important for sustaining my projects.

Purist free software advocates subscribe to the view that all software should be ‘free’ (as in speech), which is, when you boil it down, a philosophical principle. While the intention is often genuinely altruistic – enablement for all developers and users of software – in a practical sense it is also a highly prescriptive, black-and-white approach. Free software licenses like the GPL restrict as much as they enable, on the basis that not to do so would deny future users of the flexibility to alter the software. It’s an understandable point of view, if very hacker-oriented, but it’s not one that I personally sign up to. I’m not involved in open source as a ‘movement’, in order to ensure that all users have access to all the source code of every application they use. Instead, I’m involved in open source because I think it’s a damn good way to get good software written for the benefit of the many, particularly infrastructural elements that can then be used to innovate faster, by smaller teams, to challenge incumbents, and generally shake things up. I’m a firm believer that open source and proprietary software can be good bedfellows, and that each can benefit the other – open source providing solid foundations for proprietary innovation, and proprietary software contributing to the open source projects underpinning it, in terms of code and funds. In that context, the restrictive elements of the LGPL seemed well-placed – the LGPL allows proprietary use, but modifications had to be passed on.

But, after much consideration and hard self-questioning in recent weeks I realised something important. Of all the people that have contributed to OGRE over the years, I can’t think of a single good code contribution that has come about because the license conditions encouraged it. All of the people who have made a significant positive contribution to OGRE have done so because they chose to do so. Either because they wanted to do it for fun, or because they saw that it was in their own interests as users, they sent patches in, created new add-ons, joined the team etc. None of these people required any coersion from a license to do what they did, and all the better for it – because they chose to do it, they tended to be more forthcoming in terms of adhering to standards, answering questions about their contribution, and generally participating in the community rather than just doing a minimal code-dump.

The other thing I considered was the impact of someone modifying OGRE and not publishing their changes. On the one hand, this is a potential for a lost contribution, but in practice the LGPL conditions are only to pass on the source to others, not to contribute back to the core project (which requires a contributor agreement anyway), and as mentioned we’ve already established that the best contributions are from willing sources anyway. Then comes the principle of whether it matters that the end user is not guaranteed to see the modified source of OGRE – free software principles say this is not right, but I have to say that in practice, most end users don’t care and in practice it’s of little consequence for OGRE. Obviously many people in the free software camp would disagree strongly with this. It’s more of an issue in enterprise apps where a customer who receives a significantly customised application from a vendor, and needs to keep maintenance in mind; IMO regardless of whether the software is based on open source the customer should be insisting their vendor delivers source anyway – that’s what contracts are for. But I digress.

So, after much thought I concluded that the most useful pay-backs to an open source project, and thus its community, from a user (in my opinion) were:

  1. Code & documentation contributions – which based on my experience come from voluntary sources
  2. Community participation – forum support, bug reports etc
  3. Publicity.

The ‘restrictive’ elements of the LGPL (and GPL), to which so much confusing license text is dedicated, didn’t seem to contribute to any of those except number 3, and then really just as a side-effect.

It was at this point that I realised that my previous opinions about permissive licenses not providing enough safeguards against exploitation for an open source project were off-base. In practice, open source projects don’t really need protection, because their best contributors are going to be there regardless (yes, I realise the GPL provides more protection to end users who want to get at the source code, that’s not what I’m considering here). ‘Freeloaders’ – people who use or modify the open source project for their own ends but give no code or community contribution back – are always going to exist; even under the GPL it’s easy to freeload, if you make your money from hosting services for example, and thus license choice has little impact on the scale (if not the nature) of the freeloading. Besides the annoyance of ‘that guy took my work and made some money out of it’ – which you have to accept as an inevitable outcome of going open source, so stick to making proprietary software if that bugs you – freeloaders have little negative effect on an open source project, and actually their use can contribute positively to item 3 (publicity). The key is to recognise that in practice you can really just ignore freeloaders, and instead concentrate on maximising the positive contributors in your community.

So, if we acknowledge that the people whose contributions we actually want are those who contribute voluntarily, regardless of license, we quickly come to the conclusion that all that really matters is the size of the community. It’s a fair assumption that for a given project there is a relatively stable percentage of users who will choose to contribute back (the percentage itself varies per project, but is fairly stable per project in my experience), therefore the easiest way to increase your contributors is to just increase your user base. Forget about trying to coerce people into being ‘good’ members of the community, just trust that the percentage will be there and will track your overall numbers.

One way in which to attract more users is to make the licensing simpler and more easier to understand. Programmers hate legalese, and a simple, clear license is bound to be more attractive than our LGPL (with static link exclusion), plus OUL option. It’s for this reason that from OGRE 1.7 we’re switching to the MIT License.

I’d like to thank Matt Asay for his post on the subject, which really jump-started my thought processes on this subject in the last few weeks. This whole process has been a reminder to me that it’s always good to re-examine your previous assumptions and opinions in the light of practical experience, and to be prepared to reach different conclusions than you did before. The whole open source landscape is constantly changing and maturing, why should those of us immersed in it be any different?


  • Pingback: Planet Ciaran (planetciaran) 's status on Tuesday, 15-Sep-09 17:14:14 BST - MicroCiaran

  • September 15, 2009 - 5:52 pm | Permalink

    As a user of OGRE, I for one couldn’t be happier. Thank you!

    This may also help you in other ways–it’s somewhat easier to contribute code to an MIT-licensed project. I recently had a conversation on the topic with a couple of associates of mine who are working on our OGRE-based 3D engine, and having it LGPL made it harder for us to be able to contribute back to OGRE. Shouldn’t be a problem now.

  • September 15, 2009 - 6:21 pm | Permalink

    Cannot agree more on the ‘contribute back’ idea, nothing can replace free will.

    A clear and simple path on how to contribute back matters a lot more.(‘how do i make a patch’, etc…)

    ‘wiki’ website helps building doc, svn helps build patches, etc… Having the most direct and easy tools helps a lot more than any legal thing.

    (for instance, posting/handling patches on google code is a lot easier than on sf for instance, along with the nice notation idea)

    Now, you’ll have to build a complex timeline legal web page of all those license Ogre had in its existence

  • September 15, 2009 - 7:39 pm | Permalink

    I’m heartened to hear about this change. I believe that the BSD license tends to lead to a healthier community and an atmosphere of trust. You contribute code back to the community because you don’t want it to be left behind, and to be forced to continue to patch, not out of grudging obligation.

    My only question is can you even change the license at this point due to the contributions you have received.

    i.e. were those changes licensed to you under the LGPL, or under a more permissive license/copyright assignment?

  • Scott G.
    September 15, 2009 - 7:44 pm | Permalink

    Why not just go public domain then? That is by far the simplest in terms of understanding the ‘license’ — there is none. SQLite is public domain, and Dan Bernstein has recently released much of his code into the public domain.


  • Fabien
    September 15, 2009 - 7:46 pm | Permalink

    tuan.kuranes wrote:

    > Now, you’ll have to build a complex timeline legal web page of all those license Ogre had in its existence

    Too complicated. He could just say “I hereby allow everyone to use any version of OGRE up to 1.7 under the MIT licence”, and that’s that.

    You can’t remove a licence that’s been granted, but you can add a new one.
    And if the new one is strictly more permissive, the old one has no effect any more.

  • Dark Sylinc
    September 15, 2009 - 9:16 pm | Permalink

    I completely agree to all you say.

    Nevertheless, I would like to point out a similar (but reverse) situation. The WINE project (Wine allows to run Windows application under Linux without emulation by wrapping core DLLs) had an MIT license.

    Then another project named “WineX” (now known as “Cedega”) surfaced which was based on Wine, incorporating proprietary code and making profit out of it. Due to this, the license was changed to LGPL.

    I’m not worried about someone else modifying OGRE, integrating it into their own application, and making profit out of it.

    I’m worried about someone else starting a new Graphic Rendering engine based in our work, make a couple of modifications, and start selling it (that is, COMPETING with the original OGRE project, while STILL getting benefits from developers contributing to OGRE).

    Nowadays those who want to sell enhancements to OGRE, can do so by developing plugins or extensions (ParticleUniverse comes to mind). Which is OK, since the core library is still open source and free. You can opt for the enhancements or not.
    But with the MIT license, this could mean that a fork would start to do some code changes to the core and claim that the proprietary and original code cannot be decoupled anymore, thus justifying it’s “price”. That would piss me off.

    I think it would be great to read the initial discussion and how they came to that conclussion:

    Does anyone share my concern?
    Dark Sylinc

  • George
    September 15, 2009 - 9:20 pm | Permalink

    That’s naive.

    Remove everything that is free software (GPL, etc) from your computer and with what is left, see if “open source” is a good way any more to develop software. You are just taking the good things that are already there because of freedom for granted.

    You say:”I’m a firm believer that open source and proprietary software can be good bedfellows”
    Yes, and I am a firm believer that the lion and the lamp can be good bedfellows.

    People “chose” to contribute. Yes, because it is free software. Otherwise you may feel kind of stupid if you just contribute, and the other parties just take away.

    You say:
    “we’ve already established that the best contributions are from willing sources anyway”
    Well, if someone uses an open source project proprietarily, guess how willing they will be to give those “best contributions”. We are basically talking about companies here. If the program is important enough to them, they will have to contribute if it is free software. They won’t, or do it minimally, if it isn’t free. And guess how happy the “community” will be to act as free labor for a company. But if it is free software, it is in the best interest of everyone to do their best, because they will also get back the best of everyone else. That is the brilliance of free software. It is actually in the interest of each one of us.

    You say:
    “IMO regardless of whether the software is based on open source the customer should be insisting their vendor delivers source anyway”
    The real world is not always so nice. And also, you may get “source” but it may be in such a way, and under various legal restrictions, that it practically equates to not having the source.

    You talk about”restrictive” elements in free software. Let me tell you a real world analogy: Free software: I will not kill you, and (this is the “restrictive” part) you won’t either.
    Open source: I won’t kill you, (and this is the “unrestricted” part) and you can do whatever you like.
    Is this doublespeak, war is peace, we have always been in war with Eurasia, or what???

    You say:
    “open source projects don’t really need protection, because their best contributors are going to be there regardless”
    Well, “going to be there regardless”, is “famous last words”. Companies are adversaries. And they have more resources. They don’t care about your cute little project. They want to maximize what they get, and minimize what they give. The difference of those two, is, you know, profit.

    You say:
    “we quickly come to the conclusion that all that really matters is the size of the community”
    You take things for granted. Size may be currently ok for a big and established project (but not necessarily in the long run), but what about the one that is starting today or tomorrow? But who cares, right? We just take things for granted.

    You say:
    “that guy took my work and made some money out of it”
    It is not about the money. It is about giving, and also getting back the best of whatever you are interested in.

    You say:
    “Forget about trying to coerce people into being ‘good’ members of the community”
    Well, then just abolish the laws for murder too, while we are at that. Right?

  • Anders Elfgren
    September 15, 2009 - 9:22 pm | Permalink

    Cool! I think it’s definitely a good choice, for the reasons you mentioned.

    I posted your entry on reddit:

  • September 15, 2009 - 10:01 pm | Permalink

    Excellent, but I do wonder, will this affect your revenue from the OUL? Did this end up being negligible anyway, with more people coming to you for help/support rather than a licence?

  • September 15, 2009 - 10:35 pm | Permalink

    Over the years, I have contributed to a lot of open source projects and lead a few of my own.

    Do you know why I have contributed back to those FLOSS projects? Because I am a selfish bastard. In fact I am so selfish and lazy when I come to decide between a) contributing back code to the project and waste my time maintaining my patch in my own branch, and b) contribute back to the original project and have other people maintaining my patches, boy, I always choose (b).

    Usually it takes some time explaining to clients this attitude but in the end, they all have agreed with me: be a selfish, lazy bastard and have others maintain my code!

  • tourist.tam
    September 15, 2009 - 11:10 pm | Permalink

    Have you considered the WTFPL scheme? Just kidding. :p

    Nice move and nice post though.

  • Frenetic
    September 16, 2009 - 7:10 am | Permalink

    I can empathize with the reasons developers have for using GPL licenses, but in the post above I couldn’t help but mentally replace “license” with “DRM”, “freeloaders” with “pirates”, and “contributors” with “customers”.

    People who aren’t thuggish morons understand that contributing to endeavours that benefit them – whether the contribution is money or goods or labor, and whether the endeavours are technical or cultural – is in their best interests.

    Coercion doesn’t work in most cases, for various reasons (eg. you can get more bees with honey…)

  • September 16, 2009 - 8:00 am | Permalink

    I agree with your statements. We released our Ogre Middleware LUGRE ( ) since it birth under the MIT License.

    If Ogre is in future also MIT, it fits better due to more easy licensing.

  • September 16, 2009 - 9:45 am | Permalink

    @Scott G.: “Why not just go public domain then? That is by far the simplest in terms of understanding the ‘license’”

    True, but there’s one important difference – with public domain the originator effectively gives up all their rights. A permissive license effectively gives simple and broad-ranging rights to the receiver, but also keeps the originator’s rights in place (e.g. for the origin of the software to be recognised in the source), which I personally prefer.

    @Edward Kmett: “My only question is can you even change the license at this point due to the contributions you have received.”

    Yes – our contributor license agreement not only assigns joint copyright between us and the contributor, but it also states that the condition is that the code is released for free under an “OSI-approved license”, not specifically the LGPL.

    @tuan: “Now, you’ll have to build a complex timeline legal web page of all those license Ogre had in its existence”
    It’s really quite simple – OGRE’s hasn’t been GPL since 2001 so it’s really just “LGPL up to 1.6, MIT from 1.7″.

    @George: Your whole argument is basically an ‘us and them’ one, open source vs proprietary. I simply don’t agree with this. Sure, people & companies will ‘rip off’ open source – if you thought they don’t under the GPL then you’re the one being very naive. Loads of companies benefit from hosting GPL software and giving little or nothing back (since pre the Affero GPL hosting is not distribution, so no requirement to publish changes), and lots of companies just ‘use’ GPL software unmodified, or externally enhanced, such that they don’t have to release anything. The *real* question is whether any of that actually matters. I say it doesn’t, because all that matters is the positive things that happen with groups of people that choose to contribute to open source.

    It’s pointless to get frustrated about people & companies that use open source for their own ends without contributing back. It’s going to happen, even under the GPL. If it bugs you, you probably shouldn’t be releasing open source. In fact, ironically only proprietary licenses offer guaranteed protection from people using your work for commercial gain without giving back. Choosing to release a new project as open source is a balance – on the one hand you get the benefit of community assistance (from people who *want* to help, not who are forced to) and free publicity, on the other you have the potential for people to benefit without contributing back (under any license, including GPL). Up to you to evaluate that balance.

    “Well, then just abolish the laws for murder too, while we are at that. Right?”

    Way out of proportion. I’m not an anarchist, but I believe less rules are generally better than more, and you have to consider the practical *consequence*, not just the philosophical. Murder has a very real, very negative consequence. If someone uses / adapts my open source project without giving back, what does it *actually* do? If I’m uptight it might piss me off. If I’m more pragmatic, it has little real effect because I know that people who want to contribute (most often through enlightened self-interest) will do so anyway, and their unforced contributions will be all the more valuable for it. I think you need to stop looking at the theory & emotive side and look at the concrete practical side a bit more.

    @blankthemuffin: “Excellent, but I do wonder, will this affect your revenue from the OUL?”

    Yes, the revenue from the OUL will effectively disappear from 1.7, and I’m ok with that. It was never large anyway – whenever an OUL enquiry came in I always encouraged people to *really* consider whether they could use the LGPL, because at the end of the day I believe people that learn to work with open source as it is are more likely to understand it and become contributors & otherwise more active participants that way. I never wanted to try to ‘drive’ OUL revenue because to do so would undermine the open source license, and also if it got beyond just funding things like the website and occasional OGRE-related software purchases there could be some resentment that I was ‘milking’ it, which I wanted to avoid. Thus, from a business perspective the OUL was not something I could ever rely on or seek to grow further, so its value was limited. Dropping it will remove this dichotomy and make things simpler – we can just concentrate on adoption of the open source base, and I can focus my commercial activities on supplemental services and products around this core.

    @Pau Garcia i Quiles: “Do you know why I have contributed back to those FLOSS projects? Because I am a selfish bastard.”

    You’re not the only one, in reality *everyone* does this – whether it’s because it’s easier to maintain, or that they want others to help check & fix bugs, or that it gives them a nice feeling to see their code in lights. In practice, most open source runs on enlightened self-interest.

  • tom
    September 16, 2009 - 12:27 pm | Permalink

    i think you need to consider apache license. although it is more verbose, it has section dealing with patent abuse which i am not sure whether mit provides.

  • September 16, 2009 - 1:34 pm | Permalink

    Yep, considered Apache originally because of the patent clause but eventually decided against it. It’s just far too long and so doesn’t tick the ‘simplicity’ box which was one of the main reasons for switching anyway.

  • kinjalkishor
    September 16, 2009 - 4:45 pm | Permalink

    Very much thank you for making one of best OS 3D engines MIT licensed. Really great. You would have though remove any LGPL code you have modified and used in OGRE(though I donot remember any, for ex. Any Quake 3 loading source code).
    It is simple and great. Now it is lot easie r to use OGRe in MIT based projects, which is a short ans weet license. And it will mkae OGRE more popular and help it grow more.
    As given more freedom people are inclined to contribute more out of free will.
    In any case a great thing is made lot better. Very very good.
    Dont worry of Ripping, closed source softwares can rip easily, but gradually people realise that they get more by openly contributing and sharing. Such is OSS. A very good alcohol.

  • Dark Sylinc
    September 16, 2009 - 6:01 pm | Permalink

    “In fact, ironically only proprietary licenses offer guaranteed protection from people using your work for commercial gain without giving back”

    Could you elaborate on this please? Because I don’t catch that.

  • brad dunbar
    September 16, 2009 - 9:24 pm | Permalink

    This sounds great. I for one think that fanatical free software proponents cause as much, if not more, damage to the open source community as do their proprietary counterparts.

    When you fracture the community for a good or bad purpose, you really just fracture the community.

  • September 16, 2009 - 10:43 pm | Permalink

    It’s kinda obvious:
    If the source isn’t available, people cannot run off with it.. :)

  • September 17, 2009 - 8:15 am | Permalink

    Very good explanation of your point of view! wich I fully agree. I think Ogre3D will benefit from this decision :)

  • September 17, 2009 - 9:13 am | Permalink

    @Dark Sylinc:”“In fact, ironically only proprietary licenses offer guaranteed protection from people using your work for commercial gain without giving back”

    Could you elaborate on this please? Because I don’t catch that.”

    Basically, with any open source license there is always the opportunity for someone to use your work & make a living out of it without giving anything back to you. The more popular the project, the more likely this is to happen. It comes with the territory and you just have to accept that only a small % of people are going to contribute code (or donations). OSS projects only get really popular when they reach a certain level of maturity, when a lot of people can happily use it without modification, so even the GPL doesn’t protect against ‘exploitation’, if you want to call it that. Plus, GPL’ed tools can be enhanced with proprietary portions just by making the interfaces run-time (command line args, network comms) rather than build-time, or by not distributing the app (internal company use, web hosting – the latter is covered by the Affero GPL though). Whichever way you slice it, lots of people will use your OSS code for their own benefit without reciprocating, it’s inevitable.

    In contrast proprietary software comes with licenses that control the purpose for which you can use the software, something OSS licenses never do. So you can have non-commercial clauses, time-limited trials, deployment limitations, licensing fees etc. So unlike OSS licenses, they can prevent ‘exploitation’ of the work.

    So, if ‘exploitation’ bothers you, then you probably should be making proprietary software instead of OSS software, because the OSS doesn’t protect the interests of the author in this manner (and the strongest licenses like GPL protect the end user most, not the originator’s investment).

    I’ve been putting ‘exploitation’ in quotes because this is a perception, not a fact. OSS is simply a different way of going about things, and by giving up more control, you gain in other ways. Instead of ‘exploitation’, I use ‘adoption’. Sure, maybe only 10% of your users will actually contribute something back to the community (and that contribution doesn’t have to be code, it could be just adding to the discussion & vibe – code-wise it’s probably closer to 1%), but in return you get a far larger community than you could build for the same investment in a proprietary environment, and hence that 10% is still hugely valuable. The trick is not to worry about the rest, because that’s simply the cost you pay for an easier route to the ‘good’ 10%.

  • September 20, 2009 - 2:58 pm | Permalink

    Two words:
    Cedega and Wine.

    They took, they closed source, they promised to contribute, they didn’t contribute back. I sincerely hope something like this won’t happen to Ogre — someone commercializing it, adding features and not giving back.

    I know this was already mentioned, but I decided to state just the core of my fear.

  • September 20, 2009 - 3:26 pm | Permalink

    And again, I’ll say that if you care about someone doing that, you probably shouldn’t be creating open source. Being able to ‘exploit’ open source like this under MIT but not under LGPL is specific to the nature of development libraries, but as I’ve pointed out, somehow no-one mentions all the companies that are making money out of using GPL’d software without giving anything back – just because don’t distribute. Such ‘exploitation’ is rife but somehow certain types (like Cedega) get people pissed while others (like the hundreds of corporations making money out of GPL’ed software internally or for hosting) are quietly ignored. Somehow it’s considered different, but I’m not sure what twisted value systems result in that conclusion. I assume it’s because people focus on the distribution of modified source, but since that never has to touch the original project (I could legally sell a modified GPL program to someone and only give them the modified source, is that exploiting too?) I don’t see that the project gains or loses anything directly.

    My point is that caring about any of this is futile, and is entirely a distraction. It’s a zero-sum game – making a fuss over it brings absolutely zero practical gain to the project, because those who don’t want to contribute will probably just avoid software with licenses that would force them to do so, while those who do will contribute anyway regardless of license. So what have you gained? You’ve gained some theoretical high moral ground, that’s all. And really, that’s worth very little in practice. Here’s open source’s dirty little secret – it’s only as mainstream as it is because it can be used for commercial gain.

    If someone adapts OGRE and sells something with it without giving anything back, I accept that as a necessary risk / cost of the way I do things here. It doesn’t take anything away from me. Sure I could be jealous, but what does that achieve? If I wanted to stop them doing it I would have used a proprietary license.

    People did that all the time under the LGPL anyway – it’s just a subtle nuance of precisely where the additions were made (in their own app or in the core). GPL would offer more cast-iron ‘protection’ but would just make the library useless to all except people who wanted to release GPL software themselves. Unless I dual-licensed, which has its own controversies unless you’re mostly funding development internally in the company that’s receiving the dual-license money.

    People make too many of these decisions based on emotions without seeing the big picture. “I’ve been ripped off!” they cry – no, you haven’t. If company A could do it, then so could you if you put your mind to it – it’s an open situation. You chose to reap the benefits of additional resources & publicity for your project by not being proporietary, you can’t complain when the very aspect that attracted people is then used by others for their sole benefit – that’s the trade-off.

    I say ignore jealousy, it’s not worth the mental energy. Concentrate on what’s good about being open, and accept that the ‘negatives’ don’t detract from that. It’s either that, or resign yourself to only ever releasing GPL software (which either won’t get used much if it’s a library, or will be ‘exploited’ anyway if it’s a standalone or hostable app anyway), or go back to proprietary software where you can make sure you get your pound of flesh.

  • September 20, 2009 - 9:02 pm | Permalink

    Wow awesome news. I know many developers who are not allowed to use any source if it contains the LGPL or GPL. Hopefully this will bring the power of Ogre to a whole new set of games!

  • September 21, 2009 - 7:42 am | Permalink

    Congrats, I’m sure this will open up a bigger audience for you – especially those caught between the LGPL and non-disclosure agreements for properitary SDKs.

  • CABAListic
    September 21, 2009 - 8:29 am | Permalink

    @ivucica: But that’s kind of the point, isn’t it? The Wine team had chosen a license which allowed Cedega to “rip” the source and close it. But when Cedega did, it somehow became their fault. The fault was the Wine team’s – they chose a wrong license for what they apparently regarded as proper use of their work.

    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.)

  • September 21, 2009 - 9:18 am | Permalink

    @CABAListic: Bingo, you hit the nail on the head :)

  • Freddy the cat
    October 3, 2009 - 7:33 pm | Permalink

    GPL and LGPL require changes to the (L)GPLed software to be distributed only under a similar license. The point of this is *NOT* to prevent freeloading. This requirement prevents kidnapping.

    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 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?

  • October 3, 2009 - 8:26 pm | Permalink

    @Freddy the cat: I understand your point, but the risk involved here is completely orthogonal to the license that is used, I think you’re linking 2 unrelated things.

    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.

  • Freddy the cat
    October 4, 2009 - 1:56 pm | Permalink

    Apple vs. DRI wasn’t about patents, but copyright issues. Any patent on the GUI would have been held by Xerox PARC, the inventors of the modern GUI, not Apple. Apple threatened to sue about the copyright to the Look-and-Feel of the MacOS GUI. Some even think, that Apple attacked DRI only to strengthen their case against MIcroSofT (e.g.

    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.

  • October 4, 2009 - 2:21 pm | Permalink

    “So, while the (L)GPL doesn’t protect against patent lawsuits, it at least raises the effort a bit”

    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.

  • David McClurg
    October 19, 2009 - 11:26 pm | Permalink

    Nice blog. I’ve worked on several open source projects since 2000 and I’ve come around to the MIT license as well.

    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.


  • Pingback: Even The Open Source Community Gets Overly Restrictive At Times | PHP Hosts

  • Leave a Reply

    Your email address will not be published. Required fields are marked *

    You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>