World: r4wp

BrianH asked: "Was the BSL chosen because it allows you to distribute 
a binary without requiring that you distribute the license, unlike 
MIT and almost all other open source licenses?"


With the sole 3-clause BSD, users would need to provide a copy of 
the license with each compiled program, because of the runtime code 
included. So to avoid that, we chose to publish the runtime parts 
of Red and Red/System, under the more permissive BSL terms. The binaries 
that include the compilers (currently that would mean encapped version 
of Red and Red/System compilers) are still under BSD.


When Red will be self-hosted, it will include a JIT-compiler that 
will need to be released under also BSL or similar terms.

Gabriele, it's not about the code not having a licence, it's about 
not having to provide it. If the licence doesn't require physically 
including it, it's implied

Then there's also the class of unlicensed code. It used to be that 
things were sold, not licensed. Software wanted to put that on its 
head, but other things are still simply sold, and so can software

Then there's software that doesn't even need to be bought. SQLite 
is released as public domain, so it doesn't need a licence nor a 
purchase, excepting countries that outlawed the concept of public 
domain

In the future, we will have public domain software because the copyright 
term has run out

Or rather, our grandchildren might, barring further extensions of 
the copyright terms. I suppose that Ada Lovelace's work and maybe 
Jaquard loom programs have fallen into the public domain, but the 
rest of the public domain code was released to the public domain 
explicitly. Almost the entire history of computing is more recent 
than Steamboat Willy.

Doc, would you consider it sufficient to have a license that doesn't 
require that the license be included with (like MIT code) or distributed 
with (like BSD code) the product? The Apache license only requires 
that the license be given to the recipient - it hoesn't specify how 
- and it doesn't even require a copyright reference be included unless 
the product is distributed in source form. I'm just trying to determine 
the extent that you'll be able to include Apache-licensed code in 
Red, or how much this factor matters to you.

The BSL was specifically chosen so that anyone just reading the license 
text will never even have to worry about it.

I'm perfectly fine with the current BSD/BSL licensing model we use 
for Red. I don't see the need for any change there for now.


I'm not sure what you mean precisely with "product". I don't see 
why third-parties redistributing the current Red compilers would 
have problem distributing a copy of the BSD license with them. For 
end-user binaries, users have no obligations to give a copyright 
reference or distribute a copy of the license.


If you are wondering about including possible future R3 code parts 
under APL-2 in Red codebase, I see no problem with that so far (as 
long as they are separate files or modules, we don't want to start 
having several licenses per file).

Brian, where do you get that the Apache licence doesn't require a 
copyright reference be included unless the product is distributed 
in source form?

Also, Apache is incompatible with GPL 2. Mixing Apache into the Red 
runtime would make it illegal to use GPL 2 libraries

(At least if you follow the FSF's interpretation.) Any particular 
library you are thinking about, or is that hypothetical?

As in my opinion, GPLv2-only libraries are a hostile mess I'd avoid 
in any case. Luckily I don't think I have come across any.

(readline was GPLv1 and then GPLv2 and so "GPLv2-only" until the 
GPLv3 came to be, come to think of it.)

By "the product" I meant something that you or your users are distributing 
- that's why I wasn't specific.

Kaj, clause 4.3: "You must retain, in the Source form of any Derivative 
Works that You distribute, all copyright, patent, trademark, and 
attribution notices from the Source form of the Work, excluding those 
notices that do not pertain to any part of the Derivative Works"


It's the only place in the distribution section where they specifically 
mention Source form rather than Source or Binary, and that's the 
only clause that requires copyright or other notices be retained. 
Except for that weird NOTICE file requirement, of course.

Doc, good to hear that you think Apache code would be OK, even if 
it's in separated files. I'd like to help out with both projects 
:)

Quite a few media codecs are under GPL. If you would use things such 
as FFMPEG, the licence of the codec plug-ins would leak into Red 
through the plug-in framework. I haven't checked, but since those 
codecs have a long history, it's more likely that they're GPL 2 than 
3

Also, when you try to build an operating system with Red, you'd get 
into GPL 2 territory in kernel space, and you'd have a problem with 
the many GPL 2 drivers. The media codecs and some networking protocols 
mirror that situation in user space

Brian, as you noted before, "You must give any other recipients of 
the Work or Derivative Works a copy of this License" does not make 
a distinction between source and binary forms. That means that if 
you compile Apache into a Red program, you need to give a copy of 
the licence when you give the program to someone

Work" shall mean the work of authorship, whether in Source or Object 
form, made available under the License, as indicated by a copyright 
notice that is included in or attached to the work (an example is 
provided in the Appendix below)."

Let's not talk about this further in the Red group.

I'm not following the Licensing group anymore. I have work to do

Couldn't help noticing in the last checkin:

type: either dt/value = TYPE_DATATYPE [
    TYPE_DATATYPE
][ 
    dt/value
]

