*grins* Thought that would pull some Warcraft 3 fans. My Ramblings: Hey all, well I guess like most aspiring developers, after many an hour spent reading books, blogs, articles and of-course code, kindly posted on the net. I felt it was finally time to actually go ahead and make something, not just any something, the big ka-huna of something's: A cross platform game engine. *touch wood* Time passed, as the stack of empty red-bulls beside my desk slowly evolved to heaping pile it is now, with me too afraid to move it for fear of revealing 'the rot' that lie beneath. I started out committed to reinventing every wheel I could get my hands on, I suppose with good reason as this was to be a leaning experience and Cut n' Paste just wouldn't well ... cut it. Never the less I finally caved to growing time pressures, realizing that some wheels just weren't meant to be reinvented. So far asset loading (texture files and some meshes) have been the only fatality of time vs knowledge gained. To handle some of the asset loading I chose a number of third party libraries, again kindly provided by generous developers, only some are covered by the GPL or other viral licenses and as I don't wish to put the users of this engine (should it get that far) under the same constraints, this means dynamic linking. Given the current assets are either free or programmer art (yeah) this isn't a problem but I do realize that eventually licensed assets are going to be used and I can appreciate the amount of work that goes into creating that content and thus its creators should be able to trust that it is only used for what it has been licensed it for. Thus the friggen problem: No matter how I store the content/assets they eventually have to be streamed through dynamically linked 3rd party libraries where a simple wrapper will give anyone access to them and checksums don't work as a breakpoint puts an end to that. Is there anyway to deal with this short of encrypting the assets before they are saved to file? Is this overkill? So I turn to you guys, help; throw me a friggen bone here. *grin* Disclaimer: I can appreciate that anyone with enough determination and skill will eventually find a way around whatever I put in front of them but I still feel I should at lest make them work for it. Thanks.

Thanks DrEvil,
I don't have a problem with making my engine open source (providing it's good enough), after all having taken so much I feel should give something back.

What I don't want is having others using this engine to have to do the same.
I also want people who may wish to use their content, eg. Textures, Sounds, Models .ect. to know that they can do so without fear of them being easily ripped off.

[Edited by - Lumino on October 4, 2006 8:42:26 PM]

If you're using GPL libraries, it doesn't matter whether you're linking statically or dynamically - your engine's code would have to be available under a GPL-compatible licence when you distribute it, whether or not you (or anyone else using it) has a problem with that. So you might as well link statically, because that makes no difference in terms of licensing.

The situation is different with the LGPL, since it's specifically designed to allow dynamic linking with non-GPL programs. Maybe you could try to prevent somebody intercepting the data being transmitted between EXE and DLL by writing a (LGPL-licensed) modification to the DLL so it sends only encrypted data across its interface; but that doesn't help at all since they could easily modify the DLL to dump the unencrypted data, and you probably don't want to enforce a certain checksum of the DLL because that sounds like it might violate the LGPL's requirement that users can modify the library and still use it with your application. Or they could look at the modified DLL's source code and see how to decrypt the transmitted data. And for things like textures, they could just as easily intercept calls to glTexImage2D (or the equivalent with other libraries) in order to get access to the raw texture data. Those things require more than zero work, but there doesn't seem to be a significant advantage over much simpler protection systems.

But most commercial games I've seen are using something like a plain zip file to store all their data in a way that anybody can read - copyright law is enough to stop other people making games with their data, and they don't care about legitimate personal use of their data outside of their game (and, instead, often encourage (or at least condone) it in the form of modding, because that usually adds value to their game for free).

You don't need to GPL your application because you've used a GPL'd library. The GPL only applies to the library and derivaties thereof not the app that uses it - the app is not a derivative in the non-software sense. The legal situation is vague on this point, but general consensus indicates that using a library is not creating a derivative work (think about it - all linux programs use the linux kernal libraries but not all linux programs are GPL). If you make changes to the library then you need to provide a way for people to get those changes and those changes must be GPL'd. There is a precedent of sorts for this - TiVo, as far as I know, used a linux core to their set top box but didn't allow the app running on top of it to be freely available. See the following articles for more on this: Wikipedia and Rosenlaw & Einschlag.

