Re: Open Euphoria Licence
Al Getz wrote:
>
> Robert Craig wrote:
> >
> > No, I haven't decided on a license yet,
> > but thanks for all the posts. I'm learning
> > a lot. The work on preparing the open source
> > release is going pretty well. It might be
> > ready in a week or so.
> >
> > 1. Regarding a closed-source (possibly for profit)
> > person or group taking advantage of Public Domain source.
> >
> > The group could either grab pieces of the source
> > for some purpose, or grab the whole thing and make a competitor
> > to open source mainstream Euphoria.
> >
> > There aren't that many pieces that would be of much
> > general value once isolated/extracated from the rest
> > of the source. Maybe there are a few run-time library routines
> > that would have some small value by themselves.
> > More likely, someone would grab the whole source
> > and then add a few proprietary closed-source
> > features to it. They would then try to attract
> > Euphoria users over to their "improved", partially closed-source,
> > but compatible version of Euphoria. I believe they
> > would have a lot of trouble attracting more than
> > a handful of people. Most users would want to
> > stick with the mainstream fully open source version, supported by
> > RDS and many others. Users would be suspicious of
> > the partially closed source nature of the new version
> > of Euphoria. Will the closed-source code
> > disappear and be unsupported when the developers get bored?
> > Who wants to risk many long hours
> > developing a program that only runs on an obscure variant of a
> > programming language? If users were also required to pay anything
> > for the new version, that would pretty much kill the new version
> > right there. They could only be asked to pay for the value of the
> > closed-source feature itself, since all the other functionality
> > would be free to them if they stayed with the mainstream Euphoria.
> >
> > In time, open source developers would probably make their
> > own version of any successful, profit making feature. Meanwhile,
> > for a period of time, some Euphoria users might gain some
> > benefit from the closed-source version, and be glad that they
> > took the time to learn Euphoria. Is that so bad?
> >
> > So I think the threat from closed-source and/or for-profit
> > forks of Euphoria is pretty small. The bigger threat is from
> > multiple open-source forks, splitting the community into
> > small pieces.
> >
> > 2. There's one special reason I can think of for allowing
> > partially closed-source versions of Euphoria. It's
> > the binding/shrouding encryption feature. Now that I'm
> > taking it out, it would be useful to some people to
> > insert a bit of closed-source code in the IL writer (binder)
> > and IL reader (backend.exe) that will encrypt their IL
> > using their own encryption algorithm. Both routines are
> > written in Euphoria, so it's easy to modify them. This is actually
> > better than the old system where everybody depended on the
> > same algorithm never being broken. Since everyone used that algorithm,
> > there was a high value to breaking it. Now everyone (who cares) could
> > have his own algorithm. It's a safer system.
> >
> > Regards,
> > Rob Craig
> > Rapid Deployment Software
> > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
>
> Hello Rob,
>
> Really i couldnt have said it better myself 
> I'd just like to add one small but significant point...
>
> With everyone working on the 'public' version
> i think it will be very unlikely that any private version could
> become 'better' than the public one, meaning everyone everywhere
> will most likely want the public version anyway.
>
> On another topic..
> My only concern is what happens to the public version once person
> 'A' inserts bugs 1,2,3, and 4 and person 'B' doesnt like that idea,
> even though there is the appearance of more functionality.
> I've seen a trend where people like to stick stuff in their
> programs in order to increase apparent functionality only to
> also insert bugs because they were in too much of a hurry to
> get it in there. I'd like to see the 'public' version be as
> bug free as the past versions released were...no rushing to get
> features in there. If this cant happen i'll be forced to keep
> my own version as will others im sure.
>
>
> Al
>
> E boa sorte com sua programacao Euphoria!
>
>
> My bumper sticker: "I brake for LED's"
>
I also have to agree with what Rob said with all of thoes points. At the same
time however, I agree with what Al says to, as far as Bug infestation within Open
Source Code. I belive, a system would be needed in which is very similar to the
one Euphoria already endures, only with one significant point, being that there's
alot more turn around time on getting the bugs fixed, so that will shorten the
release times.
Something along the lines of this would be the appropriate way in which to
ensure that Bugs are properly handled.....
Versioning
As it stands now, Rob is using the Major and Minor Versions for releases of
Euphoria. Which is perfectly fine, except that when this goes open source,
there's going to be alot more people working on the interpreter, compared to just
one person. So the versioning system needs to be changed slightly.
The one I suggest, is Version Major, Version Minor, Patch Level and Source Code
State Tag. For an example, the first release of the Open EU Source code would be
versioned as: 3.0.0 Final. Then when people start making bug fixes, it would be
3.0.1 dev, etc, etc, when the bugs are fixed, and any new features are added,
it'd become 3.1.0 beta, and once all the code has been finalized, as being able
to work with minimal errors / bugs, it'd become 3.1.3 Final (Assuming that there
were 3 bug fixes that needed to be done.)
The next thing would be to keep up a Sub-Version or Common Versioning System, in
which to have Patch uploads, New Feature Uploads, and such, so that way, there's
a common space, in which the code can reside, there enters SourceForge for the
majority of that. This way, people can checkout the latest bleeding edge version
of Euphoria, to test on their system, and see what bugs they can find, or if
things are working pretty good. SourceForge also plays into that, with their Bug
Tracker System they have, that way, there's a centralized list of Bugs that have
been found, the procedures in which thoes bugs were found, and an Assignment area
for thoes working on the code, to say, Hey, I'll work on that. This way, you
don't have like 5 or 8 people working on the same problem at the same time,
though different input can always help.
Finally, a good check of everything by the Development Team, and Rob to ensure
that everything looks good, both on the table, and in the code, before the final
official release has been done. This saves alot of trouble with Open Source
Projects, to have a defined way of things to go, so that way, there's no
confusion.
Just my two cents...
Mario Steele
http://enchantedblade.trilake.net
Attaining World Dominiation, one byte at a time...
|
Not Categorized, Please Help
|
|
