You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by "Geir Magnusson Jr." <ge...@apache.org> on 2005/08/30 13:18:53 UTC
IDEA block cipher inclusion via the "bouncy castle" JCE provider
In Apache Geronino and dependencies like OpenEJB, (and probably other
projects at the ASF...) we are using an external project known as
'bouncycastle' (http://www.bouncycastle.org/) , a fairly well known
implementation of crypto-related stuff in Java.
Inside the distro jar from bouncycastle is an implementation of the
IDEA algorithm. This algorithm is patented, and the patent holder,
MediaCrypt, requires licenses for all implementations of IDEA, and
there's no unfettered use - even non-commercial distribution requires
some kind of correspondence with MediaCrypt.
http://www.mediacrypt.com/
You have to find the license section...
So, here's the problem - I don't believe either Geronimo or OpenEJB
is using the algorithm explicitly but I can't be sure that it isn't
invoked somewhere, and statements from the MediaCrypt site such as
"Requests by freeware developers to obtain a royalty-free license to
spread an application program containing the algorithm not for
commercial purposes must be directed to MediaCrypt"
make me believe that we have to do something to redistribute this
software.
(I can't help noting how the infinitive "to spread" makes the GPL's
language on "distribution" look clear.. :)
Of course, there are other terms for commercial users.
So, what should we do?
It may be the case that we need to get a license to redistribute the
bouncycastle jar (from MediaCrypt). If this is the case, I suspect
that we're hosed, as we wouldn't distribute something that requires
our users who wish to redistribute our software to go get a license
from someone.
If not, we can provide a warning to our users that our software
includes the IDEA algorithm which is encumbered, but at this time, I
can't guarantee that it won't be invoked somehow.
Another approach would be to petition bouncycastle.org to provide a
distribution of the software w/o the algorithm included.
I've crossposted to the geroninmo dev list for this post - please
remove to keep discussion on the legal-discuss - interested people
can come view it here.
geir
--
Geir Magnusson Jr +1-203-665-6437
geir@apache.org
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: IDEA block cipher inclusion via the "bouncy castle" JCE provider
Posted by Brett Porter <br...@apache.org>.
Geir Magnusson Jr. wrote:
> It may be the case that we need to get a license to redistribute the
> bouncycastle jar (from MediaCrypt). If this is the case, I suspect
> that we're hosed, as we wouldn't distribute something that requires
> our users who wish to redistribute our software to go get a license
> from someone.
I agree
>
> If not, we can provide a warning to our users that our software
> includes the IDEA algorithm which is encumbered, but at this time, I
> can't guarantee that it won't be invoked somehow.
Given the discussions surrounding LGPL I also don't think this will be
generally accepted.
However (also, see link below) - it is a bit different because although
it interacts with the JCE in a similar way we're talking about code not
used here. If we guarantee it is never used in Geronimo (or other), does
that make it ok? What happens if the user takes that library out of
*our* distribution and uses it elsewhere? I suspect this isn't a
problem, but I never really know.
>
> Another approach would be to petition bouncycastle.org to provide a
> distribution of the software w/o the algorithm included.
Yep, definitely the way forward. You may already have the answer:
http://www.bouncycastle.org/devmailarchive/msg05065.html
This gives a decent background on both the distribution and the
licensing. Searching for "IDEA patent" on their list archives turned up
other helpful responses.
So at the least, I guess we can repackage it ourselves, though it would
be good to ask for an official one.
Interested to hear how this progresses as we're still considering using
BC for openpgp over at commons.
Cheers,
Brett
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: IDEA block cipher inclusion via the "bouncy castle" JCE provider
Posted by Rick McGuire <ri...@gmail.com>.
Geir Magnusson Jr. wrote:
> I was talking to Alan and mentioned this. He had another suggestion
> - lets just (for now) get the ASN1 code from BC and package it
> ourselves. Coupled with the suggestion about removing the IDEA
> algorithm as a possibility, we remove the dep on BC in OpenEJB.
I took a crack at stripping down the BC package to just the ASN1 code.
There are two classes that pull in digest code, which pulls in much of
the crypto engine. Thankfully, Geronimo does not depend on those two
classes, and there are no direct references to those classes in the rest
of the ASN1 code, so they can be deleted. Once that is done, it is a
pretty manageable dependency chain, and the code builds just fine. The
resulting package has support for many more datatypes than Geronimo
requires, but I'm not sure a full pruning effort would be justified.
>
> Then, we don't ship BC w/ geronimo, but let the console detect if BC
> is present and then show a message and warning where appropriate
> where to get the jar and how to install if not.
I suggest we also take the step of removing the IDEA algorithms from the
SSL cipher suite list, otherwise the exposure scenario I outlined still
exists. The download of the bouncycastle code changes the behavior of
the SSL support without the Geronimo users having any control over the
matter. Removing those algorithms from the list removes that exposure.
>
> Then Geronimo is clean, the functionality is optional, and users have
> no risk of encountering a problem, unless they can't read.
>
> geir
>
> On Sep 1, 2005, at 1:36 PM, Rick McGuire wrote:
>
>> I found an interesting example of the inadverent problems that can
>> be caused by Geronimo's current usage of bouncycastle. The openejb
>> SunOrb codes specifies a list of supported cipher suites to be used
>> with SSL connections in the class SSLCipherSuiteDatabase. The
>> supported list includes the IDEA algorithms. The Sun default JCE
>> implemenation does not include IDEA, so this will not be used unless
>> additional JCE provides are installed which include IDEA support.
>> So far, so good. The IDEA code, even though listed as an option,
>> will not get used without explicit knowledge of the Gernonmo
>> administrator.
>>
>> However, the current console code uses the bouncycastle code to
>> implement its keystore. This usage is in a manner that requires the
>> BC provider code to be installed programmatically, which the console
>> code does. Unfortunately, once this is done, the IDEA algorithms
>> are now available for use for SSL connections as well. This server
>> is now potentially a royalty collection target by the IDEA patent
>> holders, since they can demonstrate usage by having a client connect
>> with this server using the IDEA ciphers. We might even want to
>> consider allowing these algorithms to be controlled by the server
>> config rather than just hard coding them in the class.
>>
>> One way to fix this is just remove the IDEA algorithms from the
>> SSLCipherSuiteDatabase, so these will not be used for SSL
>> connections. Another potential solution (yet to be verified) is to
>> use the BC APIs that allow the default JCE provider to be used for
>> encryption services rather than defaulting to the BC provider.
>>
>> Rick
>>
>>
>
Re: IDEA block cipher inclusion via the "bouncy castle" JCE provider
Posted by Rick McGuire <ri...@gmail.com>.
btw, I want to point out the following notice from the bouncycastle site:
"Some of the algorithms in the Bouncy Castle APIs are patented in some
places. It is upon the user of the library to be aware of what the legal
situation is in their own situation, however we have been asked to
specifically mention the patent below at the request of the patent holder."
So far, the focus has just been on the IDEA patent...it appears there
are other patented algorithms in the bc code, but they only list patents
when they have been explicitly requested to by the patent holder.
Rick
Re: IDEA block cipher inclusion via the "bouncy castle" JCE provider
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
I was talking to Alan and mentioned this. He had another suggestion
- lets just (for now) get the ASN1 code from BC and package it
ourselves. Coupled with the suggestion about removing the IDEA
algorithm as a possibility, we remove the dep on BC in OpenEJB.
Then, we don't ship BC w/ geronimo, but let the console detect if BC
is present and then show a message and warning where appropriate
where to get the jar and how to install if not.
Then Geronimo is clean, the functionality is optional, and users have
no risk of encountering a problem, unless they can't read.
geir
On Sep 1, 2005, at 1:36 PM, Rick McGuire wrote:
> I found an interesting example of the inadverent problems that can
> be caused by Geronimo's current usage of bouncycastle. The openejb
> SunOrb codes specifies a list of supported cipher suites to be used
> with SSL connections in the class SSLCipherSuiteDatabase. The
> supported list includes the IDEA algorithms. The Sun default JCE
> implemenation does not include IDEA, so this will not be used
> unless additional JCE provides are installed which include IDEA
> support. So far, so good. The IDEA code, even though listed as an
> option, will not get used without explicit knowledge of the
> Gernonmo administrator.
>
> However, the current console code uses the bouncycastle code to
> implement its keystore. This usage is in a manner that requires
> the BC provider code to be installed programmatically, which the
> console code does. Unfortunately, once this is done, the IDEA
> algorithms are now available for use for SSL connections as well.
> This server is now potentially a royalty collection target by the
> IDEA patent holders, since they can demonstrate usage by having a
> client connect with this server using the IDEA ciphers. We might
> even want to consider allowing these algorithms to be controlled by
> the server config rather than just hard coding them in the class.
>
> One way to fix this is just remove the IDEA algorithms from the
> SSLCipherSuiteDatabase, so these will not be used for SSL
> connections. Another potential solution (yet to be verified) is to
> use the BC APIs that allow the default JCE provider to be used for
> encryption services rather than defaulting to the BC provider.
>
> Rick
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: IDEA block cipher inclusion via the "bouncy castle" JCE provider
Posted by Rick McGuire <ri...@gmail.com>.
I found an interesting example of the inadverent problems that can be
caused by Geronimo's current usage of bouncycastle. The openejb SunOrb
codes specifies a list of supported cipher suites to be used with SSL
connections in the class SSLCipherSuiteDatabase. The supported list
includes the IDEA algorithms. The Sun default JCE implemenation does
not include IDEA, so this will not be used unless additional JCE
provides are installed which include IDEA support. So far, so good.
The IDEA code, even though listed as an option, will not get used
without explicit knowledge of the Gernonmo administrator.
However, the current console code uses the bouncycastle code to
implement its keystore. This usage is in a manner that requires the BC
provider code to be installed programmatically, which the console code
does. Unfortunately, once this is done, the IDEA algorithms are now
available for use for SSL connections as well. This server is now
potentially a royalty collection target by the IDEA patent holders,
since they can demonstrate usage by having a client connect with this
server using the IDEA ciphers. We might even want to consider allowing
these algorithms to be controlled by the server config rather than just
hard coding them in the class.
One way to fix this is just remove the IDEA algorithms from the
SSLCipherSuiteDatabase, so these will not be used for SSL connections.
Another potential solution (yet to be verified) is to use the BC APIs
that allow the default JCE provider to be used for encryption services
rather than defaulting to the BC provider.
Rick
Re: IDEA block cipher inclusion via the "bouncy castle" JCE provider
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Aug 30, 2005, at 7:38 PM, Bruce Snyder wrote:
> On 8/30/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
>
>> In Apache Geronino and dependencies like OpenEJB, (and probably other
>> projects at the ASF...) we are using an external project known as
>> 'bouncycastle' (http://www.bouncycastle.org/) , a fairly well known
>> implementation of crypto-related stuff in Java.
>>
>
> How about asking the Bouncy Castle people for some advice on what to
> do? They're distributing the artifacts affected by these statements
> from MediaCrypt, what do they recommend to their user base regarding
> redistribution and use?
Well, that was the plan I had in mind (note, I sent this to license-
discuss w/ a cc here...)
having an IDEA-free distro would be the best solution for everyone.
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: IDEA block cipher inclusion via the "bouncy castle" JCE provider
Posted by Rick McGuire <ri...@gmail.com>.
David Jencks wrote:
>
> On Aug 30, 2005, at 4:38 PM, Bruce Snyder wrote:
>
>> On 8/30/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
>>
>>> In Apache Geronino and dependencies like OpenEJB, (and probably other
>>> projects at the ASF...) we are using an external project known as
>>> 'bouncycastle' (http://www.bouncycastle.org/) , a fairly well known
>>> implementation of crypto-related stuff in Java.
>>>
>>> Inside the distro jar from bouncycastle is an implementation of the
>>> IDEA algorithm. This algorithm is patented, and the patent holder,
>>> MediaCrypt, requires licenses for all implementations of IDEA, and
>>> there's no unfettered use - even non-commercial distribution requires
>>> some kind of correspondence with MediaCrypt.
>>>
>>> http://www.mediacrypt.com/
>>>
>>> You have to find the license section...
>>>
>>> So, here's the problem - I don't believe either Geronimo or OpenEJB
>>> is using the algorithm explicitly but I can't be sure that it isn't
>>> invoked somewhere, and statements from the MediaCrypt site such as
>>>
>>> "Requests by freeware developers to obtain a royalty-free license to
>>> spread an application program containing the algorithm not for
>>> commercial purposes must be directed to MediaCrypt"
>>>
>>> make me believe that we have to do something to redistribute this
>>> software.
>>>
>>> (I can't help noting how the infinitive "to spread" makes the GPL's
>>> language on "distribution" look clear.. :)
>>>
>>> Of course, there are other terms for commercial users.
>>>
>>> So, what should we do?
>>
>>
>> How about asking the Bouncy Castle people for some advice on what to
>> do? They're distributing the artifacts affected by these statements
>> from MediaCrypt, what do they recommend to their user base regarding
>> redistribution and use?
>
>
> Good idea. Alternatively for our use, it looks like the directory
> project has its own asn1 implementation. IIUC that is all we use in
> the openejb corba code. Can we sidestep this problem by using the
> directory's asn1 implementation?
The directory's asn1 implementation doesn't include support for X509
names, which is the really the only bit used by the corba code.
Also, the console is using the bouncycastle code to implement its
keystore. Unfortunately, the APIs used for that require the bc code to
be installed as a JCE security provider. A JCE security provider needs
to be in a signed jar, which pretty much precludes just snipping the
idea code from the jar file. This would have worked for the openejb
asn1 support, but not for every use.
Rick
>
> david jencks
>
>>
>> Bruce
>> --
>> perl -e 'print
>> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
>> );'
>>
>> The Castor Project
>> http://www.castor.org/
>>
>> Apache Geronimo
>> http://geronimo.apache.org/
>>
>
>
Re: IDEA block cipher inclusion via the "bouncy castle" JCE provider
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Aug 30, 2005, at 7:42 PM, David Jencks wrote:
>
> On Aug 30, 2005, at 4:38 PM, Bruce Snyder wrote:
>
>>>
>>
>> How about asking the Bouncy Castle people for some advice on what to
>> do? They're distributing the artifacts affected by these statements
>> from MediaCrypt, what do they recommend to their user base regarding
>> redistribution and use?
>>
>
> Good idea. Alternatively for our use, it looks like the directory
> project has its own asn1 implementation. IIUC that is all we use
> in the openejb corba code. Can we sidestep this problem by using
> the directory's asn1 implementation?
>
If that works technically, it gets OpenEJB off the hook... The only
remaining thing for us will be the console, and if push comes to
shove, we just remove the functionality that uses it, I suppose. Or
leave it there and tell people that if they want to use it, go get BC
themselves. We can always make the portlet smart and detect BC
before becoming active, and otherwise just showing a screen w/ the
warning and where to get hte software.
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: IDEA block cipher inclusion via the "bouncy castle" JCE provider
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
Is there any chance you can just take what you have, and donate that
and keep working on it here?
We could have spent the last month working together, you doing the
work that you wanted to do, and us reading the code, asking
questions, etc. We promise we won't get in your way too much :)
geir
On Sep 19, 2005, at 4:27 AM, Kresten Krab Thorup wrote:
> On Aug 31, 2005, at 2:26 AM, Dain Sundstrom wrote:
>
>
>>> Good idea. Alternatively for our use, it looks like the
>>> directory project has its own asn1 implementation. IIUC that is
>>> all we use in the openejb corba code. Can we sidestep this
>>> problem by using the directory's asn1 implementation?
>>>
>>>
>>
>> Kresten, does the proposed Trifork ORB donation include the asn1
>> code necessary for CORBA security?
>>
>>
>
> Our CSI interceptor can certainly be included in the donation. It
> includes some hand-written code for some of the ASN.1 encodings,
> like GSS_ExportedName.
>
> For ITTDistinguishedName, we use
> javax.security.auth.x500.X500Principal to decode the ASN.1 name.
> (this should be in any 1.4+ JDK).
>
> I cannot say for sure if this is all that will be needed in the
> future, but we can take it from here. I.e. we might also need code
> to ASN.1 encode/decode x509 certificate chains. I could not
> immediately find somewhere in our code where we handle that beyond
> SSL-level management.
>
> If someone is actually working on this stuff, I can send them the
> files that make up the CSI interceptor.
>
> Kresten
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: IDEA block cipher inclusion via the "bouncy castle" JCE provider
Posted by Kresten Krab Thorup <kr...@trifork.com>.
On Aug 31, 2005, at 2:26 AM, Dain Sundstrom wrote:
>> Good idea. Alternatively for our use, it looks like the directory
>> project has its own asn1 implementation. IIUC that is all we use
>> in the openejb corba code. Can we sidestep this problem by using
>> the directory's asn1 implementation?
>>
>
> Kresten, does the proposed Trifork ORB donation include the asn1
> code necessary for CORBA security?
>
Our CSI interceptor can certainly be included in the donation. It
includes some hand-written code for some of the ASN.1 encodings, like
GSS_ExportedName.
For ITTDistinguishedName, we use
javax.security.auth.x500.X500Principal to decode the ASN.1 name.
(this should be in any 1.4+ JDK).
I cannot say for sure if this is all that will be needed in the
future, but we can take it from here. I.e. we might also need code
to ASN.1 encode/decode x509 certificate chains. I could not
immediately find somewhere in our code where we handle that beyond
SSL-level management.
If someone is actually working on this stuff, I can send them the
files that make up the CSI interceptor.
Kresten
Re: IDEA block cipher inclusion via the "bouncy castle" JCE provider
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Rick McGuire wrote, On 8/31/2005 5:15 AM:
> I've been digging through the code trying to understand how/why the
> asn1 code is getting used. It appears the BC code is just being used
> to encode/decode X509 names for transport-level security. This is
> done in two places:
>
> 1) the mech_oid field in the SECIOP_SEC_TRANS structure, and
> 2) SAS_ContextSec supported_naming_mechanisms array.
>
> These fields are just defined as opaque byte[] items, so I suspect any
> encoding is acceptable as long as it is used symmetrically.
Any encoding is fine so long as it's ASN DER. I interpret your
statement to mean that any implementation is fine.
> The BC asn1 support has APIs for encoding/decoding X509 names, so it
> was convenient to use here. There does not appear to be any crypto
> engine involvement in this process.
> It appears the need here is not for asn1 support, but rather the
> ability to consistently encode OIDs which are in an X509 name format.
Nope, one must use ASN1 DER.
Dain's got the right idea. Let's use Trifork's code for the encoding work.
Regards,
Alan
Re: IDEA block cipher inclusion via the "bouncy castle" JCE provider
Posted by Rick McGuire <ri...@gmail.com>.
Dain Sundstrom wrote:
> On Aug 30, 2005, at 4:42 PM, David Jencks wrote:
>
>> On Aug 30, 2005, at 4:38 PM, Bruce Snyder wrote:
>>
>>> On 8/30/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
>>>
>>>> In Apache Geronino and dependencies like OpenEJB, (and probably other
>>>> projects at the ASF...) we are using an external project known as
>>>> 'bouncycastle' (http://www.bouncycastle.org/) , a fairly well known
>>>> implementation of crypto-related stuff in Java.
>>>>
>>>> Inside the distro jar from bouncycastle is an implementation of the
>>>> IDEA algorithm. This algorithm is patented, and the patent holder,
>>>> MediaCrypt, requires licenses for all implementations of IDEA, and
>>>> there's no unfettered use - even non-commercial distribution requires
>>>> some kind of correspondence with MediaCrypt.
>>>>
>>>> http://www.mediacrypt.com/
>>>>
>>>> You have to find the license section...
>>>>
>>>> So, here's the problem - I don't believe either Geronimo or OpenEJB
>>>> is using the algorithm explicitly but I can't be sure that it isn't
>>>> invoked somewhere, and statements from the MediaCrypt site such as
>>>>
>>>> "Requests by freeware developers to obtain a royalty-free license to
>>>> spread an application program containing the algorithm not for
>>>> commercial purposes must be directed to MediaCrypt"
>>>>
>>>> make me believe that we have to do something to redistribute this
>>>> software.
>>>>
>>>> (I can't help noting how the infinitive "to spread" makes the GPL's
>>>> language on "distribution" look clear.. :)
>>>>
>>>> Of course, there are other terms for commercial users.
>>>>
>>>> So, what should we do?
>>>>
>>>
>>> How about asking the Bouncy Castle people for some advice on what to
>>> do? They're distributing the artifacts affected by these statements
>>> from MediaCrypt, what do they recommend to their user base regarding
>>> redistribution and use?
>>>
>>
>> Good idea. Alternatively for our use, it looks like the directory
>> project has its own asn1 implementation. IIUC that is all we use in
>> the openejb corba code. Can we sidestep this problem by using the
>> directory's asn1 implementation?
>
>
> Kresten, does the proposed Trifork ORB donation include the asn1 code
> necessary for CORBA security?
I've been digging through the code trying to understand how/why the asn1
code is getting used. It appears the BC code is just being used to
encode/decode X509 names for transport-level security. This is done in
two places:
1) the mech_oid field in the SECIOP_SEC_TRANS structure, and
2) SAS_ContextSec supported_naming_mechanisms array.
These fields are just defined as opaque byte[] items, so I suspect any
encoding is acceptable as long as it is used symmetrically. The BC asn1
support has APIs for encoding/decoding X509 names, so it was convenient
to use here. There does not appear to be any crypto engine involvement
in this process.
It appears the need here is not for asn1 support, but rather the ability
to consistently encode OIDs which are in an X509 name format.
>
> -dain
>
>
Re: IDEA block cipher inclusion via the "bouncy castle" JCE provider
Posted by Dain Sundstrom <da...@iq80.com>.
On Aug 30, 2005, at 4:42 PM, David Jencks wrote:
> On Aug 30, 2005, at 4:38 PM, Bruce Snyder wrote:
>
>> On 8/30/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
>>
>>> In Apache Geronino and dependencies like OpenEJB, (and probably
>>> other
>>> projects at the ASF...) we are using an external project known as
>>> 'bouncycastle' (http://www.bouncycastle.org/) , a fairly well known
>>> implementation of crypto-related stuff in Java.
>>>
>>> Inside the distro jar from bouncycastle is an implementation of the
>>> IDEA algorithm. This algorithm is patented, and the patent holder,
>>> MediaCrypt, requires licenses for all implementations of IDEA, and
>>> there's no unfettered use - even non-commercial distribution
>>> requires
>>> some kind of correspondence with MediaCrypt.
>>>
>>> http://www.mediacrypt.com/
>>>
>>> You have to find the license section...
>>>
>>> So, here's the problem - I don't believe either Geronimo or OpenEJB
>>> is using the algorithm explicitly but I can't be sure that it isn't
>>> invoked somewhere, and statements from the MediaCrypt site such as
>>>
>>> "Requests by freeware developers to obtain a royalty-free license to
>>> spread an application program containing the algorithm not for
>>> commercial purposes must be directed to MediaCrypt"
>>>
>>> make me believe that we have to do something to redistribute this
>>> software.
>>>
>>> (I can't help noting how the infinitive "to spread" makes the GPL's
>>> language on "distribution" look clear.. :)
>>>
>>> Of course, there are other terms for commercial users.
>>>
>>> So, what should we do?
>>>
>>
>> How about asking the Bouncy Castle people for some advice on what to
>> do? They're distributing the artifacts affected by these statements
>> from MediaCrypt, what do they recommend to their user base regarding
>> redistribution and use?
>>
>
> Good idea. Alternatively for our use, it looks like the directory
> project has its own asn1 implementation. IIUC that is all we use
> in the openejb corba code. Can we sidestep this problem by using
> the directory's asn1 implementation?
Kresten, does the proposed Trifork ORB donation include the asn1 code
necessary for CORBA security?
-dain
Re: IDEA block cipher inclusion via the "bouncy castle" JCE provider
Posted by David Jencks <da...@yahoo.com>.
On Aug 30, 2005, at 4:38 PM, Bruce Snyder wrote:
> On 8/30/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
>> In Apache Geronino and dependencies like OpenEJB, (and probably other
>> projects at the ASF...) we are using an external project known as
>> 'bouncycastle' (http://www.bouncycastle.org/) , a fairly well known
>> implementation of crypto-related stuff in Java.
>>
>> Inside the distro jar from bouncycastle is an implementation of the
>> IDEA algorithm. This algorithm is patented, and the patent holder,
>> MediaCrypt, requires licenses for all implementations of IDEA, and
>> there's no unfettered use - even non-commercial distribution requires
>> some kind of correspondence with MediaCrypt.
>>
>> http://www.mediacrypt.com/
>>
>> You have to find the license section...
>>
>> So, here's the problem - I don't believe either Geronimo or OpenEJB
>> is using the algorithm explicitly but I can't be sure that it isn't
>> invoked somewhere, and statements from the MediaCrypt site such as
>>
>> "Requests by freeware developers to obtain a royalty-free license to
>> spread an application program containing the algorithm not for
>> commercial purposes must be directed to MediaCrypt"
>>
>> make me believe that we have to do something to redistribute this
>> software.
>>
>> (I can't help noting how the infinitive "to spread" makes the GPL's
>> language on "distribution" look clear.. :)
>>
>> Of course, there are other terms for commercial users.
>>
>> So, what should we do?
>
> How about asking the Bouncy Castle people for some advice on what to
> do? They're distributing the artifacts affected by these statements
> from MediaCrypt, what do they recommend to their user base regarding
> redistribution and use?
Good idea. Alternatively for our use, it looks like the directory
project has its own asn1 implementation. IIUC that is all we use in
the openejb corba code. Can we sidestep this problem by using the
directory's asn1 implementation?
david jencks
>
> Bruce
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> The Castor Project
> http://www.castor.org/
>
> Apache Geronimo
> http://geronimo.apache.org/
>
Re: IDEA block cipher inclusion via the "bouncy castle" JCE provider
Posted by Bruce Snyder <br...@gmail.com>.
On 8/30/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
> In Apache Geronino and dependencies like OpenEJB, (and probably other
> projects at the ASF...) we are using an external project known as
> 'bouncycastle' (http://www.bouncycastle.org/) , a fairly well known
> implementation of crypto-related stuff in Java.
>
> Inside the distro jar from bouncycastle is an implementation of the
> IDEA algorithm. This algorithm is patented, and the patent holder,
> MediaCrypt, requires licenses for all implementations of IDEA, and
> there's no unfettered use - even non-commercial distribution requires
> some kind of correspondence with MediaCrypt.
>
> http://www.mediacrypt.com/
>
> You have to find the license section...
>
> So, here's the problem - I don't believe either Geronimo or OpenEJB
> is using the algorithm explicitly but I can't be sure that it isn't
> invoked somewhere, and statements from the MediaCrypt site such as
>
> "Requests by freeware developers to obtain a royalty-free license to
> spread an application program containing the algorithm not for
> commercial purposes must be directed to MediaCrypt"
>
> make me believe that we have to do something to redistribute this
> software.
>
> (I can't help noting how the infinitive "to spread" makes the GPL's
> language on "distribution" look clear.. :)
>
> Of course, there are other terms for commercial users.
>
> So, what should we do?
How about asking the Bouncy Castle people for some advice on what to
do? They're distributing the artifacts affected by these statements
from MediaCrypt, what do they recommend to their user base regarding
redistribution and use?
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
The Castor Project
http://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
Re: IDEA block cipher inclusion via the "bouncy castle" JCE provider
Posted by Davanum Srinivas <da...@gmail.com>.
no, i meant the Directory code :). Yes, +1 to put out the fire.
On 9/1/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
> Get BC fixed? No doubt. But first we needed to put out the fire...
>
> On Sep 1, 2005, at 4:49 PM, Davanum Srinivas wrote:
>
> > ok thanks. (but should we not get it fixed :)
> >
> > -- dims
> >
> > On 9/1/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
> >
> >> yes, but according to Alan, it doesn't do the right thing. I'm not
> >> sure of the details. That was the first thing we considered.
> >>
> >> geir
> >>
> >> On Sep 1, 2005, at 3:59 PM, Davanum Srinivas wrote:
> >>
> >>
> >>> Directory project has some ASN1 code. no???
> >>>
> >>> -- dims
> >>>
> >>> On 9/1/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
> >>>
> >>>
> >>>> Current solution I'm proposing :
> >>>>
> >>>> 1) We get OpenEJB to remove IDEA as a possible cipher for SSL.
> >>>> OpenEJB isn't dependent on it, just lists it as a possibility if
> >>>> the
> >>>> JCE provider has it.
> >>>>
> >>>> 2) We take the ASN1 code from BC (it's BSD) and use that for the
> >>>> ASN1
> >>>> encoding/decoding (has nothing to do w/ IDEA, but just a nice
> >>>> set of
> >>>> utils that happen to be in the BC jar)
> >>>>
> >>>> At this point, openEJB has no more BC dependency.
> >>>>
> >>>> The remaining part is in the [optional] Geronimo console, which
> >>>> uses
> >>>> BC to manipulate a keystore for managing digital certs. We can
> >>>> make
> >>>> that totally optional - that we don't ship w/ BC, and show a page
> >>>> telling the user the issue, what to do about it to get it to work,
> >>>> and a warning.
> >>>>
> >>>> Now it's up to the user to go off and find the BC jar and
> >>>> install it.
> >>>>
> >>>> Does that work for everyone?
> >>>>
> >>>> geir
> >>>>
> >>>>
> >>>> On Aug 31, 2005, at 6:21 PM, Justin Erenkrantz wrote:
> >>>>
> >>>>
> >>>>
> >>>>> --On August 30, 2005 7:18:53 AM -0400 "Geir Magnusson Jr."
> >>>>> <ge...@apache.org> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> Another approach would be to petition bouncycastle.org to
> >>>>>> provide a
> >>>>>> distribution of the software w/o the algorithm included.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> +1. Otherwise, the dependency can not be redistributed by the
> >>>>> ASF. We have no use for 'submarine' patents in our distributions.
> >>>>> -- justin
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> --
> >>>> Geir Magnusson Jr +1-203-665-6437
> >>>> geir@optonline.net
> >>>>
> >>>>
> >>>>
> >>>> -------------------------------------------------------------------
> >>>> --
> >>>> DISCLAIMER: Discussions on this list are informational and
> >>>> educational
> >>>> only, are not privileged and do not constitute legal advice.
> >>>> -------------------------------------------------------------------
> >>>> --
> >>>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> >>>> For additional commands, e-mail: legal-discuss-help@apache.org
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service
> >>> Platform
> >>>
> >>> --------------------------------------------------------------------
> >>> -
> >>> DISCLAIMER: Discussions on this list are informational and
> >>> educational
> >>> only, are not privileged and do not constitute legal advice.
> >>> --------------------------------------------------------------------
> >>> -
> >>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> >>> For additional commands, e-mail: legal-discuss-help@apache.org
> >>>
> >>>
> >>>
> >>
> >> --
> >> Geir Magnusson Jr +1-203-665-6437
> >> geir@optonline.net
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> DISCLAIMER: Discussions on this list are informational and
> >> educational
> >> only, are not privileged and do not constitute legal advice.
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> >> For additional commands, e-mail: legal-discuss-help@apache.org
> >>
> >>
> >>
> >
> >
> > --
> > Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service
> > Platform
> >
> > ---------------------------------------------------------------------
> > DISCLAIMER: Discussions on this list are informational and educational
> > only, are not privileged and do not constitute legal advice.
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
> >
> >
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geir@optonline.net
>
>
>
> ---------------------------------------------------------------------
> DISCLAIMER: Discussions on this list are informational and educational
> only, are not privileged and do not constitute legal advice.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
--
Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service Platform
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: IDEA block cipher inclusion via the "bouncy castle" JCE provider
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
Get BC fixed? No doubt. But first we needed to put out the fire...
On Sep 1, 2005, at 4:49 PM, Davanum Srinivas wrote:
> ok thanks. (but should we not get it fixed :)
>
> -- dims
>
> On 9/1/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
>
>> yes, but according to Alan, it doesn't do the right thing. I'm not
>> sure of the details. That was the first thing we considered.
>>
>> geir
>>
>> On Sep 1, 2005, at 3:59 PM, Davanum Srinivas wrote:
>>
>>
>>> Directory project has some ASN1 code. no???
>>>
>>> -- dims
>>>
>>> On 9/1/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
>>>
>>>
>>>> Current solution I'm proposing :
>>>>
>>>> 1) We get OpenEJB to remove IDEA as a possible cipher for SSL.
>>>> OpenEJB isn't dependent on it, just lists it as a possibility if
>>>> the
>>>> JCE provider has it.
>>>>
>>>> 2) We take the ASN1 code from BC (it's BSD) and use that for the
>>>> ASN1
>>>> encoding/decoding (has nothing to do w/ IDEA, but just a nice
>>>> set of
>>>> utils that happen to be in the BC jar)
>>>>
>>>> At this point, openEJB has no more BC dependency.
>>>>
>>>> The remaining part is in the [optional] Geronimo console, which
>>>> uses
>>>> BC to manipulate a keystore for managing digital certs. We can
>>>> make
>>>> that totally optional - that we don't ship w/ BC, and show a page
>>>> telling the user the issue, what to do about it to get it to work,
>>>> and a warning.
>>>>
>>>> Now it's up to the user to go off and find the BC jar and
>>>> install it.
>>>>
>>>> Does that work for everyone?
>>>>
>>>> geir
>>>>
>>>>
>>>> On Aug 31, 2005, at 6:21 PM, Justin Erenkrantz wrote:
>>>>
>>>>
>>>>
>>>>> --On August 30, 2005 7:18:53 AM -0400 "Geir Magnusson Jr."
>>>>> <ge...@apache.org> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Another approach would be to petition bouncycastle.org to
>>>>>> provide a
>>>>>> distribution of the software w/o the algorithm included.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> +1. Otherwise, the dependency can not be redistributed by the
>>>>> ASF. We have no use for 'submarine' patents in our distributions.
>>>>> -- justin
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Geir Magnusson Jr +1-203-665-6437
>>>> geir@optonline.net
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> --
>>>> DISCLAIMER: Discussions on this list are informational and
>>>> educational
>>>> only, are not privileged and do not constitute legal advice.
>>>> -------------------------------------------------------------------
>>>> --
>>>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>>> For additional commands, e-mail: legal-discuss-help@apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service
>>> Platform
>>>
>>> --------------------------------------------------------------------
>>> -
>>> DISCLAIMER: Discussions on this list are informational and
>>> educational
>>> only, are not privileged and do not constitute legal advice.
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>> For additional commands, e-mail: legal-discuss-help@apache.org
>>>
>>>
>>>
>>
>> --
>> Geir Magnusson Jr +1-203-665-6437
>> geir@optonline.net
>>
>>
>>
>> ---------------------------------------------------------------------
>> DISCLAIMER: Discussions on this list are informational and
>> educational
>> only, are not privileged and do not constitute legal advice.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>>
>>
>
>
> --
> Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service
> Platform
>
> ---------------------------------------------------------------------
> DISCLAIMER: Discussions on this list are informational and educational
> only, are not privileged and do not constitute legal advice.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
--
Geir Magnusson Jr +1-203-665-6437
geir@optonline.net
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: IDEA block cipher inclusion via the "bouncy castle" JCE provider
Posted by Davanum Srinivas <da...@gmail.com>.
ok thanks. (but should we not get it fixed :)
-- dims
On 9/1/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
> yes, but according to Alan, it doesn't do the right thing. I'm not
> sure of the details. That was the first thing we considered.
>
> geir
>
> On Sep 1, 2005, at 3:59 PM, Davanum Srinivas wrote:
>
> > Directory project has some ASN1 code. no???
> >
> > -- dims
> >
> > On 9/1/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
> >
> >> Current solution I'm proposing :
> >>
> >> 1) We get OpenEJB to remove IDEA as a possible cipher for SSL.
> >> OpenEJB isn't dependent on it, just lists it as a possibility if the
> >> JCE provider has it.
> >>
> >> 2) We take the ASN1 code from BC (it's BSD) and use that for the ASN1
> >> encoding/decoding (has nothing to do w/ IDEA, but just a nice set of
> >> utils that happen to be in the BC jar)
> >>
> >> At this point, openEJB has no more BC dependency.
> >>
> >> The remaining part is in the [optional] Geronimo console, which uses
> >> BC to manipulate a keystore for managing digital certs. We can make
> >> that totally optional - that we don't ship w/ BC, and show a page
> >> telling the user the issue, what to do about it to get it to work,
> >> and a warning.
> >>
> >> Now it's up to the user to go off and find the BC jar and install it.
> >>
> >> Does that work for everyone?
> >>
> >> geir
> >>
> >>
> >> On Aug 31, 2005, at 6:21 PM, Justin Erenkrantz wrote:
> >>
> >>
> >>> --On August 30, 2005 7:18:53 AM -0400 "Geir Magnusson Jr."
> >>> <ge...@apache.org> wrote:
> >>>
> >>>
> >>>
> >>>> Another approach would be to petition bouncycastle.org to provide a
> >>>> distribution of the software w/o the algorithm included.
> >>>>
> >>>>
> >>>
> >>> +1. Otherwise, the dependency can not be redistributed by the
> >>> ASF. We have no use for 'submarine' patents in our distributions.
> >>> -- justin
> >>>
> >>>
> >>>
> >>
> >> --
> >> Geir Magnusson Jr +1-203-665-6437
> >> geir@optonline.net
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> DISCLAIMER: Discussions on this list are informational and
> >> educational
> >> only, are not privileged and do not constitute legal advice.
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> >> For additional commands, e-mail: legal-discuss-help@apache.org
> >>
> >>
> >>
> >
> >
> > --
> > Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service
> > Platform
> >
> > ---------------------------------------------------------------------
> > DISCLAIMER: Discussions on this list are informational and educational
> > only, are not privileged and do not constitute legal advice.
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
> >
> >
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geir@optonline.net
>
>
>
> ---------------------------------------------------------------------
> DISCLAIMER: Discussions on this list are informational and educational
> only, are not privileged and do not constitute legal advice.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
--
Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service Platform
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: IDEA block cipher inclusion via the "bouncy castle" JCE provider
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
yes, but according to Alan, it doesn't do the right thing. I'm not
sure of the details. That was the first thing we considered.
geir
On Sep 1, 2005, at 3:59 PM, Davanum Srinivas wrote:
> Directory project has some ASN1 code. no???
>
> -- dims
>
> On 9/1/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
>
>> Current solution I'm proposing :
>>
>> 1) We get OpenEJB to remove IDEA as a possible cipher for SSL.
>> OpenEJB isn't dependent on it, just lists it as a possibility if the
>> JCE provider has it.
>>
>> 2) We take the ASN1 code from BC (it's BSD) and use that for the ASN1
>> encoding/decoding (has nothing to do w/ IDEA, but just a nice set of
>> utils that happen to be in the BC jar)
>>
>> At this point, openEJB has no more BC dependency.
>>
>> The remaining part is in the [optional] Geronimo console, which uses
>> BC to manipulate a keystore for managing digital certs. We can make
>> that totally optional - that we don't ship w/ BC, and show a page
>> telling the user the issue, what to do about it to get it to work,
>> and a warning.
>>
>> Now it's up to the user to go off and find the BC jar and install it.
>>
>> Does that work for everyone?
>>
>> geir
>>
>>
>> On Aug 31, 2005, at 6:21 PM, Justin Erenkrantz wrote:
>>
>>
>>> --On August 30, 2005 7:18:53 AM -0400 "Geir Magnusson Jr."
>>> <ge...@apache.org> wrote:
>>>
>>>
>>>
>>>> Another approach would be to petition bouncycastle.org to provide a
>>>> distribution of the software w/o the algorithm included.
>>>>
>>>>
>>>
>>> +1. Otherwise, the dependency can not be redistributed by the
>>> ASF. We have no use for 'submarine' patents in our distributions.
>>> -- justin
>>>
>>>
>>>
>>
>> --
>> Geir Magnusson Jr +1-203-665-6437
>> geir@optonline.net
>>
>>
>>
>> ---------------------------------------------------------------------
>> DISCLAIMER: Discussions on this list are informational and
>> educational
>> only, are not privileged and do not constitute legal advice.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>>
>>
>
>
> --
> Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service
> Platform
>
> ---------------------------------------------------------------------
> DISCLAIMER: Discussions on this list are informational and educational
> only, are not privileged and do not constitute legal advice.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
--
Geir Magnusson Jr +1-203-665-6437
geir@optonline.net
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: IDEA block cipher inclusion via the "bouncy castle" JCE provider
Posted by Davanum Srinivas <da...@gmail.com>.
Directory project has some ASN1 code. no???
-- dims
On 9/1/05, Geir Magnusson Jr. <ge...@apache.org> wrote:
> Current solution I'm proposing :
>
> 1) We get OpenEJB to remove IDEA as a possible cipher for SSL.
> OpenEJB isn't dependent on it, just lists it as a possibility if the
> JCE provider has it.
>
> 2) We take the ASN1 code from BC (it's BSD) and use that for the ASN1
> encoding/decoding (has nothing to do w/ IDEA, but just a nice set of
> utils that happen to be in the BC jar)
>
> At this point, openEJB has no more BC dependency.
>
> The remaining part is in the [optional] Geronimo console, which uses
> BC to manipulate a keystore for managing digital certs. We can make
> that totally optional - that we don't ship w/ BC, and show a page
> telling the user the issue, what to do about it to get it to work,
> and a warning.
>
> Now it's up to the user to go off and find the BC jar and install it.
>
> Does that work for everyone?
>
> geir
>
>
> On Aug 31, 2005, at 6:21 PM, Justin Erenkrantz wrote:
>
> > --On August 30, 2005 7:18:53 AM -0400 "Geir Magnusson Jr."
> > <ge...@apache.org> wrote:
> >
> >
> >> Another approach would be to petition bouncycastle.org to provide a
> >> distribution of the software w/o the algorithm included.
> >>
> >
> > +1. Otherwise, the dependency can not be redistributed by the
> > ASF. We have no use for 'submarine' patents in our distributions.
> > -- justin
> >
> >
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geir@optonline.net
>
>
>
> ---------------------------------------------------------------------
> DISCLAIMER: Discussions on this list are informational and educational
> only, are not privileged and do not constitute legal advice.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
--
Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service Platform
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: IDEA block cipher inclusion via the "bouncy castle" JCE provider
Posted by Bill Stoddard <bi...@wstoddard.com>.
Geir Magnusson Jr. wrote:
> Current solution I'm proposing :
>
> 1) We get OpenEJB to remove IDEA as a possible cipher for SSL. OpenEJB
> isn't dependent on it, just lists it as a possibility if the JCE
> provider has it.
>
> 2) We take the ASN1 code from BC (it's BSD) and use that for the ASN1
> encoding/decoding (has nothing to do w/ IDEA, but just a nice set of
> utils that happen to be in the BC jar)
>
> At this point, openEJB has no more BC dependency.
>
> The remaining part is in the [optional] Geronimo console, which uses BC
> to manipulate a keystore for managing digital certs. We can make that
> totally optional - that we don't ship w/ BC, and show a page telling
> the user the issue, what to do about it to get it to work, and a warning.
>
> Now it's up to the user to go off and find the BC jar and install it.
>
> Does that work for everyone?
>
> geir
+1
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: IDEA block cipher inclusion via the "bouncy castle" JCE provider
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
Current solution I'm proposing :
1) We get OpenEJB to remove IDEA as a possible cipher for SSL.
OpenEJB isn't dependent on it, just lists it as a possibility if the
JCE provider has it.
2) We take the ASN1 code from BC (it's BSD) and use that for the ASN1
encoding/decoding (has nothing to do w/ IDEA, but just a nice set of
utils that happen to be in the BC jar)
At this point, openEJB has no more BC dependency.
The remaining part is in the [optional] Geronimo console, which uses
BC to manipulate a keystore for managing digital certs. We can make
that totally optional - that we don't ship w/ BC, and show a page
telling the user the issue, what to do about it to get it to work,
and a warning.
Now it's up to the user to go off and find the BC jar and install it.
Does that work for everyone?
geir
On Aug 31, 2005, at 6:21 PM, Justin Erenkrantz wrote:
> --On August 30, 2005 7:18:53 AM -0400 "Geir Magnusson Jr."
> <ge...@apache.org> wrote:
>
>
>> Another approach would be to petition bouncycastle.org to provide a
>> distribution of the software w/o the algorithm included.
>>
>
> +1. Otherwise, the dependency can not be redistributed by the
> ASF. We have no use for 'submarine' patents in our distributions.
> -- justin
>
>
--
Geir Magnusson Jr +1-203-665-6437
geir@optonline.net
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: IDEA block cipher inclusion via the "bouncy castle" JCE
provider
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On August 30, 2005 7:18:53 AM -0400 "Geir Magnusson Jr."
<ge...@apache.org> wrote:
> Another approach would be to petition bouncycastle.org to provide a
> distribution of the software w/o the algorithm included.
+1. Otherwise, the dependency can not be redistributed by the ASF. We
have no use for 'submarine' patents in our distributions. -- justin
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: IDEA block cipher inclusion via the "bouncy castle" JCE
provider
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 05:32 PM 8/31/2005, Justin Erenkrantz wrote:
>--On August 30, 2005 9:58:58 AM -0400 Bill Stoddard <bi...@wstoddard.com> wrote:
>
>>This seems to be the most reasonable approach. I would argue today that
>>BC is not open source, by the OSI definition
>>(http://www.opensource.org/docs/definition.php) due to the presence of
>>the IDEA algorithm in their distribition. They are violating their own
>>license.
>
>One of the reasons I'm no longer a fan of the MIT/X11 licenses is because they don't consider patents. This is just one more example of how the world has changed and those licenses need to be frowned upon. -- justin
But that is a non sequitur. Patent language in the licences
will only provide address specific cases and repercussions,
it is not a blank check to avoid all IP issues :) The fact
that it's there is only protecting you from willful harm
by the developers, and not that well at that.
Bill
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: IDEA block cipher inclusion via the "bouncy castle" JCE
provider
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On August 30, 2005 9:58:58 AM -0400 Bill Stoddard <bi...@wstoddard.com>
wrote:
> This seems to be the most reasonable approach. I would argue today that
> BC is not open source, by the OSI definition
> (http://www.opensource.org/docs/definition.php) due to the presence of
> the IDEA algorithm in their distribition. They are violating their own
> license.
One of the reasons I'm no longer a fan of the MIT/X11 licenses is because
they don't consider patents. This is just one more example of how the
world has changed and those licenses need to be frowned upon. -- justin
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: IDEA block cipher inclusion via the "bouncy castle" JCE
provider
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 08:58 AM 8/30/2005, Bill Stoddard wrote:
>Geir Magnusson Jr. wrote:
>
>>Another approach would be to petition bouncycastle.org to provide a
>>distribution of the software w/o the algorithm included.
>
>This seems to be the most reasonable approach. I would argue today that BC is not open source, by the OSI definition (http://www.opensource.org/docs/definition.php) due to the presence of the IDEA algorithm in their distribition. They are violating their own license.
Totally +1 (smells of a submarine). As much as it pains us to
say "drat - but let's make an exception for just this one" ...
that is not a good solution for the long term health of the
foundation or its projects.
Bill
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: IDEA block cipher inclusion via the "bouncy castle"
JCE provider
Posted by robert burrell donkin <rd...@apache.org>.
On Wed, 2005-08-31 at 21:46 +0200, Jochen Wiedmann wrote:
> robert burrell donkin wrote:
>
> > or would every open source project be expected to check every patent in
> > every state in the world?
>
> Ignoring a patent knowingly is surely not the same thing than violating
> it without knowledge of doing so. Both in the legal sense and for this
> discussions sake.
unlike copyright, patent law varies substantially from country to
country. whether mathematics should be patentable is a controversial
subject and i have some sympathy for those people who live in countries
with different cultural philosophies on this issue who refuse to abide
by laws framed in countries which have made different ethical choices.
the patent is (for them) invalid and therefore it is not unreasonable to
ignore it.
(this isn't the policy that i'd like to see adopted at apache, just
interested in the logical consequences of a radical definition of open
source as patent unencumbered worldwide...)
i suspect that apache would choose to ignore any patents which were not
enforceable under US law.
- robert
Re: IDEA block cipher inclusion via the "bouncy castle" JCE provider
Posted by Jochen Wiedmann <jo...@gmail.com>.
robert burrell donkin wrote:
> or would every open source project be expected to check every patent in
> every state in the world?
Ignoring a patent knowingly is surely not the same thing than violating
it without knowledge of doing so. Both in the legal sense and for this
discussions sake.
Jochen
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: IDEA block cipher inclusion via the "bouncy castle" JCE
provider
Posted by robert burrell donkin <rd...@apache.org>.
On Tue, 2005-08-30 at 09:58 -0400, Bill Stoddard wrote:
<snip>
> I would argue today that BC is not open source, by the OSI
> definition (http://www.opensource.org/docs/definition.php) due to the presence of the IDEA algorithm in their
> distribition. They are violating their own license.
this is a point of view with some interesting implications. AIUI the
IDEA patent is not universally recognised. it is valid in some countries
but not others.
would (under this interpretation) bouncy castle be open source in one
country but not another?
or would every open source project be expected to check every patent in
every state in the world?
- robert
Re: IDEA block cipher inclusion via the "bouncy castle" JCE provider
Posted by Bill Stoddard <bi...@wstoddard.com>.
Geir Magnusson Jr. wrote:
> So, what should we do?
>
> It may be the case that we need to get a license to redistribute the
> bouncycastle jar (from MediaCrypt). If this is the case, I suspect
> that we're hosed, as we wouldn't distribute something that requires our
> users who wish to redistribute our software to go get a license from
> someone.
>
> If not, we can provide a warning to our users that our software
> includes the IDEA algorithm which is encumbered, but at this time, I
> can't guarantee that it won't be invoked somehow.
>
> Another approach would be to petition bouncycastle.org to provide a
> distribution of the software w/o the algorithm included.
This seems to be the most reasonable approach. I would argue today that BC is not open source, by the OSI
definition (http://www.opensource.org/docs/definition.php) due to the presence of the IDEA algorithm in their
distribition. They are violating their own license.
Bill
---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org