Off-Topic: Releasing source code

On Aug 10, 8:27&#4294967295;am, Rune Allnor <all...@tele.ntnu.no> wrote:

  ...

> 2 releasing source code implies support

I don't agree. Whenever I have bought proprietary code with an
arrangement for support, I was always able to arrange that the source
code be delivered (sometimes with a non-disclosure agreement) in case
support was discontinued.

> Whatever you do, make sure to get &#4294967295; clear contract.

It is also good to specify what the remedy will be in the event of
default.

Jerry
--
Engineering is the art of making what you want from things you can
get.

> robert bristow-johnson wrote:
>
>> On 8/9/11 10:50 PM, Peter wrote:
>>
>>> A client asked me to create some software (more like a module) which
>>> could be plugged in to their system.
>>>
>>> They stated that they didn't care about language or platform.
>>>
>>> So I told them that I would compile it for Windows and deliver an
>>> executable.
>>>
>>> I delivered the product and got paid.
>>>
>>> Now they want it for Linux and they also want the source code.
>>>
>>> How would you react to that?
>>>
>>
>> i guess i would negotiate a deal for whatever i think the source code
>> is worth.
>>
>> personally, *every* project i have ever done for anyone (employer or
>> contract), my work product was either source code or a document of a
>> procedure (math equations and step-by-step description). sometimes
>> (nearly all of the time) the deal was non-exclusive, which meant i was
>> free to use the same source code with another client. one client, who
>> had a problem with that, asked me to not ever sell such non-exclusive
>> code to a particular competitor of theirs and i agreed and it's in the
>> contract (as old as it is).

On 8/10/11 11:08 AM, Vladimir Vassilevsky wrote:
 >
 >
>
> It is stupid to set the clauses that could not be enforced.

i cannot agree less...

> The more
> bullshit is involved in the contract, the less the parties are
> interested in getting the actual job done.

and i cannot agree more.

regarding point 1, sometimes one finds oneself in an industry that is 
small, where virtually everybody knows virtually everybody else.  people 
can find out if you told Party A that they have "exclusive" use and 
you've sent (for more money) virtually the same code to Party B.  you 
might want to work for Party A again.  you might develop a reputation of 
"not entirely honest" in your dealings with people.

only in the Lawyer-Nation (a.k.a. the U.S.) would it seem plausible to 
weave into contracts all manner of enforceability.  how would Party A 
get to enforce that i didn't also sell the code to their competitor?

it's not stupid to make sure everyone is on the same page about what the 
scope of the work is, who is getting the work product, and what 
technology can by retained by the contractor for their future work. 
this is why i make it clear that what they are getting is 
*non*-exclusive.  but if they ask me not to do this for some *specific* 
competitor, and if i know that i haven't worked for that competitor, do 
not know anyone in the competitor's company, and do not expect to ever 
do any work for that competitor, and especially if i can squeeze a few 
more dollars out of the client for such a promise, i will respond 
positively to such a request and will even put it into the "contract" 
such as it is.  (like the OP, lately most things i've done have email 
"contracts".)

about point 2, i am quite allergic to bullshit and other forms of shit 
in agreements i make that i am expected to hold to.  i make clear what 
it is that i will supply (or try to, if it's something so novel that i 
am not sure about it), what and when i get paid for it.  and issues of 
non-disclosure and exclusivity.  that stuff should be clear, but i will 
admit, i have signed and faxed somebody's icky "NDA" or standard 
agreement for external contracts unless i was able to decode *something* 
in the agreement that was onerous (like an unrealistic exclusivity: i 
will *not* preclude myself from designing some IIR filter for future 
client, so if this is part of what i'm doing for this company that 
demands exclusivity, we will have a problem in the agreement).


-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."

On Aug 9, 10:50&#4294967295;pm, "Peter" <pe...@xyzinvalid.com> wrote:
> A client asked me to create some software (more like a module) which could
> be plugged in to their system.
>
> They stated that they didn't care about language or platform.
>
> So I told them that I would compile it for Windows and deliver an
> executable.
>
> I delivered the product and got paid.
>
> Now they want it for Linux and they also want the source code.
>
> How would you react to that?

Giving/Selling them the source code is separate from what they are
then allowed to do with that source code. These terms and conditions
would need to be sorted out. Can they resell it to someone else? Who
owns the copyright?

You may also want to think about licensing? How many copies of your
code will be out there in the wild? In some cases companies want the
source - especially from small companies - in case you go out of
business. Then they can't really come to you for support. If they have
the source they could at least farm it out to someone else. Granted it
would take some effort but at least it is an option for them.

