Licensing policies (was Re: ANN: Docuverse DOM SDK PR2

[Tyler Baker]

John Cowan wrote:

> Peter Murray-Rust scripsit:
>
> > My sincere thanks for this change of policy. It can and will make an
> > enormous difference to many of us - otherwise we end up rewriting each
> > other's software. It is a courageous decision - as was IBM's - and should
> > be applauded.
>
> Indeed! Unfortunately, the license is still very restrictive, disallowing
> modification of the DOM SDK.
>
> > I now have no problem with this, and am
> > looking at the GPL for this purpose [comments would be much appreciated.] I
> > think the quid-pro-quo would be to ask people to register their use with
> > you and you may well benefit from this.
>
> I would urge Don and you to look at http://www.opensource.org/intro/free, which
> has information on why loosening restrictions can be beneficial for
> everyone.
>
> The Artistic License is a good substitute for the GPL and allows you
> to keep control of the named product while allowing others to create
> differently named variations.  See http://language.perl.com/misc/Artistic.html .

If you ever plan on making any money off of a product, never give it away for free.
If you are not planning on ever making money on a product, then it is of the most
benefit to essentially publish the source-code as is and let anyone do what they
want with it.  The only reasons I see for creating free software is either idealism,
enhancing your personal or company reputation in the developer community, or to kill
your up and coming competitors.

Not charging for a product initially, and then later on (when the competition has
subsided) charging for a product is about the same as marking down airline fares
below cost to kill of competition and then raising them later on to insane levels.

The worst way to lose face with other developers is to not be clear about your
long-term plans for a product.  Developers (at least the intelligent ones) will pay
for a superior product that cuts down the development time of their current project
so long as the licensing is clear and consistent over time.  Anything less is
pulling a fast one in my book...

The DOM SDK license is as restrictive as Docuverse wants to make it.  In the real
world there is no such thing as a free lunch so you should not expect Docuverse or
any other small ISV to be the angels of free software.

Even though I don't plan on using the DOM SDK myself anytime soon, I think it would
do the developer community more benefit in the long run if Docuverse were to charge
a fair price for a commercial license so there is incentive in the future for
Docuverse to do bug-fixes and updates and maybe even provide some level of support.

If you look at Netscape, they have basically capitulated on improving the web
browser (no incentive to improve it or add new features) and their future as a
profitable company is suspect.  They were a company that gave everything away for
free to kill off browser competition early on and then tried to charge for it when
the competition died off.  Then of course, Microsoft jumped in and did to Netscape
what Netscape did to everyone else.  In the end, the customers lose because from
this point on web browsers will likely have little innovation applied to them from
this point out.  In other words they will just plain suck.

For those people using the DOM SDK now and who enjoy the product, I would seriously
encourage these people to plea for Docuverse to charge something for a commercial
license, even if it is as low as $99 so that they can have some solace in the fact
that there will be future quality versions of the DOM SDK.  99$ is basically the
same cost as 3 development hours for the average engineer.  If 99$ is too much money
to spend on any commercial product, then your whole business plan for your product
needs some serious reevaluation.  Small ISV's like Docuverse should not feel
pressured to capitulate to the large ISV's like IBM or Microsoft who can afford to
give all their tools away for free in their efforts to squelch the up and coming.

If you look at the best XML tools to date you will find that they are not from the
big names that we know of, rather small guys who are dedicated to quality.  If we
all want quality tools to work with we will all need to put our money where our
mouth is one way or another.

My 2 cents...

Tyler


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)