World: r4wp

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

the mezz code is a statically linked module.  it is linked by adding 
it or not within the host-kit boot up procedure.

you can remove that code completely from the host, you can even argue 
that the natives which are within the currently hidden core are also 
statically linked within the core.

rebol itself, without all of those "helper" funcs is pretty pare... 
 make do  and that is pretty much all you need to "evaluate" rebol. 
 all the hard work is done within the datatypes themselves.

pare == bare

Andreas, functions linked into GCC are used by user functions. Ladislav, 
GCC has an explicit exception to the GPL that allows this.

(My remark was going into a different direction, but I have withdrawn 
it as I don't think this would help the discussion.)

Ladislav, most of what Andreas and Maxim are saying here is true, 
but it doesn't matter. Reading comprehension requires reading the 
whole thing. The relevant part you missed is:

    or we could get a FAQ entry declaring that the functions built into 
    R3 are "part of the interpreter" rather than "library code", despite 
    R3's actual system model.


I am actually an expert on R3's system model as it relates to dynamic 
linking of code, and how code is bundled, since I wrote most of the 
code that does that. The mezzanine code is dynamically loaded and 
linked in the startup code, and is statically linked as data into 
r3.exe, so as far as copyright is concerned it is linked two ways. 
At least in the laws of the country of origin of REBOL, the code 
vs. data distinction is irrelevant to whether the code/data is covered 
by copyright, or the GPL, which only relaxes copyright. All that 
matters is that the mezzanine data is statically linked into the 
program. For that matter, it's not even bundled as a resource, so 
it's really hard to make the "mere aggregation" argument even if 
they weren't explicitly in the same program. Embedded extensions 
and embedded REBOL code are both statically linked into the program, 
and are both dynamically linked at runtime.


Nonetheless, that system model doesn't have to matter. A published, 
official FAQ entry (or even a blog post) can be used as evidence 
in a trial, so a FAQ entry that clearly states that all bundled native 
and mezzanine code is "part of the interpreter" would be sufficient 
to make it so our scripts whouldn't be affected by R3's GPL at runtime. 
Without such a FAQ entry it could be plausibly argued in court that 
your code is dynamically linked to GPL'd code, which would then extend 
GPL requirements to your code. With the FAQ entry, it's unambiguous.

I would prefer a licensing model that has that FAQ above, saying 
that the built-in functions are "part of the interpreter", but to 
also have all R3 mezzanine code covered by the MIT license rather 
than the GPL. GPL'd code, even if you're allowed to link to it, is 
still unsafe to read for a lot of people, since it can be (and has 
successfully been) argued in court that similar code that you write 
later can be considered a derived work. One of the best ways to learn 
REBOL is the SOURCE and HELP functions, so MIT source and help strings 
would make SOURCE at least safe to use. SOURCE doesn't show native 
source, so that's fine (though with the source on Github you might 
be able to make a native source function using BROWSE).

honestly I'm just confused.. but maybe it's because I do not follow 
complete conversation.. but I'm sure I will not be alone

you are not alone