DragonFlyBSD

Licence makes it impossible to use this work in DragonFly BSD base.

wtf? in what sense? we require all parts to be usable for "crimes
against humanity"?

cheers
simon

No matter how righteous it is, it's a claim that limits usability beyond
what typical open source licenses do. Slippery slope, etc.

Cheers,
--
Thomas E. Spanjaard
tgen@netphreax.net

I don't see a problem in that.

In any case I think we should always focus first on the technical parts
and maybe later on the license issues. So if something is brilliant but
has a strange license, we shouldn't shoot it down because of the license
but first comment on the technical content. After that we can issue
possible legal concerns.

cheers
simon

I'd much rather evaluate the software on its actual utility, rather than
this slippery slope idea that has us avoiding some troublesome future
license issue that doesn't exist.

We use binary blobs, and have GPL'd items (also restrictive) in the system
- no problem there. If a pedophile wants to use DragonFly, it's that
idiot's responsibility to abide by the licenses of the software involved.
Unless we do something unrealistic like purposefully distributing child
porn on the installer CD, this license does not affect this project.

:I don't see a problem in that.
:
:In any case I think we should always focus first on the technical parts
:and maybe later on the license issues. So if something is brilliant but
:has a strange license, we shouldn't shoot it down because of the license
:but first comment on the technical content. After that we can issue
:possible legal concerns.
:
:cheers
: simon

Yes, I agree.  Just worry about the technical aspects for now.  If
    it's technically good code one can always negotiate with the author
    to adjust the license.  We're using Robin's random number generator,
    by the way, and its original license was a bit weird too, but then
    changed to something compatible.

Generally speaking I am against incorporating code with odd licenses
    in it, simply because they are not realistically effective in their
    purpose.

Also keep in mind that the original submission was made way back
    in June.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

Hi,

I am the author of the code so I can change the
license if necessary.

I doubt you'd be able to use the CipherPacket source
code in C12 for IPSEC, because it is there to
encrypt/decrypt the private-key, and not for IPSEC.

But you can use the CipherPacket algorithm in IPSEC.
When I sent in the bug-report I was really
recommending DFLY use the CipherPacket algorithm in
IPSEC.

--- Simon 'corecode' Schubert
<bugs@lists.dragonflybsd.org> wrote:

DragonFly issue tracker
<bugs@lists.dragonflybsd.org>
<http://bugs.dragonflybsd.org/issue696>

Sincerely,
R Carey.

__________________________________________________
Sent from Yahoo! - the World's favourite mail http://uk.mail.yahoo.com

I just sent an email explaining that I was
recommending DragonFly should use the CipherPacket
algorithm in IPSEC. The CipherPacket source code in
C12 wouldn't I suspect be directly applicable to an
IPSEC implementation. But the algorithm as implemented
in the source code and described in the source code
comments would be applicable.

--- "Justin C. Sherrill" <bugs@lists.dragonflybsd.org>
wrote:

DragonFly issue tracker
<bugs@lists.dragonflybsd.org>
<http://bugs.dragonflybsd.org/issue696>

Sincerely,
R Carey.

__________________________________________________
Sent from Yahoo! - the World's favourite mail http://uk.mail.yahoo.com