Put the wish list for porting projects HERE...

[Svartalf]

I dont see a minefield anywhere. Someone does?

The other one would be in presuming that they can arbitrarily fork things that way. It doesn't glibly work that way.

1) He'd have to license it under the BSD and GPL from the get-go.
2) Licensing it BSD like that- why bother with the GPL in the first place?

Licensing isn't something you can really honestly play games with. It's the rules by which a rights holder gives out rights to use a piece of software, make publication copies or derivative works, and so forth. If you don't do it right, you can inadvertently place the code into a realm of unsuitability for use like I've alluded to in other posts.

The GPL (even V3, but it's a bit more verbose than I think it needed to be- but they felt that they had to boilerplate it up a bit because of people trying to find and mis-use 'loopholes' in the prior versions of the license...) is a brilliant idea and if used right (see Linux...) it can do amazing things for everyone involved. But you need to understand what you're doing when you place things under that license- or any other license for that matter.

[Tycho451]

Wow...I had no idea licensing is such a trouble even if you just release your own work.

But, none of this a permanent problem, right?
As long as you're still around you can re-license your code in something other than the GPL, when you stated that everything released under "MyGame" will belong rights wise to you. It's not like you can fuck this up without a chance to repair it, I hope.

[Dragonlord]

There's the minefield if you use GPL licensing for the engine...

It's not in your code or in being able to dual license. It's in the downstream people that it becomes a problem. If you don't integrate any proprietary closed modules, GPL is perfectly fine because it doesn't change assets rights- you can have a GPLed game engine and a closed game. It's when you or another rights holder in standing release something that's GPLed and mix it with proprietary modules that it becomes a problem. Because you're the rights holder, you can release it under any license you see fit- but the license may not provide to the downstream recipients what you intended. If you provide a Bink module under your distribution license (Lord, would that be evil expensive to provide...but let's use something familiar for this example.) you as the sole rights holder to the GPLed codebase may do so. Unfortunately, it doesn't accomplish what you sought to do because now NOBODY can legally distribute the engine or make derivative works off of it unless they rip the Bink framework out and make a fork- because they can't honor the GPL license grant without doing so.

The same couldn't be said for LGPL, which allows for this sort of thing and is only viral if you touch/modify/derive from the code that was licensed under the LGPL to you. However, if you're okay with things the way they are and can avoid doing nasty things to yourself (like I just mentioned previously...) and insist upon anything under the name Drag[en]gine has to be assigned rights-wise back to you, then there's no reason whatsoever to hold the position you are currently- it's just that you need to understand precisely what you're doing, something that's kind of clear to me that you didn't before this aside from the main thread topic.

I'm currently not sure if we talk about the same situation. The engine is only "used" by the game developer. He's not touching any modules not the engine itself. The end user ( the gamer ) chooses the modules for anything ( or rather most of the time the launcher does ) tailoring his installation to fit perfectly his machine. So why should I or a game developer be held liable if the user chooses to use a proprietary module to power some parts of his personal engine installation ( if this would ever become the case... I don't think so )? This sounds to me like holding a game developer reliable for using some non-microsoft approved driver in his system ( which is his problem, not mine ). I'm a bit confused on where you stumble upon the problem. I try to understand where you see the problem but currently I don't.

[Dragonlord]

The other one would be in presuming that they can arbitrarily fork things that way. It doesn't glibly work that way.

1) He'd have to license it under the BSD and GPL from the get-go.
2) Licensing it BSD like that- why bother with the GPL in the first place?

Licensing isn't something you can really honestly play games with. It's the rules by which a rights holder gives out rights to use a piece of software, make publication copies or derivative works, and so forth. If you don't do it right, you can inadvertently place the code into a realm of unsuitability for use like I've alluded to in other posts.

