Assistance/advice in choosing a license for POV-Ray 4.0

[Chris Cason]

Chuck Swiger wrote:
> If the vendor's code fetches the GPL'ed component without the end-users'
> intervention, and if the vendor's code will not run without it, then the
> vendor's code is probably a derivative work and the behavior you've
> described would be violating the GPL.
> 
> On the other hand, if the vendor's code works just fine by itself, but
> it provides an optional mechanism for the end-user to download
> additional components, then the vendor is not violating the GPL.  If the

One of the common requests we get is to allow POV-Ray to be used as the
'final renderer' in CAD apps which use OpenGL for the interactive stuff.
The final render is not an essential part of the app since it's just for
quality output; hence your above example is right on the mark. In fact
the ability for an app to stand by itself and not actually need POV-Ray
is one of the mandatory requirements that we currently have before we
will even consider allowing a bundling license.

In the future I expect that this sort of use will become even more
prevalent; raytracing is as a rule too slow for interactive use in CAD so
it would be quite standard for the photorealistic component to be more
or less an add-on.

> Whether dynamic linking creates a derivative work is irrelevant, if the
> work is never redistributed.  The GPL explicitly states that the use of
> the software is not governed by the license, so end-users are free to
> mix GPL'ed and other software for their own private use regardless.

Given that we cannot definitively control third-party use of our code
because of the ease of using a shared library, it appears that the only
way of preventing (or at least making it harder for) unethical vendors
from bypassing the spirit and intent of whatever license we choose is to
have some sort of words in the license over how and when the licensed
software can be installed or used.

If for example we take the clause in the LGPL that relates to linking,
and instead of (or as well as) attempting to make the vendors of the
application doing the linking responsible by defining the whole as a
derivative work, we also add that the user[1] is responsible for ensuring
that any third-party code that makes use of the licensed code (no matter
how it does this) also complies with the license terms.

Of course this places an onus on the user that current OSI licenses
don't. However if we add a clause that automatically exempts the user
from the abovementioned clause where the calling application is itself
released under an OSI-compatible license, then for the large majority of
users it becomes a non-issue. The only time they have to care about it is
if they install a non-free application that dynamically calls the
licensed code.

Can anyone comment on whether such an approach would be OSI compatible?

-- Chris

[1] the rationale here is not primarily to use this as a lever against
users, who may have no idea that software they have just installed might
violate the license they are using the shared library under; from my
point of view it seems that if a vendor deliberately took steps that
they know will cause the user of their software to be unknowingly in
violation of a license, then they could hopefully be held responsible
for doing so. That ought to be a reasonably strong deterrent (though I
would be interested in hearing opinions as to whether a vendor could
effectively EULA such responsibility away).