World: r4wp

your program typically does not call the r3lib.dll library, the r3.exe 
does

This doesn't matter for the GPL, because it's viral. If your program 
calls a BSD function that calls a GPL function, you still need to 
provide your source code under a GPL compatible licence

the DO is not implemented in REBOL at all, is it a functionality 
implemented in C

The implementation language doesn't matter for licensing, either

the DO variable is just a variable the interpreter 

knows", certainly not some code your REBOL program is "linked to". 
- and, moreover, the 'DO variable is always resolved at run time, 
no matter how you write your REBOL program"

For REBOL, it would be reasonable to view binding as linking. When 
you load a binary C library (such as r3.so) the linking is also done 
at runtime

I hope I was clear enough. However, I may try to make my thoughts 
more precise. The script:

DO %my-script.r


is not "linked" with the definition of DO in any way at all. Only 
the interpreter "knows" the 'DO variable and does something meaningful 
with the code.

There's no debate about that. Brian and Andreas have already analysed 
that the few interpreter dialects in REBOL are not the problem. All 
other functions are the problem

Actually not. Brian explicitly stated:


This means that the code that you pass to these functions can be 
closed-source, but the code that *calls* these functions needs to 
be GPL-compatible.

As you may have noticed, my POV is different.

I noticed

What Brian said there is exactly what I said

Maybe you interpret "these functions" as DO, etc. What is meant are 
all the other functions, which don't execute code, but are called 
by code

I can say the same about:

   f: func [a b] [a + b]


The interpreter "knows" the 'FUNC variable and I do not mind "how", 
since it is its "job" to understand that. I just created the data 
for it.

As Andreas noted, the FSF interprets this case as a library function

It is at least questionable in case of r3.exe and r3lib.dll

It is questionable

 - I actually don't think it is questionable. I think it is wrong.

Yes, it's easy to misinterpret the licenses, and the deepest interpretations 
have to be made in court. So that's the situation REBOL is currently 
headed for

FSF interprets a different case and that case does not resemble the 
r3.exe + r3lib.dll case at all.

Right, because it's not about r3.exe and r3.dll

Yes, that is why I do not think it is relevant to point to some unrelated 
case making some invalid point.

That's what you're doing

Re: 'Maybe you interpret "these functions" as DO, etc' - I have to 
because the citation actually is:


Though DO, PARSE, DELECT and DO-COMMANDS are interpreters, they are 
implemented as library functions. This means that the code that you 
pass to these functions can be closed-source, but the code that *calls* 
these functions needs to be GPL-compatible

Ah, yes, he meant that r3.exe needs to be GPL compatible because 
it kicks off the interpreter. That's no further problem, because 
it is already scheduled to become GPL. It is an issue when you want 
to write your own hosts

It's also a problem if you want to use DO anywhere else in your code

It's also a problem if you want to use DO anywhere else in your code!

 - as I noted I think that I can use DO as many times as I wish in 
 my code since my code is only data for the r3.exe+r3lib.dll interpreter

Agree to disagree, then. If you want to go to court to argue your 
point of view, please do, but I would like not to

I hope now it is clear where my point differs

...and I am quite comfortable with it, since the freedom to use the 
GPL'd code to any data of my choice is one of the freedoms given 
to me by the GPL.

Also, I do not need to go to court when I can read and comprehend.

to me the issue is not as much about if I Can USE R3 as much as if 
I can safely play with it.  using any GPL based license, looking 
at R3 sources becomes a big problem.  


in fact, just looking at its mezz code becomes an issue.  I can't 
see how R3 will fit my development needs.

There is no single truth here. There are a few realistically defensible 
positions, all of which have been argued extensively before.


The legal opinion of the FSF (publisher of the GPL) is pretty clear, 
by analogy to Perl or Java: all/most REBOL mezzanines are library 
functions to which a user script dynamically links. If the mezzanines 
are GPL licensed, the source to user scripts will have to be provided 
in a GPL compatible way.


Equally clear is e.g. Lawrence Rosen (IP lawyer) in articulating 
his legal opinion. Paraphrased: "linking is irrelevant for deciding 
wether the result is a derivative work" -- this mostly matches Ladislav's 
stance.


The whole point of this debate is not really ultimately deciding 
the resolution for that issue as pertaining to a GPL'd REBOL, but 
pointing out that, without additional clarification, the GPL results 
in a problematic legal uncertainty. This legal uncertainty may lead 
to quite the opposite effect of what many believe Carl actually intends.


So one very easy solution, is to include a few definitive clarifications 
along with the GPL.


Another, probably much easier, solution would be to simply sidestep 
this issue and use a different license.

