I've been told that vegastrike-0.4.3 has src/cmd/collide/prapid.* which is probably undistributable. The files are also found in current svn. More information about the bug can be found at http://bugs.debian.org/449475
Here's quoting the bug report.
After looking up copyright notices in the various files in the
vegastrike tarball, it appeared that the files
src/cmd/collide/prapid.h and src/cmd/collide/prapid.cpp cannot be
distributed.
Indeed, the code is said to be Copyright (C) 1998 by Jorrit
Tyberghein and licensed under the GPL, but it is said to be based on
an implementation originally Copyright 1995 The University of North
Carolina at Chapel Hill, and whose license only permits
modification/distribution and so on 'for educational, research and
non-profit purposes'. This is, to my knowledge, incompatible with the
GPL. So these files cannot be distributed.
I was under the impression Crystal Space is GPL code. That remark you quoted says nothing about the license. It specifically says "based on
an implementation originally Copyright ..."
Unless this method of collision was patented, I believe it should be fine.
However we are using a significantly older version, and it's possible that the code we included with Vega Strike was on legally shady ground at the time.
Let's see what the Debian Legal team says about this issue.
In the meantime, I would be interested in this older version from 1995 (If the legal bug submitter had actually posted a link to the original source code). It's possible he used that as a reference implementation, but wrote the GPL code himself.
This Debian report really ought to have been directed to Crystal Space, but it's true that we include a specific revision of their collision engine that might specifically be at fault.
I've checked with debian-legal, and they confirmed that the files cannot be distributed (by no one, basically); see the replies in the bug page http://bugs.debian.org/449475.
The version of CrystalSpace currently in debian does not include this code. Would there be any way to adapt the current code in vegastrike to use more recent collision-detection algorithms from Crystalspace ? I don't know how much work that represents, but I'm afraid we would have to remove vegastrike from debian if this situation does not change (we can't afford to have legal problems with anyone, especially if we're sure to lose). That would really be a pity.
Wait, does that mean that vegastrike could be built with a stock version of CrystalSpace rather than embedded code ? Could this be reasonably done ? That would solve our problem here.
While I'm on the subject, the vegastrike version we have in Debian is really outdated. What could I pull from SVN to make a more up-to-date (but not beta, probably) version ? Thanks
We are still at the beta stage very playable but beta still a few stoppers buried somewhere till they bite and are reported.So as much as i would like a new version in your repos not yet not sure on the path that the devs will take on replacing the offending code.
Enjoy the Choice
my box::HP Envy i5-6400 @2Q70GHzx4 8 Gb ram/1 Tb(Win10 64)/3 Tb Mint 19.2/GTX745 4Gb acer S243HL K222HQL
Q8200/Asus P5QDLX/8 Gb ram/WD 2Tb 2-500 G HD/GF GT640 2Gb Mint 17.3 64 bit Win 10 32 bit acer and Lenovo ideapad 320-15ARB Win 10/Mint 19.2
vince-deb wrote:Wait, does that mean that vegastrike could be built with a stock version of CrystalSpace rather than embedded code ?
In short - not exactly.
Initial analysis by HellcatV indicates that the offending piece of code (a couple of functions originally copied from an ancient version of CrystalSpace) can be replaced by the code that handles the same/similar functionality from CrystalSpace v1.2. While this should not be difficult (as the interfaces seem, at least on initial inspection, to not have diverged significantly, if at all) it would not be entirely accurate to say that VS can be built against a stock version of Crystalspace.
(HellcatV, who is the most familiar with the code in question, is coming up on a SIGGRAPH submission deadline, or he'd have already done the code swap/cleanup himself.)
jackS wrote:
(HellcatV, who is the most familiar with the code in question, is coming up on a SIGGRAPH submission deadline, or he'd have already done the code swap/cleanup himself.)
Many thanks that you are working on this. I'm not in a hurry: the bug has been around for quite a while now. It just need to be fixed before Lenny's freeze, say, sometime this summer.
Well I'm hoping 5.0 will end up in debian anyway, or at least a beta version of it. I'm thinking the final release *will* happen during february come hell or high water so that should make the debian deadline.
(I know people said the same thing in September but I think what we have now is in general pretty well tested)
This is definitely going to be fixed before we release 5.0, probably around the end of january
Is there any update about this ? I haven't noticed any release of vegastrike for the past month ... (though I surely didn't miss the posts about the new collider !) It seems I was wrong about the freeze for next Debian version, and it would be good if a new version of Vegastrike could make its way into the Debian archive reasonably soon. Can I pull a SVN version ? Would there be a preferable revision to pull in that case ?
The current rev doesn't seem too bad. Bugs are going away rather than appearing it seems like . I think we are inching very close to the release. Just a couple more things being worked on and no new projects starting (I hope ) Maybe wait another week or so and see if it can be packaged.
Great, thanks ! I'll package the state I'll find beginning of April (but that will not prevent a later more mature version from being included later on).
So, then, you'll be glad to know that I have started to re-package vegastrike for debian, now that legal problems have gone away. During the process, I had to review quite a few very old patches that were applied to the previous (also very old) version of vegastrike included in debian/unstable.
Some are of no interest to the community in general, but some could be. I'll post them to the sourceforge trackers (suggestion from Patrick Horn).
Thanks to the developers for your being very nice to packagers !