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

[Chris Cason]

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 Win32 API has some useful functions in it that aren't available on
Win95, but were present on Win98 and later. However since we wanted to
maintain compatibility with Win95, I can't directly refer to these
because then the exe will fail to load on '95. Additionally I don't
necessarily get access to the prototypes either (this depends on what I
have set the macro WINVER to when the Win32 headers are included).

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.

The point I am making here is that if someone makes sufficient effort, it
is almost always possible to get access to exported entry points without
either having to include someone else's copyrighted header file, or using
the 'traditional' method of linking (either static or dynamic)*.

Of course using LoadLibrary/GetProcAddress on Win32 could still be called
'linking', though I would be interested in knowing at what point the act
of loading a module into your address space and obtaining an address you
can call stops being 'linking' and becomes something else.

For example do I 'link' with a Microsoft COM object when I load it via
the COM API? Microsoft don't use that term, and the techniques for
getting the entry points for the various methods are different from the
above, but the net outcome is the same - I can end up invoking (directly
or indirectly) code in the loaded module.

What if the process loads my EXE directly into its own address space and
calls code inside it by using some known hard-coded offsets based on the
EXE version ? Is *that* linking ? (Extreme example perhaps, but perfectly
feasible).

To me the entire issue of licenses and run-time linking seems to get more
and more murky every time I think of it. It's probably the sort of thing
that can't be depended on to give a definitive outcome with respect to
the things I want to achieve WRT licensing.

regards,

-- Chris

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