License Discussion

[Lioric]

Most of our work inside the plug-in are derative works (copied code of Ogre), but sence they are inside a plug-in
we are home free. We also have our own code inside there as well. But most of the code is Ogre code.

Can you tell me where exactly in the LGPL license document says that because the derivative work is inside a plugin, then the derivative work is not covered by the LGPL

LGPL says that you cant use any of the library code inside your application (plugin or executable), or use it but your application then is LGPL'ed, that is why the issue with the inline code that was clarified/updated in another thread

If you dont want your project open source, you can only dynamically link with the library, so your project dont contains any library code, but uses the library code on run-time

Lioric

[jacmoe]

Most of our work inside the plug-in are derative works (copied code of Ogre), but sence they are inside a plug-in
we are home free. We also have our own code inside there as well. But most of the code is Ogre code.

I say Ogre has a very good structure for letting people add things to it and not share it freely.
(...)
Ogre just offers fundamental stuff it's up to us to flesh it out and then we can choose when and how we want to share it with the Ogre community.

[Lee04]

No I can't.

But the fact is that we had to overload several scene manger Ogre functions inside the custom scene manager (which is open source and included in our sample files), but some of the overloaded functions have been moved inside our plug-in for the purpuse of glueing our plug-in code to Ogre and hiding what it is we do exactlly.

Ofcourse we can rewrite these functions in our plugins from scratch, but the functions inside will do almost the same things as the Ogre functions do anyhow, so there is no point if not the license force us ofcourse. There are just some functions but they are changed and derative code of Ogre for the moment. Like the render function and such.

I don't know exactlly where the line is drawn, but personally I think it's fine to borrow codes from Ogre and use it in our plug-in.
We still patch Ogre when we have something that we notice can be improved in Ogre.

One benifit of using the same lines of code is that when Ogre comes with a new version we can easilly see what we need to change in the plug-in to make it work with the new Ogre version.

I would say that is one good reason not to rewrite the functions inside the plug-in from scratch.

If you should interupte the exact words correctlly in LGPL we might need to open source our plug-in or rewrite thoose 500 lines of code. I don't know, any ideas of whats right or wrong?

/Lee04

[Lee04]

My last inputs surly answered all questions about LGPL I lgueass since the debate stoped.

I thought it would start an even larger and hotter debate.

I like to test limmits of rules and regulations, basically because they are some times controdicional and unclear. By testing them they get to be very clear of what you are allowed to do or not. Knoledge that are worth a lot to other projects and life decitions.

/Lee04

[Lioric]

I was waiting for an official (Ogre team) reply to your post, to see what they think

But in general i agree with you that the license can be interpreted in a "good faith use" perspective, but a license is a legal contract and it can only be interpreted in a legal way if there is not an interpretation document

I don't know exactlly where the line is drawn, but personally I think it's fine to borrow codes from Ogre and use it in our plug-in.
We still patch Ogre when we have something that we notice can be improved in Ogre.

From the earlier Ogre Team posts, looks like they support this "in good faith use" of the license

Lioric

[sinbad]

Like anything which has copyright attached to it, you can't copy & paste large chunks of the code from OGRE and expect to be able to set your own license terms. On the other had, we're not going to slap you if you copy little titbits here and there, because we're coders too and we know that some things are just trivial. SCO probably would though

In my opinion this is a question of magnitude. If you copy and paste a lot of code, we'd frown on that not being released as LGPL with proper copyright statements in place. If it's small things here and there we won't have a problem.

[DarkSeraph]

Copying an entire class and adding a couple of functions would probably violate the LGPL. However, if you create your own class that uses the Ogre class as a base class, you're home free I really don't think the License is that hard.

[Lioric]

Sinbad, thanks for your reply

How about if i move the vector, quaternion, math and matrix clases inside my project for performance reasons, of course Ogre will be the renderer used, is this allowed

We have our own math/geomtry classes but if used with ogre, there is a performance overhead because of the runtime convertion between them

Lioric

[Lee04]

Sinbad wrote:

If it's small things here and there we won't have a problem.

I say: If you inherite the Ogre scene manger and used that as your scene manager. Then infact you have borrowed ALL the functions of the Ogre scene manager.

