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

World: r4wp

[Ann-Reply] Reply to Announce group

BrianH
26-Sep-2012
[652x2]
It is common to use this FAQ entry as a way to make GPL extensions 
that wrap proprietary components: http://www.gnu.org/licenses/gpl-faq.html#WindowsRuntimeAndGPL


Developers commonly put links on their web site to the vendor's web 
site to download the DLL. However, it's iffy with GPL2 because the 
actual exception is worded like this:

However, as a special exception, the source code distributed need 
not include anything that is normally distributed (in either source 
or binary form) with the major components (compiler, kernel, and 
so on) of the operating system on which the executable runs, unless 
that component itself accompanies the executable.


Read literally, it would exclude runtime libraries that aren't bundled 
with the OS. It's more unambiguously OK with GPL3.
The same would apply to hosts that are meant to be plugins for closed-source 
software.
Maxim
26-Sep-2012
[654]
I read through the page and it seems pretty clear that encapping 
would be impossible if any part of R3 is GPL .
BrianH
26-Sep-2012
[655x2]
You might manage a Click-to-Run like setup if R3 is GPL2, since that 
loophole wasn't closed until GPL3.
Still, having R3 being GPL means a return to the R2-style SDK licensing, 
as long as RT requires copyright assignment. They could sell a commercial 
license allowing closed-source encapping and host creation. I don't 
know if the revenue generated could offset the inhibited adoption 
that would result from using a copy-left license in the first place 
though.
GrahamC
26-Sep-2012
[657]
If the aim is to promote the development and prolongation of R3, 
then GPL doesn't appear to be the way to achieving that aim.  If 
the underlying primary aim is to monetize what's left, then it might 
be the way to go.
Gregg
26-Sep-2012
[658x2]
Doc +1. Andreas +1.
Thanks for continuing to improve INCLUDE Ladislav. I will have to 
check out the new version soon.
Ladislav
27-Sep-2012
[660x7]
The first paragraph would apply to data passed to DO, PARSE, DELECT, 
DO-COMMANDS, or other dialect processors.

 - actually, there is absolutely no need to not apply it also to the 
 r3.exe+r3lib.dll
Also, the sentence:


However, 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.

 applies to any "extension library" written in REBOL under GPL. It 
 does not apply to the "barebone interpreter" at all.
For example: is DO an extension of the interpreter? Certainly not, 
DO is a basic functionality described in the documentation to the 
interpreter.
Also, the example used shows a completely different situation.
For example: "The JNI or Java Native Interface is an example of such 
a binding mechanism; libraries that are accessed in this way are 
linked dynamically with the Java programs that call them. These libraries 
are also linked with the interpreter. If the interpreter is linked 
statically with these libraries, or if it is designed to link dynamically 
with these specific libraries, then it too needs to be released in 
a GPL-compatible way." - this refers to the following situation when 
transposed to the REBOL case:


R3 can be dynamically linked with REBOL extensions. If the extensions 
are GPL'd, then r3.exe has to be GPL'd as well.
The other case: "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" - this, transposed 
to the REBOL case would refer to REBOL modules coming with the interpreter. 
Are there some modules coming with r3.exe and r3lib.dll?
...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.