[CALUG] What would YOU do?

[James Ewing Cottrell 3rd]

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