Comments on: An open conversation about open source with Larry Rosen

I had lunch today with Larry Rosen, top open source guru, prior general counsel to the Open Source Initiative, prior director of Apache Software Foundation, advisor to Python software, Free Standards Group, and the author of the Academic Free License, Open Software License, Open Source Licensing Software Freedom and Intellectual Property Law, and much more.

I quickly discovered that my understanding of licenses like GPL is a bit lacking, and that there are common misconceptions about these popular source licenses. I'm sure I'm not alone here.

As the author of AFL and OSL, Larry provides a unique perspective, and I've invited him to join our conversation.

Although all parts of the license are open for discussion, the main issue I have is point #2 from what I suggested in Defining the REBOL source license:

In return, when you make improvements to that system, you agree to send them back, and if I decide to include them in future distributions, they can be used gratis and libre, not only by me, but by everyone else.

As you know I've more recently been leaning toward the Apache 2.0 license, but I not totally comfortable yet. So, I'm eager to hear Larry's insight.

I should add that Larry made many similar comments to those you posted earlier. That this is about building and expanding the community and its involvement... and avoiding a fracture to the common standard that is the REBOL system.

129 Comments

Comments:

Carl Sassenrath 16-Oct-2012 14:54:31	Larry mentioned this concept is called "reciprocity". See Larry's chapter: Reciprocity and the GPL. Link is: http://www.rosenlaw.com/pdf-files/Rosen_Ch06.pdf (As you can see, direct hyperlinks are no longer allowed from comments. Blog spammers are to blame - they were using this blog to boost their Google rankings.)
Kaj 16-Oct-2012 15:27:57	Carl, you may want to switch CloudFlare in front of your web sites. They will stop most attacks: http://www.cloudflare.com
Joe Latone 16-Oct-2012 15:38:54	The Eclipse Public License offers reciprocity, while at the same time being commercial-friendly, aka, "weak copyleft." And the Eclipse.org community is one of the most successful OSS communities, albeit largely commercial-driven. I'd also much rather see the EPL than the GPL, because the GPL's going to mean problems for many. But, hey, Apache's fine, too! It's pretty-much just as permissive as the BSD/MIT, so anybody can do just about anything they want, including building a commercial product based--or entire company--on REBOL and never giving a single thing back to the community. It depends what you're trying to achieve, Carl, while at the same time trying to understand your future community. And, you even have the advantage of looking back in time at examples & counter-examples all over the OSS world. Good luck! :)
Lawrence Rosen 16-Oct-2012 15:55:17	Hi everyone, I had a great conversation with Carl today, catching up on things as well as learning about the status of Rebol. I was delighted to learn that Carl is (finally) leaning toward turning parts of Rebol into open source code. I've been hoping for that since he first introduced me to this software many years ago. It is so powerful a tool that it belongs in everyone's available toolkit. Carl and I thought it would be useful to let the community (you!) try to reach a consensus on the appropriate license. I'm anxious to hear your justifications for each alternative. I'll try not to prejudge the conclusion, but you should know that I'm a strong supporter of the Apache model for most kinds of software projects, but I'm also a fan of reciprocal licenses like the GPL for software like Linux that -- for important reasons of the technology -- must remain open, and perhaps "standard". Which kind of software is Rebol? /Larry
Kaj 16-Oct-2012 16:29:58	Hello Larry, nice to see you here. It's good to ask which kind of software REBOL is. It spans from an operating platform to applications, so both the Linux and Apache situations apply to parts of it. However, much has been said already about the fact that REBOL is an interpreter, and at that a very dynamic one where code is data, so the situation in Linux where the kernel is at arm's length of user space applications does not apply. In REBOL, the platform and a user program become tightly intertwined at run time. Inbetween are the mezzanine functions. Another consideration is that REBOL is not operating in a vacuum anymore: there are now several direct competitors. If there is to be coopetition with Red, the mezzanine code should be interchangeable. This can only be achieved when REBOL mezzanines match Red's licence for its runtime, which is under the Boost Software License.
Brian Hawley 16-Oct-2012 17:18:13	Rebol is infrastructure and glue. The trick is when it's glue. Most of the time Rebol is run on other platforms rather than being a platform of its own. If we want to increase the adoption of the language then we will likely want to support integrating with growing platforms. Unfortunately, there are some significant growing platforms, such as iOS and the others with app stores based on its one, that really don't work too well with GPL-style copyleft license requirements. So that's a minus. Worse, Rebol has other infrastructure and glue competitors that increasingly have permissive licenses nowadays. We have to consider that if we are more restrictive than them we will lose potential adoptees to those competitors. This includes other languages made by Rebol community members which would be better allies than enemies, as long as Rebol's license encourages cooperation. Btw, Kaj, afaik (from having read both licenses) you can combine Apache-licensed code and BSL code without either having to switch to the license of the other. Neither license is viral. Mr. Rosen would be better able to say this for sure though.
Brian Hawley 16-Oct-2012 17:23:03	Reciprocity is a different issue though. Traditionally, due to a mostly intentional quirk of the language, the only practical optimizer of Rebol code has been a smart person who knows what they're doing; it's inherently difficult to optimize by machine. As a side effect, the best Rebol optimization strategy has been to post your code for the community and then let them one-up each other in making the code better. This tends to encourage people to publish their ideas, at least for improving Rebol. Also, as people make improvements to Rebol they want to take advantage of other people's improvements as well. Even in fork-heavy projects like the Linux kernel there is a tendency have patches move upstream so that they can be better maintained. We can use similar social methods to encourage further reciprocity. It doesn't have to be a hard requirement, and in some ways a softer requirement will encourage greater adoption. It's like taxes: A high requirement can lead to lower tax revenue overall if as a result the tax base stays tiny; sometimes you can bring in more revenue by increasing the tax base, and then having ways to encourage participation and discourage cheating. Rebol is lucky in one way though: Its standards aren't really that inherent. Even its syntax is implemented with functions that can easily be replaced, or supplemented with other functions that implement other syntaxes. Rebol's focus on dialects and messaging makes it unusually easy to be compatible with, or to interoperate with. I've written projects that use both R2 and R3 at once, and those have very different system models. We have even discussed adding binary loaders, and we retrofitted script compression into R3 with no difference in the function interfaces. Rebol compatibility is driven by aesthetics and practicality - in a hand-optimized language, those considerations are inseperable. Carl has always been the center of Rebol not just because he owned the copyright and trademark, but because he's an astoundingly great Rebol programmer. People will want to contribute their stuff to the core if it will benefit them, and having it optimized and maintained by Carl and the best of the rest of the community is a real benefit. Awesomeness can act like gravity :)
Kaj 16-Oct-2012 17:29:35	It's not about being able to combine BSL and Apache, it's about the consequences of the combination. Does Apache allow binary distribution without including the licence?
Brian Hawley 16-Oct-2012 17:47:48	Kaj, yes, that's section "4. Redistribution". But you don't have to provide the license with the work. The exact phrase is this: You must give any other recipients of the Work or Derivative Works a copy of this License Many projects provide their licenses on their web sites, or in their app store descriptions or help files. Still, that is a tradeoff compared to the BSL. You have to ask if that is the reason that the BSL was chosen in the first place, or whether it was just because it was less restrictive than the MIT license that Red used to have. I think that the patent grants make it worth the tradeoff though, since it makes it more possible to have the "free and gratis" part of Carl's goals.
Brian Hawley 16-Oct-2012 17:59:50	Stupid typos; I meant libre and gratis :) It does look like all of these licenses that require you to provide the license somehow might also require it of Bittorrent peers. The GPL fixed that in version 3. You don't actually have to include the whole license though: Apache recommends just including a copyright notice and a link to the license on your or their website. See "APPENDIX: How to apply the Apache License to your work".
Kaj 16-Oct-2012 18:19:15	Anyone distributing a program would have to code that into the program.
Kaj 16-Oct-2012 18:22:20	Red never had the MIT licence. It still has the BSD licence. It's the runtime that's under the BSL.
Brian Hawley 16-Oct-2012 18:25:43	Or into their web site. The license doesn't require that even license notifications be provided with the thing, just that the license be given somehow. You only need to include copyright notices and such in the source of the Apache-licensed portion if distributed in source form (section 4.3). For binaries it's not necessary. There is that weird NOTICE file thing though (section 4.4).
Kaj 16-Oct-2012 18:46:39	When you distribute your REBOL program now, you just dump the script somewhere, on a web site or in an email or in AltME. To match that with Red, you don't want to have to give a licence at all. Hence, the Red runtime is under the BSL. To cooperate with Red, REBOL would have to match that.
Brian Hawley 16-Oct-2012 18:58:42	Is there something like the BSL that has Apache's patent grants? Because (given that I'm in the US) patents are a bigger issue for me than a license clause. I'm having trouble seeing how a user could hold a contributor to their patent pledge if they don't have some kind of proof that they licensed the code with the grants, no matter what the copyright situation is. Given that the Apache license (apparently) doesn't require the license to actually accompany the work, just that you "give" it somehow, this seems less intrusive than licenses like BSD (which says "provided with the distribution") or MIT (which says "included in"). Mr. Rosen, what would you suggest?
Brian Hawley 16-Oct-2012 19:01:56	Kaj, R3 hostkit apps and R2/R3 encapped apps would be affected by this same issue, unless an exception were made. Perhaps the license could be put on GitHub or rebol.com, but would that work for user apps? Is this really a big issue?
Lawrence Rosen 16-Oct-2012 20:39:34	I was watching the presidential debate which, I may add, was far more epochal than anything you've talked about here. :-) So that's why I wasn't online answering your questions as they arrived. 1. You said that Rebol is "Interpreter + Mezzanine functions" or "Infrastructure + Glue". I interpret that to mean that there are many opportunities for commercial entities to make money organizing or coordinating or supporting that entire combination or parts of it. That makes it a good candidate for a *successful* open source project. 2. You asked some questions about combinations of works under various licenses. That is largely irrelevant to my current question, but I can refer you to these links if you have time to read more about licenses than matters to us here: Apache published policy: http://www.apache.org/legal/resolved.html FSF/GPL published policy: http://www.gnu.org/licenses/quick-guide-gplv3.html 3. Carl in his introductory message did not define "reciprocity" precisely right -- as that word is applied technically and legally to open source licenses. I honestly don't think it is worth my explaining the distinctions here, though, until I hear from someone a reasonable justification for Rebol to *require* that anyone reciprocate *in any way*. Will this community or Rebol suffer if there are free-riders and selfish users of your source code? Explain to me why this community doesn't already operate successfully by people *volunteering* their contributions. 4. Why all this talk about patents? Don't waste your time talking about anything other than *real* patents that read on Rebol or on some community software. Please assume that any modern open source license you end up adopting will deal with patents appropriately. I'll make sure to explain that when we get to that point. /Larry
Maxim Olivier-Adlhoch 16-Oct-2012 21:36:20	Sorry for the long post... but having such a license expert here is quite amazing. I'd like to discuss one aspect of copyright and its repercussions if the GPL where used for licensing the REBOL project. I think, beyond the distribution aspects and rights to copy there is one aspect of the GPL which shies away quite a few devs from GPL'ed projects and that is the derivatives concept in copyright, applied to software. I read a good part (if not all) of the GPL reciprocity chapter link which Carl gave, and have been looking around a bit on my own for the last two weeks and the actual concept of a derivative is something so vague (or with so little parameters) that it is open to a lot of interpretation... by all parties involved. The licensor, licensee, and any one involved in settling a dispute. There doesn't seem to be provisions as to who is responsible for defining what constitutes a derivative work, and what extent or types of modifications or plagiarism are acts of derivation. Are the following (and other) acts of derivation? Deriving a class from another, when used for polymorphism and using the same member names... this, even if no actual code from the original was edited. porting code to a different language with absolutely no code re-use and possibly absolutely no equivalency in project form and substance. If you only imitate the algorithms or their effect, but don't actually imitate the sources. Generating the exact same application using a completely different code base, having never evolved from each other, written in the same time The mere learning of an algorithm or parcel of code and its use in another wholy un-related project, possibly even unknowingly and even years later. Is merely having the same 5 notes in succession in over 100 songs any indication of derivation... not usually. Is having some function in 100 other project also cause for derivation... probably not, but legally... ? Is a derived project 1%, 10%, 50% 90% of source lines, function/class count, feature count? If I start off with a single function (and its considered fair use or too-little to be considered derivative), but a project evolves, on its own, and ends up including 50% of another project's code (source similar by the very nature of both projects) do I become a derivative, even though the code is original. If I work on a GPL project, can I even work on another project of the same domain, ever again, without someone claiming that some code or functionality is a derivative, and forcing me to open the source, even when that functionality is fundamental or basic to Computer science? I have my own opinions on most, some are probably also/instead covered by patent law. I don't aim to have an actual answer on these here (well, maybe only the last point ;). But these types of issues are so complicated/subjective, that many simply won't take the risk because of possible "tainting" and the retroactive backlash one could suffer if law in the future would be extended to specifically rule one way or another on any more or less ambiguous cases. Most of the above are quite easy to answer for any artistic works, but in source code, not so much... there are overlaped levels of creation involved. So I guess the question is, what is the feeling of mr Rosen on the general idea of the point raised: Could the GPL legally prevent so called "proprietary" developpers from participating in the maintenance of the REBOL codebase itself, based on fears of the consequences following allegations of derivation, even in unrelated works?
Brian Hawley 16-Oct-2012 21:48:49	IANAL :) 1. 2. Sounds good! 3. The R3 project did operate somewhat successfully for a while, with people volunteering contributions. I was one of those people. It had some difficulties because of financial considerations, because its license situation wasn't very clear (a problem for some) or wasn't open source (a problem for others). The contribution license situation wasn't clear either, so I just licensed my contributions to RT under the MIT license and others followed suit. The main reason that it stopped working is that Carl became busy with other work and the rest of us didn't have the native source access to fix some things, and didn't know when he was coming back. It wasn't a license thing. No offence intended, Carl, and that's past now. Some of use still use and fix R3, even professionally, because it's that useful even in alpha form. We're really looking forward to the new release. 4. Glad to hear. We were talking about patents because the Rebol clone languages and Rebol patches and extensions that arose while Carl was out are all licensed as MIT, BSD, or BSD with BSL for the runtime library in one case that Kaj was mentioning. Because of this the community is more familiar with those licenses, and is concerned with cooperating with those projects in order to keep the community together, like Ruby's or Python's multi-implementation communities. Unfortunately, none of those licenses deal with patents, which is why I suggested the Apache license last week. The patent arguments that ensued were in comparison with those other licenses. I'm slightly more concerned about patents than most of the community because software patents exist in my country (and yours), but don't necessarily exist yet in theirs. I'm not aware of any particular patents that affect Rebol, though the existence of such wouldn't surprise me. If I'm just paranoid here, so be it. Thanks for your help! We've referenced some of your articles in the recent arguments, so you've been helping already :)
Fork 17-Oct-2012 2:00:14	Given that there is a new and knowledgeable person in the debate -- and we've started seeing some source :) -- I'll just say my piece on #3: "Will this community or Rebol suffer if there are free-riders and selfish users of your source code?" Suffer in the short-term? I doubt it. Ability to use adapted code in popular-but-evil app stores and proprietary situations will expand the base. Desire would be strong to keep sync with the main trunk's improvements and fixes. It's in fact easiest when your own unique branch becomes the "blessed" one so you drive the agenda and everyone has to integrate with *you*. But that power play is possible with or without a copyleft license. Bigger near-term problem will be unselfish folks, who nonetheless use teases to test the waters without source. They often want to hold back until it is ready or if it is perfect. I've drawn an analogy to how we feel about the timeline of development for R3 (regardless of any right to demand the source). It helps in planning to gauge the progress with one's own eyes--a lot of deadlock happens otherwise--we've seen that on projects around here and that's suffering. Copyleft may shrink the pool of players in the game a little. But discouraging opaque processes accelerates collaboration. Programmers who remain (or get recruited) will be the sort who are ready to work in the open, and can use oversight to keep things moving. But if the main goal is to accelerate development timeline of the project, a non-reciprocal license will still probably be faster. The true suffering will be long-term. I call it suffering to lose a chunk of one's lifetime having to re-implement code you should have been allowed to have, and years down the road a non-sharer of significance *might* arise. But a more likely danger is not that someone will improve Rebol and hold that back, but rather corrupt it into malicious software while keeping that fact hidden. It's better to require those modifications be put out in the open, where experts like Carl can call out the implications of the changes. As an added benefit, it would help assess the credibility of closed implementations that claim they're "99% compatible with Rebol!" A quick look at what they actually changed might expose crazy bugs or vulnerabilities. I'll repeat that Rebol and Transparent Software Freedom are a good mix. If a language can't be morphed into something concise that speaks in the relevant domain, how can its programs be vetted in a reasonable amount of time? What good is having a spiral of dependencies in source you can't follow? But if rate of features, bugfixes, and popularity in the wild in the next years are the most important thing...that will correlate with numbers and attention. Making Red happy as possible will bring those numbers back. Making it seamless for companies to derive products behind closed doors and chase big profits will bring not just numbers, but maybe some money to the table in terms of contracts for customization and a job market for Rebol developers could appear. I'd make a different decision, as I think there will be an acceptable (to me) increase in project timeline with a copyleft on kernel (moreso a weak one, hence fine)...and Red-approved license on Mezzanine. But I return to silence on the licensing issue to keep from delaying the release longer.
MaxV 17-Oct-2012 3:20:03	I'm a fan of GPL license, and it's used in commercial application.
Nick 17-Oct-2012 3:35:25	Larry, Thank you for your time! The core question in this discussion seems to be: what license should be choosen to avoid alienating potential developers and stunting REBOL's growth, while still enabling Carl's desire to enforce reciprocity? (I'm using the term "reciprocity" loosely to refer to any requirement to give back code). Carl said "this is about building and expanding the community and its involvement... and avoiding a fracture to the common standard that is the REBOL system." Is enforcing reciprocity the best way to avoid fracturing the common standard? As long as Carl has the final say in choosing which donated features make it into the official release of REBOL, he will continue to be the person who chooses what is included in the "standard". Releasing the source just enables others to make contributions. Eliminating potential developers who can't even look at GPL code is a tremendous potential danger. If developers don't give back changes they've made, then those changes are no more a part of the standard then if they'd never existed. So, I don't see how requiring reciprocity will help build or expand the community and its involvement. The community is current as fractured as it possibly could be, and growth has halted entirely. The big question for me is: how do we ensure that Carl is the person who continues to choose what's included in the standard? I have to imagine that that's Carl motivation for a GPLish licence. Larry, is enforcing reciprocity the only way to ensure Carl's position as "leader" and to continually rally support for REBOL's core goals, or are there better ways? Is the creation of a REBOL foundation, or organization of some sort, more effective at achieving that end? I don't know the answer to "which kind of software is REBOL?", but to me the priority of growing community seems to be the most important consideration. My opinion is that it's most important to avoid artificially stunting REBOL's adoption and community growth in any way. Larry, you asked for someone to provide "reasonable justification for Rebol to *require* that anyone reciprocate *in any way*." I think any attempt to do that counters Carl's hopes to see REBOL regain market share. You asked "Will this community or Rebol suffer if there are free-riders and selfish users of your source code?" What we do already know is that REBOL will suffer immediately if it requires reciprocity. Many of the most prominent developers in the existing community have stated that they won't be able to contribute to REBOL, or even use it, if a restrictive license is chosen. Projects such as Red will not be able to interoperate as easily, and that will fracture the community. I have to assume that the requirement for reciprocity is an immediate barrier to many other potential developers, and future contributors. I'd rather see REBOL, and Carl, and all the potential users of REBOL, benefit from as large and as unified a community as is possible. If part of that community uses REBOL without giving back, we're in no worse a position than if no one uses REBOL at all. I see far more potential for growth in expecting a small portion of a large community to donate, than hoping for a large portion of a small community to donate. If REBOL has no community, then it will not survive or grow.
Nick 17-Oct-2012 3:37:39	Larry, You asked "Explain to me why this community doesn't already operate successfully by people *volunteering* their contributions". Historically, there has been an enormous volume of successful contribution - when the community was bigger. Code donations to rebol.org and on privately hosted sites, support donated via the email list and AltME, code donated to R3 by Brian, Robert, Cyphre, etc. Now there's virtually no community left, so those donations have dried up. Look at the reasons why developers stopped donating, and it had largely to do with the fact that source wasn't available. Development work and donations WOULD HAVE continued if those guys had had access to do whatever they wanted with the code. Red already has a non-restrictive license, so any of Doc's work can already be donated back to REBOL, and look how the community is rallying around him. Carl seems to welcome his involvement. Carl, If you want REBOL to be a success, my opinion is that every barrier to adoption needs to be removed. I think REBOL has a real chance at achieving significant adoption, only if developers see no reason not to use it. From what I understand, whether it's sensible or not, there's a danger that many developers will reject REBOL if the "wrong" license (in their opinion) is chosen. The majority of your real competition is licensed in non-restrictive ways. So the answer to the core question seems to be, eliminate the requirement for reciprocity, as long as you can find some way to maintain control of the "standard". I hope Larry can help us understand how to choose a license and/or organization that works in every way. Carl, I hope it's clear that everything I say is with tremendous gratitude for what you've created, and with every hope that you'll achieve greater success and satisfaction in your choice to release the source. Thank you for listening!
Pierre 17-Oct-2012 5:28:51	About reciprocity: what about explicetly *encouraging* giving back contributions, instead of an obligation? It is kind of unusual in a licence; but why not?
shadwolf 17-Oct-2012 5:52:35	Hehehehe... Well to have a serrious talk about "free" licence you need to talk to a lawyer. Which will say to you that you are playing with the "free" licences outside the scope of the legislation in any country. Public domain exists. The unalterability of author rights is granted. But then how do you control, and overlook what is done with the things you authored once you abandonned them to public domain. and that is exactly what the free licences try to do. To not remove the author from his unalterable rights to control and overlook his own creations. And it's even more complicated since the commercial licences are in general 1) pay to use 2) never look how it is done inside 3) never share 4) infriging point 1 2 and 3 will make you eligible to a ton of troubles and the lost of your right to use the product. With those kind of licences how can anyone know that the fantastic media player I sell for 300 USD isn't just a front end for VLC? And lest assume I'm clever anough to not give in my binary installer a vlc.dll :)... Off road baby! OFF ROAD! P.S I would be the spammers that spams to advertise for their websites I would do that spams from a rebol script... at least my spaming would have a concrete relation with the whole thing here.
shadwolf 17-Oct-2012 5:59:53	r3 having no rebol/browser linked to rebol.org that doesn't help people to contribute with code. And the best parts of given rebol codes like cheyenne! or rebgui were never by default integrated in rebol Virtual Machines. So yes if those are not worth the honnor to be integrated to rebol VM what is ? AS the community dried. Well this is our own individual and collective faillure. We are not the kind to see the global interrest over our particular interest. We fail to organise things. The gurus (selected few in charge) failed to hear and motivate people to assist them in other ways than endless blabberings on altme...
Giuseppe Chillemi 17-Oct-2012 7:23:13	We have discussed a lot about licenses and REBOL. Open source REBOL is good and we all agree. The question is: Does the Apache 2.0 license help REBOL3 or not ? We all want: 1) Develop and Bug Fix REBOL via a community approach. 2) Integrate REBOL with existing applications. 3) Promote it to have a larger community and let it be adopted by commercial companies. The relevant point is: Apache 2.0 allows companies to use REBOL without "reciprocy". They could use, develop, promote and bug fix it without giving anything back. The community ASWERED to this concern: "We will develop (reasonably) anything a closed initiative could implement. Forks are highly discouraged because they would split the language and create multiple standars." A license with the "Reciprocy" Clause mitigates the danger but REBOL3 consists of 2 pieces: CORE and HOST KIT. The HOST KIT has been created with open source in mind. REBOL could be extended via HOST KIT. It could be Apache 2.0. Companies could use the HOST kit to interface and extend REBOL with their products. It is not a "Viral license", it can be linked to closed source applications. Having REBOL3 Core with a "Reciprocy" based licence and HOST KIT with Apache 2.0 license, which improvements, interfacing, extension would impossible for companies adopting a closed source approach ? In which way the "CORE" could be axtended in a way that such extentions should be closed source for a company ? What isn't in the HOST KIT that would force a company to extend the CORE istead ? I am not so inside REBOL3 to answer my questions. Carl and the others could help. A last note: in the REBOL3 CORE with "Reciprocy" based Licence AND HOST KIT with Apache 2.0 licence. Do we need a CLASS PATH Like NOTE to have ENCAPPED applications ? Thanks Giuseppe Chillemi
Maxim Olivier-Adlhoch 17-Oct-2012 7:38:58	Larry, "What kind of software is Rebol?", At its heart, Rebol is a tool, not a product. It's not the picture, it's the brush. It's not the wine, it's not even the grape, its the sickle, press and barrels. The biggest divergence is here: It can be used for consuming information, like a browser. for building a new platform which consumes, the browser itself. It is also used to create completely stand-alone applications which are not able to interpret source code, for which reciprocity is, in fact, not even desireable for the language. One might say that its even usable as a shell as if it where an abstracted OS (with a simple kernel). These multiple identities are probably where the biggest rift in licensing occurs when topics like GPL vs ASL/MIT/... are raised and get passionate. I use the the rebol language almost 365 days a year, and I use it in all modes. In one aspect, I'd be fine with GPL (in fact I prefer it as a way to ensure it stays clean) but in another, GPL just can't allow me to do my work. In the end, there are so many colliding aspects to Rebol, that IMHO using a permissive license like the Apache 2.0 license ensures one aspect of Rebol doesn't shackle the others. As long as derivatives (yeah that again) have guidelines limiting how they may refer to and use the Rebol brand name (in describing or relating themselves), I think that we can then stop thinking about the poor contamination of Rebol by (any) means. They won't be Rebol anymore. The "true" Rebol will always continue to exist and be the one version which is blessed by its original author. No one can change that.
Maxim Olivier-Adlhoch 17-Oct-2012 7:57:11	Giuseppe, Playing around in the core may be required in a project simply because you are integrating your company's core business logic into it. We can't do everything with the Host kit. What if I am using a licensed, patented Garbage collection algorithm and want to add it to REBOL for my own use. With the GPL, The moment I try to do client work, then I can't really use my changes, so it ultimately defeats the purpose. once we start taking Rebol into new spheres, the concept of an interpreter might be completely alien (a kernel, using some of the code or ideas in the original R3 sources). One project might only need to extract the native LOAD function and the internal datatype structures in order to make a bridge tool for other platforms, or in order to replace XML as their data storage. what happens then? if it's GPL'ed all manner of weird questions occur (even when linking). Even the legal applicability of the GPL in this regard isn't completely asserted AFAICT. It just becomes a basket of crabs which many of us don't want to start handling (commercially or not, in fact). In much the same way that people have been leaving the platform because of its mere potential for dying out, some people will not touch it now because of the potential legal issues.
Maxim Olivier-Adlhoch 17-Oct-2012 8:28:15	"Some people will not touch it now" is a bit harsh, it should be: "Some people won't participate in improving it", though they may use it as if it still where a closed-source project.
shadwolf 17-Oct-2012 8:36:48	but can we affort that REd and rebol be antinomic projects fighting for their own survival on their own? I think it isn't the idea behind rebol open source. AS for the ones participating or not in rebol3 futur endevior. Well if they don't we will loose alot but this is to assume that red and rebol will share same thematics. and that Red will code pump REbol3... I'm not sure at all that the code in rebol3 will be of anyuse in red... first they both have diametrically separated approach. It's like fearing that apache could feed from cheyenne! or vis et versa (latin words ... ask google ...enhance your horizon) .
Lawrence Rosen 17-Oct-2012 9:10:33	Nick asked: ...Is enforcing reciprocity the only way to ensure Carl's position as "leader" and to continually rally support for REBOL's core goals, or are there better ways? Is the creation of a REBOL foundation, or organization of some sort, more effective at achieving that end? That's a great question! There can be better and more effective ways than reciprocity to support the goals you've mentioned. Remember that nobody but the trademark owner can call this software Rebol. So if you agree on an organizational structure to manage that trademark, in effect that organization is managing the software known as Rebol. That is the model used by the Apache Software Foundation to make sure that we define the software known as "Hadoop" and "Open Office", etc. Is that enough for a Rebol organization (whatever that might be) to "control" unwelcome forks? /Larry
Lawrence Rosen 17-Oct-2012 9:22:39	I want to add a postscript to my previous post: Note that the Linux Foundation also operates by managing a trademark. Unacceptable forks cannot be called Linux regardless of any derivative work analysis you might want to do to enforce GPL reciprocity. Indeed, the Linux community has never sued anyone on a derivative work theory to enforce the GPL. Enforcement has only been on ancillary conditions of the GPL such as the publication of the license itself and an offer for the original source code. Other than making people afraid of derivative works, I'm not personally convinced that the GPL has prevented forks of functional software in any meaningful way. /Larry
Brian Hawley 17-Oct-2012 9:46:55	Trademarks can be used to cut down on forks that falsely claim compatibility, and that can be a benefit. That method sounds like a good idea, as does the foundation. However, forks in and of themselves aren't necessarily bad. You can do a lot of experimental stuff in a fork where it can be more safely explored. The stuff that pans out can be sent back upstream for all of us to benefit from. Linux benefits from this kind of thing as well. The long-term viability of the community depends on experimentation and growth. Forks can be a good way to help that along.
shadwolf 17-Oct-2012 9:46:56	I don't want to be a pain in the neck but... Can we affort to have Carl as leader of something he totally lost interest in or have no time to be interest in? If the new organization allow car to overlook and contribute on a better pace it's okay for me. But if it's to have a disappeared into thin air leader like we experience those past years better not...
shadwolf 17-Oct-2012 9:57:50	being a leader is more than just a title it is a responsability too organise to set a coherent and followable course of action and not only overlook upon things and say this is a no this is a yes. I have in mind a very unpleasant example of how Carl leader things. Gabriele Santilli 's rewriting of VID for rebol3. which was tested and overlooked by merely 2 guys (brian and Carl) and discarded by Carl to do the VID reset rebol3/gui which is a fiasco we can say that... In the end from my point of view I feel that it was a all mighty God decision to discard Gabriele SAntilli's rebol3/VID and not a comunity based decision set upon a global consensus of the majority of people. And Gabriele Santilli was alone for his work could it have been polished could it would lead to a better understanding by the community of the needs and direction to set to that project? Hell we will never know because it went to the trash and there is no more discussion upon that. If that is the way you see fit the way to organize the work around rebol open source with a missing leader that only comes to throw his Zeus Carl all mighty lightning bolt upon every suggestions comming from the community. I predict that this open source intent will end in the exact same state that rebol3 is actually. 1) people left 2) people don't want to hear about it anymore 3) people prefers rebol2 and its ton of bugs. This is why I'm asking so much what comes next to the licence pick. Because the licence pick is just the tree hiding the forest!
Lawrence Rosen 17-Oct-2012 10:48:57	Please don't turn this into a discussion about Carl. He's a friend of mine and I trust his honesty in starting this thread so that he can come to a better conclusion about how to transform Rebol into an open source community. Every successful Apache or Linux project has one or more "benevolent leaders" who were instrumental in the early versions of the software who remain connected in some way with that project. These projects are lucky to retain these people as mentors and, perhaps, as members of the Project Management Committee ("PMC"). The most political thing you will need to do in the next few months is to pick your open source PMC. You'd be crazy not to invite Carl to join. :-) Who else would you want in that important group of "leaders"? Perhaps Carl can start a NEW THREAD on that topic so we don't end up confusing personalities with process. /Larry
Omei 17-Oct-2012 10:55:09	Hi Larry, have to say something too to get an autograph :D A big problem is “braintainting”. There is a clean room rebol implementation called red. Which got the surviving elite community. Or better, it is a rebol inspired c-replacement. On which a real rebol could be build. Or which could be used for embedded (its compiled), and still keep a lot rebol-feeling. Or write native extensions for r3. Reds Main developer DocKimbel said: http://www.rebol.com/cgi-bin/blog.r?view=0511#comments -pekr- 25-Sep-2012 7:55:40 I know that Red is kidn of a competing product, althought a bit complementary one. But here's what DocKimbel thinks: "The GPL precludes me from looking at the code, the risk is too high to unconsciously write similar code and infringe the license. It is even worse than that, all Red contributions implementing a feature that exists in R3, will need to pass through a peer-reviewing process to determine if it is a derivative work of R3 or not. The reviewing persons would be able to look at R3 sources, but doing so, would not be able to contribute code to Red. So I strongly advise current and future Red contributors that wants to add REBOL features to Red from looking at R3 sources.... Porting GPL code to another language falls under derivate work clause too. If it wasn't the case, it would be too easy to workaround GPL terms by porting it from language A to B, then from B to A .... There is a reason why most big software companies prohibit their developers from looking at GPL source code." So - will it lead into a community split? As Maxim shows (16-Oct-2012 21:36:20), misunderstandings about this are important. If derivation restricts only copypasting, people could use GPL, a shell-alike and armslength, and work on both sides. If it is “braintainting”, that would not work, and a permissive license is needed. I think this should be resolved first.
Omei 17-Oct-2012 10:57:47	How about contributing r3 to apache, like hadoop etc? Would that get help with organisation?
Bo 17-Oct-2012 11:08:46	(at)shadwolf, for Larry's benefit, would you admit that there is some bad blood between you and Carl? I may have you confused with someone else, but didn't he ban you from the Rebol AltME group? I ask these questions just so Larry can weigh your comments with that information in mind.
Maxim Olivier-Adlhoch 17-Oct-2012 11:47:46	(at)Brian, I think forks are the single most beneficial reason to go open source. As you say, they allow experimentation even massive paradigm shifts like we see in some other language forks. (at) ALL, IMO there are two basic types of forks. One which is meant to participate in the project's ecosystem, this type of fork BENEFITS from copyleft licensing. The other (not inherently "evil") fork is when we adapt a project in order to change its original mission. This can, in fact, be HARMED by copylefting because the nature of the change may not allow copyleft licensing to begin with. Do we really want reciprocity in a project which effectively "Takes" a project and mutates it into something else? should it be forced? I think that if only part of the fork can be reciprocated, those parts will naturally be shared back, if only because it frees the community to work on other parts which the fork can again benefit from. Even From a business sense it's in their best interest. This sharing by example is what Saphirion and others have done and it works. There are loads of thriving permissive licensed projects out there. Built on a common ground of trust and sharing.
Brian Hawley 17-Oct-2012 11:48:11	Shad, there were many people in the project when the Gabriele GUI thing happened, but I was only advisory at that point, mostly working on DevBase. I didn't become an active contributor to R3 until after that, in part to help fill the void left by Gabriele's departure. I wasn't involved with the decision to restart the GUI, but I don't necessarily think that it was a bad decision under the circumstances, for reasons that are extremely off-topic here and mostly irrelevant now. Nonetheless, the past is the past. We need to move forward. We need Carl, even if it's in a benevolent leader capacity. We could use Gabriele too, since he has great ideas and is a guru coder. We even need the commercial developers, the Red developers, all of those people. Omei, braintainting isn't the only reason that Red developers would be excluded if R3 is even weak copyleft. They would be less likely to contribute improvements to R3 which were originally developed for Red because the contributions would only be one way. The copyleft restrictions would make the reciprocity not mutual, which would discourage cooperation. Same goes for commercial closed-source developers, such as most of the developers who are currently qualified to be top contributors. In the long run it might work out, but in the short run Rebol would lose most of the momentum and goodwill it has, we would be excluded from important platforms, and the already-split community would stay split. And that short run could be long enough to kill Rebol altogether.
Maxim Olivier-Adlhoch 17-Oct-2012 11:57:46	As a community member, I'd much rather be part of something where people all share a little, hapily, even if it means we don't get all of it all the time. IMHO, the license will definitely affect the social nature of the community centered around an OSS project. I'd rather be in a room with doors and no cameras(ASL), than one with seemingly no doors but cameras everywhere (GPL). :-)
Arnold 17-Oct-2012 12:14:59	Agreed, do not let the personal issues get in the way here. Carl, can you give Larry his own color (rose/pink) so his messages stand out between the other comments? His contributions may be not so epochal that you thought to do just about that by this time ;) Hi Larry, good to have you on the discussion. Not get tempted to stray of into the bushes here. It must be hard enough to focus on what REBOL is and how the different licenses fit it, if at all. The few things I now have seen the community doesn't want to split up. It just needed to start anew for various reasons (ORCA BORON World and Red). For sources from REBOL, it will be harder to get this far into them to 'fix' things than adapt your script until it does what you want it to do (work around). For low level (networking, new platforms to target etc) that doesn't work and the R3 source should be extended. This can be done in different ways too (via creating a library or via Red or via the REBOL source way). There is no telling whether REBOL will be misused in the future, the chance of that happening is only 1. Viruses and malware can be written in various computer- and scriptlanguages. Well that is enough for me for now, unless you want to buy a rolex or some lipozene creme ;)
Luke 17-Oct-2012 12:47:16	Given things have been so quiet with R3 over the last year a space has emerged which other REBOL inspired languages have sought to fill (Orca, Red, World, Topaz). We need to pull together as a community and pool our common knowledge. Particularly if Carl is uncertain as to whether he will have the inclination or resource to lead ongoing development on Rebol. If Carl is able and inclined to engage, we can of course benefit from his vision. However he has recently said he is very busy: "I also need to tell you that I don't have much time to help out with whatever the REBOL future may be. I can help a little from time to time, but generally I'm very busy these days." (from http://www.rebol.com/article/0510.html). This - in my view - is why we need a permissive license - to ensure we can share our energies in the widest possible way. The free rider problem is unavoidable, but it should not drive us in the direction where we cannot easily share experiences. R3 should be the common source around which the whole community should be able to orient itself.
Andreas 17-Oct-2012 16:31:17	Larry, thanks for taking the time to participate in this discussion. I guess I'll better use the term "academic" instead of "permissive" licensing :) The possible uses of computer languages are incredibly diverse and manifold, and it lies in their very nature that we cannot predict exactly what will be done with and through them. What is certain, however, is that too strict a licence can only hamper adoption. As we all know too well, the value of a language is nowadays often decided by the richness and vitality of the whole ecosystem surrounding it, rather than by the virtues of the/one core implementation. So I say "let a hundred flowers blossom" -- by using an academic licence. While acknowledging the reality of "free riders", let's not have our decision and Rebol's future be dominated (or even taken hostage) by a (potentially irrational) fear of them. As many other open source projects have experienced, even the so-called "free riders" typically enrich the ecosystem. So let us also create a healthy ecosystem enabling fruitful collaboration between commercial and non-commercial peers, just as languages such as Python, Lua, or Ruby have done before -- with open & inclusive academic licensing.
Karl Robillard 17-Oct-2012 16:39:08	The only thing I'd like to see in the new license is that it be GPL compatible. That gives a number of commonly used open source licences to choose from, so I'm feeling hopeful...
Brian Hawley 17-Oct-2012 19:25:33	Great to hear from you, Karl! Good news: Our top candidate licenses are all compatible with the LGPL 3 that your Boron and Orca are licensed under, at least in the direction of you incorporating R3 code without requiring a special license. It helps that you're using version 3. If you want to contribute changes to an Apache-licensed R3 you would have to do so explicitly under that license - we wouldn't be able to accept LGPL contributions - but you can use Apache licensed stuff in your LGPL code. We would appreciate you contributing back what you feel you can, of course :)
Brian Tiffin 17-Oct-2012 22:17:12	I'm still for GPL tool and LGPL runtime. Posting this ditto partly to be a part of the history, what with all the big names in play here, and partly to try to nudge things towards the 'restrictions' implied with copyleft. Having appreciated the efforts, taking the opportunity to add a big thanks to all the big names.
Luis. 18-Oct-2012 1:36:23	Inasmuch as shadwolf's comments may be construed as personal attacks, Mr Sassenrath and others (including shadwolf!) are still PEOPLE, and he is expressing his concerns over not just the licence but also what may govern the decision, regardless of the community's drive. Let's not forget our history (see comment by Luke 17-Oct-2012 12:47:16 on this thread for a reminder as to the potential level of involvement/commitment) and that all opinions are personal. There isn't the benefit of the doubt without the doubt in the first place. (at)shadwolf: 'Because the licence pick is just the tree hiding the forest!' - Sharp, very sharp. Cheers, Luis.
Robert M. Münch 18-Oct-2012 2:55:40	I posted it in the past: Rebol is such a small community, has mostly no momentum, no visibility, maybe a hand-ful real big projects using it. What it has, in our view, is potential. But, to be honest, the rest of the world doesn't see, doesn't care, or just ignores it (which would imply they know about it). Hence, let's make it as simple as possible. Meaning: I don't won't to takle with a license that results in more questions than answers. I must be sure I can use Rebol as I need, and than I will. If not, if things get complicated, for most it won't be worth the effort. There are other options. The chance that some "dark force" is planning to dominate the game and going to spend time and money to achieve this is: 0% Rebol needs some supportes that are investing time & money into it. And, there are only very few at the moment. If we push these out of the game, it won't lift up. Thinking, that OSing R3 will immediatly attract millions of users, is IMO, pure non sense. It's the only and right way, to further keep those already involved on board and through them have a chance to raise the level of R3 recognition. So, let's keep it simple. And Carl's idea is the right direction.
Shadwolf 18-Oct-2012 5:09:16	(at)Lawrence Rosen: I never doubted that CArl had the best intensions in the world. But there is what you wish to do or achieve and what you really do. And sorry yes Carl is know for his long period of silcence. And this is a really problem when it comes to organise work. Having hime in a critical spot with a veto upon what the community do means he implicate and is aware of what happends. I like Carl too. I can't call him a friend because I don't know him personally so much. I'm just stating facts and trying to see where we are going. I want to believe in Carl's good will. This is why I point things we absolutly should not, see repeated. Like Carl disapear in feb 2011 without notice and we hear from someone else that he is focusing on other projects than r3 around july 2011. It is unelegant to say the least.
shadwolf 18-Oct-2012 5:13:56	(at) Robert: "Rebol is such a small community, has mostly no momentum, no visibility, maybe a hand-ful real big projects using it." Hillarious! IF you want a better community start with not asking the banishement of the people willing to help you. After all I said that you will end with RMA/GUI in the spot you are because of your own lack of vision and organisation and this my friend it is your downfall and not anyone else. ;P
shadwolf 18-Oct-2012 5:24:27	I don't want to be pecimistic but this discussion started on august 26th there is more than 700 messages around what people wants, what Carl wants. And actually we don't reach consensus. And we probably never will. SO I think I will do like the vast majority remain in silence and hope for nothing anymore. Have fun with endless blaberring this is a sport you excel in.
Nick 18-Oct-2012 7:11:22	Larry, You said "Carl and I thought it would be useful to let the community (you!) try to reach a consensus on the appropriate license". There are many responses at http://www.rebol.com/cgi-bin/blog.r?view=0512#comments, and MaxV put up a Facebook Poll at http://www.facebook.com/groups/rebol/. Results so far are: MIT license (10 votes) Apache-2 license (7 votes) Dual license (4 votes) LGPL2 (3 votes) BSD (4 votes) GPL2 (1 vote) Since that poll already exists, I'd recommend others vote there to help gather more response. You said "I'm not personally convinced that the GPL has prevented forks of functional software in any meaningful way". You also suggested that "There can be better and more effective ways than reciprocity to support the goals you've mentioned". It sounds to me that your recommendation, based upon your experience with several (very successful) projects, is to choose a non-restrictive license and focus on managing the trademark. Carl, You said that you've "been leaning toward the Apache 2.0 license, but ... not totally comfortable yet". It sounds like you're getting close to making a decision. Is this discussion, or any of the previous blog feedback, having an impact on your preference? Have your thoughts potentially progressed towards organizing a group of people to help manage the REBOL trademark, and the future direction of the project?
shadwolf 18-Oct-2012 7:59:48	http://gopollgo.com/what-licence-do-you-want-for-rebol-opensource results are: MIT/BSD licence 43 votes LGPL v2 14 votes custom RT licence 4 votes others 8 votes. But yes as it is a poll opened by me it is irrelevant and what said around 70 people is not to be taken in account! This is still the same way as usual you people treat the information. You take what your acknowledge circle of few close friends says into consideration and what the other can say is of none importance. If you search for a main reason why this community ejected around 99% of the people that approached it along those past 10 years take that fact into consideration.
Nick 18-Oct-2012 8:24:53	Thank you for the poll, and the link shadwolf!
Giuseppe Chillemi 18-Oct-2012 8:47:31	Don't forget the poll has been created before the long discussion about Apache 2.0 license. Apache 2.0 in the best candidate for a language such REBOL3.
Brian Hawley 18-Oct-2012 8:52:51	The Facebook poll was also created before Apache was suggested. Apache was added in later. The polls seem to have pretty small samples; most didn't participate in them.
shadwolf 18-Oct-2012 12:14:57	(at)Carl: Nice to know you can compile rebol3/core for any OS/arch in less than 5 minutes. Can I have a linux rebol3/core for linux 64bit please pretty pretty please ?
shadwolf 18-Oct-2012 12:21:36	that website is open you want to do a "Do you want rebol opensource with Apache 2.0 licence?" it is just a click away .. Okay two click away ! no need to register no need to stuff weird like giving you credit card number etc... just ask put a yes a no and tada ! enjoy ! But then you will say that the no for this poll doesn't take in consideration the scale of the possibilities involving the no ... poll here have fun! http://gopollgo.com/apache-2-dot-0-licence-for-rebol-opensource P.S : the next to come communication tools for the rebol community should be as easy to use than gopoolgo.com
Brian Hawley 18-Oct-2012 13:36:41	Shad, converting to 64-bit is not something that was done yet, when last we heard. Agreed that it would help to put that on the todo list soon. R3 was designed with eventual support for 64-bit platforms in mind, so it should be a matter of tweaking the headers to account for platform-specific methods of declaring 64-bit integers (which are different from the methods used to declare them on 32-bit platforms), and setting a value layout that can handle 64-bit pointers. All doable. Porting to 32-bit platforms should be pretty easy though, even in that 5-minute range :)
Carl Read 18-Oct-2012 14:00	shadwolf, I clicked 'other' on your poll and wasn't offered any way to enter 'Apache 2.0', so all I achieved was increasing 'other' by 1. I'd consider the Facebook poll as slightly more reliable than a totally open poll. (But I haven't voted on the Facebook poll because I'm not on Facebook...)
droid rebellion 18-Oct-2012 15:00:14	Here is a link to a discussion of when common FLOSS licenses can be combined. It is worth studying to see the consequences of using weak vs protective licenses. Apache 2.0 maybe less flexible than BSD for using other software libraries from REBOL. ------ The Free-Libre / Open Source Software (FLOSS) License Slide http://www.dwheeler.com/essays/floss-license-slide.html
Brian Hawley 18-Oct-2012 15:49:29	That chart doesn't cover using libraries, it covers adding code to the project itself under the project license. An Apache 2.0 project can use the same libraries that a BSD project can.
Lawrence Rosen 18-Oct-2012 16:30:20	For compatibility of licenses with the Apache License 2.0 see: http://www.apache.org/legal/resolved.html#category-a
Lawrence Rosen 18-Oct-2012 16:42:39	In summary, Rebol software can be included in Apache projects if its license satisfies the following criteria: The license must meet the Open Source Definition. The license must not place restrictions on the distribution of independent works that simply use or contain the covered work. The license must not place restrictions on the distribution of larger works, other than to require that the covered component still complies with the conditions of its license. Of course, the Apache License 2.0 itself meets those criteria. So do other open source licenses listed at the URL I just posted, but there is no reason for us to consider any of those older or less-popular licenses. /Larry
Bo 18-Oct-2012 21:17:40	So, Larry, now that you've had a chance to hear from some of the active members of the community, which direction do you think would be best for Rebol to go in relation to open source licenses?
shadwolf 19-Oct-2012 4:46:16	brian because there is no linux 64 bits version of rebol3/core I have to translate to perl my cute and fabulous rebol script and that is no way the way to be. And yes rebol3 open source should point to be able to be massively distributed in linux distros. I want to code in rebol and not in C not in C++ not in java, not in python, not in perl, not in tcl/tk, not in algol, not in lisp etc... IS that a crime?
Brian Hawley 19-Oct-2012 6:49:23	We all share that need, Shad. Let's get back to the topic at hand though so we can make that happen :)
Omei 19-Oct-2012 8:16:16	64bit-linuxes run 32apps.
Omei 19-Oct-2012 8:17:28	Can we agree on Apache quickly? Weekend coming :)
Giuseppe Chillemi 19-Oct-2012 9:58:41	I think there is a wide consensus. Ok for Apache 2.0 Carl, release it !
Bo 19-Oct-2012 11:08:56	Just FYI: My understanding is that Carl is out of town on business until the end of the weekend, so I wouldn't expect a release of source until he's back at home.
Bo 19-Oct-2012 11:10:22	I should have said, "I wouldn't expect a release of source until some point after Carl gets back home."
Lawrence Rosen 19-Oct-2012 13:43:04	I said earlier that "Rebol software can be included in Apache projects if its license satisfies the following criteria:..." Does anyone here have any reason to believe that existing Apache projects will care if Rebol becomes available? The most important reason for choosing a specific open source license is that you can work better with other projects that use that same license. For example, if you expect integration of Rebol software with Linux, perhaps you should choose GPLv2? As you can tell, choosing a license depends on the results you want to achieve. /Larry
Kaj 19-Oct-2012 14:44:02	Hence my suggestion that if Carl is serious about collaborating with Red, its BSL/BSD licences should be matched.
shadwolf 19-Oct-2012 15:44:42	lawrence Rosen I agree with the fact that the licence is to be choosen in order to feet the larger possible projects. being integrated in linux with apache 2.0 licence isn't a hold for apache 100% of the linux distro propose it. If we can reach that repartition for rebol virtual machine and if the incharge group of dev isn't lacking then it can be a true chance for rebol to go through. For example actually there is a very great software creator aid called Illumination software creator that relies on python to it's portability production. But rebol could be fit and offer why more possibilities and less pain to that kind of project.
Brian Hawley 19-Oct-2012 15:55:16	Aside from making an R3 host that is an Apache module for Rebol-based web services (something that people already do using other means), I am not aware of any other current Apache-licensed projects that know they would be interested in R3. Some might benefit from it, though they might not know it yet. OpenOffice extensions come to mind, or code that integrates with the open source .NET projects like Mono, Entity Framework, or ASP.NET MVC. I don't know of anyone related to the Linux kernel that has expressed an interest in Rebol. Maybe a FUSE plugin, though I don't know how they're licensed (I think that they run in user space). No one I know of has suggested making Linux kernel modules in Rebol. We know of a lot of commercial closed-source projects in or using Rebol; the aforementioned Rebol spinoff languages that are licensed as MIT, BSD/BSL, LGPL3, and closed-source; and various applications or operating systems, with all sorts of licenses, that we would like to extend. That variety requires a flexible license. Kaj is pushing for compatibility with the Boost Software License (BSL) because of Apache 2.0's requirement that you "give" recipients of distributed binaries a copy of the license, while the BSL only requires this for recipients of source distributions (more or less). He and the Red project don't want end-users of Red (or host-kit or encap users of Rebol) to have to include or otherwise distribute license files to their users with their compiled binaries. Red itself is licensed as BSD, which requires such license distribution, but its runtime library is BSL so programs compiled in Red won't. It seems to me that this could be handled by some kind of license exception or change, but I'm not aware of the legal implications of not including the license file with binaries (IANAL). Or, we could be reading this wrong and it's not a real issue at all. It would help if you could address this issue, Mr. Rosen, if only because it is a cause of a (minor) argument that actually needs a lawyer's advice, AFAICT.
Lawrence Rosen 19-Oct-2012 15:56:34	Kaj and others, Please don't try to convince me that the BSD or MIT licenses are worth using nowadays. We're in the 21st century and Rebol needs a more modern license that includes appropriate references to patents and other important provisions. I wrote about these inadequacies in Chapter 5 of my book: http://rosenlaw.com/open-source-licensing-software-freedom-and-intellectual-property-law/ and, while I don't want to overly influence your (Carl's) licensing choice, I do want to steer you away from old-fashioned solutions. Thus, choose (for now) between Apache License 2.0 and GPLv3. The other two licenses that come to my mind after reading the above thread are the Eclipse license (if you intend Rebol to integrate into the "tool" focus of the Eclipse Foundation), or the LGPLv3 license (if you want a version of the GPL that is less frightening for your commercial software customers). There are other licenses, but those other licenses introduce mere details that obscure the big picture. /Larry
Kaj 19-Oct-2012 16:04:06	I'm not trying to convince you. Use whatever you want for your code, if any. I'm just stating a choice that Carl has.
Lawrence Rosen 19-Oct-2012 16:06:39	Brian Hawley wrote: Kaj is pushing for compatibility with the Boost Software License (BSL) because of Apache 2.0's requirement that you "give" recipients of distributed binaries a copy of the license, while the BSL only requires this for recipients of source distributions (more or less). He and the Red project don't want end-users of Red (or host-kit or encap users of Rebol) to have to include or otherwise distribute license files to their users with their compiled binaries. Red itself is licensed as BSD, which requires such license distribution, but its runtime library is BSL so programs compiled in Red won't. It seems to me that this could be handled by some kind of license exception or change, but I'm not aware of the legal implications of not including the license file with binaries (IANAL). Or, we could be reading this wrong and it's not a real issue at all. It would help if you could address this issue, Mr. Rosen, if only because it is a cause of a (minor) argument that actually needs a lawyer's advice, AFAICT. I advise all my commercial clients who embed open source software in their products to acknowledge that fact and to make copies of that source code and its licenses available to its customers. Every company I know does that nowadays. For example, go to the Settings function in your Android phone and click a few links to view "Open source licenses." I personally would never recommend that you adopt an open source license that doesn't require some reasonable level of attribution (to Carl and others!) and an offer for a copy of the corresponding open source code itself. /Larry
Kaj 19-Oct-2012 16:31:31	Very well, but know that the consequence is that there can be little collaboration with REBOL's main competitor. Also, a consequence of the Apache licence would be that REBOL would be incompatible with GPL 2 code. A consequence of the GPL licence for REBOL would be that, reversely, REBOL would be incompatible with Apache code, and there would be serious doubt for closed source about the status of their code on top of REBOL.
Brian Hawley 19-Oct-2012 16:51:06	Kaj, to be fair, incompatibility with GPL2-only code is only hypothetical at this point. That definitely would be true if there where any GPL2-only projects that needed to incorporate R3 code, but I haven't seen any projects licensed as such that currently exist or are proposed that need to do this. The only significant current GPL-ish Rebol-related projects that could use R3 code are Orca and Boron, and they both are LGPL3, which can include Apache 2.0 code two different ways. (L/A)GPL3 projects aren't GPL2-only compatible either. Aside from the Linux kernel there aren't that many significant GPL2-only projects left out there; even the FSF doesn't recommend (L/A)GPL2-only. As for Red, you have complained about R3 code use, but Doc has said it would be OK as long as it's in separate source files. That's a bit of a toss-up. I suspect that we can work things out in the long run.
Kaj 19-Oct-2012 16:56:22	It's not hypothetical; you know I said this on AltME: 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
Kaj 19-Oct-2012 16:59:15	You also know that Nenad has said that the Red runtime needs to remain under BSL, and that this will include the entire JIT compiler in the future.
Brian Hawley 19-Oct-2012 17:55:09	It doesn't make sense to include the R3 code in the Red JIT because that is the place where their system models differ - R3 isn't JIT. The only place where it makes sense would be mezzanine code, and as long as that's in separate files (or based on R2/Forward) it should be OK. Whoever needs to be BSL-pedantic can do their own runtime library. For that matter, you might want to do that anyway just because the different system models may merit reoptimizing the code, the way porting from R2 to R3 does. Red itself, being BSD, can use Apache 2.0 code with no difficulties. FFMPEG is GPL 2-or-later or LGPL 2.1-or-later, both being able to use Apache 2.0 code because of the "or later" part. It is only (A)GPL 2-only projects that can't be combined with Apache 2.0 code, because of the "only" part. LGPL 2.1-only or Classpath 2-only code can be combined with Apache code using the same methods that closed-source code can. Incompatibility with (L/A)GPL3 code is why (A)GPL 2-only projects are rare now. The Linux kernel is the most significant holdout, and I'm not aware of any other significant projects that haven't switched to or weren't always 2-or-later. Many, like Boron, have switched to version 3.
Gregg Irwin 19-Oct-2012 18:26:33	Mr. Rosen, thank you for taking valuable time to comment on this issue. We, as the REBOL community, can only benefit from your expertise in this area. I'm agree with Andreas about freedom, Robert Muench about keeping it simple, and Kaj about the importance of being able to share mezz code between REBOL-like languages. Trademark protection seems enough to protect the REBOL name, and I don't fear the free-rider effect. If the sticking point is the license distribution with Apache, would it be acceptable to include the required license text *in* the Red runtime, which could be displayed via an 'about or 'version function?
Brian Hawley 19-Oct-2012 18:36:41	Found another significant project with GPLv2-only parts: BusyBox, which includes some contributions from Linus himself. I'm not aware of any plans to incorporate R3 into BusyBox, or to combine the two in any way other than R3 calling BusyBos programs. FWIW.
Brian Hawley 19-Oct-2012 18:38:22	Gregg, that would work (according to the FAQ Mr. Rosen linked above).
Fork 20-Oct-2012 0:49:06	I also want to thank Mr. Rosen for his time, and for all the great advice here. A refreshing and informed outbreak of sanity. :-) As the conversation converges on viable options (and hopefully...code?), I'm compelled to repeat one of my previous thoughts that did not make it to this thread. It's worth breaking silence to say it once again: Many commentators seem to operate under the assumption Rebol is on its deathbed. Thus it needs to hurry and get hooked up to the respirator and tubes, or perish. I'd instead argue that Rebol has yet to be born. We've simply never seen how programmers might react to this tool without the "proprietary and closed-source" albatross around its neck. While some label my projects "weird", I've been scouting ahead for how to map Rebol into the open source ecology, and explain what it has to offer. There's lots ready to go...including a logo design that has tested very well against audiences I've tried it with (have you seen it, Larry?) http://www.rebol.net/wiki/REBOL_logo But every gesture--no matter how big or small--hasn't budged anyone. I might get someone hyped about an aspect I showed them. Then they'd look at the site, the bickering in the community, the closed nature and say "not for me". Open source Rebol will be so new that pessimism is not called for; either license will "work". Apache may keep Richard Stallman from giving it a look, but I'm not sure who else is that religious (I'm not). GPL may completely eliminate some Apple or Microsoft fanboy, maybe? I don't know any programmers who don't at least use GPL tools. Yet in my view, Rebol is a language whose raison d'etre is about a philosophical fight. It's a kind of Zen and the Art of Motorcycle Maintenance manifesto on complexity. I find it disappointing that few of the comments from the *current* community have discussed the long-tail philosophies of the license choice...they focus on "me and what the person who pays me needs right now today". I feel strongly that Rebol has yet to find its soulmates. Case in point: a lot of the Rebol projects out there brazenly mistake brevity for simplicity. They've produced impenetrable, terse, tricky code (without comments) that only the original author can understand. The way many are using it, they might as well program in Perl (!) :-/ It will be *dialects* that are going to make a name for Rebol, and few have written any...much less good ones. Funny that it fell to me to write a dialect explicitly proving how well Rebol can excel at code competitions based on brevity! Soulmates or not...it's nice to take the community's input and see who can be satisfied and who can't. But we don't know what projects Rebol will have a home with when it finds its new friends. The best compass is that old saying "to thine own self be true". Apache and GPL represent differing decisions about the definition of what software freedom is. It's just a matter of picking which one feels right. When I was younger, I too didn't care beyond "make money, get paid". But ever since I began thinking about the issue 12 years ago, I've aligned myself with saying software freedom is "freedom to inspect, modify, and share". As computers drive our cars, control our pacemakers, and ride around in our pockets everywhere we go...we will realize that Stallman was right. Without access to that stack, we're not free. So my main point here is, I think Rebol can flourish either way. Not only do any existing community members have an alternative in Red, but the yet to be born aspect means the license choice should prioritize the future over the present. This project has favored aesthetics over haste so far...the license should be no different. I won't complain about either decision, but I think GPL is the forward-thinking choice for mission-critical software infrastructure of the future.
Omei 20-Oct-2012 1:17:29	Some thoughts: Part of the problem is, the community was once like a familie, and it feels cruel to push some away. With the people here it is not just a about compatible with projects, its about compatible with people. Carl pulled some stuff out of a time-machine, and they wanted to be part of it and ride the ufo. And had fun together. And they believed in it and stayed far to long, trying to keep it running. And Carl was never strong enough to tell them about fuel and its empty. And now, all those hurt puppy eyes. And Carl has those eyes himself, i bet. About GPL a different view: It is not about reziprocal. It is, i try a medical analogy: I can cure myself, go to an expert or give up all control. All can use all of the knowledge and technologie in the world, and consult any experts. I can veto everything. That is important to me. GPL is similar for programs. I like that. Especially as a communication-cyborg. :) About future: Rebol just got its first new contributor, a legal one. Maybe rebolers should look into the “friends and dinner” angle more. After all, rebol is a family thing ;) About license: AGPL3 with friends list. Make the openness a feature. Promise people they can work in the cloud, but download data and code and go somewhere else. Make sure it stays that way.
Arnold 20-Oct-2012 2:59:43	And the license is not needed for Apache projects using REBOL: It is for all of us. With Red and REBOL together we all have the most possibilities the most power, the best arguments to use the best of all computer languages ever, everywhere and to make a living doing so. And without the need of distribuing countless licenses please! (That would be imho worse than windows dll-hell). As mr. Rosen's proposal to steer us away from outdated licenses toward more modern ones, the way forward for REBOL may lie in a license from the future: the Unified REBOL License (the URL for short) that states Carl's wishes along with some other wishes from the community.
just saying... 20-Oct-2012 5:09:38	the way the discussion is going, if we have N people in the debate, we'll end up with N+1 licences proposed. and the debate will rage on until 2015... why don't you consolidate a list of all everybody's requirements and let Carl and Larry , analyse and have the final say of which license come close to those requirements ? this is what we do everyday in our IT job ? eh ? get requirements and do the analysis then come up with a solution ? which is part of any SDLC, that even a novice developer has to know. why with so many experienced IT guys in this debate, you can't do the same thing here ? instead of those futile, never ending ramblings that lead to nowhere except to more ramblings ... just saying.... stick to the basics or SDLC 101 ... that's why I've also learned in my after work, martial arts fights. Most of the matches are won on basic strikes or kicks or locks.
shadwolf 22-Oct-2012 5:47:58	(at) just saying...: N+1 licences proposed is not what I call a consensus. I don't know what else can be done the discussion is going to be endless and we know that when things tend to have a big time span Carl don't have time anymore to focus and participate on the endless debate. Yes someone kind enough to read the 700+ messages resume the opinions of every intervenants and post here the short version would be great. AS for me my opinion is I prefere a licence that allow rebol to be used widely aqnd difused if that means MIT/ BSD ok if that can be achieved by Apche licence 2.0 ok. For me the licence is just the first step what bother me more is what comes next to that first step. And the selected few overlooker is a strategy that already proven to be a failure.
-pekr- 22-Oct-2012 6:28:58	Shadwolf - I think, that the debate is eventually over. As you can see, no new posts appear, and ppl are imo mostly waiting for the final decision. Now we can start to eventually play a betting game. So my bet is Apache 2 :-)
Giuseppe Chillemi 22-Oct-2012 13:54:44	I think there is a wide consensus. Apache 2.0 Go for it !
John 22-Oct-2012 14:13:03	+1 on Apache 2.0
Arnold 22-Oct-2012 22:50:11	Debate is over :) Of all the N+1 opinions stated here, like in a good democracy, only that 1 vote really counts. I agree with Pekr if BSD/MIT is ok or if Apache is also ok that's ok with me. My bet is also on Apache 2 License, and FWIW My votes are Same license as Red: +10 otherwise Apache: +1
Ralph K 25-Oct-2012 11:16:17	The major goal is the continued development of REBOL. Those who use the technology ought to be required to at least contribute their improvements and developments, to satisfy the goal of continued development. To do otherwise might see a greater uptake of the technology, but without the benefit of development. Why sacrifice development for a (potential) increase in product acceptance? Isn't this, in short, a "rip"? The requirement of when any improvements/developments must be submitted, that is, the timing of the contribution, could be extended to provide some advantage to developers. This might be 6 months or a year perhaps, from the release of their product. Any license must include the principle of reciprocity.
Paullys 25-Oct-2012 12:52:09	You should now think about what rebol is, what does rebolish mean...That Will drive you to see thé truth of rebol: REBOL is not Only programming language, rebol is a way of programming even of thinking...to protect That you have to define a standard and see r2 or r3 and later red or topaze as implémentations of rebol standard...
Nicolas 25-Oct-2012 17:11:44	I don't have time to describe how I feel about rebol. All I will say is that what rebol desperately needs is some semblance of popularity. To that end I propose what I believe is the most popular license - MIT. Remember, the improvements we are so eager to differentiate from extensions will not come without new users. Only if the discussion is just about 100% positive on the programming language forums will there be an influx of new users. If there is a "yeah, but" in there then people will be inclined to think that rebol is still kind of proprietary and not worth the trouble. I know it may not be logical, but most people are not logical creatures. The click one way or another of a decision is made based on how you feel. And programmers who are interested in novel languages are a fickle bunch. That being said, after they go to rebol.com they should be met with a clean, simple, polished website that is mainly to download the exe. Send them to re-bol.com for a tutorial. I think it would also be very helpful to lower the difficulty of entrance into the community if we as a community started using web irc for chat and reddit.com/r/rebol for code submission because that way you can vote on the best code and it becomes easier to find. I believe we should optimize the growth of the community. It will grow the code base faster than legally enforcing reciprocation which turns away potential new contributors.
Bo 25-Oct-2012 22:42:10	I want Rebol to be popular if for no other reason than for Carl to get his "props" for his elegance in language design and architecture. (Incidentally, and off-topic, he is an excellent building architect as well.) Of course, if Rebol was popular and open source, then we should hopefully draw some other fine minds and language architects. I'd also like Carl to be able to benefit financially from his years of hard work. I currently enjoy the notoriety I get from my employees and clients when I crank out a new useful utility written in Rebol and delivered as a stand-alone executable sometimes in as little as 15 minutes from the time of conception to the time of delivery. Maybe when Rebol is more popular and it becomes commonplace to release utilities in a matter of minutes using Rebol, it won't be so special any more, but I guess I'll have to get over it. ;-) But these accomplishments are only possible due to the foundation that Carl has given us through Rebol. For instance, just the other day I wrote a utility that displays the surveillance cameras in our office via Rebol, and it seriously took me less than 15 minutes to write it, encap it and release it to my employees. Now none of them have any excuse to not know what is happening in other parts of the building. :-) One of these days I want to find some Java coder fanboys and challenge them to a programming duel. To keep this on-topic, I'm looking forward to Carl moving forward with the open source license choice, whatever it may be. For me, Rebol is more than a language, it's a lifestyle.
Nicolas 26-Oct-2012 1:27:09	Attracting New Contributors. 0. An unobjectionable open source license. The conversation about the open sourcing must not degrade into a discussion about the license. 1. a simple, polished website. Honestly, you just need a big download button and a couple of helpful links. http://www.lua.org/ http://golang.org/ 2. Nick Antonaccio's re-bol.com tutorial is very good. home page link. 3. rebol's quick download and installation is helpful :) 4. rebol one-liners 5. web irc chat - 10 second setup altme setup - ~1 day setup? This is serious. I couldn't tell someone how to get an altme pass by themselves at the moment. 6. reddit/r/rebol has a voting system which would help new users to easily find the most popular rebol code. :) I've uploaded a couple of examples. Rebol's pretty cool but it's not perceived that way. If it gets a good reputation and enough people start using community portals then it can hit a critical mass and Carl can reap the rewards of his labor. And so can we!
-pekr- 26-Oct-2012 7:16:25	Nicolas, 1) as a reboller you should know, that the count starts from 1, not from 0 :-) 2) Altme server install - quite opposite - it is just under one minute, including registering the world. I don't believe in your 10 sec web irc chat install any second, so yet - it is serious :-)
Maarten 26-Oct-2012 14:58:40	Apache 2.0, but more importantly.... I'd like to see the REBOL project as part of the ASF. So all the legal and project infrastructure is in place.
Carl Read 26-Oct-2012 17:38:52	AltME may be problematic as the official communication channel for an open source REBOL, given AltME is neither open source or written in R3. An open-source alternative written in R3 is what's needed. And with a mix of clients, starting with a Web-browser interface, followed by a REBOL client and then whatever else takes people's fancy. (Perhaps creating an API for it is all that's needed?) Something like this, allowing people to host worlds on their own sites, would be both useful and a good advert for REBOL. And the ability to have public worlds as well is a must. (For the advertising REBOL bit.)
Bo 26-Oct-2012 23:10:51	(at)Carl Read, nothing's stopping the community from making an open-source AltME clone right now. Especially if the framework is for a CGI version as R3 could be used in its present form. Even if it was started in R2 now, porting it to R3 later shouldn't be too hard. Anybody want to start a project and conversation regarding this on GitHub or somewhere else? It could keep some of us occupied while we wait for the licensing issue to shake out. Incidentally, there's tons of prep work the community could be doing to prepare for the release of the R3 source.
Henrik 27-Oct-2012 3:59:13	The OpenME project is already on Github, but nothing is happening right now: https://github.com/greggirwin/OpenME
Nicolas 27-Oct-2012 4:49:27	Maybe I should flesh out what I mean by unobjectionable. I mean that we should consider how the larger community will discuss the rebol open source news when it hits. If the license is somehow confusing or ambiguous then it will hurt adoption. If we're going to try and differentiate improvements from extensions then it must be really clear. Something like if you create a new datatype then it must be contributed. Really, my point is about marketing and how R3 is perceived. If it gets a good image then it will grow in popularity, but if there is something that creates doubts then it will languish.
Maxim Olivier-Adlhoch 27-Oct-2012 7:35:38	(at)Nicolas, people who don't want to share back their code will write horrendous code. People who intend to share back their code, cause they understand the philosophy behind it, will write clean and usually well tested code. I don't get the people who try to force others into sharing back. I don't want the code from people who aren't intending to help. Who cares about so called "free-riders"... Really, why this obsession with getting back because you've given? Open sourcing code is a selfish decision (in the good sense). You are allowing people to fix and report your bugs for you. You are allowing people to stop pestering you for changes and improvements which don't fit with your design. It allows you to fork and branch on projects you'd never have been considered before. You free yourself from a responsability and a role which becomes tedious after a few years. Its as good for the person who's giving, than for those who receive. This is the real value of open sourcing REBOL, I hope Carl (and all of you) see this. If there where a single person contributing back, that would already be an improvement on the status quo.
AdrianS 27-Oct-2012 10:13:04	WRT communnication, the chat system built into R3 is pretty nice, IMO. The CLI front end is not necessarily appreciated by all, but, personally, I think it's quite good for a CLI client. In any case, the idea was that various GUI clients could be developed for the back end. I would think this would minimize the effort needed to develop a next gen AltME.
Fraser 27-Oct-2012 12:13	Is there anything left holding the release up now after everything about the license has been said and discussed? Time passing by without any news or updates brings back bad memories for the REBOL community.
Carl Sassenrath 28-Oct-2012 20:07:05	Good discussion. The last two weeks of thinking this over have been helpful to me. The main result is that I came to realize that the reciprocity requirement isn't necessary, so GPL wouldn't be the right choice. Many thanks to Larry for his participation and perspective. I'll check-in with him via phone and get his feedback. Then, we'll get this wrapped up and the code released. So, we're good with Github right? I'll be posting more comments on: http://www.rebol.com/cgi-bin/blog.r?view=0513#comments
Ralph K 28-Oct-2012 23:26:36	On ya, and on on then! Time to leap forward. Viva!!
Nick 28-Oct-2012 23:51:57	A million thanks Carl - can't wait to see how this progresses!
Giuseppe Chillemi 29-Oct-2012 7:55:49	We will have soon a "REBOL3 Indepencence Day" to celebrate
onetom 29-Oct-2012 19:27:55	Git and github is terrible. Very much a bloated overkill which is quite against the spirit of Rebol. Git's command set and options are not orthogonal, not logical, hence hard to remember. Github is throwing another layer of NON-opensource "social" branching on top of the custom, built-in branching of git, instead of utilizing file system manipulation tools for branching, like http://darcs.net does... in case u don't like something about darcs, then fossil is probably the middle ground then. That fits the spirit of Rebol quite well, since it's small, self contained and even provides a web interface. From publicity standpoint github is better than anything else though because it's popular, like in the joke: let's eat s**t! 1000000000 flies can't be wrong...
Nicolas 30-Oct-2012 0:09:22	I'm happy you feel that way.
Arnold 30-Oct-2012 1:25:19	Agree with onetom. Github has developed a helping program on various platforms but it doesn't support for example MAcOSX10.5 (It is 10.6 and higher, let alone PPC). I would only get the source, preferrably from the rebol site anyway, for if I manage to grab it from github that is 'way' more trouble and there wouldn't be a chance in a million years I could merge any improvement back to the main or development repository. I am not a C programmer, so little chance I would be able to improve on the source but that aside, in that case I would only mail my improvements to the development team and let them figure out how to use or neglect it.
Andreas 30-Oct-2012 2:47:26	Thanks a lot for the update, Carl!
Luke 30-Oct-2012 3:27:55	Great news - I look forward to the next announcement :-)
Omei 30-Oct-2012 13:09:29	Some dont understand git ;) With git, everything is in one folder, and you can move and copy and zip that folder around without noticing git. No need for github-magic, if that really is a problem. Leave that to people who like history ;)
Arnold 30-Oct-2012 15:27:56	Develop a REBOL script to handle git, not specific github thats the proposed solution?
Brian Hawley 30-Oct-2012 16:53:45	Right, Arnold. Github doesn't require the Github client, it only requires git. For that matter, it doesn't even require git to just get the code, a regular web browser will do, even on OSX PPC. You don't even need a Github account. We can even have rebol.com link to a download right on Github. Don't downplay popularity though. It's more valuable that you imply.
Brian Hawley 30-Oct-2012 18:46:52	Sorry Arnold, it was onetom who was downplaying popularity. Whoops.
Fork 30-Oct-2012 19:24:52	I worked on a research DVCS for tree-structured data, a la semantic web. So I had a curiosity about the increasing popularity of the paradigm in the open source world, and followed progress on Monotone in particular. Linus considered Monotone as the closest possibility to use for the kernel...but then rejected it for performance reasons (and probably also because it was a "Modern C++" program, using boost etc., and he is not a fan of that.) The Monotone people looked at what Linus did and basically said "yes, that's where we started, but that was the naive approach and what we have now incorporates experiences with the failure of that simplicity." Point being: Git is not that complicated at all, and that's one of the reasons it is so fast. It's a filesystem of sorts...people have written clients for the format in other languages. If someone wrote a Git client in Rebol, that might raise some attention. I just ran du --total git* in /usr/bin and get 5 megabytes, it would blow people's minds to see an sub-1MB git implementation. Then when you tell them that the interpreter nested inside of that 1MB could do lots of other things...their eyeballs would fall out of their heads. Not so if you give them "RebVCS" which has no command compatibility and starts from scratch. Just look at the big deal being made about learning something new here...among self-proclaimed gurus... (!) I've used the phrase "apples-to-apples comparisons". And there are pretty much no cases where someone can download a turnkey Rebol solution that supersets the functionality provided by the thing it replaces. I'd like to do this...I scraped the Redis command descriptions and merged it with some extra information scraped out of the C source code, and translated everything into Rebol-ese: http://metaeducation.com/media/shared/reblis/reblis-commands.rebol But no one will look at anything I do like that until Rebol is open source, so, uh... ...can we Git this going?
onetom 31-Oct-2012 17:06:25	Just to make it clear: 1, i didn't try to downplay popularity; quite the opposite. popularity is the ONLY reason for git(hub). but its popularity doesn't come from its "high" quality, "ease" of use or "short" learning curve... 2, no doubt, git's underlying storage engine is quite smart and efficient, but the /usr/bin/git command line UI is a catastrophe. it waste a lot of time the same way as bloatware makes our life sour. 3, Fork: Reblis is beautiful! You were always a bit ahead of time, but please keep up the good work. I will be appreciated later in history. what is this metaeducation.com about, btw?
Fraser 1-Nov-2012 18:37:25	REBOL is such an ingenious and powerful language. Like many others I was really happy to hear that it's becoming open source. Open sourcing it will allow it to be used in many of my projects and I think I'm not alone with that. Its popularity and the number of available extensions, modules and libraries will surely increase fast. But the slow progress and long delay since the initial announcement to open source it on October 1st is REALLY frustrating.

Post a Comment:

You can post a comment here. Keep it on-topic.

Updated 9-Dec-2023   -   Copyright Carl Sassenrath   -   WWW.REBOL.COM   -   Edit   -   Blogger Source Code