World: r4wp

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


Restricting "library" to only encompass "OS libraries" is certainly 
a debatable opinion, but it's not the stance the FSF takes. Perl 
modules and Java classes are not OS libraries, but still libraries 
in the FSF's opinion.

OS libraries and R3 libraries are both libraries. However, with GPL2 
they make an exception for linking to OS libraries even if they're 
closed source. With GPL3 they extended that exception to libraries 
that come with a runtime or VM, like Java, .NET, or closed-source 
REBOL. The exception doesn't go the other way though: It's not allowed 
to link to GPL'd libraries with closed code.


Ladislav, the runtime library is used to implement the interpreters, 
and includes the interpreters for that matter, but it's still a library. 
The DO interpreter really doesn't do a lot; it resolves the op and 
path syntax and dereferences words, but everything else is done by 
the functions of the runtime library, which your code is bound to 
at runtime. But for the good news, it's at runtime, so afaict the 
GPL doesn't require you to release your source because of that binding, 
as long as you load the source at runtime, which you pretty much 
have to do at the moment for scripts.


Encapping is a trick, but you can handle that with some limitations. 
Extensions will need to be GPL 2, and that means that they can't 
be used to wrap closed-source libraries unless they were included 
with the operating system you're running on. Encapping regular scripts 
and modules is semantically iffy, but you could handle that with 
a FAQ entry that explicitly says that loading a R3 script doesn't 
count as linking, even if you bind the words to GPL'd values. The 
same FAQ entry would apply to scripts in files, databases, whatever.

Our lives would be a lot easier if r3.exe and r3lib.dll were LGPL, 
and the host code MIT or something. We wouldn't have any restrictions 
on usage then.

We wouldn't have any restrictions on usage then.

 Except static linking r3lib. Or being able to see the source and 
 work on Red or Topaz.

So, what are the benefits to RT going GPL 2 ?

I like Ladislav's point.  Many people have claimed that Rebol like 
Lisp, there is no difference between code and data.  So, your source 
code is just data for the interpreter.

The data is still linked with other data (mezzanine code) which may 
also be licensed as GPL. So, you better put off linking that together 
until runtime. That means that if you use something like prebol as 
part of your encapping process, you better preprocess the mezzanine 
code and your own code separately and combine them in memory when 
your program loads. Yay modules?

Benefits of GPL vs closed source: the project continues. Benefits 
of GPL 2 vs GPL 3: it's legal to make a non-decappable encapper, 
and compatibility with Boron and Orca. Benefits of GPL 2 vs LGPL, 
Classpath, MPL, EPL, MIT: for us, none; for RT, more oportunities 
to sell commercial licenses.

Presumably the investors have had a say in the license then

Basically, GPL 2 has a lot more loopholes for exploiting the customers 
than GPL 3. Of course, we're the customers. GPL 3 doesn't have those 
loopholes, but it does have some repairs of bad legal code in GPL 
2 that we would miss, and an exception mechanism that's pretty nice. 
However, many businesses won't use GPL 3 code, more than the number 
that won't use GPL 2, so that may be a factor.

What was the dual mysql license?

GPL 2 with copyright assignment, vs commercial. Even their client 
library was GPL, so applications that used MySQL had to be GPL'd 
too, or pay the price. Or they could use a third-party client lib 
like Doc's.

Perhaps that's what RT is planning ..

Brian, you sure know a lot about this subject. Thanks for bringing 
these details up on behalf of all of us who just want to create programs 
without all the conditions you are outlining.

That doesn't work too well for programming languages, unfortunately, 
it doesn't compete very well. This is why even GPL'd development 
tools mostly use permissive-licensed libraries.

'Restricting "library" to only encompass "OS libraries" is certainly 
a debatable opinion, but it's not the stance the FSF takes.' - My 
reservation is:


- everything mentioned here is just an opinion of the respective 
person, certainly not a qualified opinion of the lawyer

- the DO is not implemented in REBOL at all, is it a functionality 
implemented in C, and the DO variable is just a variable the interpreter 
"knows", certainly not some code your REBOL program is "linked to".

- also, the user of the interpreter obtains r3.exe and r3.dll, not 
some other "hypothetic library" which is just a construct you are 
creating

- and 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

Similarly for every other variable your program may refer to

(the dynamic = run-time resolution of variables is the property of 
the interpreter as every REBOL user knows)

I wrote my notes here not to present "the complete truth", just to 
show that even some opinions presented here may look as qualified 
but may be controversial when inspected thoroughly enough.

Ladislav: an oxymoron (if it's the right term) - qualified opinion 
of a lawyer is irrelevant, although it is very relevant :-) What 
I simply mean is - there are end users, who need to orientiate themselves 
and feel safe about the licencing, so what we need is someone, who 
can answer easy usage scenarios. So here's mine:


- want to "encap" an app and produce my-app.exe. Am I forced to release 
the source also to my app, "linked"/"packed" into final executable, 
or not?

- if I dynamically link a DLL which is GPL licences, the same question 
...

Hmm, in another thread I can see you don't call encapping a linking, 
but mostly a bundling with data?

Hmm, in another thread I can see you don't call encapping a linking, 
but mostly a bundling with data?

BrianH: "Our lives would be a lot easier if r3.exe and r3lib.dll 
were LGPL, and the host code MIT or something. We wouldn't have any 
restrictions on usage then."  - Nothing to add, and Carl should follow 
his KISS principle in this topic too. LGPL or MIT.

Robert: Brian also added: "We wouldn't have any restrictions on usage 
then." Except static linking r3lib. Or being able to see the source 
and work on Red or Topaz"


Guys, you should think about it a bit deeper and not only to cover 
short-term needs. I'm not sure that betting on R3 + copyleft license 
(even LGPL) will be a winning bet when Red will catch up with R2/R3 
and then, leave them behind.


MIT/BSD is the only way for R3 and Red/Topaz to collaborate instead 
of being in direct competition.

Our lives would be a lot easier if r3.exe and r3lib.dll were LGPL
 - actually, I doubt it

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