World: r4wp

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

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.