You're right, source hiding is the right term. RT, Webmin, and Bricolage are free software, though some charge for support. If (like us) you're marketing an enterprise-level product, and you invest a lot of time in enhancing it, then you will want some kind of source hiding.
We've developed our own encryption, but it's XS based and thus painful to port to different OSes and architectures (our customers often have no C compiler.) Does anyone know if there "a ByteLoader variant of pp" in the works somewhere? FYI, we have used a modified version of Filter::Decrypt, and are looking at Stunnix. ----------------------------- Mr. Lindsay Morris Lead Architect www.servergraph.com 512-482-6138 ext 105 > -----Original Message----- > From: Autrijus Tang [mailto:[EMAIL PROTECTED] > Sent: Friday, October 17, 2003 7:38 PM > To: Mr. Lindsay Morris > Cc: [EMAIL PROTECTED] > Subject: Source Hiding (was: Encyrpting Source) > > > On Fri, Oct 17, 2003 at 06:43:03PM -0400, Mr. Lindsay Morris wrote: > > You know why Java is more widely used (by sw development firms) > than Perl? > > (Even though it ... well ... I don't like it...) > > Because you can send your customers compiled code. > > Google for "Java decompiler". :-) > > While I do agree that a cross-platform bytecode is a neat thing to > have, it does not prevent anybody from reading your source code. > > > Maybe Perl 6 offers some help here, too - not sure. > > Perl6/Parrot does have such a bytecode-compiling facility now. > > In fact, Perl 5.8.1 also has a decent platform-specific bytecode > module, so if you are shipping pp-packed executables anyway, that > may be good enough. > > And yes, I agree that a B::Bytecode input filter for PAR/pp may > be very useful for some people. I have already mentioned it in > pp's documentation, that "a ByteLoader variant of pp is entirely > possible". > > > I believe that developers need this kind of control if Perl > > is to become usable for commercial quality code. > > Well, "more widely usable" maybe, but Perl is hardly non-usable today > in the business world. Bricolage, Webmin and RT are all good examples > of "commercial-quality" perl systems. > > > (Maybe that's anathema to the open-source community. > > I'm not trying to be flame-bait here, but encryption > > would sure help us a LOT.) > > I think it will also help us, if we can make a distinction between > "source hiding" (or "source obfuscation") and "source encryption". > > The term "source encryption" is ambiguous: it may also mean > cryptographical encryption, where the user has to enter a passphrase > to run or see the data; it may also simply mean "converting plain text > into code". Since it is not always easy to tell which meaning is > intended, I'd be grateful if we can use "source hiding" on PAR-related > discussions. > > Thanks, > /Autrijus/ >
