• Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r4wp

[Ann-Reply] Reply to Announce group

Oldes
25-Sep-2012
[559]
that's what I do from the beginning
Chris
25-Sep-2012
[560]
I forget, is an R3 a superset of R2? Or are there R2 values that 
won't load in R3? (not including #[...] literals)
Kaj
25-Sep-2012
[561]
PARSE level should be compatible, except for bug fixes
Chris
25-Sep-2012
[562]
So there's not likely many cases where R3 would not load a .r script?
Andreas
25-Sep-2012
[563x2]
Very few if any "regular" cases, yes.
MaxV: whenever you use FUNC in your scripts, you call an interpreted 
library function.
BrianH
25-Sep-2012
[565x2]
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.
Henrik
25-Sep-2012
[567]
The blog post states October 1st, but there is no year mentioned...
Sunanda
25-Sep-2012
[568]
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
BrianH
25-Sep-2012
[569x2]
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.
GrahamC
25-Sep-2012
[571]
It's interesting though who has been draw back by this announcement. 
 Will we see Romano?
Kaj
25-Sep-2012
[572]
If he didn't succumb to smoke yet
GrahamC
25-Sep-2012
[573x2]
Eh?
He's a Java developer now ...
Kaj
25-Sep-2012
[575]
He was a heavy smoker when I met him
GrahamC
25-Sep-2012
[576]
Ahh ... it only takes about 10 years off your life
Kaj
25-Sep-2012
[577x3]
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
Ladislav
25-Sep-2012
[580x3]
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
However, (to Pekr) if you encap your program and the source of the 
encapper is available, it is not a problem for somebody interested 
to "decap" your program and obtain its source. This is not related 
to the kind of license used for the interpreter, it is just the consequence 
of the availability of the source code.
So, Pekr, you may see that the open source license has got some consequences 
you don't like
Andreas
25-Sep-2012
[583]
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.
BrianH
25-Sep-2012
[584x3]
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.
GrahamC
25-Sep-2012
[587x2]
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.
BrianH
25-Sep-2012
[589x2]
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.
GrahamC
25-Sep-2012
[591]
Presumably the investors have had a say in the license then
BrianH
25-Sep-2012
[592]
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.
GrahamC
25-Sep-2012
[593]
What was the dual mysql license?
BrianH
25-Sep-2012
[594]
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.
GrahamC
25-Sep-2012
[595]
Perhaps that's what RT is planning ..
james_nak
25-Sep-2012
[596]
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.
BrianH
25-Sep-2012
[597]
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.
Ladislav
26-Sep-2012
[598x5]
'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.
Pekr
26-Sep-2012
[603x3]
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?
Robert
26-Sep-2012
[606]
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.
DocKimbel
26-Sep-2012
[607]
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.
Ladislav
26-Sep-2012
[608]
Our lives would be a lot easier if r3.exe and r3lib.dll were LGPL
 - actually, I doubt it