[CALUG] What would YOU do?

[James Ewing Cottrell 3rd]

Jason C. Miller wrote:
> With all due respect, I can tell that you probably don't operate under 
> the same business models that we (my company and I) do.

As mentioned elsewhere, and previously by myself, you're not likely to 
get much sympathy from us. However, rather than drive you and your 
company towards more closed-source approaches, it may be worthwhile 
keeping this dialog open in order to find some middle ground.

> In our 
> business,

Don't be coy, state what your business is. Give us your company URL if 
you can.

 > ... it's about value-added software and often the need to deploy
> rapidly prototyped applications that are well in the infancy of their 
> life cycles.  Anyone who's ever gone head-to-head with another company 
> to win a contract based solely on your ability to out-innovate your 
> competition (and quickly) would understand that.

No quibble with that.

> Allowing access to our software by these competitors with blatantly open 
> scripts is unacceptable, at best.

This is the part that I don't understand. Why must your code, either 
binary or source, be visible or available to your competitors?

Your solutions and their should ideally be hosted on different 
computers. If that can't be done, your code should be stored under your 
home directory which is unreadable by your competitors and vice versa.

> I'm really going to try to avoid going into the ages-old rhetoric of 
> open and closed source software.  This is also hardly a contractual 
> issue.  I would love to see someone tell Microsoft...."Sure....beat 
> everyone to market with your innovations and make sure that you have a 
> great EULA to blanket your yet-to-be-secured source because that will 
> DEFINATELY keep any drooling competitors from being influenced by your 
> problem solving and coding methods".

Agreed, I think we all know the arguments.

> I'm just a grunt engineer.  I hate dealing with money and I hate dealing 
> with managment and contractual issues even more.  I simply wanted to ask 
> some seasoned geeks how they would go about protecting the privacy of 
> their work until their projects became a little more mature and secure.  
> I most certainly am not advocating closed source software or even the 
> proprietarization (is that a real word??) of any open source software.

One possible thing you could do is generate a sed script to run your 
perl code thru. It would simply replace all your variable names with 
names like "___o0_Oo_", rendering the source incomprehensible to humans.
Running thru the "fmt" program to densely pack the tokens (however, 
watch out for what it might do to string constants, you don't want 
newlines inserted) will also help.

> I mean, things like iptables/ipchains is open source, yet there are 
> probably plenty of people out there that wouldn't share their firewall 
> rules with ANYBODY because maybe they have a particular way of doing 
> things that they think brings value to them.  Same concept!

Yes, but a stupid one. One should be willing to publish their firewall 
rules in the newspaper For All To See. If they are Correct, well, No 
Harm Done, and if Incorrect, well, you will Find Out Quicker.

> There's 
> also openssh.  You can use that to secure everything but the kitchen 
> sink.  Just because you're securing your stuff doesn't mean you're 
> wanting to close-source everything.
> 
> My question is a technical one...pure and simple.  I've got some stuff 
> that I want to keep prying eyes away from. When I want good insight from 
> some good professionals on how to get things done, I typically come here 
> first (well...after Google).  I seriously doubt that telling a lawyer 
> "They stole lines from my script!!" is the solution to my problem.

Well, as we have been telling you, IT IS!

Do you remember when you were a kid and you heard the maxim that "when 
you cheat, you only cheat yourself?" That still applies.

The kind of company and people that resort to stealing other people's 
code will never be the ones with the technical savvy to write the best 
code in the first place!

Put another way, if you are good enoough to win on your own merits, it 
won't matter if your competitors copy what you do!

When you run a race, you don't look at your competitors; you look at the 
finish line!

Finally, if you have a warped send of humor, put a bunch of buggy code 
where people can snoop at it :)

> Anyway...for anyone out there who's interested.  I'm currently looking 
> at the Solaris 'crypt' utility.   Hopefully that'll bring me down some 
> good roads.  :)

IIRC, the sun crypt program just applies DES, a key, and a salt to the 
content. It has been broken, but it's probably good enough for your 
applications.

One problem that you are going to have is that of embedding the key into 
your programs and keeping the key hidden!

Your Turn.

JIM
> 
>                                                                                        
> -j
> 
> James Ewing Cottrell 3rd wrote:
> 
>> Don't confuse Ownership with Visibility. You can still write contracts 
>> and restrict usage and distribution even tho the source code is 
>> available. Your attempt to hide it only does the following: [1] delays 
>> your development time while you work out a solution [2] further delays 
>> your development while you debug the mess. [3] delays the finish 
>> product  while the finished product runs [4] pisses off your customers 
>> and everyone who hears about it because you are assuming that they 
>> will steal it if you don't hide it.
>>
>> Given that Linux is Open Source Software, you won't get much support 
>> here for what you are trying to do here.
>>
>> We understand that you wish to make money, retain ownership and 
>> rights. There is still a way to do that without closing your source. 
>> Take the High Road and Find the Middle Ground.
>>
>> JIM
>>
>> Jason C. Miller wrote:
>>
>>> I would like to get some advice from all the smart folks out there.
>>>
>>> I was tasked to create a non-trivial application in an unbelievably 
>>> unreasonable amount of time.  So, I basically just made a nice 
>>> front-end with a bunch of buttons (using Glade) and simply made 
>>> system() calls to external bash scripts for each button.  Not my 
>>> favorite way of doing business, but, gotta do what ya gotta do. 
>>> Anyhoo, I will be making incremental releases of this software and 
>>> will be filling in the gaps as I go along.  One problem is that it is 
>>> going to be a while before I have the time to implement all of the 
>>> button functions in C/C++. My question to everyone is this...
>>> For the sake of trying to keep code proprietary in the interim , does 
>>> anybody have any ideas as to how one could maintain the scripts in a 
>>> way that would make it difficult for someone else to understand the 
>>> logic that executes within them? As an example, I considered writing 
>>> the scripts in PERL and using perlcc to compile the scripts into 
>>> system binaries.  This would allow me to maintain the scripts for 
>>> development but deploy them as binaries for delivery. However, in the 
>>> past, I haven't been very pleased with the perl compiler and would be 
>>> happy to avoid it.
>>>
>>> I don't have a very extensive history in subversive development 
>>> practices, so I was hoping that someone out there might have some 
>>> ideas.  :)
>>>
>>>                                       -jason
>>>
>>>
>>>
> 
>