World: r4wp

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

The argument that we (paraphrasing) "have the source to the mezzanines" 
already is of course a very practical one. However, it only works 
as long as those mezzanines don't experience GPL-only changes.

(Sorry for picking up the GCC remark at all. I really want to let 
that rest, and I fully acknowledge your (Ladislav's) former description 
(the one I originally contested with "bad comparison").)

In the official statements that refer to the versions of R3 that 
have the current system model (approx. the last dozen versions), 
the functions included with R3 are referred to as the "Runtime Library". 
The other online docs haven't been updated to reflect the current 
system model, and most of them haven't even been updated for R3 yet, 
still referring to their R2 behavior. There are indications either 
way, enough to drive a trial through. We need an unambiguous published 
statement to be sure we won't be sued for using R3, or that at least 
such suits will fail.

Andreas, there is apparently a difference between code/data that 
is considered to be part of the interpreter and code/data that is 
considered to be part of the runtime library, according to this FAQ: 
http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL

Ladislav is stating that being statically linked makes it part of 
the interpreter, though there are counter-examples of statically 
linked runtime libraries in other programming languages that legally 
infect the code they run. It is considered bad form though, so you 
don't see it often. It's an ambiguous situation, so a statement resolving 
the ambiguity would be helpful here.

Based on this same entry, I still don't think that how the library 
is linked makes any difference, as long as the library is itself 
interpreted.

Agreed, though it doesn't matter whether the library is interpreted 
either. You can statically link a native library to the interpreter 
for use by interpreted or native code, and it can legally affect 
the code that is using it. The only way around it is to declare that 
code to be part of the interpreter rather than part of the runtime 
library, which can only be done with permission of the rights-holder 
of that code.

Yes, the "interpreted" part does not really matter in general, but 
that's what is specifically applicable to R3 mezzanines.

GPL + classpath exception would also be fine, to overcome that problem.

Using R3 natives can have that effect as well if they're not declared 
to be part of the interpreter.

Yes, IMO as well. But that's an issue I don't really want to discuss 
because it is less obvious/more complicated. The mezzanine problem 
is already as bad as it gets. If we can't satisfyingly overcome that, 
we don't even need to discuss other GPL-induced problems.

Given that this is not how REBOL actually works, declaring it to 
be a monolithic interpreter would be more of a legal declaration 
to not sue. Such a declaration would also affect REBOL script code 
that dynamically loads extensions, not just REBOL code.

Only statically embedded extensions would be affected by the GPL 
then.

but we can't even derive from any mezz without jeopardizing our code, 
no?

Yes, we can't even _use_ any mezz without the GPL affecting our code.

You can of course choose to interpret the GPL differently. But I 
wouldn't bet my business on that.

Same with statically embedded modules, like the mezzanine code. The 
mezzanine source could be licensed as MIT, but by being linked into 
r3.exe it would be constrained by the GPL, essentially becoming MIT/GPL 
dual licensed, and would need to be declared to be part of the interpreter 
in order for your code to use them at runtime. However, if the mezzanine 
source was licensed as MIT, you would be able to derive code from 
them without being affected by the GPL, even if the way that you 
read that source was to use the SOURCE function at runtime.

Open sourcing REBOL mentioned on OSNews.com, no comments yet ...

So programming language announcements (not related to an OS project) 
are not off-topic on OSNews? Good to know for Red v1.0. ;-)

They have strange policy on that. Back at the time, Thom refused 
to inform RT starts R3 project. I found it interesting news, he declined. 
But - OSnews degraded badly in last xy years, many "political" topics, 
no real industry news. Engadget completly rules the game ...

Right, it has changed quite a lot since it has become Thom's personal 
blog...

Andreas, there is apparently a difference between code/data that 
is considered to be part of the interpreter and...

 - yes, hat is exactly what I tried to underline, and I especially 
 wanted to cite these:


If a programming language interpreter is released under the GPL, 
does that mean programs written to be interpreted by it must be under 
GPL-compatible licenses?
When the interpreter just interprets a language, 
the answer is no. The interpreted program, to the interpreter, is 
just data; a free software license like the GPL, based on copyright 
law, cannot limit what data you use the interpreter on.

...However, 
when the interpreter is extended to provide “bindings” to other facilities...


- I have to emphasize *when the interpreter is extended* and *other 
facilities* - i.e. other code not considered to be a part of the 
interpreter. Also, code present in the interpreter does not qualify 
as *interpreter extension* providing bindings to *other facilities*

 there are counter-examples of statically linked runtime libraries 
 in other programming languages that legally infect the code they 
 run.
 - I suppose that is not an interpreter case, though?

I created a "Licensing" group to move the licensing-related discussions 
to, so as to free up Ann-Reply again to discuss other more recent 
announcements.

I do not see the group

aha, OK

Kaj: great job!