Simple SSL/TLS - Some Questions

[Jerrold Leichter]

| From: Jill Ramonsky <Jill.Ramonsky at aculab.com>
|  > From: Ian Grigg [mailto:iang at systemics.com]
|  >
|  > The only question I wasn't quite sure of
|  > was whether, if I take your code, and modify it,
|  > can I distribute a binary only version, and keep
|  > the source changes proprietary?
|
| You can't distribute a binary only version of ANY crypto product,
| surely? No crypto product can EVER be trustworthy unless you can see the
| source code and verify that it has no back doors, and then compile it.
| Unless you give your users the power to inspect the source code, and
| /know/ that it is the source code (because they can actually compile it
| and run the resulting executable) then you could have put all sorts of
| back doors into it. You could have added password theft, key escrow, who
| knows what?
This sounds nice in principle, but if you follow that where it goes, you are
left with GPL - not even LGPL.  There's no way for a library to protect itself
against code it is linked with.  (Where's TOPS-20 when you need it....)  Even
if you let me completely rebuild the crypto library you've shipped with your
product, why should I trust it?

| Don't get me wrong. I agree with you that crypto has enough barriers
| already, and I would like to produce something that is as freely
| distributable as possible. "For the masses" crypto is, I guess, an
| unwritten design goal. But allowing people to hide the crypto source
| from crypto users would allow the bad guys (you can define your own bad
| guys) to produce Trojan Horse crypto. Closed source crypto is to all
| intents worthless. (In my opinion). Please feel free to argue that I'm
| wrong.
This is not really a soluable problem.  Going full GPL will render your project
useful for just about any commercial use.  Anything less leaves even someone
with the necessary skills, desire, and time in a position where they can't
say anything meaningful about the system in which the code is embedded.

|  > Q:  Does your employer  have any say or comment
|  > on this project?  Might be wise to clear up the
|  > posture, and either get it in writing, or make
|  > the repository public from the git-go.  Many an
|  > open source project has foundered when the boss
|  > discovered that it works...
|
| It has absolutely nothing whatsoever to do with my employer. All my code
| will be written at home in my spare time, and uploaded to CVS or
| whatever also from home. It is true that I happen to be sending this
| email from work, but even that's in my own time. I don't see how they
| have any say. To be /really/ safe,  I'd be happy to always post to this
| list only from home, but right now I don't think it's a problem.
Check your employment contract carefully.  Many contracts these days basically
say "if you invented/developed/wrote it while you worked for us, it's ours".
(Sometimes there are provisions like "if it's related to what we sell", but
when you look more closely, they will define "what we sell" so broadly - and
then add the ability to change their minds later anyway - that it doesn't
change anything.)

Lawsuits about this sort of stuff get ugly and *very* expensive.  Just because
your current employer is reasonable doesn't mean it won't be acquired by
someone who isn't.  Doing a bit of up-front checking is only prudent.

BTW, someone remarked in another issue that you could put of your choice of
license from among a variety of possibilities until later.  Well ... yes and
no.  Once something goes out the door under less restrictive terms, you can't
add restrictions later.  Let a copy go out with the phrase "released to the
public domain" and it's no longer yours - it's everyone's.  Let it out under
a BSD license, and you can't apply GPL terms later.  (You can apply stricter
terms to new versions, but if you try that, the resulting confusion will kill
any possibilities of broad acceptance:  You'll end up with a competition
between your restrictive versions and evolved versions of less-restrictive
ones that other people do because they aren't willing, or can't accept your
later restrictions.)
							-- Jerry

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com