I don't think I'm missing your point (at least I'm trying not to).
I'm just arguing that if having an extension point in a product in
which an end-user can write their own code separate of Apache (in our
case, retrieving the DB password, but really any extension point), in
which the end-uesr can incorporate encryption -- and thus require the
BIS/etc, then that opens a huge can of worms for a lot of projects
(like Ant). Even if you don't provide an extension point, the
end-user could always unpack the jar, write their own substitute class
(we provide the source to the classes as a good starting point), and
put together a new jar that plugs encryption into the framework.
I think I'm playing devil's advocate a bit on this one and it would
still be good to get an official ruling from legal. I'm not at all
opposed to that. However, we aren't providing any automatic hooks
into any export-controlled cryptographic software. If an end-user
wants to write their own code that does cryptography, it is up to them
to obtain that software and legal comply with its restrictions. It
isn't a ROT-13 question as much as our software is open and free and
the user can do what they want with it -- I've just made it a tad
easier to do something they might want and is perfectly legal. Just
my opinion.
Thanks,
/dev/mrg
On 2/22/07, Mike Kienenberger <mkienen..mail.com> wrote:
> Michael,
>
> You're still missing the point. It's not the ROT-13 that would cause
> us to have to register. It's an api that allows for plugging in
> arbitrary encryption. However, my suspicion is that we're exempt
> because our "encryption" only deals with authentication.
>
>
> On 2/22/07, Michael Gentry <blacknex..mail.com> wrote:
> > I certainly don't mind having this cleared by legal and it is a good discussion.
> >
> > I've had a bit more sleep and caffeine now and went over to
> > http://www.apache.org/dev/crypto.html and just read this bit:
> >
> > "The U.S. Government Department of Commerce, Bureau of Industry and
> > Security (BIS), has classified this software as Export Commodity
> > Control Number (ECCN) 5D002.C.1, which includes information security
> > software using or performing cryptographic functions with asymmetric
> > algorithms."
> >
> > ROT-13 and ROT-47 (the only ones we provide) are symmetrical
> > algorithms. To quote the Wikipedia (yeah, I know some people don't
> > feel it is definitive about anything):
> >
> > "An additional feature of the cipher is that it is symmetrical; that
> > is, to undo ROT13, the same algorithm is applied, so the same code can
> > be used for encoding and decoding. "
> >
> > This still feels like a non-issue to me, but worthy of discussion and
> > perhaps feedback from Apache legal. And if anyone really feels ROT-13
> > is secure, I know a 6-year old girl with a sheet of paper that can
> > hack their system. (She uses it to send "secret" messages to her
> > grandmother.) :-)
> >
> > Mike K. did raise an interesting point about if Cayenne Modeler starts
> > using Derby instead of HSQL, what does that mean for us? Would we
> > only need the BIS/etc if we run the preferences DB with encryption (I
> > can't imagine we would -- no reason to)?
> >
> > Thanks again!
> >
> > /dev/mrg
> >
> >
> > On 2/22/07, Mike Kienenberger <mkienen..mail.com> wrote:
> > > Jean,
> > >
> > > Thank you for looking into this. I guess at some point I should join
> > > legal-discuss, but I already feel I'm overloaded with apache mailing
> > > lists :-)
> > >
> > > On 2/22/07, Jean T. Anderson <jt..ristowhill.com> wrote:
> > > > Mike Kienenberger wrote:
> > > > > ... if we start providing derby as a component of
> > > > > cayenne, then we are subject to the export regs.
> > > >
> > > > I just posted a question to legal-discuss asking if an Apache product
> > > > includes any product listed at http://www.apache.org/licenses/exports/,
> > > > does it need to also do the BIS notification.
> > > >
> > > > -jean
> > > >
> > > >
> > >
> >
>
This archive was generated by hypermail 2.0.0 : Thu Feb 22 2007 - 11:18:53 EST