Smalltalk deployment

Bijan Parsia bparsia at email.unc.edu
Mon Jul 23 15:58:36 UTC 2001


On Mon, 23 Jul 2001, Frank Lesser wrote:
[snip]
> **** I agree on it - I am not focussing on obfusc. as a important feature
> which
> needs to be implemented for Squeak - Squeak lives from its openess .
> I pointed out that in general for Smalltalk apps you give ** potentially **
> your sources away .
[snip]

There's two issues here, one technical, one socio-legal.

Technical side: Reverse engineering is always possible, it's only a matter
of effort.

Socio-legal: What happens when someone "sees" your source?

Just because it's moderately easier than C to decompile reasonably
obscured Smaltalk doesn't entail that you're "giving your source
away" (potentially) in the latter case (as opposed to the former case).

After all, copyright and patent protection are rather extensive.

Finally, there's a overarching issue (which Andrew raise) of whether
there's a business case for leaning heavily on the technical side
(actually, the Open Source movement asks whether there's a case for
abandoning the traditional way for the way folks manage the socio-legal
side; often there is).

Source *itself* isn't the worry, I take it. Rather *trade secrets* are
(ideas/processes/algorithms which, for a variety of reason aren't
patented). If they are easily discerned in the delievered code, that might
argue for legitimate exposure. Of course, one counter is NDA and other
restrictive licencing.

Where it *actually* makes clear sense to take such onerous measures, they
are sufficient. If you really don't want to take such measures *and yet*
you worry about disclousure and what some obscuring thingy to work that
technical magic on you're problem, it likely doesn't make sense to do
*them* either.

If all you *really* want is copy protection (i.e., protection against the
casual noodler) then mild technical solutions are reasonable.

Cheers,
Bijan Parsia.





More information about the Squeak-dev mailing list