Recommend use of MIT license to fit in other VulkanSceneGraph projects,

[robertosfield]

All the vsg-dev VulkanSceneGraph projects use the MIT license to make it clear that developers on embedded platforms can use the various VSG libraries without infringing upon LGPL requirements. This was a problem for the companies wanting to use the OpenSceneGraph, which is why we adopted the WxWdigets relaxation of LGPL, but this was never a satisfactory solution and caused issues of it's own. I regret not keeping life simple and just adopting MIT for the OSG project at the outset, 24 years of hindsight is lovely thing!

I understand Rui Wang's (@xarray) osgPhysX was reviewed prior to the development of vsgPhysX but as the implementation shares no code, and only a couple so very specific function name similarities vsgPhysX is not a derivative work of osgPhysX and needn't adopt the LGPL because of this. It does however directly reuse VSG code which is MIT, while the MIT permits this type of copying and I'm fine with my code being copied this way., to me it feels a bit perverse to adopt the LGPL for appearance sake, rather than the MIT which is used on code that 's been directly copied in and then amended.

I included Rui's github account into this message so he's aware of this project, my suggestion to move to MIT, and can do a code review to see if he has any concerns w.r.t any similarities and licensing.

[AnyOldName3]

I'll start by saying that if Rui Wang/xarray appears and says it's okay to use MIT for this project, then that makes all other discussion moot and I can change the licence right away.

I'll also mention from the outset that when the licence was chosen, I was expecting to directly copy a decent amount of code, and ended up not doing, so was expecting to end up unambiguously needing to be LGPL, and not in a grey area.

Unfortunately, the amount of inspiration one library can take from another without being considered a derivative work is very much a grey area, with case law setting precedents in conflicting directions while leaving plenty of gaps. Google v Oracle is still being reviewed, so it's not even unambiguously okay to have matching method names, and in this case, there are similarities in the implementation, too (although that's got more to do with there being only one sensible way to use PhysX with scenegraph middleware to do certain things than the fact that I was looking at how osgPhysX did things). It really comes down to whether the things I copied are too trivial to contain IP, and what my appetite for legal risk is.

It's a stretch to say there's no shared code when there are functions whose only difference is that I've added physx:: prefixes to some things whereas osgPhysX has using physx at the top of its files instead. However, these functions are all small and obvious, so aren't necessarily a problem even if they are derivative.

It's probably fine to relicense as MIT, but I want to be sure I've got good grounds to do so first.

[robertosfield]

There is well established principle that interfaces are not copyrightable:

"The set of operations available through the interface is not copyrightable in the United States under Lotus v. Borland"

https://en.wikipedia.org/wiki/Software_copyright#:~:text=The%20graphics%2C%20sounds%2C%20and%20appearance,United%20States%20under%20Lotus%20v

My adding Rui to this thread is out of curtesy not any actual copyright requirement.

[AnyOldName3]

It's not just two APIs with a similar set of operations, and Lotus v. Borland only covers the user interface (e.g. GUIs) rather than APIs. For APIs, Google v. Oracle is the most relevant case (which found Google copied Java APIs under fair use, but initially that APIs are copyrightable), and that's still not finalised, and only makes the similar APIs okay, not the similar implementations. There are literally functions with identical implementations that I wrote while looking at the original, which makes them derivative both on grounds of similarity and provenance, so the justification has to be the implementations being copied under fair use, or that they're too simple and obvious to be copyrightable. They're certainly too simple and obvious for me to do a from-scratch rewrite that implements them differently, which I believe means the similarity wouldn't matter had I not been looking at the original when I wrote these functions, but provenance matters to copyright.

My adding Rui to this thread is out of curtesy not any actual copyright requirement.

I mentioned that he can make this discussion moot because, as the copyright holder, he can grant any permissions he wants, or say he believes he's already granted them, even if they're not already granted by the licence of his project or copyright law itself.

[robertosfield]