Isn't that equivalent to

type: dt/value

Yep :) I've changed those lines so many times today, that my mind 
should have blocked from reading them anymore. ;-)

:-)

It was a bit painful commit anyway, as the internal API is not yet 
fully stabilized and to do it right, I would need to fully define 
the public runtime API first, but that would delay the 0.3.0 way 
too much, so we'll deal with that later.


What I mean by "public runtime API", is the Red API exposed to Red/System 
and to other host languages loading Red as a library. I'm still uncertain 
if such public API can be just some internal exposed or will need 
a thin layer of wrappers to make it handier (and in some cases, safer) 
to use. 


The R3 extension isolation model is too strong for my taste and makes 
the extensions harder to write than they should. I'm also uncertain 
if this model was stricly motivated by providing the safest possible 
interface with the core or, if the willing to keep the core internals 
as secret as possible was also playing a big part in this model choice.


Once the `dyn-lib-emitter` branch merged, I plan to study the Lua 
(and others) public API, to see if and how we can do better for Red. 
I already have a rough idea of how it should look like, I just need 
to refine it.

Sounds good

In my view, the R3 interface is also motivated by the wish to be 
independent from any operating system loader mechanisms, to discard 
them for Wildman in some unknown future

Red/System extensions will usually be compiled together with the 
Red runtime, so they will be much more flexible. For interfacing 
with precompiled binaries, a more stable interface would be needed

Public API stability: right, that's a good point in favor of a set 
of wrappers on top of current Red runtime API.

A stack-oriented API might be a good candidate for that...

For example, I've noted the alias! issue before. As long as all code 
is compiled together, alias numbers are a good interface, like symbol 
IDs are assigned at runtime in REBOL. But when precompiled code needs 
to communicate they become useless, hence why the R3 interface makes 
efforts to map symbols to known numbers

Alias! type ID are attributed per compilation session, so they are 
not shareable with other binaries.

Anyway, we want to expose Red API to host languages/apps, not Red/System's 
one (at least not for now).

Think PARSE usable from any other language as example. ;-)

The same issue affects Red symbols

Red/System is already easy to expose to other languages, because 
it's C compatible, and you made the dynlib interface. :-) However, 
alias IDs break it

Part of the motivation of the R3 extension/host API was to isolate 
the extensions and hosts from changes in the underlying data model, 
which makes hosts and extensions really resilient to upgrades of 
R3. It also was designed to let you have a consistent internal execution 
model even in cases where the host has a completely different process/thread 
model.

I think it went a little too far at times, especially the lack of 
marshallers for immediate values that are more than 64 bits internally. 
I've frequently wanted to supplement it with marshallers for the 
other datatypes in R3, particularly the date, time and money types.

The big win is the command dispatch model though, because it basically 
lets you get dispatch to JIT-compiled functions for free. The dispatch 
function can manage changes between execution models completely without 
R3 even noticing. Lua has similar separation, though since it doesn't 
have to support anywhere near as many datatypes it can get away with 
a stack-based interface.

Another interesting side effect of the strong separation is that 
it would be possible to implement the client-side of the extension 
interface in other languages, such as Red, so that it could use R3 
extensions without changes. The REBOL portion of the extension might 
be trickier to implement though, because that code tends to be more 
tied into the actual R3 runtime model. You could write your own wrapper 
code if your system model is different, but the native code could 
be used as-is.

However, the way that the R3 script loader works, you could make 
an extension that has both Red and Rebol scripts in the module data, 
especially if Red uses a similar script-in-a-block embedding method,

That would make it so you could make one extension that can be used 
by both languages, that shares the same native code.

Hi Kaj on my macbook:

Last login: Fri Oct 19 07:21:16 on 
ttys001

 MacBook-van-Arnold-160:~ Arnold$ 
 /Users/Arnold/Downloads/Red\(/System\)\ 
 Testing-dc1b702068063b65/Darwin/Red/hello 
 ; exit;
Hello, world!
§±ÖÁµ, ºÌüµ!
`O}Y, NLu
Dobrý den sv
te
logout

[Proces voltooid]

 /Users/Arnold/Downloads/Red\(/System\)\ Testing-dc1b702068063b65/Darwin/Red/Fibonacci 
 ; exit;

MacBook-van-Arnold-160:~ Arnold$ /Users/Arnold/Downloads/Red\(/System\)\ 
Testing-dc1b702068063b65/Darwin/Red/Fibonacci ; exit;
Fibonacci 35: 9227465
logout

[Proces voltooid]


MacBook-van-Arnold-160:~ Arnold$ /Users/Arnold/Downloads/Red\(/System\)\ 
Testing-dc1b702068063b65/Darwin/Red/empty ; exit;
logout

[Proces voltooid]
I took the programs from the Red tree under Darwin

Oh the Hello World looks very much better than is shown above. Still 
unreadable by me but I recognise different charactersets.

Do you need a print?