Skizz

AFAIK Excors remark is correct, and I disagree with Skizz' comments. IMHO: Using a GPL'ed library forces you to GPL your application, using a LGPL'ed library does not as long as you link dynamically.

About the OP's problem, I don't really see what the license of the library used for reading the assets has to do with the problem. It is not so that when you read an image file (or the like) with a GPL'ed library, that you need to supply the image using the GPL.

That makes the problem just that you don't want assets leeched by other people. And that kind of a hard problem: your application needs to be able to read those assets, so the user will need to have everything necessary to read those files, including encryption keys etc. So, any determined leecher can never be stopped of getting to these files. As said, many commercial games don't even encrypt these files, but just place them in Zip-like-files and depend on copyright law to stop people from ripping these files.

I hope I understood your issue correctly, and this comment was helpful. [wink]

Linux programs communicate with the kernel only using system calls (as far as I'm aware - please correct me if I'm wrong), which is not the same as dynamic linking and can have different rules (in the same way that dynamic linking is not the same as static linking, even though they look kind of the same from a certain distance). With code that non-free/open Linux programs do link against, that code's licence has special exceptions to permit static linking - e.g. the libstdc++ exception - or uses the LGPL, because of the FSF's claims like "If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program" (and so are both affected by the GPL, since it doesn't give permission for dynamic linking like the LGPL does).

Some (maybe many) people do disagree with the FSF's belief that dynamic linking is covered by the GPL - but it doesn't really matter who is right, because you don't want to risk the legality of your software on an unresolved issue where there is disagreement, unless you have a brave lawyer who thinks it's a good idea to take such risks.

Edit: changed references to hopefully make more sense.

DaBono - I can see you didn't read the links (specifically the second one). I'll copy what it said:

Quote:
The meaning of derivative work will not be broadened to include software created by linking to library programs that were designed and intended to be used as library programs. When a company releases a scientific subroutine library, or a library of objects, for example, people who merely use the library, unmodified, perhaps without even looking at the source code, are not thereby creating derivative works of the library.

My emphasis.

Skizz

The link also says "The Copyright Act ... is a little vague" and "Here's how I would decide in the edge cases that I described above" - it's an (educated) opinion on how the writer thinks the law should be interpreted, and not an agreed-upon-in-court fact (for slightly loose definitions of 'fact'). Also "We need to make sure that companies know, with some degree of certainty, when they've created a derivative work and when they haven't" - the problem is that we don't know with any certainty, and so it's not safe to dynamically link to a GPL library.

It's not a good situation for people who want to use GPL libraries but aren't interested in FSF-style Freedom, because of the ambiguities and questions raised by that article - hence its call to stop "scaring proprietary software users away" (which is basically the purpose of the GPL, and the difference between Free Software and Open Source philosophies). But since that is (as far as I'm aware) the situation now, I don't think it's a good idea to ignore the problems and use other people's libraries anyway, unless they've specifically agreed with dynamically linking to non-open programs by using the LGPL instead of the GPL. (Of course you can still do it if you're willing to fight for your interpretation of the law - but that's probably more costly than just using one of the other LGPL or BSD/MIT/Zlib/etc libraries.)

Really that is academic, because whether you create a derivative work or not is not the issue. The issue is the license agreement you enter into in order to use GPL code. If you use it in a way prescribed by the license (ie. "when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License") and then don't open your code as the license requires, you're breaking the license agreement. You can get your lawyer to argue over the definition if 'a work based on the program' and the like, but that does not change the fact that the intent and meaning of the GPL explicitly covers libraries you link to - hence the existence of the LGPL, which explicitly doesn't. This is quite clear in the GPL FAQ.