The GPL (even V3, but it's a bit more verbose than I think it needed to be- but they felt that they had to boilerplate it up a bit because of people trying to find and mis-use 'loopholes' in the prior versions of the license...) is a brilliant idea and if used right (see Linux...) it can do amazing things for everyone involved. But you need to understand what you're doing when you place things under that license- or any other license for that matter.

That's clear. The main problem here is that I have two goals.
1) engine fully available to anybody ( so nobody can "deny" you the engine ). since it's the center stone of all and the main idea is that nobody else but the engine team is required to touch this code at all, that's what the GPL can do.
2) possibility to port it over to restricted platforms. GPL can't do this since restricted platforms tend to have "special" licenses.

So the GPL by itself can do anything that I need for computer platforms ( Linux, Windows, MacOS, Haiku ). It fails though for console platforms where the manufacturer dictates the tone. If it is possible to keep a clean licensing ( and GPL is for me clean, LGPL not ) for computer platforms and the restricted ones only for the tricky consoles I would be glad.

[Svartalf]

Wow...I had no idea licensing is such a trouble even if you just release your own work.

Welcome to the wonderful world of IP rights that the folks like the people from MPAA and RIAA member companies have brought to all of us. It's something I live with day-in, day-out, producing code and having filed Patents on a couple of things...

But, none of this a permanent problem, right?
As long as you're still around you can re-license your code in something other than the GPL, when you stated that everything released under "MyGame" will belong rights wise to you. It's not like you can fuck this up without a chance to repair it, I hope.

You can have booby-traps lying about.

Code that people think is GPL compliant but really isn't.

Duke Nukem and Lo Wang: Shadow Warrior are PRIME examples of this. If you CAREFULLY read the GPL license grant, you will find that you're unable to provide the entire enchilada under the same terms as the GPL or a less restrictive license (See: BSD without Advert...). You have the BUILD engine license standing in the way as a dependent piece of the puzzle. Yes, you can license it under whatever license you see fit. Unfortunately, since it's a derivative works and publication license, you have to abide by the terms of the GPL to distribute copies, etc. The only way you can distribute the GPL version of those programs is in SOURCE only form. Any binaries would be in violation of the licensing requirements of the GPL- and it doesn't matter what the original authors say, if a downstream author doing it right insists upon compliance anyone downstream of them will have to come into compliance (which is to stop producing the binaries...) or face a situation like Verizon or Actiontec faced over busybox if the rights holder is flush with cash.

Yeah, you can "fix" the problem retroactively, but like one's words, it's a bit difficult to "take back" something you screwed up on with this- you could leave lingering problems around for a long time.

[Svartalf]

I'm currently not sure if we talk about the same situation. The engine is only "used" by the game developer. He's not touching any modules not the engine itself. The end user ( the gamer ) chooses the modules for anything ( or rather most of the time the launcher does ) tailoring his installation to fit perfectly his machine. So why should I or a game developer be held liable if the user chooses to use a proprietary module to power some parts of his personal engine installation ( if this would ever become the case... I don't think so )? This sounds to me like holding a game developer reliable for using some non-microsoft approved driver in his system ( which is his problem, not mine ). I'm a bit confused on where you stumble upon the problem. I try to understand where you see the problem but currently I don't.

What about the content player pieces? Those are modules too. Unless you insist upon nothing but FOSS codecs, etc. you can't presume what you're presuming at this point...

[Svartalf]

So the GPL by itself can do anything that I need for computer platforms ( Linux, Windows, MacOS, Haiku ). It fails though for console platforms where the manufacturer dictates the tone. If it is possible to keep a clean licensing ( and GPL is for me clean, LGPL not ) for computer platforms and the restricted ones only for the tricky consoles I would be glad.

Why is the LGPL "less clean"? It accomplishes most of what you're seeking- which is to encourage people to contribute back to the engine and to make the engine pieces itself clearly open to use and modification by the developers producing games and the users finding problems and helping the studios fix their games without needing as much intervention.

GPL forces you to expose ALL the code underlying the stuff and you will need to have assignment back to YOU and solely to YOU to relicense the stuff under more restrictive licensing. Unless you get that for everything on the GPL side of the fence, you end up with a morass of fractured versions all over the place, defeating one of the main purposes of your whole concept.

Please explain to me why you think it's less clean because I'm not clearly getting what you're thinking here.

[Dragonlord]

I'm grown up with the GPL license and you know there are various people around. We don't want to get started with the entire FS vs OS dispute since this is already a flame bait by itself. The LGPL is often down-looked upon by GPLers as being "not clean" since you taint the original GPL allowing a "restriction of freedom" or how they see it a potential loop-hole to suck up free software into a closed form denying it from public. That said my knowledge of the LGPL limits itself to being "less strict" than the GPL allowing linkage. That's why I need to question you out a bit here since you have obviously a far better understanding of the LGPL than I.

Now what goes for me I'm not stubborn in this matter. I want to talk this license topic over before going gold since obviously I'm building here a very large system and without acceptance from users out there it will be hard to get anywhere. Hence I'm first trying to explore together with you if a pure GPL solution with an optional sidekick is viable or not. Should this not be the case and only LGPL being a solution I'm not going to dickhead. I just want to be sure that I checked out all options before stepping down from the GPL to different license type.

So far I considered a dual-license a possibility since I've seen this pulled off at various places ( greping through portage shows various funny examples ). I see the problems you are referring to ( the problems of multiple versions ). Now the question is:

1) Is the LGPL enough to deal with the mentioned scenarios under the assumption game designers play by the rules?

