World: r4wp

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

definitely not.

if you have to think this much when deciding to use a tool or not, 
I would guess many (most?) would probably pass. Too many nuances 
and interpretations...

I haven't followed the conversation either. For me it's still the 
basic issue that one license is (way) more complex than the other. 
Therefore I would work with the tool that has the least complicated 
license.

and I base that on what Carl said in the past.

'or we could get a FAQ entry declaring that the functions built into 
R3 are "part of the interpreter" rather than "library code"' - that 
is where I do agree with you, except for the fact that we do have 
such an indication:


1) the functions *are physically/* part of the interpreter, they 
are "linked into it" (I would say "statically", since the interpreter 
does not need to look for them "elsewhere in the system", they are 
"inside")

2) the functions are a part of the interpreter, the interpreter documentation 
specifically mentions the functionality of the interpreter (the documentation 
mentions that the "ordinary version" of the interpreter "understands" 
FUNC, DO, PARSE, whatnot...)

Bad comparison. Functions linked into GCC are not used by user programs.
 - that is false, in fact. For example:

double j = 1.0 + 1.0;


is being done by the compiler, because the compiler is able to do 
it, not needing to link in any function to do this at runtime.

Also, the compiler does everything indicated in the program it can 
do at the compile time.

(at least some optimizing compilers do that, if they are able to 
detect what can be done at the compile time)

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

 - you can do whatever you want, I think I explained what I can do

There is actually one more reason why we should not worry about the 
mezzanines. The mezzanines were published under some license some 
time ago, and that license permitted to use them in non-GPL'd programs 
already. Having that right already coming from the current lic, we 
are safe anyway.

Moreover, Carl could explicitly allow encapping when the restrictions 
he already stated somewhere are fulfilled. Essentially, the restrictions 
are that the encapped program shall not be a derived version of the 
interpreter.

(i.e. a program that interprets REBOL code entered by the user, etc.)

The `double j = 1.0. + 1.0` example is another bad one, sorry. It 
won't result in GCC runtime code being statically linked into the 
binary generated from a user program. But I will let that discussion 
rest, as it won't lead us anywhere.

Again, how a GPL library is linked to _the interpreter_ is irrelevant 
for deciding wether it encumbers a _user program_. If your _user 
program_ dynamically links to that library, the user program is affected 
by the GPL. It is irrelevant wether that library was statically or 
dynamically linked to the _interpreter_.