World: r4wp

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!

I'll work on shared libs support for other platfoms very soon.

Good job, guys, especially as R3 being open sourced becomes de-facto 
competition to Red. Nice you are supporting it though ...

Congrats Kaj, the example looks very nice:


http://red.esperconsultancy.nl/Red-REBOL-3/artifact/06f9d09a50394ed9f957f568e29bae8e651e9202

Thanks

Cool work Kaj!

So, would this mean that you maintain eg. the one curl binding for 
red/system and then also use the same for R3 ?

I don't understand the example. My imagination was, that I will have 
some make-native function or make-extension in R3, and somehow very 
easily I just plug in the red/system code, without the need of knowledge 
to cumbersome and cryptic R3 extension interfacing at all - I don't 
want to know anything about RX_Init etc functions ...

... kind like R2 DLL interface in R3 level ....

Yes, I want to rebase my cURL and 0MQ extensions on the Red bindings

On top of the Red bindings, you'll have to do marshalling to the 
R3 extension interface and data types. There's no way around that

A make-extension function to wrap the compilation of the extension 
would require the Red compiler to be ported to R3. In the end, this 
won't work anyway, because it's going to be ported to Red itself

The R2 DLL interface is rather specific functionality: it implements 
dynamic loading and binding of libraries. This could be implemented 
as a specific R3 extension, written in Red

Currently it only works on Windows, and you need the dyn-lib-emitter 
branch of Red/System
 I did n't know you have a Windows machine ;)