third party library copyright issues

Engines, Libraries and Tools Xith3D Forums
#1

I was thinking about the third-party libraries earlier and realised that we really havn’t credited the authors and have possibly voilated their copyright (most licenses require you to list the distributions terms etc…).

I think we should have (in the xith3d cvs tree) a readme text file in the third-pary folder that listed all of the third party libraries along with, their versions, copyright holders and main download location or other contact details. Also, we probably should have a copy of their respective licenses in each folder.

While this is not a huge issue now, probably a good one to get out of the way.

Is all of the code BSD-licensed? The vorbis library for example? Someone writing a closed-source (or simply non-GPL) application will have to be carefull if using a feature of Xith which uses GPL code (ie they will have to not use that feature). More importantly the vecmath library being so intergral - I guess the one is the Sun one? Has anyone tried this one: http://objectclub.esm.co.jp/vecmath/? If that latter is reliable it’s probably good to switch to that… Sun have a rather energetic legal team after all :wink:

Normally it would be the developer of a program that would worry about such matters (eg in the case of Java, how to distribute the JRE) but in this case, we are distributing the libraries along side Xith3D rather than telling people where to get them and because of that we should make the legal stuff very clear (ie. tell people what the deal is and make sure they know they should check it all out themselves).

Will.

#2

The Vorbis library is LGPL. I agree that we should post and publish any necessary license statements and copyright notices as is legally required.

As far as I know the current copyright holders are:

ShavenPuppy BSD - spatial objects
Xith3D Development Group - BSD
Vorbis - LGPL - Ogg reader
JOGL - BSD
JOAL - BSD
Vecmath - Sun Microsystems
John Ratcliff - BSD - Sphere trees
xith_utilities - David Yazel

#3

thanks for that list - the only questionable thing I can see is the vecmath library.

Reading this: http://java.sun.com/products/java-media/3D/java3d-1_3_1-license.html

and in particular:

Looks like the Xj3D people have also made their own implementation: http://www.web3d.org/TaskGroups/source/doc/org/web3d/vecmath/package-summary.html
no idea where to get it though (I guess it’s bundled as part of Xj3d?)

Will.

#4

ok, I have added the licenses of JOGL, JOAL and JOrbis into their respective folders in the third-party directory, and started a third party license readme file. Should cover our backs for now :).

Will.

#5

Shawn kendall is working on a new vecmath library. Hopefully he will release it with a BSD license. If so we can switch.

#6

I just released a chuck of the vecmath API.
The post is over at:
http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=share;action=display;num=1064642997

#7

edit for readability :slight_smile:

thanks for the library, I might plug that in and give it a spin with Xith3D tonight, see if it behaves itself :slight_smile:

To summerise the Third-Party library issues:

  • the Java3D native dep is gone,
  • and it looks like Java3D vecmath dep is on the way out
  • once the xith_utilities future is clarified, we will be good to go.

When people start distributing their projects, the distribution issue will be extreemly important, so I think it is wise to resolve it early. I shall conduct some tests with the vecmath against the example code I have and aganst the official demos (com.xith3d.test).

Will.

#8

I’m sorry I misunderstand your last post.
Did you give a whirl?
It read like you modded your post.
Anyway, please let me know you success/failure as it goes. The APIs is very incomplete compared to J3D VecMath, but it’s building out as needed and we didn’t need anymore other than the invert()s.
I think your tests will be far greater than ours so you guys will hit errors/weaknesses before I.
I will fix ASAP, of course, anyone can now and I’ll fold (or you guys can) it back into the “offical” release. :slight_smile:

#9

my apologies I have translated it into English now :wink:

I will give it a test in a few hours when I get home.

It would be a lot better if the package had the same name as the official one (my reasons for this are in the other thread). Fair enough it’s not too hard to change a few import statements with a batch find-replace but i feel even that I should not need to do :slight_smile:

Will.

#10

No offense, but the package name can NOT be the same.
It’s not the same API, or code.
And it’s not “javax”, that is a “semi” official package division used on many Java APIs.

Anyone else have an view? I’ve never heard of releasing an API with the same package name as an existing one from another source…

#11

I would not think it would have the same package name. If we made this switch it would by ripping sun’s vecmath out completely and refactoring for the new library. It would not matter what the package name was. Of more importance would be the compatibility on method signatures and its behavior.

#12

Agree with David.

Package name does not really matter.

Yuri

#13

[quote]No offense, but the package name can NOT be the same.
It’s not the same API, or code.
And it’s not “javax”, that is a “semi” official package division used on many Java APIs.

Anyone else have an view? I’ve never heard of releasing an API with the same package name as an existing one from another source…
[/quote]
A misunderstanding of the goals of your project, I thought it to be more inline with the other unoffiical vecmath package (http://objectclub.esm.co.jp/vecmath/?) that does retain the javax.vecmath name. My mistake. I have replied in full here: http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=share;action=display;num=1064642997

Fair enough, not too hard to change the Xith3D code, and it will be good to be totally rid of Java3D.

Would this however add another hurdle for people porting Java3D code to Xith3D? Would it matter if it did?

Has anyone actually tried using the other javax.vecmath implementation with Xith3D maybe all we will have to do is just replace the Java3D one with that and all our (copyright) problems will be solved? I shall be testing it myself today.

Cheers,

Will.

#14

I see quite simple scenario of porting from javax.vecmath to another library - if we achieve compatibility on a such level where we just replace imports (package names), this would be perfect.

Afterwards we can tune some points to use improved functionality (what I miss is an pint array transforms [i.e. applying some transform to all the points in the array]).

Yuri

#15

okay, well I guess I got a bit too excited over nothing :-X

An enhanced vecmath seems like a good way to go. Is full backward compatibility to the old vecmath library (eg. the colour types) somthing we need as well?

One question I would really like to have answered is what can we do about xith_utilities.jar? I understand that the code is currently David’s. Are there any plans to either open source that library or integrate the nessesary components into Xith3D? Either way it would be nice to be able to tinker with the code directally and it seems unnessesary that Xith3D would use a closed source library like that one when the rest of the project and it’s related libraries are totally open source.

Will

#16

Are there any news on this very important topic?
Thanks.

#17

xith_utilities.jar has been integrated in the Xith3D core, which solved the license problem.

#18

[quote]xith_utilities.jar has been integrated in the Xith3D core, which solved the license problem.
[/quote]
Thanks, that’s fine.
However what’s with vecmath? I’ve read here that it’s the Java3d’s vecmath so … in case you would like to distribute a game based on Xith3d: would you really have to include the entire Java3d package, too?

#19

I think vecmath.jar is a free implementation of vector math and not actually the Java3D version.

Kev

#20

AFAIR it’s the Java3D version. Shawnkendall said he’s working on a vecmath API. There probably exist more free implementations, which could be used.