So a lot of this depends on context. Hope that helps.
David

On 8/10/11 11:23 AM, Jerry Avins wrote:
> On Aug 10, 8:27 am, Rune Allnor<all...@tele.ntnu.no>  wrote:
>
>    ...
>
>> 2 releasing source code implies support
>
> I don't agree. Whenever I have bought proprietary code with an
> arrangement for support, I was always able to arrange that the source
> code be delivered (sometimes with a non-disclosure agreement) in case
> support was discontinued.
>

i'm with Jerry.  a long time ago, when i was working for someone else 
and we happened to contract with a third party who is much bigger, it 
was when we supplied either linkable files or (in one case) a few text 
files with relocatable machine code in hex (and well defined entry 
points) is when we needed to support them much more than sending them 
source (which would have been easier, but the boss didn't want to give 
away any of the company's secret sauce - they ended up disassembling the 
machine code anyway, so they had some kinda uncommented source anyway).

>> Whatever you do, make sure to get &#4294967295; clear contract.
>
> It is also good to specify what the remedy will be in the event of
> default.

yah, and getting a lawyer to enforce it is like getting a lawyer to get 
my insurance company to pay a legit claim.


-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."

On Tue, 09 Aug 2011 22:50:31 -0400, Peter wrote:

> A client asked me to create some software (more like a module) which
> could be plugged in to their system.
> 
> They stated that they didn't care about language or platform.
> 
> So I told them that I would compile it for Windows and deliver an
> executable.
> 
> I delivered the product and got paid.
> 
> Now they want it for Linux and they also want the source code.
> 
> How would you react to that?

I would decide on what I considered to be a fair price, and I'd suggest 
that I charge that much.  Then I'd see how they respond.

