Myst Online: URU Live Forums

Re: Possible GPL issue with PhysX

Mac_Fife — Tue May 17, 2011 5:51 pm

Author: Mac_Fife

Posted: Tue May 17, 2011 5:51 pm

The illustration in the GPL Quick Guide expresslly shows zlib as compatible with both GPLv2 and GPLv3: http://www.gnu.org/licenses/quick-guide-gplv3.html

Re: Possible GPL issue with PhysX

Stucuk — Tue May 17, 2011 2:56 am

Author: Stucuk

Posted: Tue May 17, 2011 2:56 am

PaladinOfKaos wrote:

if Newton is GPL-compatible now

According to the GNU website the ZLib License (Which Newton uses) is compatible with the GPL License. There is nothing which states its incompatible with GPLv3 (According to the GNU website if they don't state that a particular license is incompatible with a version of GPL then all versions should be compatible).

Re: Possible GPL issue with PhysX

PaladinOfKaos — Tue May 17, 2011 2:37 am

Author: PaladinOfKaos

Posted: Tue May 17, 2011 2:37 am

if Newton is GPL-compatible now, I may make the effort to look into it. I'd basically decided to use Bullet already, since I had good luck with it in PlasmaClient. I made the initial decision to use bullet for PC before Newton was open-source, though.

Re: Possible GPL issue with PhysX

Stucuk — Mon May 16, 2011 11:11 pm

Author: Stucuk

Posted: Mon May 16, 2011 11:11 pm

Newton Game Dynamics is under the ZLib License which is compatible with the GPL license.

Newton went Open Source earlier this year. Newton unlike some Physics Engines has been designed to be as accurate/stable as possible(So you don't have ragdolls flying away magically like you do in Half-Life 2 when you put a ragdoll in a doorway and close the door) but at the same time fast(It has 2 solvers, one thats very accurate but slower and one designed for real-time usage such as games).

Re: Possible GPL issue with PhysX

Keikoku — Mon May 16, 2011 2:06 am

Author: Keikoku

Posted: Mon May 16, 2011 2:06 am

ChloeRhodes wrote:

Couldn't we simply, create an install package for the client itself that would copy the required libraries from the physx directory into the Uru directory. So in short, when installing you install the PhysX SDK. Then the you open the install package that we distribute and it simply installs the Uru components onto your system in the appropriate places, and copies the PhysX and any other GPL issue libraries from the previous SDK download into the new Uru directory?

I don't think that this is sufficient. Even if we don't include the PhysX or OpenSSL DLLs in any binary distribution, the executable itself still has to be built using those libraries' header files.

Re: Possible GPL issue with PhysX

ChloeRhodes — Tue May 10, 2011 12:21 am

Author: ChloeRhodes

Posted: Tue May 10, 2011 12:21 am

PaladinOfKaos wrote:

While those are overall ecosystem issues and they do (somewhat) limit the directions the code can go by limiting which libraries we can use, I'm mostly just concerned with making sure distributing client builds is 100% legal.

I am in favor of replacing non-GPL components when possible... but it's not a particularly high priority, as long as they don't interfere with distributing client builds.

Couldn't we simply, create an install package for the client itself that would copy the required libraries from the physx directory into the Uru directory. So in short, when installing you install the PhysX SDK. Then the you open the install package that we distribute and it simply installs the Uru components onto your system in the appropriate places, and copies the PhysX and any other GPL issue libraries from the previous SDK download into the new Uru directory?

Re: Possible GPL issue with PhysX

PaladinOfKaos — Sat May 07, 2011 5:52 pm

Author: PaladinOfKaos

Posted: Sat May 07, 2011 5:52 pm

While those are overall ecosystem issues and they do (somewhat) limit the directions the code can go by limiting which libraries we can use, I'm mostly just concerned with making sure distributing client builds is 100% legal.

I am in favor of replacing non-GPL components when possible... but it's not a particularly high priority, as long as they don't interfere with distributing client builds.

Re: Possible GPL issue with PhysX

Keikoku — Fri May 06, 2011 7:22 pm

Author: Keikoku

Posted: Fri May 06, 2011 7:22 pm

PaladinOfKaos wrote:

The GPL is fine for this, but they need to add the correct linking exceptions.

A linking exception is enough to allow distribution of binaries made from the existing code, but still leaves a couple of problems:

1. It needs to be made clear that any contributions are made under GPLv3-with-exceptions, not just GPLv3 (or compatible, e.g. GPLv2-or-later). Ideally, before someone is granted commit access, they should provide an explicit licence statement regarding their contributions.

2. We can't use any GPL libraries without first getting exceptions from their authors. And unless the library is developed by a relatively small team of people (or it requires GNU-style copyright assignment), getting such an exception is unlikely.

In the longer term, replacing PhysX with Bullet would eliminate a significant issue. The OpenSSL issue could potentially be worked around by delegating connection management to a plug-in (e.g. invoking ssh or s_client to create the connection).

Re: Possible GPL issue with PhysX

PaladinOfKaos — Wed May 04, 2011 6:37 pm

Author: PaladinOfKaos

Posted: Wed May 04, 2011 6:37 pm

MustardJeep wrote:

Wow put my foot in it a little bit the early version of GPLv3 I saw a while back wasn't nearly as nasty as the finished product.

Wonder why in creation Cyan picked it.

I assume they picked it becasue it means they'll be the only company that can offer closed-source licenses - a more distributor-friendly OSI license would allow someone else to create a closed product from the code.

The GPL is fine for this, but they need to add the correct linking exceptions.

Re: Possible GPL issue with PhysX

Deledrius — Wed May 04, 2011 3:12 pm

Author: Deledrius

Posted: Wed May 04, 2011 3:12 pm

MustardJeep wrote:

Wonder why in creation Cyan picked it.

I was going to assume it's due to the server provisions of the Affero clause, but it seems they chose not to use that particular version.

Re: Possible GPL issue with PhysX

MustardJeep — Wed May 04, 2011 6:09 am

Author: MustardJeep

Posted: Wed May 04, 2011 6:09 am

Wow put my foot in it a little bit the early version of GPLv3 I saw a while back wasn't nearly as nasty as the finished product.

Wonder why in creation Cyan picked it.

Re: Possible GPL issue with PhysX

PaladinOfKaos — Wed May 04, 2011 4:34 am

Author: PaladinOfKaos

Posted: Wed May 04, 2011 4:34 am

ODE from Myst 5 won't cut it for Uru physics, not by a long shot.

I've had good luck with Bullet in PlasmaClient, and I do have plans to port CWE to use Bullet... it's one of many things on my list.

Re: Possible GPL issue with PhysX

D'raekmus — Wed May 04, 2011 3:35 am

Author: D'raekmus

Posted: Wed May 04, 2011 3:35 am

Well, I'm not sure how feasible it is... but, when replaying my Myst V game, I noticed one of the credits referenced the ODE, the open Dynamics Engine, a physics engine, which is under the LGPL.

Now, the way I see it, we can kill two birds with one stone: if we ask Cyan to consider working on releasing their information regarding the ODE implementation in Plasma (NOT, mind you, releasing Myst V or even more of their engine. Just the libraries and calls to ODE), we might have more feasibility, legally speaking.

In addition, by getting off of PhysX, we would be able to take a far more open approach (If we get some REALLY good devs to work on the ODE library, we might be able to rival the Havok engine in performance!) and modify a greater portion of the code... without having to use a different physics engine.

But, I'm no programmer, so I'm not sure to what extent the ODE is released. Surely more than PhysX, though.

Perhaps this would also increase our own ability to implement cross-platform support, as well as add in a 64-bit client for those running the advanced OSes.

Then again... I saw the latest PhysX have a Linux client... hmm... who knows. Just a rambling thought.

Re: Possible GPL issue with PhysX

MustardJeep — Wed May 04, 2011 1:51 am

Author: MustardJeep

Posted: Wed May 04, 2011 1:51 am

@ adam

Did, but this post is just to congratulate you. Eight years in I finally see a post of yours stating a bad opinion on the gpl.

Cheers!

On another note not that I've been Researching the applicable licenses for the last eight years in fear cyan would go gpl considering it's popularity with a certain "redacted" guild group when thing finally went os..... but

as long as a file is nominally a "library" free standing and separate a gpl program can make use of it but not "infect" it. So the easy answer is the same one as the moula data file repository. Use the moula install. take great pains in keeping the fan client versions in line with the current moula version of physx and it's possible.

simplistic maybe but it is arguably a faster approach then gutting physx out of the client or getting a better license from cyan.

ps jwplatt did you really expect the gpl guys to tell you a "official" way on how to bypass the gpl?

Re: Possible GPL issue with PhysX

JWPlatt — Tue May 03, 2011 5:53 pm

Author: JWPlatt

Posted: Tue May 03, 2011 5:53 pm

Both OpenUru.org and the GoW have sent their opinions on this matter to Cyan Legal. For our part, I first communicated with a representative of the Free Software Foundation who, after some discussion, could not provide an authoritative answer specifically about PhysX except that in the absence of clear permission, an exception is recommended. However, PhysX is not the only library affected by this question. The GPLv3 does have a somewhat ambiguous "out" when a library can be reasonable expected to be part of the OS. The question gets technical and I could find no precedent for or against PhysX, a free physics SDK with a liberal licence (the main constraint being that you must register and download it yourself for distributed builds), but it's not open source.

In the absence of a clear ruling or precedent, or exceptions in the Cyan license, these are some of the options: 1) Make everyone compile their own client and plugin - hardly workable, but legal. 2) Wait for Cyan exceptions in their license. 3) Develop for other libraries. 4) Go ahead and build for public release to draw attention and wait for legal complaints to test precedent for a clear ruling. The last option is clearly not preferred.