World: r4wp
[Ann-Reply] Reply to Announce group
older newer | first last |
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 |
older newer | first last |