[macstl-dev] Re: macstl 0.2 is finally here! whew...

[Paul Baxter]

Glen,

In amongst the 101 other things you've got to do right now, I notice the new 
mailing list might not be working... Neither my message or your reply appear 
on the list, and I didn't receive your reply via the mailing list (just 
direct from you). Mind you the mailman interface only shows January 2005.

On a separate tack: Given the new licensing, how should/could a company 
evaluate MacSTL prior to purchase? e.g. benchmark using their own algorithms 
against say Blitz++/BLAS/uBlas/another for business purposes (including 
sharing the source code/object code amongst the team who write the tests?)

I'm not trying to get a free lunch here, I am hoping to purchase this if it 
proves its worth (as well as a commercial license for FFTW which costs even 
more). I just wonder whether paying $499 for a corporate version to run some 
tests at work for evaluation might be counter-productive to the uptake of 
your library where an organisation cannot reciprocate some of the test code 
being evaluated. This is exactly the situation I'm currently facing (though 
it is possible that I've misunderstood your proposed licensing as I'm no 
lawyer)

Any plans for a 30 day evaluation period after which object/source etc must 
be destroyed? (I think that was the jist of the previous evaluation 
licensing wasn't it - my memory's going so apologies if I'm 
mis-remembering).

The other thing I found surprising is that you refer to the redistribution 
of 'proprietary object code'. Given that your library provides source code 
and my compiler provides the object code, I thought you would need to 
prohibit the generation of object code for the purposes of redistribution 
(etc). Its probably a fine and rather stupid point, but your comments 
appreciated.

PS
The benchmark tests for windows compile OK but throw unhandled exceptions 
when run. I haven't had time to chase this yet (10 hrs at work + a kid is 
limiting my spare 'fun' time right now :) ) but I'm doing this at home on my 
Athlon XP which is lacking SSE2/3.

I'm not expecting any support, but it might be useful as a FAQ. I'll post 
something when I find out why.

Paul

----- Original Message ----- 
From: "Glen Low" <glen.low at pixelglow.com>
To: "Paul Baxter" <pauljbaxter at hotmail.com>
Cc: <macstl-dev at pixelglow.com>
Sent: Tuesday, February 01, 2005 12:27 AM
Subject: Re: [macstl-dev] Re: macstl 0.2 is finally here! whew...


> On 01/02/2005, at 7:11 AM, Paul Baxter wrote:
>
>> Glen,
>>
>> I want to congratulate you on your work. Its been evident from your posts 
>> on the altivec list that you love this stuff and are very good with it.
>>
>
> Thanks!
>
>> Any chance of outlining future plans for MacSTL beyond the yellow, 
>> red/green blocks in vec-common-interface? It may help those of us 
>> considering the redistributable license. Its quite a commitment 
>> (particularly if just wanting to use this on Intel/AMD) without knowing a 
>> very broad outline of what is going to be added over the course of the 
>> next year. $499 for rights to use in my commercial code was fine as a 
>> disposable 'try it out' price, $2499 was a bit of a surprise. (though I 
>> understand the need to eat as well :-)
>
> I think it's reasonable. JoelOnSoftware thinks software should either be 
> less than $1,000 or more than $75,000, so perhaps this is in the middle of 
> the field. Then again, given that macstl is by nature and intent 
> open-source, I doubt I could sell a proprietary version for $75,000 :-). 
> However VAST, an autovectorizer for Altivec sells for $3,000 for embedded 
> systems.
>
> Also it's a bit to do with the size of the market. Eric Raymond of CATB / 
> OSI fame thinks 80% of the software written is in-house vs. shrink-wrapped 
> packaging, so it makes sense that the redistributable price is 4x to 5x 
> the in-house price.
>
>> I've seen the coloured feature boxes, but it doesn't make clear whether 
>> for instance you may devote more effort to bringing the x86 platform 
>> intrinsics onto a par with the altivec ones. For instance I am interested 
>> in implementation of complex numbers of the x86 platform and despite my 
>> realisation the 'Mac'STL may never truly be as well supported on x86 as 
>> on the PowerPC, I would be interested to know your take on things.
>
> I hope to tackle the low-lying fruit first -- multiplies, divides and some 
> trig functions, and then complex numbers, all of which can be easily 
> ported over from the Altivec side. Help is always welcome!
>
> Or particular development could be sponsored -- that's how the complex 
> number arithmetic on Altivec came to be, it was sponsored. (SSE3 
> intrinsics would help in this regard.)
>>
>> On a separate note, perhaps you could explain if your code might be used 
>> with something like GPL'ed code. Is your open source code amenable to 
>> being published within a GPL'd context (given GPL's 'viral' nature) or is 
>> it limited to open source that only supports your reciprocal license?
>>
>
> I had this discussion with the RPL writers (Technical Pursuit) and raised 
> it with license-discuss at opensource.org and also briefly with the FSF. The 
> main opinion seems to be that RPL is incompatible with GPL. On the other 
> hand I'm pretty amenable to making some exceptions a la the MySQL folk, 
> but it's hard for me to figure out how to maintain the "extra" virality of 
> RPL when it's combined with GPL -- e.g. if I explicitly allow RPL to be 
> combined with a particular piece of GPL, can I maintain that the whole 
> must be reciprocated even if it is in-house? Would this be a violation of 
> GPL (no extra restrictions allowed)?
>
>
>
> Cheers, Glen Low
>
>
> ---
> pixelglow software | simply brilliant stuff
> www.pixelglow.com
>
>