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

[Rodrigo Barbosa]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Nov 14, 2005 at 05:39:17PM +1100, Chris Cason wrote:
> Rodrigo Barbosa wrote:
> > You see, for you to dynamicaly link some code, you need to make
> > references to it on your own code, so the linker can know how to
> > hook to the functions inside the dynamic library.
> 
> [snip example]
> 
> Well, yes and no. I agree I have to make references to it; however there
> is no technical requirement to include header files or even tell the host
> OS loader what my program requires. I'll give you a real example based on
> the Win32 version of POV-Ray.

(...)

> The way around this is to declare the prototype in my own code, and use
> the GetProcAddress API to attempt to resolve the function, either by name
> or ordinal (in the latter case I don't even need to embed the name of the
> function in my code). If it fails then can I can work around not having
> the function, rather than just have the entire app fail to load. I am
> sure that Linux and other OS's have analogous facilities.

Yes, I can understand that. We usually call that an abstraction layer.
Under that concept, you have no control over which DLL (.so etc) will
be loaded. So, in that case, I don't think it would constitute a
derivative work.

One would say that yes, it is a derivative work, as long as you are
directly linking/accessing a given component (DLL, .so, whatever).

This you are describing is very close (although not the same) what
we encounter when using ODBC and JDBC objects.

> * of course the term 'linking' is not necessarily important; as Martin
>   pointed out I should really be determining whether such creates a
>   derivative work. it appears to me that unless and until the simple act
>   of having a third-party module visible in your address space and
>   performing a CPU-level 'call' to an address located within it gets
>   defined as 'creating a derivative work', then it will always be
>   possible to make use of previously-installed third-party code without
>   license restrictions, unless said code imposes its own internal
>   licensing regime (e.g. requiring an access token).

I have seem some discussions about the legality of these issues, mostly
when I was trying to work with dietlibc.

We can go even further into this issue. In Linux, we can force a
dynamicaly linked executable to load ANY given library:

# LD_PRELOAD=/usr/lib/libEvil.so myExec

In that case, it doesn't matter is my code is using the functions inside
libEvil. The lib will be loaded and will be present on the address space
of my application, and I have no control over it from the developer side.

Taking that into consideration, one might assume that it will constitute
a derivative work as long as the source code makes use of the library,
since the developer of the code can have no control over the executing
enviromment, or even any expectation(?) over it.

By having an expectation I mean: when you create a code using zlib.h and
linking against libz.so, one can still make the code load another
library instead of libz.so (either by replacing it or my messing around
with the ld.so configuration/code/options). But in that case, you have
the expectation (plan, desire etc) that libz.so will be used.

To be on the safe side, I would include on the program documentation
a listing of the expected libraries, just to make sure everyone understands
which licenses my program would have to cope with.

- -- 
Rodrigo Barbosa <rodrigob at suespammers.org>
"Quid quid Latine dictum sit, altum viditur"
"Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDeKw6pdyWzQ5b5ckRAijcAKCJ7Frv6K9ODWHpilydc9bP3s5MGACgwFvT
M2RJ8UZW5y/Y3vqFP0v7Mdo=
=PyOM
-----END PGP SIGNATURE-----