Robert Osfield wrote:
This exception covers the distribution of your final application, not
source code modifications. If you modify the source then those
modifications must be open sourced under the same licence as the
orignal work - the LGPL parts of the license cover this.
The exception refers to "works based on the Library". The phrase "based
on" is defined in the GPL and covers any source code changes. If this is
not what you intended I would recommend changing the license.
Again, I don't expect that my company will be behaving contrary to your
current understanding of the license, but it seems that some behavior is
allowed by the license that you want restricted. You might want to check
this with a lawyer.
Where do I configure the SO version number, and how does it
restrict which plugins are loaded?
The plugins directory is number be the version. If you bump the SO
version then there will always be bump of the version number.
So I would use version 2.8.1 then? Seems this would easily conflict with
someone else's updates. Or an official patch to OSG. The SO version
doesn't seem to affect plugins.
I don't think this addresses the general problem handling the
coexistence of builds using different compiler versions or build
options (e.g. different settings for OSG_USE_FLOAT_MATRIX). Should
everyone use a different SO version number? Should we just accept
that multiple installs of OSG may not work on a single machine?
If you have multiple installs then you shouldn't have a problem. But
if you say you are installing it one place and then move it elsewhere
and don't set the paths explicitly and have version number and SO
versions overlapping then you may come across a problem.
I install it in a path configured by the user when he installs the
application. This is pretty much standard behavior for programs
nowadays. The problem is that OSG compiles in an install path at build
time, which is much too early in the install process (with a possible
exception for developers).
Let me spell out specifically a sequence of events that will lead to a
problem.
1. Two applications, AppA and AppB, distributed by different companies,
install the same version of OSG on a system.
2. These two builds of OSG use different options for
OSG_USE_FLOAT_MATRIX (or some other setting).
3. These two builds use the same (default) compiled in
OSG_DEFAULT_LIBRARY_PATH.
4. AppA installs a plugin not installed by AppB.
5. AppB will find this plugin in its plugin search path and try to use
it if the user tries to load a file of the appropriate type.
6. Any MatrixTransforms created by this plugin will be binary
incompatible with the running version of OSG. A crash will likely ensue.
The only steps that look reasonable to change to fix this problem is #3
or #5: where plugins are loaded. Either make sure everyone who
distributes an OSG binary uses a unique install path or not have the
install path searched. Your preference seems to be to tell developers to
move their plugins if their customers have problems. I personally think
this problem should be avoided before customers get their hands on the
product. Force developers to specify a unique install path in the CMake
configuration (if CMake has this ability, perhaps suggesting they use
their company or application's name in the path), or drop the default
install path.
Regards,
Mark
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
