From: Scot McSweeney-Roberts (newton_at_mcsweeney-roberts.co.uk)
Date: Fri Sep 10 2004 - 04:56:57 PDT
Jim Witte wrote:
>>I think one of the problems with the DCL is that it's not been released
>>under one of the "recognized" opensource licenses, but it's own
>>licence.
>>I think other developers are going to be more likely to use
>>it/contribute to it if it's license was a bit more standard (ie, either
>>under the GPL, LGPL or BSD license). I'm not even certain that the
>>
>>
> I'm not so sure. I don't remember what the KRL is and is not
>compatible with (haven't checked lately), but I seriously doubt that
>the lack of a "standard" license is going to stop a developer form
>working on the project. Now, you might be right when it comes to
>getting it on SorceForge or something - I don't know how many people
>scour projects to work on based on say BSD.
>
>
I suppose it depends on how you define the difference between working
"with" and working "on" a project - which can be a bit grey in open
source. I believe that being released under it's own license is
certainly going to be a hinderance to developers working "with" the
project ie, developers will be less likely to use the DCL in their own
projects as it is not obvious that the DCL can be legally used with
their GPL/LGPL/BSD/etc licensed code. As there will be fewer people
using the DCL, there are effectively fewer people working on the DCL, ie
all the developers who would have been using the DCL and in doing so
coming across bugs, fixing them and submitting patches (development that
could be classed as "working on" the DCL) aren't going to be there
because they are not comfortable with using the DCL in their own projects.
> Notice I didn't say, "a particular license is going to stop a
>developer" Because Paul has stated in the past, and I tend to agree
>with him in part, been averse to working with GPL, and certainly won't
>release under GPL unless he absolutely has to (meaning existing
>software project and can't get it relicensed) But I don't really know
>what I'm talking about here - he does.
>
>
>
Which is fair enough - if you don't agree with the terms of the GPL,
than you shouldn't license under it. However, when you go and do your
own thing, you shouldn't be disappointed that few people follow. When I
read that people were disappointed in the project as an experiment in
open source software I have to say that I'm not surprised, as the
developers really didn't follow most open source conventions. While an
OSI approved license and an area on sourceforge is a far cry from
garunteeing a successful project, it is at least is a way of welcoming
more developers to the project.
> You can read the thing at
>http://www.kallisys.org/reflexive/reflexive.html As far as I understand
>it (not having read it all *that* closely, meaning taking 20 minutes to
>do so without my brain on fast mode), it only really mandates that you
>document things internally in a clear and concise manner, give
>variables meaningful names
>
>
But I have to ask - what is this doing in a license agreement? I can
understand a maintainer not accepting patches that don't conform to a
project's coding standards, but putting such restrictions in the license
just gives one a feeling that the developers don't really want others
involved. I understand that there are good intentions behind it, but I
just find it very offputting.
Looking at the reflexive license again, I've come across other items
that just get in the way of people distributing the DCL (and therefore
people using the DCL)
3.8 *"DEVELOPMENT SYSTEM"* means a set of one or several software that
are required and can adequately create an EXECUTABLE from the SOURCE
CODE. In this License, there shall be, for each EXECUTABLE, several
independent DEVELOPMENT SYSTEMS that are functionally equivalent.
However, there may be only one if it's FREELY AVAILABLE or included in
the HOST SYSTEM.
4.3.4.5 A notice explaining step by step how to install the
EXECUTABLES if they need to be installed to be used. This notice can
refer to the documentation of the HOST SYSTEMS.
4.3.4.6 A notice indicating which version of the DEVELOPMENT SYSTEM
has been used to generate each EXECUTABLE.
4.3.4.7 For each EXECUTABLE, a notice explaining how to obtain the
corresponding DEVELOPMENT SYSTEM if there is only one or at least two of
them if there are more than one.
I would hate to be the maintainer of the rpm or deb of the DCL. A deb or
rpm makes 4.3.4.5 pointless - the instructions would be inside the
package, and if you don't know how to install a package you are probably
even less likely to know how to extract files from a package in order to
read the instructions. As for 4.3.4.6, do you just state which version
of gcc you used, or do you also include which version of make, which
version of glibc, even which version of the kernel? As everything on
Linux is so interdependent on everything else, you'd almost have to list
every library and executable installed on the build machine to truly
satisfy 4.3.4.6. As for 4.3.4.7, how do I satisfy that one? Just have a
notice that says "go to www.debian.org and download debian and install -
while installing be sure to install all the development packages"?
The KRL, to me at least, seems to go out of it's way to be burdensome
and offputting to those who are not directly involved in the project.
> Well, there *is* documentation. In the code - about 30-40% of it is
>doc.
>
> I think what would help is a set of example/'tutorial' projects. Say
>the following sequence (this is for MacOSX because that's what I use,
>but could be applied to any platform):
>
>
>
What I would want to see is a nice PDF containing the API and examples
of how to use it (ie, something a bit more elaborate than something
generated by doxygen). I don't want to go pouring through the source to
find out how to use the library from my own code. Few people go through
GTK's code to learn how to use it, and the same cane be said for
practically any other code library - the DCL is no different.
>>manner - it seems to be more orientated towards OS/X. Besides a
>>directory layout that screams of OS/Xness,
>>
>>
>
> Not exactly sure *what* that means, not being a UNIX geek myself
>(other than perhaps the fact that it's actually organized, and doesn't
>have a whole bunch of 3-4 character names - sorry, I don't like that
>part of legacy *NIX) Other than OS/X of course, where you can
>basically avoid being a UNIX geek as much as you like - although I
>prefer terminal CVS to MacCVSX..
>
>
>
I mean it has spaces and mixed case in directory names, which besides
being a bit of pain from the command line (not much of a pain, but still
some), does give the instant impression that it's not really meant for a
traditional *nix platform. While I understand that OS/X is the primary
development and target platform, the majority of open source programmers
out there are using traditional *nix platforms, and being so obviously
nontraditional can be offputting.
Scot
-- This is the NewtonTalk list - http://www.newtontalk.net/ for all inquiries Official Newton FAQ: http://www.chuma.org/newton/faq/ WikiWikiNewt for all kinds of articles: http://tools.unna.org/wikiwikinewt/
This archive was generated by hypermail 2.1.5 : Fri Sep 10 2004 - 06:30:01 PDT