David Bovill wrote: > 1) Some people consider this stealing free code donated by other people > and then charging for it - like we do with the environment - and get all > irate.
If they can find a Rev user who already has a great-looking IDE to pay for the MC IDE which would also be freely available, I applaud their marketing skills and would like to hire them to sell ice to eskimos. > 2) Others take a pragmatic approach and look at which licence > stimulates the evolution of (their) public code most. > > 3) Others still take a competative approach and ask which license best > supports the evolution of (their) public code in the face of competition > with the commercial sector. > > The only consideration I suspect interests this list is 2) - which > approach stimulates the evolution of the IDE most. This is a long term > consideration as in the short term all we are doing is maintaining a > static IDE with a few tweaks here and there. > > That is the thing about evolution and open source change happens by > small incremental changes (save the odd Revolution :) which build on > each other to make a big difference. The importance of each change is > not noticed at the time. > > I feel that this is important to our community because while we have one > of the best tools on the market and probably the best user community, we > have a problem evolving the contributions we make. How many people out > there have been a little dissapointed after submitting a udeful > contribution and finding that they less than they hoped in terms of user > improvements? > > I feel we have a chance to start in a small way to create an environment > which addresses this with the MC IDE being made open source by Scott. I > agree with Richard that we should start by just maintaining the IDE, but > by learning from the open source community how best to do this, we are > more likely to avoid this project stagnating into nothing more than a > dead end archive, and give it a chance to evolve into something much > more interesting. Choosing the right license is a part of this. > > This just emphasises the importance of the choice (it is important even > though most users don't really give a fig :) The argument regarding the > choice between public domain (such as the MIT style open source > initiative OSI licence) and the lesser GPL (LGPL) licence is all about > which achieves this evolution most effectively. I'm really into simplicity and freedom. If the license is public domain (or MIT Public Domain, which may have an additional benefit of better ensuring the disclaimer is not removed from the work), then people can choose to contribute to the commnunity or not as they wish. Why force someone to share? That doesn't feel like sharing to me. And if that "enforced sharing" carries any possibility at all of affecting any commercial derivative work few of us could afford to use it. It may be the case that I'm completely underestimating the world-changing possibilities of the MC IDE. I've been seeing it as a maintenance and modest enhancement project not likely to ever be of interest more more than a few dozen people. RunRev has some great growth plans for Revolution, and their IDE is feature-rich and attractive. Even if they increase market share fpr the language we all love by a factor of 20 in the next year, most (if not all) of the new users will be using the Rev IDE. If there's an opportunity for an enhancement to any IDE that uses Transcript (the artist formerly known as MetaTalk), it would be a disservice to that enhancement and its potential audience not to have it also run in Rev in addition to MC. The MC IDE is a great tool and a valuable test bed for the engine. But the future of Transcript's market share (and really its present as well) is with Rev. Let's see what we can do to keep the MC IDE the nimble, efficient friend it's been to us for years. There's no need to limit any significant plans for Transcript-based tools to it; dual use seems optimal for all. > Some (more recently) argue that the very restrictions (cohersion) in > LGPL style licenses actually hinder the process by putting people off > (notably companies that have a problem with the inability to protect > their code improvements), others insist that without this the quality of > the public code deteriorates over time. There is no consensus on this > point - although I detect a slow shift in preference for public domain > style licenses in the open source community. > > I don't usually like long rants about licenses on public lists - so i > hope my 2 cents worth hasn't bored everyone, and i'd usually recommend > taking this sort of discussion off list into an interested subgroup > (reporting back) - but Richard bullied me into this :) No, I merely reminded you that when the members of this list were asked earlier if they felt such discussions should be here or elsewhere, there was a nearly-unanimous sentiment that they should be here. And I didn't bully; I begged. ;) -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge: Publish any database on any Web site ___________________________________________________________ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc _______________________________________________ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard