World: r4wp

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.

Thanks for continuing to improve INCLUDE Ladislav. I will have to 
check out the new version soon.

The first paragraph would apply to data passed to DO, PARSE, DELECT, 
DO-COMMANDS, or other dialect processors.

 - actually, there is absolutely no need to not apply it also to the 
 r3.exe+r3lib.dll

Also, the sentence:


However, 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.

 applies to any "extension library" written in REBOL under GPL. It 
 does not apply to the "barebone interpreter" at all.

For example: is DO an extension of the interpreter? Certainly not, 
DO is a basic functionality described in the documentation to the 
interpreter.

Also, the example used shows a completely different situation.

For example: "The JNI or Java Native Interface is an example of such 
a binding mechanism; libraries that are accessed in this way are 
linked dynamically with the Java programs that call them. These libraries 
are also linked with the interpreter. If the interpreter is linked 
statically with these libraries, or if it is designed to link dynamically 
with these specific libraries, then it too needs to be released in 
a GPL-compatible way." - this refers to the following situation when 
transposed to the REBOL case:


R3 can be dynamically linked with REBOL extensions. If the extensions 
are GPL'd, then r3.exe has to be GPL'd as well.

The other case: "Another similar and very common case is to provide 
libraries with the interpreter which are themselves interpreted. 
For instance, Perl comes with many Perl modules" - this, transposed 
to the REBOL case would refer to REBOL modules coming with the interpreter. 
Are there some modules coming with r3.exe and r3lib.dll?

...could apply to built-in functions unless we get an exception like 
GCC's;

 - again, wrong. The built-in functions are related to the functionality 
 of the program, which is unrestricted. The problem with GCC (why 
 there is the need for the exception) is that the functions needing 
 the exception are the ones provided and statically linked in the 
 extra libraries.

Another similar and very common case is to provide libraries with 
the interpreter which are themselves interpreted.

This applies to all mezzanines shipped with R3.

Actually not. The mezzanines are not libraries because they are built 
into the program.

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.