2) How does it look like on a restricted platform like a console? Is the LGPL enough to allow down-grading to a platform specific license?

[Svartalf]

I'm grown up with the GPL license and you know there are various people around. We don't want to get started with the entire FS vs OS dispute since this is already a flame bait by itself. The LGPL is often down-looked upon by GPLers as being "not clean" since you taint the original GPL allowing a "restriction of freedom" or how they see it a potential loop-hole to suck up free software into a closed form denying it from public. That said my knowledge of the LGPL limits itself to being "less strict" than the GPL allowing linkage. That's why I need to question you out a bit here since you have obviously a far better understanding of the LGPL than I.

I carefully read and parsed the LGPL, GPL, MIT/X11, MPL, and the varying BSD license variants. I've licensed code under GPL, LGPL, MIT/X11, and BSD over the years. I prefer LGPL, GPL, BSD with advert in that order, depending on just what I'm trying to accomplish.

1) You're the one making the license decision. What you choose is your call. I'm not complaining, only commenting on concerns. Anyone being verbally obnoxious over this should probably be ignored.

2) The license decision you make can impact how useful the gift you're working on giving to the world will be received. Linux benefits from the GPL; it's choice was apt, really, because GPL protects the interests of all parties involved. However, it's not a good choice all the way around as it really requires everything involved to be part and parcel of the GPLed software ecosystem, which, for the space your engine lives, isn't really possible or practical for the aforementioned (earlier in the thread) reasons I've been concerned about those choices.

3) The LGPL is not a "loophole" to suck FOSS software into proprietary closed systems, to be forever closed. It has EXPLICIT requirements and under some circumstances linkage can actually get you into trouble with compliance. What LGPL mainly does is to allow you to link the LGPL licensed stuff against a closed application without requiring anything other than your modifications explicitly to the LGPLed piece (There's some gotchas like modifying your stuff against the LGPLed stuff in a way that the derivative work lies across both parts- did you actually contribute the real modifications?) with the proviso you can't prohibit reverse engineering work against the closed components and can't prohibit linking future versions, wrappers to ameliorate new ABI edges, etc. ANYONE telling you that it allows you to proprietarize the code is spreading FUD and needs to be ignored.

4) If anything is a loophole to proprietarize code it's the BSD license variants and the MIT/X11 license. They do NOTHING to prohibit closing off access to derivative works against the licensed work. For some things, this makes sense. Stallman will even agree that some licensing along those lines makes sense (See: libvorbis...).

5) Stallman will tell you he views the LGPL as a "less pure" license, because he'd like to see everything in the software space as GPLed for very good reason. I would like to see it too, to bluntly honest. Changes the rules of the game in a useful manner. Unfortunately, the realities of things dictate that compromises be made. The LGPL is one such compromise that Stallman himself made (Think about that LONG and HARD, folks...) and I agree with him having done it. Many of the things I've released have been under the LGPL for good reason- propagation of the free code. Unless you have an iron-fisted dictator-like control over the codebase, GPL doesn't make sense with code that will interact with proprietary code. Unless you can provide vastly superior GPLed answers and be largely self-sufficient (See ioquake3...) and rely solely on closed control of the assets, you probably don't want to do GPL with a game engine.

