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

[Glen Low]

On 02/02/2005, at 4:42 AM, Paul Baxter wrote:

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

That's somewhat puzzling, my Mailman seems to have sent it out through 
my ISP SMTP as expected, so I have to chase this up with the ISP. The 
archives are going to be slightly out of date, since the main website 
where it resides is my web host's server and I archive and upload 
manually the mails -- eventually I will script this of course.

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

I should make it clearer, perhaps in a FAQ.

By default without paying the software is under the RPL. Clause 1.2 
says:

"Deploy" means to use, Serve, sublicense or distribute Licensed 
Software other than for Your internal Research and/or Personal Use, and 
includes without limitation, any and all internal use or distribution 
of Licensed Software within Your business or organization other than 
for Research and/or Personal Use, as well as direct or indirect 
sublicensing or distribution of Licensed Software by You to any third 
party in any form or manner.

Thus you are allowed to evaluate ("Research") macstl without it being 
considered a deployment and invoking the reciprocation clause. You have 
to draw a reasonable line in the sand between internal use e.g. if 
actual users are using beta or final versions of your software that 
#includes macstl in-house, vs. an evaluation situation e.g. the team 
hasn't decided yet to incorporate macstl and is just testing.

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

Hmm, I did have a 30 day eval period before, I have to check with my 
lawyer about whether that would conflict with RPL.

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

Unpacking the phrase "redistribution of proprietary object code", it 
means if you want to distribute code that #includes macstl but don't 
want reciprocate your own code, then it's proprietary, and requires you 
to pay the redistribution license fee. I can't prohibit the generation 
of object code since you have those rights at all times with the RPL -- 
one the finer points of open source rights that I learnt from 
license-discuss at opensource.org -- that all the OSI-certified 
licenses do not prohibit combining code, they just prohibit what can be 
done with combined code.

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

Yes, the library is currently tuned for SSE2. You can selectively 
disable support by not defining the appropriate macro: __MMX__, 
__SSE__, __SSE2__, __SSE3__ in the VS.NET project level -- the valarray 
library will then transparently scale back and use scalars for ops it 
cannot find, and the vec library will tell you what ops are undefined. 
For now, the trig support requires __SSE2__ because I couldn't get a 
decent argument reduction happening with the floats of __SSE__ -- on 
Altivec the fused multiply-adds have higher precision than SSE multiply 
then add -- so with SSE2 I had to argument reduce in double, then move 
back to float for the polynomial estimate.

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

OK, much appreciated!


Cheers, Glen Low


---
pixelglow software | simply brilliant stuff
www.pixelglow.com