World: r4wp

If you made a race game, probably you would not modify rebol intepreter. 
So you can protect your work and eventually claim if someone copied 
your work.

On the other hand, if you notice some bug in rebol, you can correct 
it and publish your correction; this way all the community will take 
the advantage of your work.

That is how I don't understand what GPL is about.

MaxV, unfortunately your idealised wishes don't match up with the 
GPL and the understanding and intention of the FSF of the GPL.

when you encap your app with rebol you are just making something 
like packaged version of app (that includes a rebol runtime), you 
are not releasing new rebol.

This whole issue has seen a wealth of debate in the past:
http://en.wikipedia.org/wiki/GPL#Linking_and_derived_works

The problem is only with compiled softwares. If you don't bellieve 
in me, looks at Java. Nobody has problem selling java software. Java 
intepreter is opensource, but your code not.

If I make a picture, and you need glasses to see it, I don't have 
to give the same license of the glasses to the picture.

Most compiled languages chose a more permissive license for their 
runtimes, precisely to avoid this issue.

From Wikipedia:


Therefore, software distributed under the terms of GPLv1 could be 
combined with software under more permissive terms, as this would 
not change the terms under which the whole could be distributed, 
but software distributed under GPLv1 could not be combined with software 
distributed under a more restrictive license, as this would conflict 
with the requirement that the whole be distributable under the terms 
of GPLv1.


So it means - you can't have statically linked GPL and closed source, 
you simply have to release everything. Now the only thing you can 
do is to argue, that REBOL encap process is not a link, just a packaging 
of REBOL interepreter together with your script, but not sure, it 
would be an acceptable excuse :-)

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