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

[Chuck Swiger]

On Nov 22, 2005, at 11:39 AM, Chris Cason wrote:
> Chuck Swiger wrote:
>> 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.

It appears your proposed license would violate OSD #9:
"9. License Must Not Restrict Other Software

The license must not place restrictions on other software that is  
distributed along with the licensed software.  For example, the  
license must not insist that all other programs distributed on the  
same medium must be open-source software.

Rationale: Distributors of open-source software have the right to  
make their own choices about their own software.

Yes, the GPL is conformant with this requirement. Software linked  
with GPLed libraries only inherits the GPL if it forms a single work,  
not any software with which they are merely distributed."

>> 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.

Unethical vendors who disregard the license are not going to be  
affected by writing a more complex license.

> 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.

Some licenses have attempted to define what constitutes a derivative  
work in the fashion similar to what you've described, but it doesn't  
seem to be a useful exercise.  The terms of a license only apply to  
the licensed materials, not to third-party code.

If you simply invoke povray as a separate process via fork(), system 
(), etc, the third-party code is not a derivative work (it doesn't  
include or link to the povray software) and thus would not be subject  
to the terms of your license.

> 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?

See above-- probably it would not be.  You could read:

http://www.opensource.org/docs/definition.php

...but you should choose a license which meets your needs and suits  
your users, whether or not that is OSD-compliant.

-- 
-Chuck