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

World: r4wp

[Ann-Reply] Reply to Announce group

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
Kaj
26-Sep-2012
[609x6]
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
Ladislav
26-Sep-2012
[615]
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.
Kaj
26-Sep-2012
[616]
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
Ladislav
26-Sep-2012
[617]
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.
Kaj
26-Sep-2012
[618x3]
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
Ladislav
26-Sep-2012
[621]
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.
Kaj
26-Sep-2012
[622]
As Andreas noted, the FSF interprets this case as a library function
Ladislav
26-Sep-2012
[623x2]
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.
Kaj
26-Sep-2012
[625]
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
Ladislav
26-Sep-2012
[626]
FSF interprets a different case and that case does not resemble the 
r3.exe + r3lib.dll case at all.
Kaj
26-Sep-2012
[627]
Right, because it's not about r3.exe and r3.dll
Ladislav
26-Sep-2012
[628]
Yes, that is why I do not think it is relevant to point to some unrelated 
case making some invalid point.
Kaj
26-Sep-2012
[629]
That's what you're doing
Ladislav
26-Sep-2012
[630]
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
Kaj
26-Sep-2012
[631x2]
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
Ladislav
26-Sep-2012
[633]
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
Kaj
26-Sep-2012
[634]
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
Ladislav
26-Sep-2012
[635x3]
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.
Maxim
26-Sep-2012
[638]
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.
Andreas
26-Sep-2012
[639]
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.
Arnold
26-Sep-2012
[640]
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.
Maxim
26-Sep-2012
[641]
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.
Kaj
26-Sep-2012
[642]
It's much worse. ORCA had the choice of LGPL and GPL, Boron is just 
LGPL
Pekr
26-Sep-2012
[643]
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.
BrianH
26-Sep-2012
[644]
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.
Pekr
26-Sep-2012
[645]
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?
Maxim
26-Sep-2012
[646]
they are still potential derivatives which is where the issues *may* 
occur.   

especially when you are looking at source for learning or curiosity 
purposes.
BrianH
26-Sep-2012
[647]
If you don't look at the source, but just examine the behavior from 
the outside, that is called clean-room reverse engineering. You can't 
be blocked on copyright violation grounds, just patent and trademark 
stuff. Even the function specs could be considered to be not copyrightable, 
according to Google vs. Oracle, though that case's appeals haven't 
made it to the supreme court yet. The doc strings are another issue 
though since they aren't technically necessary for interoperability. 
Copyright laws (at least in the US) don't make a distinction between 
code and data when it comes to derived works.