Home Original page

Why so few Python jobs? (and licenses)

Alan Miller ajm at enteract.com
Tue Oct 9 13:58:35 EDT 2001 
Joshua Macy (l0819m0v0smfm001 at sneakemail.com) wrote:
>   Can you name a single time this [license problems with closed-
>source development in Python] has ever happened with something 
>included in the standard Python library? The Python Labs crew has, 
>according to what I've seen posted here, spent inordinate number of 
>hours and dollars trying to make sure that the Python license was both 
>acceptable to the FSF and permitted the development of closed-source 
>commercial products.  From where I sit this looks like (possibly 
>unintentional) anti-Python FUD--"ooh, better not use Python...don't know 
>if its libraries are properly licensed...beware! beware!"

I doubt that there have been any problems with Python itself (and the 
included libraries).  As the follow-on articles discuss, I'm much more 
concerned about licensing added functionality from third parties.

As an example, say I was developing a pretty-printer to reformat a data 
stream for printing, and one of the things I needed to generate was a 
PDF417 (2D) bar code.  Data in a PDF417 is scattered across the entire 
area of the barcode along with error-correction data and it's not a 
particularly trivial operation to actually generate said barcode (assume 
that all I need is the pattern, I can convert it to appropriate printer 
codes myself).

Further, assume that someone has developed and GPL'd code to take a data 
stream and actually generate the barcode pattern.  I might be impressed 
by their dedication to releasing code that will be so rarely used (at 
least legally), but I'd still go spend the $150-200 on a commercial 
package instead.  I'd perhaps take a little extra time to wrap my use of 
the package so if necessary I could replace it without affecting most of 
the program, but that's about it.

Why wouldn't I use the GPL'd code?  I'd have to spend time negotiating a 
license with someone who's likely never had to deal with the issue 
before, there's a decent chance that at least initially the price 
requested would be very high, I'll probably end up getting more 
functionality (e.g. additional barcode formats) from the commercial 
package that I can use in later projects or enhancements to the current 
product, and it's generally just probably not worth the trouble.  

Why do I think the price would be high?  Because the starting point 
would probably be "Well, I developed it and you get to pay for the 
development time."  Not the way it works - if I wanted to pay for the 
full cost or even a large part of the cost of developing a library to do 
this, I'd do it myself or hire someone to do it.

Quite frankly, that kind of pricing is a part of the reason we're not 
using Ghostscript for some PDF conversions (the other being that part of 
the functionality we needed is still in development).  Between the 
initial technology access fee and the quarterly minimum licensing fees 
for just one year we could buy Acrobat or another commercial package at 
full retail for every site we're likely to need PDF output at over the 
entire lifespan of our product.  In fairness the prices we got were 
nowhere near what it would cost to actually develop the functionality 
ourselves, but they were high enough to make it unsuitable for use with 
a low-volume product unless we wanted to sharply raise prices.

I'm sure there are a significant number of people and companies out 
there using GPL'd libraries or products such as Ghostscript in closed-
source limited-market software and not worrying about it because it's 
unlikely that they'll ever get caught, but for those of us who are 
actually conscientious about licenses it just means avoiding GPL'd code 
no matter how spiffy it might be.

What I'd love to see is available information for developers on 
licensing products outside the GPL as well, but it's not something I 
have the time or expertise to do myself and this message is already long 
enough.

ajm
More information about the Python-list mailing list