Hi Daniel,

>> following the comment at the beginning of security.c I gave a try at
>> rewriting the file. The diff against trunk is attached along with the new
>> implementation. It passes all the tests on my machine but the compilation
>> has not been tested outside a Linux/32bit machine. The diff is pretty big
>> and can be split upon demand to ease review.
>
> Whoa, very cool work! Sorry for being slow at responding, it slipped between
> somehow.

Thanks, I have been pretty busy too and haven't pinged about that too.

> I fear that security.c is mostly used for kerberos4 and possibly some gssapi
> stuff and I must admit that I have _never_ used any of those since the days
> we first introduced krb4 (when I was given a krb account to borrow for a few
> days) so if we go this route I think we just need to trust that the tests
> are decent enough to at least not break everything completely and then wish
> and hope that someone who actually uses krb4 or gss will try it.

I don't have a kerberos account and I just went ahead with the tests
and trying to match the old code to keep the behaviour close enough.

> The original code that the copyright covers was first modified quite a lot
> by Martin Hedenfalk to adapt it to curl, and then I did my share at
> curlifying it. That was even before the file first appeared in the directory
> as the first version we can find with git (September 2000). From there, the
> file has been further modified. Now you've modified it a lot on top of all
> this. Is there any traces left that would warrant a copyright and thus a say
> in which license to use?

The code is inspired in its structure and some of its algorithm from
the previous one. Also looking at the original code, it looks like
some of it is still around.

> In all fairness, however much I'd like to just get out of that annoying
> announce license, I can spot similarities in the patched code and the
> original code we imported into curl. They are close enough to be seen by a
> human eye looking for it. Are they big enough to warrant copyright? I don't
> know, but in this case I rather leave the copyright in just to be safe and
> play nice.

I think as long as you integrate one line of a previous change, it may
be considered as a derivative work and thus be submitted to the same
license. It may be difficult to prove that a one-liner is included
though so usually the threshold is higher (function, algorithm).

> But, given that you've worked a lot on this and fixed a bunch of issues and
> quirks in the code, I think we should proceed and merge your patch even if
> it doesn't (yet) remove the Original BSD license from the file.
>
> What do you think? Am I wrong?

It seems like a good middle ground and the wisest decision considering
our lack of better legal knowledge. I was hoping to get some insights
from fellow hackers on this license issue (and I have thanks!).

My understanding of a rewrite was that it needed to be done in a
block. If we don't go this way, I would rather split the huge patch
into different components so that they can get better reviews. It will
also be easier to spot regressions that may arise. Please find
attached the first split. I will do the rest over the week-end.

Regards,
Julien

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html