Sign in to follow this  
Lumino

DotA - Defense of the Assets

Recommended Posts

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

Share this post


Link to post
Share on other sites
If you're linking to GPL, even dynamically I believe that means your engine has to be OS.

I would find some libraries that let you static link freely.

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Even that is open to interpretation. "a work based on the Program" is not "a work that uses a Program". So, imagine I'm using a GPL'd PNG image loader library in my latest blockbusting FPS. An FPS is not based on a PNG image loader, it is orders of magnitude more than an image loader. Could I distribute the FPS without the PNG loader and include instructions for installing the library? Or distribute it as two separate packages? Now, if I extended the PNG loader to include meta-data for the FPS, then yes, the bits I've added should be publicly available. What if the FPS used patented and properly licensed software as well? What if the FPS linked to another non-GPL'd library, should that other library become GPL'd? I don't think Havok et al would appreciate that idea very much.

Personally, I think the idea of forcing GPL on to applications that use GPL code is wrong.

It seems to me that the whole point of license agreements (and lawers) is to be vague and therefore open to interpretation and thus require a test case in a court of law to define the limits. Until that happens......

Skizz

Share this post


Link to post
Share on other sites
If you don't want to follow the ideas imposed by the GPL (of releasing your own code under the same licence), or if you're unable to follow its terms (because you're also using libraries with GPL-incompatible licences), you simply don't use any GPL'd libraries. That's intentional - the GPL is meant to encourage free software by giving it access to code and libraries which can't be used by proprietary software.

It's perfectly fine to disagree with the intent - you should encourage library authors to release their code under a more permissive licence, and in the meantime you can still use libpng and libjpeg, use wxWidgets instead of Qt, buy commercial libraries, etc. OGRE changed from the GPL to the LGPL, and you could ask other projects to do the same (though that'll only be possible if they are the owners of all the code). I'm working on a project where we haven't decided yet whether to release any/all of the code, so we use libraries which are okay with that and put up with the slightly limited choice. But you can't just ignore the restrictions impose by the licence because you don't agree with them.

(Uh, is this getting off-topic? If the original poster is using GPL and not LGPL libraries, then the way to avoid the stated problem is to either statically link (and have to release the engine's code, same as when dynamically linking) or to use non-GPL libraries instead. If there's some use of LGPL libraries where it does make sense to dynamically link, then technical ways to stop people accessing the data as it travels around their own computer would be relevant, even if they happen to be infeasible and provide little benefit [smile])

Share this post


Link to post
Share on other sites
Thanks guys,
It's nice to get an idea of how others are dealing with this. I've decided to go with FreeImage and use it under their own licence (FIPL).

I think I should be able to handle the model loading code myself *crosses fingers* but I guess I can allways give you guys a yell if it dosen't quite work out.

I'll be sure to make note of how everything is handled once the website is up so anyone working with it knows what has been done in an attempt to look after their work.

Thanks again.

Share this post


Link to post
Share on other sites
It's for the reasons above that I don't understand why some programming library authors release their libraries under the GPL. They must know they're seriously reducing the number of people that will use their library.

GPL is more a religion than a license.

Share this post


Link to post
Share on other sites
Quote:
Original post by PlayerX
It's for the reasons above that I don't understand why some programming library authors release their libraries under the GPL. They must know they're seriously reducing the number of people that will use their library.


Asking for money for a proprietary library will reduce the number of people using it just as well. For that matter, a free (as in free beer) proprietary library will reduce that number too, because it won't be possible to link it into a GPL program. Do you think the authors realize that? I bet they do, and they probably don't care. [smile] They target the proprietary software developers. Likewise, the GPL library authors target the free software crowd, and they probably don't care if you can't use their work in your proprietary game. I know I wouldn't.


Quote:
GPL is more a religion than a license.


I think "communism" and "terrorism" are more trendy this time of the year. Or is that already old school? [grin] Anyway, gotta run to the church, Saint IGNUcius is waiting.


Lumino: in a nutshell, if you don't want the users of your engine to have to release their source code, then you'll want to avoid GPL libraries. That's the "safest" way.

Share this post


Link to post
Share on other sites
Wow. Licensing is really complex and totally out of date with the way software works. For example, lets assume I've written a system that uses a plugin architecture (like 3DSMax) and I make the plugin API public. Let's say I make the application free but not open source (i.e. not GPL). Now, what happens if someone writes a plugin and makes the plugin GPL (there are some programmers that slap GPL on software without really thinking about it). Would that mean no-one would be able to use the plugin? And what's the difference between this situation (non-GPL app dynamically linked to GPL plugin) and me writing a non-GPL app that uses a GPL DLL? Technically, they work identically.

Can->Fill (Worms);

Skizz

Share this post


Link to post
Share on other sites
Quote:
Original post by Skizz
Wow. Licensing is really complex and totally out of date with the way software works. For example, lets assume I've written a system that uses a plugin architecture (like 3DSMax) and I make the plugin API public. Let's say I make the application free but not open source (i.e. not GPL). Now, what happens if someone writes a plugin and makes the plugin GPL (there are some programmers that slap GPL on software without really thinking about it). Would that mean no-one would be able to use the plugin?


Incidently, this is a FAQ. Note that the price is absolutely irrelevant.


Quote:
And what's the difference between this situation (non-GPL app dynamically linked to GPL plugin) and me writing a non-GPL app that uses a GPL DLL? Technically, they work identically.


The former application doesn't need the GPL plugin to function, the latter needs the GPL library to run at all. The latter therefore depends on the GPL library, and by the FSF definition, it becomes a derived work. Whether you think that's OK or not doesn't matter: if you don't agree with these terms, then you aren't accepting the license, and nothing else grants you the right to use the software. Of course, I'm saying "FSF", but what really matters is what the author thinks: some authors wouldn't consider dynamic linking a derived work, some would. It's probably wiser to ask the author beforehand.

Also, note that a GPL library can only be used with other GPL-compatible code. Therefore, you can either 1) license your own code under a GPL-compatible license and release the whole under the GPL or 2) not use the GPL library, because it can't be used with proprietary software (unless explicitely allowed by the author, obviously, c.f. the GNU libc and GUILE).

Seriously, in 22 years of existence, I'm quite sure that the GNU people have managed to cover most of these "cans of worms", especially obvious ones like these.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this