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

World: r4wp

[Ann-Reply] Reply to Announce group

Ladislav
27-Sep-2012
[666]
...could apply to built-in functions unless we get an exception like 
GCC's;

 - again, wrong. The built-in functions are related to the functionality 
 of the program, which is unrestricted. The problem with GCC (why 
 there is the need for the exception) is that the functions needing 
 the exception are the ones provided and statically linked in the 
 extra libraries.
Andreas
27-Sep-2012
[667]
Another similar and very common case is to provide libraries with 
the interpreter which are themselves interpreted.

This applies to all mezzanines shipped with R3.
Ladislav
27-Sep-2012
[668]
Actually not. The mezzanines are not libraries because they are built 
into the program.
Andreas
27-Sep-2012
[669]
The lib context is a runtime library bundled with the interpreter.
Ladislav
27-Sep-2012
[670]
So, readers may see different opinions. From "there are libraries 
different than r3lib.dll in the r3.exe+r3lib.dll interpreter" to 
even more extreme: every one of DO, PARSE, etc. is a separate program 
(obviously false) to which the GPL has to be applied on a separate 
basis".
Andreas
27-Sep-2012
[671x2]
Yes.
Again, the FSF's "library" interpretation is much more relaxed than 
yours, and does not only encompass OS libraries.
Ladislav
27-Sep-2012
[673]
I know, in the REBOL case it comprises modules, so once there will 
be some modules shipped with the r3.exe, they will fall under this 
category. However, since such modules are not shipped at present 
this is only applicable in the future.
Andreas
27-Sep-2012
[674x3]
It goes much further than modules.
It comprises any collection of functions.
So if I follow the FSF's interpretation, I definitely see the collection 
of mezzanines as a library. How they are actually bundled/distributed 
(as multiple .r's, as one .r, bundled into r3lib.dll, bundled into 
r3.exe, something else) is irrelevant.
Ladislav
27-Sep-2012
[677]
Right, also the collections of extensions, etc. Still not present
Andreas
27-Sep-2012
[678]
No, also the collections of mezzanines.
Ladislav
27-Sep-2012
[679]
So if I follow the FSF's interpretation, I definitely see the collection 
of mezzanines as a library.

 - that is not correct, because there is no library, just the r3.exe 
 interpreter, which has got its basic functionality implemented in 
 some way. Using the FUNC word in my program I am just using the functionality 
 built into the r3.exe+r3lib.exe program. No linking.
