[CALUG] What would YOU do?

[david l goodrich]

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. 

with all due respect, you probably don't operate under the same business
model as the linux/foss movement.

and linux/foss is /why/ calug exists.  you won't find a sympathetic
audience here.
  --david


> In our 
> business, 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.
> 
> Allowing access to our software by these competitors with blatantly open 
> scripts is unacceptable, at best.
> 
> 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".
> 
> 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. 
> 
> 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!  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.
> 
> 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.  :)
> 
> 
>                                                                                         
> -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
>>>
>>>
>>>
> 
>