Proposed DanielMD License for Review.

[Jeffry Smith]

Daniel MD said:

>> > > > What i DON'T want, is to have 100 completely incompatible
>> > > > distributions that will retard the development and evolution of 
the
>> > > > code, and latter will lead to the hard task of standardization 
like in
>> > > > the case of the Linux OS undergoing right now
>> > > > (http://news.cnet.com/news/0-1003-200-6445478.html).
>> > >
>> > >See Sun's Java history WRT this point.
>> > >
>> > >It's been argued by many (self included) that the ability to fork 
code,
>> > >compatibly or otherwise, is a major benefit of the free software
>> > >process.
>> >
>> > Fork code is one of the worst things that happened to the BSD
>> > community in my opinion, and the efforts of the Free Standards Group,
>> > is the prove that sooner or latter standardization becomes a
>> > necessity, i wish to avoid that necessity, by providing standard ways
>> > of creating new processes.
>>
>>The argument here is that the GPL allows for two things:
>>
>>   - 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?

>
>>   - 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).

>
>>     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, 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).

>
>> > > > 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.
>
>> > > > 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.

jeff

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