Andreas
27-Sep-2012
[680]
No OS linking.
Ladislav
27-Sep-2012
[681]
No linking at all.
Andreas
27-Sep-2012
[682]
The FSF sees it as dynamic linking.
Ladislav
27-Sep-2012
[683]
No, since the dynamic linking would require (according to FSF's own 
words) a separate extension to the interpreter.
Andreas
27-Sep-2012
[684x3]
Huh?
FUNC is part of a library of mezzanines provided with the R3 interpreter 
which are themselves interpreted.
These libraries and the programs that call them are always dynamically 
linked together.
Ladislav
27-Sep-2012
[687]
CItation: 'when the interpreter is extended to provide “bindings” 
to other facilities (often, but not necessarily, libraries), the 
interpreted program is effectively linked to the facilities it uses 
through these bindings' - so, clearly, the interpreter needs to be 
*extended* by some *other* facilities
Andreas
27-Sep-2012
[688x2]
That does not apply to this case. That's for the interpreter providing 
bindings to third party libs, such as OpenSSL.
Unrelated to the "libraries coming with the interpreter which are 
themselves interpreted" case.
Ladislav
27-Sep-2012
[690]
Also a wrong interpretation. There are no "libraries coming with 
the interpreter" and your interpretation is overly extensive, like 
the interpretation that DO, PARSE, etc. are "separate programs".
Andreas
27-Sep-2012
[691x2]
I don't follow the DO, PARSE, etc interpretation.
But I am convinced that the collection of mezzanines forms a library 
coming with the interpreter.
Ladislav
27-Sep-2012
[693]
No, it would, if you e.g. put in a separate library as a module which 
could be linked or not. In this case there is just one-piece program 
(speaking about r2.exe) or two-piece program (r3+r3lib)
Andreas
27-Sep-2012
[694x2]
How the library is bundled is irrelevant.
You can choose to use it or not (via boot levels).
Ladislav
27-Sep-2012
[696]
It is clearly not in this case, because "the library" has been already 
linked with the interpreter once the r2.exe has been created.
Andreas
27-Sep-2012
[697x2]
Yes, but it has not been linked with your user script.
Which, through mezzanine usage, still dynamically links to the library.
Ladislav
27-Sep-2012
[699x2]
Not at all. The library has been statically (it is already in) linked 
with the interpreter in this case.
And it is not distributed at all. Just the interpreter is.
Andreas
27-Sep-2012
[701]
Your user script still links dynamically to the library.
Ladislav
27-Sep-2012
[702]
No, the library is not distributed.
Andreas
27-Sep-2012
[703]
That does not matter.
Ladislav
27-Sep-2012
[704x2]
As I said, different levels of overly extensive interpretations.
For example, in the GCC case, some library functions are statically 
linked with the gcc executable, however, they are also (at the same 
time) present in the libraries shipped with the gcc compiler and 
statically linked with user programs. The exception is needed only 
for the second use, not for the first one.
Andreas
27-Sep-2012
[706x3]
Bad comparison. Functions linked into GCC are not used by user programs.
If you choose to use GPL'd mezzanines in your program, you must release 
your program in a GPL-compatible way.
(Strike that bad comparison.)
Maxim
27-Sep-2012
[709x4]
the mezz code is a statically linked module.  it is linked by adding 
it or not within the host-kit boot up procedure.
you can remove that code completely from the host, you can even argue 
that the natives which are within the currently hidden core are also 
statically linked within the core.
rebol itself, without all of those "helper" funcs is pretty pare... 
 make do  and that is pretty much all you need to "evaluate" rebol. 
 all the hard work is done within the datatypes themselves.
pare == bare
BrianH
27-Sep-2012
[713]
Andreas, functions linked into GCC are used by user functions. Ladislav, 
GCC has an explicit exception to the GPL that allows this.
Andreas
27-Sep-2012
[714]
(My remark was going into a different direction, but I have withdrawn 
it as I don't think this would help the discussion.)
BrianH
27-Sep-2012
[715]
Ladislav, most of what Andreas and Maxim are saying here is true, 
but it doesn't matter. Reading comprehension requires reading the 
whole thing. The relevant part you missed is:

    or we could get a FAQ entry declaring that the functions built into 
    R3 are "part of the interpreter" rather than "library code", despite 
    R3's actual system model.


I am actually an expert on R3's system model as it relates to dynamic 
linking of code, and how code is bundled, since I wrote most of the 
code that does that. The mezzanine code is dynamically loaded and 
linked in the startup code, and is statically linked as data into 
r3.exe, so as far as copyright is concerned it is linked two ways. 
At least in the laws of the country of origin of REBOL, the code 
vs. data distinction is irrelevant to whether the code/data is covered 
by copyright, or the GPL, which only relaxes copyright. All that 
matters is that the mezzanine data is statically linked into the 
program. For that matter, it's not even bundled as a resource, so 
it's really hard to make the "mere aggregation" argument even if 
they weren't explicitly in the same program. Embedded extensions 
and embedded REBOL code are both statically linked into the program, 
and are both dynamically linked at runtime.


Nonetheless, that system model doesn't have to matter. A published, 
official FAQ entry (or even a blog post) can be used as evidence 
in a trial, so a FAQ entry that clearly states that all bundled native 
and mezzanine code is "part of the interpreter" would be sufficient 
to make it so our scripts whouldn't be affected by R3's GPL at runtime. 
Without such a FAQ entry it could be plausibly argued in court that 
your code is dynamically linked to GPL'd code, which would then extend 
GPL requirements to your code. With the FAQ entry, it's unambiguous.