World: r4wp

Thanks for continuing to improve INCLUDE Ladislav. I will have to 
check out the new version soon.

The first paragraph would apply to data passed to DO, PARSE, DELECT, 
DO-COMMANDS, or other dialect processors.

 - actually, there is absolutely no need to not apply it also to the 
 r3.exe+r3lib.dll

Also, the sentence:


However, when the interpreter is extended to provide “bindings” to 
other facilities (often, but not necessarily, libraries), the interpreted 
program is effectively linked to the facilities it uses through these 
bindings.

 applies to any "extension library" written in REBOL under GPL. It 
 does not apply to the "barebone interpreter" at all.

For example: is DO an extension of the interpreter? Certainly not, 
DO is a basic functionality described in the documentation to the 
interpreter.

Also, the example used shows a completely different situation.

For example: "The JNI or Java Native Interface is an example of such 
a binding mechanism; libraries that are accessed in this way are 
linked dynamically with the Java programs that call them. These libraries 
are also linked with the interpreter. If the interpreter is linked 
statically with these libraries, or if it is designed to link dynamically 
with these specific libraries, then it too needs to be released in 
a GPL-compatible way." - this refers to the following situation when 
transposed to the REBOL case:


R3 can be dynamically linked with REBOL extensions. If the extensions 
are GPL'd, then r3.exe has to be GPL'd as well.

The other case: "Another similar and very common case is to provide 
libraries with the interpreter which are themselves interpreted. 
For instance, Perl comes with many Perl modules" - this, transposed 
to the REBOL case would refer to REBOL modules coming with the interpreter. 
Are there some modules coming with r3.exe and r3lib.dll?

...could apply to built-in functions unless we get an exception like 
GCC's;

 - again, wrong. The built-in functions are related to the functionality 
 of the program, which is unrestricted. The problem with GCC (why 
 there is the need for the exception) is that the functions needing 
 the exception are the ones provided and statically linked in the 
 extra libraries.

Another similar and very common case is to provide libraries with 
the interpreter which are themselves interpreted.

This applies to all mezzanines shipped with R3.

Actually not. The mezzanines are not libraries because they are built 
into the program.

The lib context is a runtime library bundled with the interpreter.

So, readers may see different opinions. From "there are libraries 
different than r3lib.dll in the r3.exe+r3lib.dll interpreter" to 
even more extreme: every one of DO, PARSE, etc. is a separate program 
(obviously false) to which the GPL has to be applied on a separate 
basis".

Yes.

Again, the FSF's "library" interpretation is much more relaxed than 
yours, and does not only encompass OS libraries.

I know, in the REBOL case it comprises modules, so once there will 
be some modules shipped with the r3.exe, they will fall under this 
category. However, since such modules are not shipped at present 
this is only applicable in the future.

It goes much further than modules.

It comprises any collection of functions.

So if I follow the FSF's interpretation, I definitely see the collection 
of mezzanines as a library. How they are actually bundled/distributed 
(as multiple .r's, as one .r, bundled into r3lib.dll, bundled into 
r3.exe, something else) is irrelevant.

Right, also the collections of extensions, etc. Still not present

No, also the collections of mezzanines.

So if I follow the FSF's interpretation, I definitely see the collection 
of mezzanines as a library.

 - that is not correct, because there is no library, just the r3.exe 
 interpreter, which has got its basic functionality implemented in 
 some way. Using the FUNC word in my program I am just using the functionality 
 built into the r3.exe+r3lib.exe program. No linking.

No OS linking.

No linking at all.

The FSF sees it as dynamic linking.

No, since the dynamic linking would require (according to FSF's own 
words) a separate extension to the interpreter.

Huh?

FUNC is part of a library of mezzanines provided with the R3 interpreter 
which are themselves interpreted.

These libraries and the programs that call them are always dynamically 
linked together.

CItation: 'when the interpreter is extended to provide “bindings” 
to other facilities (often, but not necessarily, libraries), the 
interpreted program is effectively linked to the facilities it uses 
through these bindings' - so, clearly, the interpreter needs to be 
*extended* by some *other* facilities

That does not apply to this case. That's for the interpreter providing 
bindings to third party libs, such as OpenSSL.

Unrelated to the "libraries coming with the interpreter which are 
themselves interpreted" case.

Also a wrong interpretation. There are no "libraries coming with 
the interpreter" and your interpretation is overly extensive, like 
the interpretation that DO, PARSE, etc. are "separate programs".

I don't follow the DO, PARSE, etc interpretation.

But I am convinced that the collection of mezzanines forms a library 
coming with the interpreter.

No, it would, if you e.g. put in a separate library as a module which 
could be linked or not. In this case there is just one-piece program 
(speaking about r2.exe) or two-piece program (r3+r3lib)

How the library is bundled is irrelevant.

You can choose to use it or not (via boot levels).

It is clearly not in this case, because "the library" has been already 
linked with the interpreter once the r2.exe has been created.

Yes, but it has not been linked with your user script.

Which, through mezzanine usage, still dynamically links to the library.

Not at all. The library has been statically (it is already in) linked 
with the interpreter in this case.

And it is not distributed at all. Just the interpreter is.

Your user script still links dynamically to the library.

No, the library is not distributed.

That does not matter.

As I said, different levels of overly extensive interpretations.

For example, in the GCC case, some library functions are statically 
linked with the gcc executable, however, they are also (at the same 
time) present in the libraries shipped with the gcc compiler and 
statically linked with user programs. The exception is needed only 
for the second use, not for the first one.

Bad comparison. Functions linked into GCC are not used by user programs.

If you choose to use GPL'd mezzanines in your program, you must release 
your program in a GPL-compatible way.

(Strike that bad comparison.)