Then if you overload one of it's functions to alter it's behaviour somewhat then then thats "deritive work of the orignal scene manager code" as well.

I saw somewhere that the Ogre demos are not LGPL you can use them for anything as you will, well almost you can't say you made them etc.

I sudgest this solution:
Ogre scene manger could be concidered one of the Ogre demos as well
A scene manager demo that is none LGP more free like the other demos.
( Note my good retorics )

But if the Ogre scene manager plug-in gets to be free then the question pops up: Why not the other Ogre plug-ins has well???

And then soon not much of Ogre will be left that is LGPL.
The Ogre scene manager is a big part of Ogre.

Well just some thoughts,

/Lee04

[jacmoe]

Nice try, Lee04 !

[sinbad]

How about if i move the vector, quaternion, math and matrix clases inside my project for performance reasons, of course Ogre will be the renderer used, is this allowed

No.

We have our own math/geomtry classes but if used with ogre, there is a performance overhead because of the runtime convertion between them

This is a question of organisation. You'll have the same issues with physics systems, sound systems and anything else that has state to sync up. Many games have state copying anyway since the internal game state is maintained at a fixed frequency, and the graphics state is interpolated where the frame rate is higher than that. So I don't see this as a valid argument at all.[/quote]

Ogre scene manger could be concidered one of the Ogre demos as well

Absolutely not. Deriving from a class is completely different from copying and pasting the source code. I've written / maintained a couple of scene managers, and haven't had any need to block copy & paste code from SceneManager to do it. If you need to because you're doing something different to most people (which I think you are), the way to deal with it is to refactor the SceneManager code so that it behaves the same way but allows you to override what you need without duplicating code, and submit a patch.

[Lee04]

Nice try, Lee04 !

The fact is if someone came along and wrote a new scenemanager that was free as the demos. We would be there already wouln't we.

After all the scene manger files are not so long. (cpp/h)

In fact we will do a scene manager for Ogre soon, maybe then we can flesh it out and cover a complete Ogre scene manager class that any one can extend freely and use witth or without hardware occlusion.

If we don't do it some one else will think it's a good idea.
And then LGPL of the orginal scene manager will seam out of date somehow.

If you need to because you're doing something different to most people (which I think you are), the way to deal with it is to refactor the SceneManager code so that it behaves the same way but allows you to override what you need without duplicating code, and submit a patch.

Sinbad: You do mean OR submit a path not AND submit a patch?

Hmm, in my case it seams to make my own scene manager files from scratch. Because I have been trying to splitt our stuff from the Ogres scene manager code over and over, but there will always be some neuclus that in the plug-in that is still a deriative to Ogres scene manager class.

So makeing my own scene manager class from scratch is the only "leagal" way if I don't wont to submitt a patch on the finer details inside my plug-in.

By know I know a bit about Ogre renderings, I don't know as much about general Ogre scene manager stuff. But we see.

If I choose to make this scene manager LGPL just as Ogres is does that mean I to have to submitt changes to my own scene manager project.

Say if Sinbad does something to his Ogre code or the Ogre team does something do they have to submitt patches to there own LGPL project
just because they decided to go with LGPL???

Just a thought.

/Lee04

[Lioric]

This is a question of organisation. ...... So I don't see this as a valid argument at all.

Sinbad, can you explain how is a matter of organization the overhead of this case

Our math/geom classes are presented to the script engine, so for example the user/script writter do a simple script as this

position = entityX.GetCurrentPosition
entityX.SetPosition(position + someInputValue)

The classType of position is of our OwnVector3 class

so in the engine this will be

Code: Select all

void SetPosition(OwnVector3& newPosition, Entity& ent) {
OgreVector3 pos;
pos = OwnVector_2_OgreVector(newPosition);

ent.SetPosition(pos);
}

[\code]

And multiply this by hundred scripts functions for each frame and we have a considerable overhead because of the runtime convertion

Of course i can refactor our own classes to match the size and property struct of the ogre classes and simply cast to them, but that is not good

How can i avoid this with a different organization


Lioric

[sinbad]

After all the scene manger files are not so long. (cpp/h)

OgreSceneManager.cpp is 4000 lines. That's what I don't agree to make 'as free as the demos'.