Contracts are good things -- email conversations are much more difficult 
to point to and say "this is what we agreed upon".  Contracts tend to 
focus the mind, and make one (or one's customers) say "this is really 
what we want" or "is this really what we want?"  They don't have to be 
fancy.

So -- figure out how long it'll take you to make it work on Linux, figure 
out how much you need to be paid for the source code to be happy (I would 
have delivered the source with the executable regardless, but that's me), 
and name your price (or better, name your _estimate_ and charge by the 
hour -- that way, when they want "one little thing" added you can say 
"sure thing!, it'll be xxx hours" and proceed).  If you're just not a 
Linux person, say so and offer to sell the source code (or just give it 
to them) and give them an hourly rate for supporting whatever Linux 
person they find to do the work.

-- 
www.wescottdesign.com

On 8/9/2011 7:50 PM, Peter wrote:
> A client asked me to create some software (more like a module) which
> could be plugged in to their system.
>
> They stated that they didn't care about language or platform.
>
> So I told them that I would compile it for Windows and deliver an
> executable.
>
> I delivered the product and got paid.
>
> Now they want it for Linux and they also want the source code.
>
> How would you react to that?
>
>

First off: any way I please as you've suggested that the original job is 
over.

This is now a new job, right?

You act in your own best interest which may nicely coincide with the 
customer's interests.  I have no way of knowing.  You know best.

That there may be details and guidance about *how* to do it is beyond 
what you've asked or, at least, would be a huge extrapolation.

I sense there's more to this than you've told us.

Fred

On Aug 9, 10:50&#4294967295;pm, "Peter" <pe...@xyzinvalid.com> wrote:
> A client asked me to create some software (more like a module) which could
> be plugged in to their system.
>
> They stated that they didn't care about language or platform.
>
> So I told them that I would compile it for Windows and deliver an
> executable.
>
> I delivered the product and got paid.
>
> Now they want it for Linux and they also want the source code.
>
> How would you react to that?

In the US, the answer is pretty simple. You did "work for hire." That
means they own it once they pay for it unless your contract exempted
this out. Now if your agreement was only for executable code and you
have delivered this, then you are pretty much done from a legal
standpoint unless they can claim you were an employee instead of a
contractor.  This supreme court case lays out the differences:
http://supreme.justia.com/us/490/730/

 But beyond the legal issue, is do you want more work from them in
which case some simple negotiating can get you some more money and not
leave them with a bad taste in their mouth. Also how valueable is
keeping the source code? Can you sell it elsewhere? If not, then
giving it to them may buy you future work.

My 2 cents worth.

Clay

robert bristow-johnson <rbj@audioimagination.com> wrote:

(snip)
> regarding point 1, sometimes one finds oneself in an industry that is 
> small, where virtually everybody knows virtually everybody else.  people 
> can find out if you told Party A that they have "exclusive" use and 
> you've sent (for more money) virtually the same code to Party B.  you 
> might want to work for Party A again.  you might develop a reputation of 
> "not entirely honest" in your dealings with people.

> only in the Lawyer-Nation (a.k.a. the U.S.) would it seem plausible to 
> weave into contracts all manner of enforceability.  how would Party A 
> get to enforce that i didn't also sell the code to their competitor?

Well, it isn't so hard, but harder to restrict resale by those
you sell to.  The competitor could find someone else to buy it,
avoiding the restriction, then buy from that company/person.

For hardware, (and I suppose also software) you should always assume
your competitor has access to the device/system.

-- glen

On 8/10/11 3:12 PM, glen herrmannsfeldt wrote:
> robert bristow-johnson<rbj@audioimagination.com>  wrote:
>
> (snip)
>> regarding point 1, sometimes one finds oneself in an industry that is
>> small, where virtually everybody knows virtually everybody else.  people
>> can find out if you told Party A that they have "exclusive" use and
>> you've sent (for more money) virtually the same code to Party B.  you
>> might want to work for Party A again.  you might develop a reputation of
>> "not entirely honest" in your dealings with people.
>
>> only in the Lawyer-Nation (a.k.a. the U.S.) would it seem plausible to
>> weave into contracts all manner of enforceability.  how would Party A
>> get to enforce that i didn't also sell the code to their competitor?
>
> Well, it isn't so hard, but harder to restrict resale by those
> you sell to.  The competitor could find someone else to buy it,
> avoiding the restriction, then buy from that company/person.

that affirms my point, no?  i was meaning that Party A is the company 
that is your client.  i do not see how they could easily enforce against 
*you*, the contractor, that you may have transferred technology that you 
created, but assigned to Party A (or some lessor measure of 
exclusivity), to a competitor when it is possible (below) that this 
competitor could obtain it by other means.

but it's good to put in the agreement or contract *anyway*, at least so 
that everybody knows what the deal is, and cannot claim ignorance or 
license to do something that sorta betrays this party who is paying you 
money.

so, if a contractor *did* discretely violate a promise of exclusivity 
(even one specifically targeted toward one or two competitors), 
especially in a small industry, some engineer or exec or other 
contractor in that competitor's company might later end up in the 
client's company and would know both ends of the nefarious deal.  kinda 
like both girlfriends discovering you're two-timing them.

but, if a 4th-party, not in the same industry, buys code from you and 
you have a use-as-you-please-indefinitely-but-do-not-transfer deal and 
*they* nefariously sell to the precluded competitor, that is not the 
contractor's problem.

> For hardware, (and I suppose also software) you should always assume
> your competitor has access to the device/system.

sure, reverse-engineering is doable both in hardware or software but, 
depending on the degree of integration, could be difficult and expensive 
to do.  (i wonder, are there algs now where they take a micro-photo of 
the IC chip and do something comparable to OCR and "disassemble" that 
image to get verilog or firmware code?)  and there is no problem with 
popping off a flash ROM and, if you know the processor, decoding that 
from the reset vector.  that's always doable (but generally not 
particularly easy).

-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."

robert bristow-johnson <rbj@audioimagination.com> wrote:

(snip, I wrote)
>> For hardware, (and I suppose also software) you should always assume
>> your competitor has access to the device/system.

> sure, reverse-engineering is doable both in hardware or software but, 
> depending on the degree of integration, could be difficult and expensive 
> to do.  (i wonder, are there algs now where they take a micro-photo of 
> the IC chip and do something comparable to OCR and "disassemble" that 
> image to get verilog or firmware code?)  

You can get the mask image for ASICs.  There were stories in days
long past of the Russians building an 8080 clone that way, though
a little larger (and slower).  The intel copyright symbol still there!
At least that is the way I heard it.

But HDL code is a different question.  Going from FPGA bitstream
to netlist should be possible.  To verilog, that is human readable,
much more work.  About the difference between disassembly and
decompilation (to a high-level language) for software.  In
any case, you don't get commments or descriptive symbolic names.

Now, many companies have firmware on the web site for download.
Maybe with an agreement where you promise not to disassemble it,
but one could always go out of the country where the laws are
different.

> and there is no problem with 
> popping off a flash ROM and, if you know the processor, decoding that 
> from the reset vector.  that's always doable (but generally not 
> particularly easy).

It seems to me that versions are changing so fast, and the old
outdated so fast, that doesn't help in many cases.  Well, if you
allow for downloaded firmware maybe.  

Then again, there is the story about the Chinese clone iPhone
that, unlike the Apple version, allows for two SIM cards.

-- glen