World: r4wp

There are also differences between GPL1,2 and 3 - http://en.wikipedia.org/wiki/GNU_General_Public_License

The problem with REBOL is not with the "interpreter" (neither is 
it with Java), but with the libraries.

GPL says:  Ambiguity arises with regards to using GPL libraries, 
and bundling GPL software into a larger package (perhaps mixed into 
a binary via static linking). This is ultimately a question not of 
the GPL per se.

Andreas of wich libraries you are talking?

Andreas - even if you link libraries dynamically? Well, maybe so, 
because that's why LGPL exists? You can use the code in the form 
of dynamically loadable library, but not statically?

Rebol is released as a single executable, so I don't see any problem

The FSF claims that even if you link dynamically to a GPL'd library, 
the result is a derivative work and therefore needs to be GPL'd.

Isn't LGPL meant to be used for libraries (in general, not with R3)?

MaxV: I'm talking of all the REBOL functions you are using in your 
own code.

Janko - yes ... which means, MaxV is not right ...

simply put - you can't use libraries with GPLed code, statically, 
nor dynamically, unless you open up all your app ...

For more of the FSF's interpretation, also have a look at:

https://gnu.org/licenses/old-licenses/gpl-2.0-faq#IfInterpreterIsGPL


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, and a Java implementation comes with 
many Java classes. These libraries and the programs that call them 
are always dynamically linked together.

btw - no word about the R2. Many guys would be probably interested 
here too, as there's many R2 apps in the usage out there ...

With intepreted language there are no such problems. Look at a more 
complicated case: Abbyy Fine Reader. It costs € 129, it's an OCR 
based partially on GPL code. When you install it, a pop up appear 
that advice you the a part of it is under GPL. It's clear what is 
open and what is not.

OK, I will let it to experts. You can find some BrianH comments in 
the prior blog article, where Carl asked for the opinion. Please 
read it as well. But imo really - why to complicate the situation? 
Why not MIT or BSD? Is Carl fearing some big company will behave 
badly, build commercial stuff upon REBOL, and make some money, without 
donating changes back?

MaxV, did you actually read the FSF statement above?

Per the FSF, a program needs to be GPL'd if it calls interpreted 
libraries that come with GPL'd the interpreter. That'd be precisely 
the situation for GPL'd R3 mezzanine code.

Let's try again: "Per the FSF, a program needs to be GPL'd if it 
calls interpreted libraries that come with GPL'd interpreter."

You don't call intepreted libraries, you use an intepreter. It's 
different.

Looks like we will soon all become GPL terms experts. :-)

Ah ah ah

I wonder if the GPL won't clash with the BSD mezz code Brian wrote 
for R3?
 It won't

I've already had to become a GPL expert in a decade of Syllable, 
and I can confirm Andreas' explanations

In Syllable, we're firm that libraries should be no more than LGPL, 
and only apps can be GPL

Ok, now the other big problem is: all the scripts in internet are 
in rebol2. Is there a retrocompatibilty mode?

For R2, not for R3

Well, I suppose that the first thing is to create something to elaborate 
R2 script.

For example if a script ends with .r, il launches rebol2, if it ends 
wth .r3, it launches rebol3 intepreter.

that's what I do from the beginning

I forget, is an R3 a superset of R2? Or are there R2 values that 
won't load in R3? (not including #[...] literals)

PARSE level should be compatible, except for bug fixes

So there's not likely many cases where R3 would not load a .r script?

Very few if any "regular" cases, yes.

MaxV: whenever you use FUNC in your scripts, you call an interpreted 
library function.

My contributions are still MIT-licensed. However, I haven't separated 
my R3 contributions into a separate package that can be reused easily 
without looking at the R3 source. Still to do.

MaxV, REBOL isn't really an interpreter. DO is an interpreter, as 
is PARSE. The rest are library functions. If your code calls any 
of these functions, you need to provide the source to your code, 
even if it's encapped.

The blog post states October 1st, but there is no year mentioned...

Chris -- a couple of articles about experience in retrofitting R2 
scripts to run as R3:
   http://www.rebol.org/art-display-index.r?a=R3

Oh, weirdly enough, DELECT and DO-COMMANDS are also interpreters. 
There is an additional gotcha though.


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. If you make a REBOL-in-REBOL 
interpreter or compiler that treats the code it runs as data, and 
the code it runs doesn't call any REBOL functions at all, even indirectly, 
then the code it runs can be closed source. This is basically what 
Red is, so Red would be legal.

Chris, the first article is a little outdated, but it's not far off. 
The articles don't reflect how many of the R3 functions have been 
ported back to R2, such as the reflection functions and some other 
tricks. You might find that some of the changes you would want to 
make to your code to make it R3 compatible are also supported in 
R2.

It's interesting though who has been draw back by this announcement. 
 Will we see Romano?

If he didn't succumb to smoke yet

Eh?

He's a Java developer now ...

He was a heavy smoker when I met him

Ahh ... it only takes about 10 years off your life

Channel that to my father

Statistics don't mean much to the individual

Last week I heard a surgeon say that who got that insight when he 
got cancer

Let me make a few remarks:


- "MaxV, REBOL isn't really an interpreter." - stated this way it 
looks correct, but:

-- specifically, the couple of r3.exe and r3lib.dll (speaking about 
the Windows case here) are two parts of the R3 interpreter (in my 
opinion, of course, but this looks quite legitimate)

--- the R3 interpreter consisting of the r3.exe and r3lib.dll interprets 
such expressions as:
    do ...
    func ...
    etc.

-- the collection of the above (DO, FUNC, ...) is not a library, 
the r3lib.dll is

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

-- your program is actually just data for the R3 interpreter, the 
data is what you are bundling with the interpreter when encapping