If we don't do it some one else will think it's a good idea.
And then LGPL of the orginal scene manager will seam out of date somehow.

Not following you at all.

Sinbad: You do mean OR submit a path not AND submit a patch?

I meant AND, like I said. The point here is that you feel you need to copy lots of code, it might mean the original SceneManager is not modular enough. Hence the patch to make it more modular so you don't have to copy large bits. But like I said, I've written several SMs and not had this problem.

Say if Sinbad does something to his Ogre code or the Ogre team does something do they have to submitt patches to there own LGPL project
just because they decided to go with LGPL???

Well for a start I don't submit patches, I commit directly! For the things I wrote entirely myself, because copyright is never overridden, I could choose to release a version some other way if I wanted to. I've never done that though, and for code which has been contributed to significantly by others I'd have to get their agreement (because of their copyright). Anyway, if we're talking 'good faith' here, I don't think you'll find many here who's given away more code than I

@Lioric: please read http://www.gamasutra.com/features/20050 ... e_01.shtml
This is an example of your 'model' having one set of positions, updated on one frequency, and your graphics system having a different, interpolated set updated at the frame rate. This is to avoid overburdening your game update and providing consistency across systems running at different fps. This would require copying no matter what you did. In the grand scheme of things, copying a few hundred floats is not very significant.

[Lioric]

During research on libraries, there are some interesting LGPL licenses with exceptions, used by major projects like the FLTK and the wxWidgets, to encourage their wider use and benefit from the improvements and code changes

Please take a lookt at this

http://www.fltk.org/doc-2.0/license.html

http://www.wxwidgets.org/newlicen.htm

DevLib library forum post about their LGPL license, that resulted in a LGPL with an exception notice added

http://www.devlib-central.org/phpBB2/vi ... .php?t=167

Lioric

[makeshiftwings]

During research on libraries, there are some interesting LGPL licenses with exceptions, used by major projects like the FLTK and the wxWidgets, to encourage their wider use and benefit from the improvements and code changes

Please take a lookt at this

http://www.fltk.org/doc-2.0/license.html

http://www.wxwidgets.org/newlicen.htm

DevLib library forum post about their LGPL license, that resulted in a LGPL with an exception notice added

http://www.devlib-central.org/phpBB2/vi ... .php?t=167

Lioric

Those licenses only add that you can link statically if you don't change anything at all. In your case, you're still wanting to change Ogre source code, or copy code from it to your own project. None of those licenses give you that right.

[makeshiftwings]

You have to release the modified Ogre source code to your users under the LGPL license. LGPL means that *everyone* has the right to see it, share it, modify it, as long as they respect the license terms. It's not possible to restrict that.

Ah, that's what I thought. So even though technically you don't HAVE to give your code to anyone that asks for it (as in hosting it on your own website for non-valid users), it's still ok for a valid user to distribute it to whoever they want, and it's still LGPL.

does the creator maintain the copyright on the modified code if he only distributes it to users who have bought his product?

The creator always maintains the copyright of his parts of the Ogre code. Still, the terms of the LGPL apply to it. But it's a misconception that you are giving away copyright. You still have copyright in case someone decides to relicense the library commercially or with a more/less restrictive license, even if it's the project leader that decides that.

That's true. But most LGPL products, if you submit an official patch, require transferring your copyright to the owner (in this case sinbad), so that if he decides to offer the ogre code under a different license to someone, he can do so without violating your copyright. I guess Ogre doesn't require that currently, but a lot of sourceforge projects I've seen do. Personally I think it's a good idea... I've seen other GPL or LGPL projects get into trouble when they wanted to change some term of their license and they weren't allowed to unless they got signatures from every single person who ever submitted a patch...

[sinbad]

We don't require copyright assignment, but we do expect you to agree with the contributor license agreement (see the docs folder).

Ok, I have finally lost the will to live whilst reading this thread. I think I've spelt out our position on our licensing enough times already, and many people agree with our interpretation. Please can we close this discussion now before I'm forced to poke my eyes out with a pencil so I don't keep seeing it in the recent posts list?

[makeshiftwings]

Hehe, sorry, didn't mean to add to the pain. But unfortunately it's a fact: licenses are scary and mysterious, best left to lawyers and asylum inmates.