Proposed DanielMD License for Review.

[Daniel MD]

First off, i would like to say i have given up this proposal, and i am 
going to adapt the MIT/BSD license.
This way i don't have to wait to get my license approved, and the good 
people at OSI have one less license that is very similar to others that 
already have been approved, on their backlog.

At 15:08 01-09-2001 -0400, you wrote:
> >>   - Forks can happen.
> >
> >I wish them not to happen in the case of ProgramX.
>
>Then it's not Open Source.  Sorry, but one of the fundamental aspects in
>Open Source is the ability to fork the code.  Otherwise, what do you do
>when the original developer / developer community disappears?

It's open source ! It's just not open source under the terms of the open 
source definition.
Well one solution would be to include a clause, of time limit, after 2 
years, the program gets licensed under the MIT license, or include a clause 
tat states, that the program can be sub-licensed with written permission.
There are several ways of circumventing this and get the licensed validated 
as open source.

> >>   - Forked variants are always compatible, from a licensing standpoint.
> >>     There's no inherent legal barrier to re-merging forked code.
> >
> >Maybe in theory, not in practice.
> >
> >>     The result is that forking in GPLd projects is rare, and
> >>     reconcilliation has been known to happen.  The Alan Cox (ac) Linux
> >>     kernel series is a persistant, but narrow, fork of Linus's own
> >>     development.  emacs/xemacs is probably the most significant
> >>     persistant fork.  Many window managers are forks of initial
> >>     development:  twm begat fvwm bgat fvwm2 begat WindowMaker, E, and a
> >>     slew of others.
> >
> >And this is why i don't use most Linux Distributions (RED HAT, SUSE,
> >etc...)you get 100 programs that do basically the same thing, almost
> >without a distinguishing feature, i consider this neither productive or
> >evolutionary positive.
>
>Some would argue it IS a good thing.  I personnally think the KDE/GNOME
>wars have resulted in two better projects.  Samba/Samba-TNG is another
>good split (very amicable on both sides, with sharing of code - they just
>have different goals).

KDE/GNOME have worked in two better project's ? Well i must say i disagree 
with you on this one.
Hum, your statement makes me wonder why, so many Admins and simple home 
users have been uninstalling Linux from their Offices and homes, and 
started installing BSD systems and Solaris systems.

> >>     Merges have occured.  The gcc/egcs fork was resolved in 1999,
> >>     probably one of the highest profile merges.
> >>
> >>     http://www.xent.com/pipermail/fork/2001-June/001093.html
> >>
> >>The conventional wisdom is that forks are expensive, free software
> >>builds on network (aka Metcalfe) effects, which grow with the square of
> >>the nodes, and profit motives are weak.  Hence, forks are rare, unless
> >>driven by compelling rationales:  divergent goals, project management
> >>frictions.  There's a substantial literature on this topic.
> >
> >As i said, a waste of time and resources, evolutionary counterproductive,
> >and results on mergers most of the times. With my license i wish to make
> >the evolution go forwards not sideways, witch is what forking creates. If
> >the features to be added are good, they will be added, the developers
>will
> >vote in a democratic way, in case of a 50-50 result, the feature will be
> >submitted to the original author and will be added if the vote is
>positive.
>
>And if that community disappears?  Now, NO progress happens, because the
>mandatory reporting community is GONE.  That's the problem with the
>"Mandatory notification" clauses - they make no allowance for the
>originators disapearing.

Again this can be solved with a clause, that is on my proposal.

>Again, multiple projects is NOT necessarily a bad thing.  Many companies
>actually do multiple projects for the same goal, as it's a way to test out
>different approaches.  Also, not every end-user operates the same way
>(example:  mh folders vs standard mail files.  I prefer the former, others
>prefer the latter.  Neither is right or wrong, just different).

I agree that multiple projects is not a bad thing.
They would just need written approval to create their project.
But i also know lots of company that went bankrupt because they had so many 
hype projects that they never finished none, and after the Internet stock 
market crashed, well lets just say, ebay saw it's listings increase in a 
abnormal way.

> >> > > > Resume: You can Hack the Code, and Create your Distribution, but
>First
> >> > > > you have to send a RFC to (the malling list ) with the hacked
>code,
> >> > > > so that (the development team ) has the opportunity to put it the
> >> > > > Official Distribution, if it's in the official distribution, there
> >> > > > will be no need to create more distributions, and Standardization
>will
> >> > > > not be a problem.  Resuming even more: Hack IT, Send IT For
>Comment,
> >> > > > Approved and Polished for standardization issues (included in the
> >> > > > Official Distribution), Not Approved (you can create your own
>Hacked
> >> > > > Distribution).
> >> > >
> >> > >I'd drop this whole concept.  Rather, explore the concepts of
>integrity
> >> > >and/or trademark management as espoused by Perl (Artistic License),
> >> > >the Apache Project (Apache License -- BSD derived), or the Linux
>kernel
> >> > >(GPL plus a trademark held by Linus Torvalds, managed by Linux
> >> > >International).
> >> >
> >> > But this is the same concept that lies under the linux kernel, apache
>and
> >> > MIT license. :-?
> >>
> >>It's a tacit, implied, concept.  There's no formal requirement for
> >>notification, there *is* some control over integrity-of-concept and use
> >>of marks.
> >
> >Control is distributed by the developers, you can do everything with the
> >mark we only require like in the case of Apache to ask us first.
>
>Actually, you can do whatever you want with the Apache code.  However, if
>you want to use the Apache trademark, you have to talk to them.  You
>should look at something like that.

The license scheme is basically the same, on my proposal since it is an 
adaptation of the Apache license.

> >> > > > I DON'T Think that software can be more free that THIS, without
> >> > > > compromising development evolution and standardization.
> >> > >
> >> > >Talk to Sun, and/or study the Java/SCSL debates.
> >> > >
> >> > >I suspect it's premature to start discussing specific language until
> >> > >you've clarified (internally and externally) your goals and their
> >> > >implications.
> >> >
> >> > Isn't that what i just did ? My goal Release Free Code, be able to
> >> > maintain a Official Distribution, and enable others to create their
> >> > distributions, but all with standard processes so that they are all
> >> > compatible.
> >>
> >>I don't think your issues are yet resolved.
> >
> >Could you create a list of things you think i have not been clear, it
>would
> >be of great help to me, and point me some solutions, i have read all the
> >OSI licenses, and none fits my needs they are either to restrictive or to
> >permissive.
> >
> >Have you understand my needs ? If not please let me know i will try to
>make
> >them more clear.
>
>Best bet is to use trademarks to control the original project, and
>encourage people to submit changes to you.

Thanks for the tip, but the problem has already been solved.

>jeff
>
>--
>license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3

Thank You for your time, Compliments, and Have a Nice Day...
Daniel MD [DanielMD at im-thinking.com] of IM-Thinking Consulting.
_______________________________________________________
Portugal [portugal.org], EU [europa.eu.int], [1 € = 200.482 Escudos] 

--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3