> I think this is an opportune time for me to express that I think the > ability to close-source a module is important. I love open source, > and I couldn't imagine writing anything by myself that I wouldn't > share. But in order for Perl to be taken seriously as a commercial > client-side language, it must be possible to close the source. I > started writing a game with a few friends last year, and as we were > picking our implementation strategy, using Perl as the primary > "sequencing engine" for non-time-critical tasks was immediately > discounted when I commented that anybody can look at your perl source > if they want to.
I'd be interested in finding out how this is reasonably feasible for, given that you just said a disassembler for Parrot is going to be relatively simple due to the level of introspection Perl is going to require. Of course, given that Parrot is the ultimate interoperability swiss army knife, one could envision a language without the introspection Perl requires (such as C) that would target Parrot quite nicely. (Isn't Carrot the name for this push? I haven't kept up with the Parrot list.) Then, disassembling that bytecode back to its original form becomes much less desirable. > Of course, there is no argument there for allowing closed-source > *modules*, just complete applications. But I'm sure you could fish > one out involving dynamic loading, or modding, or whatever you want to > call it. The argument that was made was for closing modules, not applications. Specifically, a DB vendor might be more comfortable providing a DBD for their product(s) if they could close the source.