I fear Kaj is right and there is no reason to trust that the reasonable 
standpoints of Ladislav will be accepted in a court of law. Not only 
a costly but also a timeconsuming and mentally draining event. Pass.

Orca is a good example of what can realistically happen to R3.  


very few of us have actively looked into it, even those who do support 
open source and GPL licensing.   when there is a  less virulent license 
around, people would rather use that.  through the years, some (many) 
people have claimed that they refuse to use orca because of its license.

It's much worse. ORCA had the choice of LGPL and GPL, Boron is just 
LGPL

Max - imo Orca is a different sitaution here. It appeared when REBOL 
was still officially developed and supported, many of us believed 
into R3 becoming new star, so all the steam was stealed away from 
such clone projects imo.

Similar situation: Potential contributors were unwilling to look 
at the source because of potential contamination that would prevent 
them from participating in competing projects, or using it for commercial 
code. For Orca/Boron, the main competitor was commercially licensed; 
for GPL R3, the main competitors are MIT licensed, but it's a comparable 
situation.

I am not skilled at licencing stuff, but isn't it a bit exagerrated, 
that just looking into sources or even studying them just to understand 
the architecture, might possess a legal problem, if you use different 
architecture in the final product, along with your own code implementation, 
which can't be regarded a direct 1:1 rewrite?

they are still potential derivatives which is where the issues *may* 
occur.   

especially when you are looking at source for learning or curiosity 
purposes.

If you don't look at the source, but just examine the behavior from 
the outside, that is called clean-room reverse engineering. You can't 
be blocked on copyright violation grounds, just patent and trademark 
stuff. Even the function specs could be considered to be not copyrightable, 
according to Google vs. Oracle, though that case's appeals haven't 
made it to the supreme court yet. The doc strings are another issue 
though since they aren't technically necessary for interoperability. 
Copyright laws (at least in the US) don't make a distinction between 
code and data when it comes to derived works.

until something is tested in court (in your country) its dangerous 
to assume.    Goggle's recent java API court issues shows how you 
can get in trouble over things which even seem pretty clear.

GPL's licensing is much more murky when it relates to languages and 
interpreters.  in court it could be a much bloodier battle than it 
was for Google vs Oracle.

Here's the FSF FAQ entry that covers encapping: http://www.gnu.org/licenses/gpl-faq.html#MereAggregation

The relevant part is this: "If the modules are included in the same 
executable file, they are definitely combined in one program. If 
modules are designed to run linked together in a shared address space, 
that almost surely means combining them into one program."

Here is the FSF FAQ entry relating to interpreters and their libraries: 
http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL

Pretty much the whole entry is applicable. The first paragraph would 
apply to data passed to DO, PARSE, DELECT, DO-COMMANDS, or other 
dialect processors.


The second paragraph would definitely apply to extensions, and could 
apply to built-in functions unless we get an exception like GCC's; 
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. Note that PARSE's built-in operations are 
more unambiguously "part of the interpreter", and the same could 
be said for other similar dialects.


The last two paragraphs apply to mezzanine code and embedded modules. 
If they are GPL'd and your code uses them, it would be affected.

It is common to use this FAQ entry as a way to make GPL extensions 
that wrap proprietary components: http://www.gnu.org/licenses/gpl-faq.html#WindowsRuntimeAndGPL


Developers commonly put links on their web site to the vendor's web 
site to download the DLL. However, it's iffy with GPL2 because the 
actual exception is worded like this:

However, as a special exception, the source code distributed need 
not include anything that is normally distributed (in either source 
or binary form) with the major components (compiler, kernel, and 
so on) of the operating system on which the executable runs, unless 
that component itself accompanies the executable.


Read literally, it would exclude runtime libraries that aren't bundled 
with the OS. It's more unambiguously OK with GPL3.

The same would apply to hosts that are meant to be plugins for closed-source 
software.

I read through the page and it seems pretty clear that encapping 
would be impossible if any part of R3 is GPL .

You might manage a Click-to-Run like setup if R3 is GPL2, since that 
loophole wasn't closed until GPL3.

Still, having R3 being GPL means a return to the R2-style SDK licensing, 
as long as RT requires copyright assignment. They could sell a commercial 
license allowing closed-source encapping and host creation. I don't 
know if the revenue generated could offset the inhibited adoption 
that would result from using a copy-left license in the first place 
though.

If the aim is to promote the development and prolongation of R3, 
then GPL doesn't appear to be the way to achieving that aim.  If 
the underlying primary aim is to monetize what's left, then it might 
be the way to go.

Doc +1. Andreas +1.