Now what goes for me I'm not stubborn in this matter. I want to talk this license topic over before going gold since obviously I'm building here a very large system and without acceptance from users out there it will be hard to get anywhere. Hence I'm first trying to explore together with you if a pure GPL solution with an optional sidekick is viable or not. Should this not be the case and only LGPL being a solution I'm not going to dickhead. I just want to be sure that I checked out all options before stepping down from the GPL to different license type.

Best bet overall, really. You may still want to keep it GPLed. But that has consequences to it you might want to fully understand before keeping it there.

So far I considered a dual-license a possibility since I've seen this pulled off at various places ( greping through portage shows various funny examples ). I see the problems you are referring to ( the problems of multiple versions ). Now the question is:

Heh... The dual licensed stuff typically has iron-grip control over the GPL licensing rights and who's the one with the rights assignment which has it's own issues regarding those selfsame vocal GPL advocates- whom have earned a bad name elsewhere as a result of the silliness they've perpetuated over perceived problems with compliance, license choices, etc. I've had to patiently educate people over what the GPL license means, what LGPL means, etc. for many, many years as a result- I even got my foot in the door and earned a BUNCH of respect over at the OpenPandora project because of one of those sessions (I'd commented on concerns (valid, btb...) about unclean OpenGL ES support and got initially branded as a "GPL Loonie" because of the tar and feathering that'd happened over the GP2X's code core (Linux, and Gamepark wasn't at all in compliance initially...)) which eventually turned into an honest discussion over several posts where they figured out I wasn't kidding, there was an issue, and I was honestly trying to head off another pitchforks and torches session with that community. It's all you can do there.

1) Is the LGPL enough to deal with the mentioned scenarios under the assumption game designers play by the rules?

It should be. The main requirements is that you can't prohibit RE work against the final product to allow people to be able to fix/replace the proprietary components if there's a desire to do so and you honestly provide any modifications to the code needed to accomplish your use thereof. No cheating by pulling part of it into a closed module and part of it into the LGPLed side. The mods must stand on their own for it to count. It's pretty much the GPL, save for the condition, legit as can be, of linkage to something else produces a derivative work. This means you can come up with a proper Bink module if you want for cutscenes (with the FOSS stuff done right, you could remove most of the desire for that, but it's still there if you want it... ) for example and it'd be fine as long as your license on the resulting game didn't preclude someone doing RE work and ripping the Bink module out- it wouldn't be a supported act, mind, but you see where I'm going with on that.

2) How does it look like on a restricted platform like a console? Is the LGPL enough to allow down-grading to a platform specific license?

You can have a license on the game that's separate from the engine- as long as it doesn't conflict with the LGPL, you should be okay with damned near anything. The truths be known here, all they probably care about is your compliance with the licensing on the components you provide to them and the compliance with their license terms. The LGPL probably will go just fine on the console by itself. If you do a dual license, unless you've got sole rights to control the licensing itself, you're back to square one with the same problem you're facing with the GPL, a fractured space. Before making a decision, I'd see if Sony and Nintendo (Don't bother with MS, you'll know what their answer will be and it'll not be what they'll actually accept as an fait accompli on your part and theirs...) on what their take on the use of LGPLed stuff would be on a title on their console.

[xav1r]

Damn, i didnt know licensing was such a difficult thing. I havent placed any code under a F/OS kinda license, mainly because i dont know if they are at an appropiate level, but I have 10 page research paper that i would like to release to the public under a free open like license. I know about the creative commons, and was considering the most unrestrictive license, the CC-BY-SA, but i read somewhere that it is incompatible with the GPL FDL (free documentation license). My paper is a research paper on free software in schools in developing countries. It's not a computer program, or the documentation for a computer program. Would anyone know which would be an appropiate license for it?