World: r4wp

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

Hmm, even Shadwolf is positive to the news ... well ... kind of :-)

I'm a fan of GPL, it keeps people on their toes.  But, I'm also a 
fan of LGPL for runtime so those same people can make food money 
when they feel the need.

I don't see any problem: rebol is an iterpreter, so if you don't 
modify it, you haven't to release anything.

If you use a modified version of Rebol, you must show your Rebol 
source. Where is the problem?

JAVA is open source, but a lot of sotware use Java and are closed 
source. Java is just an interpreter.

MaxV: the problem (as how I understand GPL so far) is, that once 
you Encap REBOL Core along with your app (you create one executable), 
all source code has to be provided, including your app, which might 
mean a busines logic, etc. In that regard (and if I am right about 
the GPL), the licence is unacceptable for me - why should anyone 
care about what my app is doing. In that regards, LGPL allows you 
to at least link GPL libraries dynamically.

In my humble opinion, you see things from the wrong point of view. 
What source is released?  Rebol intepreter

Do you modify it? No, you just put the intepreter and you software 
in the same container (zip, encapper, etc.)
So you don't need to make your software open source.

Well, it is possible that I don't understand correctly GPL obligations. 
But from what I have learnt in the past, I was told (or I incorrectly 
understand the licence), that once your application link any GPL 
code, it has to be fully open sourced. So - when you encap rebol 
interepreter and create an executable called my-app.exe, all my-app.exe 
sources have to be open sourced. And if so, the licence is something 
I am not willing to accept ...

If I made a "opensource car ", you wouldn't have to publish your 
routes or way of driving .

If you modified the "open source car", you would hate to publish 
your mods to the car.
Don't confuse vehicle with driver!

Thi is easy with inepreted language (like Rebol), on the contrary 
with compiled language the diffenrce is a little more obscure.

This is easy with intrepreted language (like Rebol), on the contrary 
with compiled language the diffenrce is a little more obscure.

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