When I talked about using osgPhysX to learn about PhysX/SceneGraph integration it was never my intention that vsgPhysX would be directly based on/derived from osgPhysX. It was always my intention that vsgPhysX would be an independent work and licensed under the MIT like all the rest of the vsg-dev family projects. I'm sorry if I didn't make this clearer at time. As soon as you made vsgPhysX public I flagged this to you as an issue that you needed to resolve.

If you really think that these function signatures in some way in some universe might be construed derivative work then rewrite them. It's a tiny amount of code in question. We've wasted far more time trying to get you to do what was originally intended than it would to just rewrite these methods.

The licensing issue is an important one to fix as others might start trying out vsgPhysX, making submissions, which would be under the license they checked it out with, then you are stuck needing to get permission from all contributors to change the license subsequently. This issue is the only reason why the OSG isn't under the MIT license, once the horse has bolted it's very hard to get back into the stable.

I want vsgPhysX to be a valued part of the VSG suite of libraries, to have a consistent approach to building, linking and licensing,. This consistency is a big part of easing the burden on developers who lives are already way too complicated by 3rd party dependencies all doing different things. At least within the VSG family of projects we need to provide some kind of sanity. Consistent licensing is a big part of that.

[AnyOldName3]

When I talked about using osgPhysX to learn about PhysX/SceneGraph integration it was never my intention that vsgPhysX would be directly based on/derived from osgPhysX.

Without two people working on it so there was provable clean-room design, there was no unambiguous way to make it not a derivative work. I did bring this up before I started. Even if we take Google v. Oracle's current status as fixed, it's not carte blanche to look at the headers for a C++ project as, in addition to the API that's okay to copy, there can also be inline functions and templates that expose you to implementation (this is also a problem with the LGPL as it doesn't grant unambiguous permission to call any of these from a non-copyleft project, and I think it's one of the reasons the Wx modifications exist I double checked and the LGPL has an explicit carveout for inline functions). If there'd been sufficient documentation, I could have looked through that to work out what I needed to do without looking at headers, but there wasn't, and the behaviour of some functions (e.g. whether box size was the half extents like PhysX or whole box like OSG shapes) was ambiguous with just the declaration.

If you really think that these function signatures in some way in some universe might be construed derivative work then rewrite them. It's a tiny amount of code in question.

The three remaining functions that I'd not determined to be definitely safe a couple of days ago are too simple to rewrite differently. If I deleted them and wrote new ones to do the same jobs, git wouldn't detect any changes and there'd be nothing to commit. Rewriting them wouldn't accomplish anything.

However, this gives a pretty strong argument that they contain no expression, only ideas, which aren't copyrightable. That's been one of two prongs I've been investigating. The other's that as I've clearly got 3/4 of a fair use claim, whether these functions are trivial enough that there's also the nature of the copyrighted content part, that would bring it up to a whole fair use claim, and then there's no need to worry about copyright for these functions.

We've wasted far more time trying to get you to do what was originally intended than it would to just rewrite these methods.

It didn't need to be a two-person task - I said days ago that I was looking into it, and I expect that it would have been sorted by now had I not needed to spend so much time explaining why I felt I needed to check.

[AnyOldName3]

Okay, I'm done checking, and am satisfied that at least one of the things that makes this probably-okay will apply. I'll change the licence now.

[AnyOldName3]

https://github.com/AnyOldName3/vsgPhysX/commit/a0cfc946cf276cea0f33f04adcaab733cd8c1295

[xarray]

I've changed osgPhsyX license to MIT now. Please feel free to modify and use any parts of this project. I'm also considering integrate PhysX 5 later, with osgVerse (https://github.com/xarray/osgverse) and with VSG later. Current osgPhysX repo may be deprecated at that time. Sorry for my late reply as I can't sit still these days because of a sudden attack of arthritis.

[robertosfield]

Thanks for the reply. Sorry to hear about your arthritis, that sucks. I hope you find treatment quickly.