World: r3wp

Well, you said "To understand how to use a moderately complex system 
like a full-featured web server, it is going to be important to capture 
the thinking of those who wrote the code.". and then you want to 
force your users not to look at it?

BrianH, i agree.

what?

AFAIK the GPL-attorneys are thinking about the dual-license-line 
too.

I just use BSD for code I just don't care about at all, or for code 
that I want everyone to use, whether they are Jedi or Sith :)

ScottH - choosing one of two ways. either passing the freedom by 
giving your changes away, or to pay the GPL-part coder with some 
of the money you get. As you would do if you hired a coder to do 
that part.

I think that Classpath-style would be best for Uniserve, but that 
may be just me.

Or make a clear cut about which part you want freedom. as with classpath, 
or linux-kernel where you can run closed stuff on.

I wish I would not have said anything about licensing, but I saw 
uniserver on the list and it's gpl.  that doesn't mean BSD, which 
was part of the spec.  I like BSD MIT school of thinking.  My brain 
doesn't jive with GNUfree  the old free was just fine.

IIRC uniserve has some style of classpath. That is, it allows to 
add cgis etc not to be gpl. based on this "its on arms length" or 
something like that? not sure.

Bad example with the Linux kernel. Their license really doesn't allow 
that kind of binary linking, but that restriction is just not enforced 
that much because the linking is usually done locally.

The BSD-free, you are right, is old. at that time the GPL was standard, 
just not written. if you asked someone how something worked, you 
got answer, examples, etc. was a closed group, such programmers, 
no need to think big about licensing.

GNU can continue to develop the term "free" so long as they prefix 
all gnuWords with gnuPrefixes so everyone gnu:knows what one is gnu:talking-about

ScottT, if the REBOL powerpack spec doesn't allow GPL restrictions, 
then it doesn't. Good point.

No, linux allows explicitely running closed stuff on it. it does 
not allow closed stuff in it, there you are right. which relates 
to some video-drivers.

I agree about good point. but the posting said nothing about its 
gpl, but we want bsd. it started flaming against gpl, that was all. 
so i responded to that.. ;)

it was really just a passing thought

and I could have skipped straight to the documentation discussion.

its ok to have another opinion than me btw ;)

The REBOL community in general seems to be more pro-BSD anyways, 
if only to accept use of the proprietary software that is REBOL itself.

AFAIK the community is a bit more BSD, but Carl not, and GPL means 
he will not use it. Thats a heavy argument.

yeah, I like the REBOL licensing schemes so far.  As long as Carl 
gets to do what he wants, then I'll be happy.

Yes. Also, rebol shows a lot of its source, even if officially closed. 
thats a lot of the "good old informal way" before GPL was needed. 
:)

and from what I've read, the only thing that really weighs on him 
is a bunch of soap opera caliber licensing discussions, which I can 
now say that I participated in. . .oh well.  guess I'll have to label 
that button hot, I generally avoid that discussion.

:))

Hey, at least it mattered in this case :)

(i guess licensing could be a very good base for a soap opera, thought 
:)

basicly Free means the author is free to choose the licence of his 
creation ... You can't contest the right of an author to protect 
his creation ... Offerring the  use and sharing the code is yet a 
great thing .. And with GPL you can work on the creation  as you 
want until you respect the licence terms and do not want to appropriate 
a creation that doesn't belongs to you ;)

property and robe are the base of our culture read the bibble it's 
full of those deprecated concepts ...

you can make free to use things and do not want people to claim what 
they don't have

invented

you are free to use free to modify free to distribute free to work 
with the author isn't that enough franckly ?

if we take MacOS X example we all know what is the gain for Apple 
but it is more blur to see what is the befefit that OpenBSD project 
writers retrieves of this experience. A part a spot light put uppon 
there project. But every a little serrious coder was yet knowing 
that freeBSD and OpenBSD were rock stable OS

I think we should consider moving licensing discussions to the licensing 
channel ...

I yet expose my way to think .... As many people are not playing 
the same game and as software is an industry we need to make a difference 
betwin what is donate and what is the fruit of the industry that's 
all  in fact ... People who want to choose what ever licence they 
want no body can contest this or arg a licence is better than another 
without thinking what is behind this  ...

One major point wasn't said: We need a library system to handle all 
this. I won't use code, where I need to 'do zillions of single files 
in a specific order, handle path and lookup things, need local sub-directories 
to load images etc.


I'm still using Slim on my xpeers system, because that's the only 
thing I know about that handles all this quite well. And I can tell 
you, it pays off. Something like this is required.

And libraries must be compatible. The current running RebGUI projects 
is a good example. Feedback loop is fast, releases are done often 
(thanks to Ashley) and momentum is raising.

As already said, I see some parallels to the RPC idea. And as Ashley 
said, quality matters, and the ultimate test is to see if the stuff 
is used. So, just throwing together some cool stuff and hoping that's 
it isn't enough. I really would like to see this effort merged into 
the RPC idea. This would avoid this licensing discussion too.

hum having all in one file until it's not a stable release complicates 
a lot the search and find for bugs ...

you don't handle one file with more than 2 thousand lines than several 
files with at max 200 hundred lines ;)

2 hundred ,à

if people now the code scruture it's easy for them to work with a 
sigle hudge file if people don't  know the file scruture it's hard 
for them to locate the place where they have to act (adding code, 
fixing bugs)

I agree shadwolf. The need for a library system points to the more 
general need of how to structure larger REBOL projects.

There's the preprocessor setup in Rebol/SDK.

Yeah, but we need more than that

I agree, absolutely. I'd like to see something like perl-style runtime 
'require/import/use' semantics, even if it's just in a wrapped-rebol 
app.

Some remarks: wrt licensing, RP components will be BSD based. RP 
should help you jump-start and it only does that if you can use it 
in all circumstances. No need for discussion about that (how nice 
to be a benevolent dictator ;-)

Wrt library system: in time there might be a library system in RP, 
but any componet will be self-contained. Otherwise you end up being 
forced to use a bloated library whenall you need is just a small 
subset of functions.

The way it looks now is that the Viewtop in 1.3 will have a place 
that can be used by RP. This solves a lot of problems in terms of 
version managemet and accessibility.

Meanwhile.... send me your code that is BSD licensed and well documented!