Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server

[Alexandru Mihail]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "mini-httpd":

* Package name : mini-httpd
Version : 1.30-4
Upstream contact : Jef Poskanzer j...@mail.acme.com
* URL : https://www.acme.com/software/mini_httpd
* License : BSD-2-clause
* Vcs : https://salsa.debian.org/debian/mini-httpd
Section : web

The source builds the following binary packages:

mini-httpd - Small HTTP server

To access further information about this package, please visit the following URL:

https://mentors.debian.net/package/mini-httpd/

Alternatively, you can download the package with 'dget' using this command:

dget -x https://mentors.debian.net/debian/pool/main/m/mini-httpd/mini-httpd_1.30-4.dsc

Changes since the last upload:

mini-httpd (1.30-4) unstable; urgency=medium
.
* New maintainer. (Closes: #927950)
* Added missing newline in the rules file
* Bumped Standards-Version to 4.5.1

Regards,
--
Alexandru Mihail

[Nicholas D Steeves]

Control: owner -1 !
Control: tag -1 +moreinfo
Control: block 927950 by -1

Hi Alexandru,

Welcome! I'd like to sponsor your work, and I hope that attention to
detail doesn't annoy you. Please take a look at the questions in the
following reply:

Alexandru Mihail <alexandr...@protonmail.ch> writes:

> * Package name : mini-httpd
> Version : 1.30-4
> Upstream contact : Jef Poskanzer j...@mail.acme.com
> * URL : https://www.acme.com/software/mini_httpd
> * License : BSD-2-clause
> * Vcs : https://salsa.debian.org/debian/mini-httpd

Do you intend to continue to maintain mini-httpd at this location (Vcs
location), or do you have a new one in mind? Do you intend to maintain
the package in git, and if so would you please share the remote of your
fork? You don't have to if you don't want to, by the way.

> mini-httpd (1.30-4) unstable; urgency=medium
> .
> * New maintainer. (Closes: #927950)

Thank you for adopting this package!

> * Added missing newline in the rules file
> * Bumped Standards-Version to 4.5.1

This doesn't make sense, because, in 1.30-3, Håvard F. Aasen updated
Standards-Version to 4.6.1; in other words, this line claims you
regressed the package back to 4.5.1. Yes, Aasen didn't document this
change in the changelog, and that makes it unclear what happened...maybe
it was a "bump", but maybe Aasen did the work of checking the package
was compliant. I'd like you to verify compliance with the current
version of Debian Policy (4.6.2), and here is the checklist to help you
along your way. Please start at 4.4.1.

https://www.debian.org/doc/debian-policy/upgrading-checklist.html.

and I'd like to see you document your work with:

* Declare compliance with Standards-Version 4.6.2. (no changes required)

because I believe that you're not a robot ;) One of the perspectives I
was mentored to uphold is that "bumping" is for robots. Please note
that your sponsor will need to manually check for compliance with Policy
before uploading. Yes, this means duplicate work, or even triplicate
work if it was a package that needed ftpmaster review! The number is
just a number, and what really counts is the work.

On the topic of work, has upstream resolved any of these old bugs:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=mini-httpd

If so, let's talk about closing them! This is a normal part of adopting
a package (closing fixed bugs, and/or reopening ones that are still
relevant).

Regards,
Nicholas

[Alexandru Mihail]

Hello again, I have reuploaded mini-httpd to mentors as per your recommandations Nicholas. Please see my last mail for some questions regarding upstream/VCS.

Regards,

Alexandru Mihail

[Nicholas D Steeves]

Hi Alexandru,

Please take care to reply in cleartext to this RFS bug (#1036751), using
"reply to all" or "reply to list", because it's expected that most
Debian development and discussion happens in the open.

It's also important to have evidence of progress so that someone's bug
cleanup script doesn't mark the project as stalled and close the bug.

May I quote your decrypted email (the first and longer one) at this bug
in my reply?

Best,
Nicholas

[Nicholas D Steeves]

Hello Alexandrus,

It appears that your mail user agent (possibly webmail) is encrypting
emails to me when you "reply all" to the bug; the effect is non-public.
It may be that the only way to fix that effect is to either 1. not CC me
(just send to the bug) 2. Make that interface forget my key, because it
always encrypts when a key is available. 3. Maybe there's a config
toggle that disables unconditional encryption, for use with mailing
lists?

Alexandru Mihail <alexandr...@protonmail.ch> writes:

> Hello Nicholas,
> Of course, please quote the first email at the bug. My apologies for omitting to reply all :)

-- Re PM follows:

> Thank you a lot for taking the time to sponsor my work, it is a great pleasure and honor for me to finally contribute to Debian packages, after 11 years of daily usage :) . Sorry for the later reply, it's morning here.

You're welcome! :) No worries with taking time to reply, and feel free
to ping me if I take to long to reply.

>> "Do you intend to continue to maintain mini-httpd at this location (Vcs location), or do you have a new one in mind?"
>>

> Do you have any preferences/suggestions regarding this question?
> I am comfortable with git so forking on git wouldn't be a problem. I have no remote to share so far.

Since you're comfortable with git, please consider creating a Salsa
account and continuing to maintain the package in the Debian (previously
collab-maint) group. Here's more info on what that means:

https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group

It's ok if you don't want to; however, in this case we'll need to update
the Vcs links in the package.

>> "On the topic of work, has upstream resolved any of these old bugs"
>>

> The latest upstream release is still mini_httpd-1.30.tar.gz. ACME
> produces quality releases in general, but their release cycle is
> pretty lethargic as they are a small team working on many tools.

That's ok, and totally understandable. What I meant is that 1.30 isn't
that old compared to Bug #437932 (14 Aug 2007), #516307 from 2009.
Those look like they may have already been fixed upstream. Then there
are ones like #491078 that may have been fixed in Debian and/or
upstream, or could be fixed in the next upload to Debian.

> As context, I've worked professionally on patches for mini-httpd for about 9 months, adding PAM support and AAA authentication. Sadly, the license of my work is evidently proprietary. If I have the time I can try to tackle all the bugs alone, as I know everything that's happening in mini_httpd.c. I'll try mailing Jef (from ACME) to see if any fixes are in the pipeline.

Nice, it sounds like you're the ideal maintainer for Debian's
mini-httpd! It also sounds like you already know work to get things
merged upstream whenever possible.

> I might need a wee bit of assistance with lintian errors/Debian
> conventions as I mainly come from RPM land. I've packaged debs before
> for my employer, but Debian's standards and procedures are very
> different (and that's a good thing !).

Oh good, you're already using lintian :) Please take care to use a
recent version like 2.116.3 or 2.115.1~bpo11+1 (bullseye backport). Run
it with the "--info" argument to get explanations. There is currently
one warning (W) that needs to be fixed before this package is ready to
upload.

> I'm looking forward to your input and have a great weekend !

Thank you, I hope yours was as good as mine!

Regards,
Nicholas

[Alexandru Mihail]

Hello again, Nicholas

ProtonMail wins this time, I shall send directly to the bug as of now.

> Since you're comfortable with git, please consider creating a Salsa
> account and continuing to maintain the package in the Debian (previously
> collab-maint) group. Here's more info on what that means:

Sure, I'm absolutely fine with that

> That's ok, and totally understandable. What I meant is that 1.30 isn't
> that old compared to Bug #437932 (14 Aug 2007), #516307 from 2009.
> Those look like they may have already been fixed upstream. Then there
> are ones like #491078 that may have been fixed in Debian and/or
> upstream, or could be fixed in the next upload to Debian.

I'll check if those are resolved, of course; I'll add a suitable systemd service to resolve "missing-systemd-service-for-init.d-script".

>
> Thank you, I hope yours was as good as mine!
>

Sure was, thank you too and have a great day/night !

Best,
Alexandru

------- Original Message -------

[Lorenzo]

Hi Alexandru,

On Thu, 01 Jun 2023 12:05:51 +0000
Alexandru Mihail <alexandr...@protonmail.ch> wrote:

> Hi Nicholas,
> I've uploaded again to mentors, the (now gone) lintian warning
> complained about missing the SystemD service for the package. I've
> added one from scratch and upon initial testing it performs OK. I
> modified debian/rules to take the service into consideration though
> this raises some concerns for non-systemd Debian installations. I
> assume further modifications are required to intelligently enable or
> ignore the service (use old init.d mechanism).

(looking at your rules file)
override_dh_installinit:
dh_installinit --no-stop-on-upgrade --no-start --name=mini-httpd

override_dh_installsystemd:
dh_installsystemd --name=mini-httpd

if the '--no-stop-on-upgrade --no-start' is to avoid a conflict between
the systemd service and the init.d file, you don't need that: debhelper
generated scripts should do the right thing.
If you look at generated maintscripts you see that systemctl calls are
guarded by a test for /run/systemd/system (it imply that systemd is the
running init); the equivalent code for sysvinit (invoke.rc.d) is not
guarded but that's ok since other inits are supposed to mask
initscripts and systemd already does that.

Regards,
Lorenzo

> Kind regards,
> Alexandru Mihail
>

[Nicholas D Steeves]

Alexandru Mihail <alexandr...@protonmail.ch> writes:

> As for the old bugs, at least #491078 and #1018900 are stil present, I
> shall test a user submitted patch for the first one.

Thank you for taking the time to verify and document this. While not
required, it would also be nice if #491078 was noted in the appropriate
patch[es]. Bug-Debian is an optional field:
https://dep-team.pages.debian.net/deps/dep3/

> I'll also create a salsa account soon.

Thanks! Do you know if you'd prefer to fork and file pull
requests/merge requests, or wait for the permissions to push directly to
be granted?

> I hope this mail finds you well !
>

Thanks, you as well!
Nicholas

[Alexandru Mihail]

Hi,
Thanks everyone for the input !
Indeed the forking service type is the correct one for this package as daemon() is called as part of the initialization sequence. (if daemon() is not available, plain fork() is called anyway)
I've adjusted debian/rules, taking into consideration Lorenzo's advice, thanks Lorenzo !

> Thanks! Do you know if you'd prefer to fork and file pull
> requests/merge requests, or wait for the permissions to push directly to
> be granted?

I'd prefer waiting for push permission, for sure; if that is not possible in the near future, I can also fork and file requests.

Have a great weekend!

Alexandru

------- Original Message -------

[Alexandru Mihail]

Hello again,
Uploaded again to mentors.
Turns out bullseye-backports lintian (2.115.1~bpo11+1) only checks for 4.6.1 Standards, therefore a more serious error (depends-on-obsolete-package lsb-base) was reported by sid lintian.
Upon inspecting the situation (lsb-base is now a transitional empty package only here for debootstrap purposes mainly) and reading https://lists.debian.org/debian-devel/2023/01/msg00160.html I removed the package dependency entirely. This should be entirely safe. I also added Upstream-Contact into debian/copyright and stripped some trailing whitelines. Package should be lintian O.K. now.
Nicholas, my salsa account is verified now, waiting for push permission if that is ok. Is there anything else I should do now about that ?

Best,

Alexandru

------- Original Message -------

[Nicholas D Steeves]

Hi Alexandru,

Alexandru Mihail <alexandr...@protonmail.ch> writes:

> Turns out bullseye-backports lintian (2.115.1~bpo11+1) only checks for 4.6.1 Standards, therefore a more serious error (depends-on-obsolete-package lsb-base) was reported by sid lintian.
> Upon inspecting the situation (lsb-base is now a transitional empty
> package only here for debootstrap purposes mainly) and reading
> https://lists.debian.org/debian-devel/2023/01/msg00160.html I removed
> the package dependency entirely. This should be entirely safe.

Nice catch, and if someone using OpenRC is affected, I hope that person
will be willing to provide a patch for what sounds like a corner-case.

> I also added Upstream-Contact into debian/copyright and stripped some
> trailing whitelines. Package should be lintian O.K. now.

Thank you.

> Nicholas, my salsa account is verified now, waiting for push permission if that is ok. Is there anything else I should do now about that ?
>

1. What is the purpose of the dh_installsystemd override? (hint: see the
dh_installsystemd man page about --name).

2. I found an inaccuracy in the upstream sections of debian/changelog;
please fix it. Plain old grep or manual header check should be enough
to spot this.

3. Do the patches have accurate filenames, subjects, and synopses?
Adopting a package is the perfect time to fix anything misleading.

4. Does everything in your changelog entry still accurately reflect the
package? (ie "not started by default").

Would you please push your work to your personal Salsa namespace (fork
relationship optional), and provide the link to the repo? This way I
can responsibly grant you permissions, because I will have reviewed how
you work in git :) I can also review from git, if you prefer

Regards,
Nicholas

P.S. It seems like Debian's copy might be the defacto upstream, as of
eight years ago, when someone wrote we were "doing a good job"
maintaining mini_httpd.

[Alexandru Mihail]

Hello Nicholas,

> Nice catch, and if someone using OpenRC is affected, I hope that person
> will be willing to provide a patch for what sounds like a corner-case.

Thanks, I hope so as well

> 1. What is the purpose of the dh_installsystemd override? (hint: see the
> dh_installsystemd man page about --name).

I missed that, fixed now, thanks !

> 2. I found an inaccuracy in the upstream sections of debian/changelog;
> please fix it. Plain old grep or manual header check should be enough
> to spot this.

Can you please elaborate a bit ? Are you referring to my changelog entry or any mistakes in upstream.changelog or older debian/changelog entries ?

> 3. Do the patches have accurate filenames, subjects, and synopses?
> Adopting a package is the perfect time to fix anything misleading.
>

Most of them are fine, I'd change the filename of "0006-fix-makefile", a bit too generic, it changes some install dirs and adds -lssl to a compile target, not exactly something obvious when you read "fix-makefile". I'll come up with a better name.

> 4. Does everything in your changelog entry still accurately reflect the
> package? (ie "not started by default").

Fixed, thank you !

> Would you please push your work to your personal Salsa namespace (fork
> relationship optional), and provide the link to the repo? This way I

Will do, it was a very busy week :)

> P.S. It seems like Debian's copy might be the defacto upstream, as of
> eight years ago, when someone wrote we were "doing a good job"
> maintaining mini_httpd.

Hah, I've heard the same thing from an OpenWRT maintainer a few years ago. We're their defacto upstream as well (and any OpenWRT based router firmwares such as Tomato, etc etc). Long live the red spiral, I guess :)

Have a great day,

Alexandru

------- Original Message -------

[Nicholas D Steeves]

Hi Alexandru,

Alexandru Mihail <alexandr...@protonmail.ch> writes:

>> 2. I found an inaccuracy in the upstream sections of debian/changelog;
>> please fix it. Plain old grep or manual header check should be enough
>> to spot this.
>
> Can you please elaborate a bit ? Are you referring to my changelog entry or any mistakes in upstream.changelog or older debian/changelog entries ?

Sorry, my mistake. I meant to write "debian/copyright". One or more
entries in the copyright file conflicts with upstream evidence. Our
obligation is to accurately represent upstream's claims; however, if you
think the existing state better represents reality, and that upstream's
copy is inaccurate, then please do something like 1. Correct our copy of
upstream's claims. 2. Make a note about how the file previously
contained a different claim, which you think is correct, and write why.
The field that is used for this can be (quickly) found in this
documentation:

https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

>> 3. Do the patches have accurate filenames, subjects, and synopses?
>> Adopting a package is the perfect time to fix anything misleading.
>>
> Most of them are fine, I'd change the filename of "0006-fix-makefile", a bit too generic, it changes some install dirs and adds -lssl to a compile target, not exactly something obvious when you read "fix-makefile". I'll come up with a better name.

I agree most are fine, and yes the one you've pointed out could be
nicer. The one I'm concerned about has a subject that doesn't appear to
describe what the patch actually does, which is misleading. Strictly
speaking these patch fixups aren't release critical, and you can ignore
them if you'd like.

>> Would you please push your work to your personal Salsa namespace (fork
>> relationship optional), and provide the link to the repo? This way I
> Will do, it was a very busy week :)

No worries :)

>> P.S. It seems like Debian's copy might be the defacto upstream, as of
>> eight years ago, when someone wrote we were "doing a good job"
>> maintaining mini_httpd.
> Hah, I've heard the same thing from an OpenWRT maintainer a few years ago. We're their defacto upstream as well (and any OpenWRT based router firmwares such as Tomato, etc etc). Long live the red spiral, I guess :)

Wow, I guess it's true then, and that your work will benefit more people
than anticipated! This makes me think of the Civil Infrastructure
Platform
(https://wiki.linuxfoundation.org/_media/civilinfrastructureplatform/2017-08-cip-debconf-r5.pdf)

> Have a great day,

Likewise, you too!
Nicholas

[Alexandru Mihail]

Hello Nicholas,

> Sorry, my mistake. I meant to write "debian/copyright". One or more
> entries in the copyright file conflicts with upstream evidence.

No problem, I think I found what you were referring to and corrected our copyright, upstream is right. I documented the changes in the changelog.

> > > Would you please push your work to your personal Salsa namespace (fork
> > > relationship optional), and provide the link to the repo?

https://salsa.debian.org/alexandru_mihail/mini-httpd
Forked from master of:
https://salsa.debian.org/debian/mini-httpd

> speaking these patch fixups aren't release critical, and you can ignore
> them if you'd like.

I will fix them, it's fine :)

Also, I uploaded again to mentors last night.
Thanks and farewell,

Alexandru




------- Original Message -------

[Nicholas D Steeves]

Hello Alexandru,

Alexandru Mihail <alexandr...@protonmail.ch> writes:

> Hello Nicholas,
>
>> Sorry, my mistake. I meant to write "debian/copyright". One or more
>> entries in the copyright file conflicts with upstream evidence.
>
> No problem, I think I found what you were referring to and corrected our copyright, upstream is right. I documented the changes in the changelog.

Aha, yes, that's 1/2 of what I was referring to :) The other half are
those copyright years that predate the 1999 claimed in our copyright
file.

I also found what looks like a new issue: Those files that Rob McCool
authored as part of NCSA httpd that are part of mini-httpd, what
license are they? Attribution would be required if they were MIT/Expat,
BSD, or similar. This issue might also affect apache2's copyright file,
if anything remains of NCSA in Apache. Httpd predates the "NCSA"
license, by the way. If you can't find anything about it, then consider
contacting the debian-legal mailing list, because someone there might
remember the original NCSA httpd licence. P.S. It feels like
archaeology to find missing documentation for something from the dawn of
the Web! Also, it's a mystery to me what license the original httpd
was.

>> > > Would you please push your work to your personal Salsa namespace (fork
>> > > relationship optional), and provide the link to the repo?
>
> https://salsa.debian.org/alexandru_mihail/mini-httpd
> Forked from master of:
> https://salsa.debian.org/debian/mini-httpd

Thanks.

>> speaking these patch fixups aren't release critical, and you can ignore
>> them if you'd like.
> I will fix them, it's fine :)

Thank you :)

> Also, I uploaded again to mentors last night.
> Thanks and farewell,

You're welcome. We're in the last round of review, by the way, and I
think it will be ready to upload with the next update.

I hope that the forests aren't burning, wherever you are.

Take care,
Nicholas

[Alexandru Mihail]

Hello again,

> I hope that the forests aren't burning, wherever you are.
>
> Take care,

Oh damn, I really hope you and your family are going to be safe if you're facing wildfires near you..
Here in Eastern Europe it's not really that much of an issue, thankfully.

> remember the original NCSA httpd licence. P.S. It feels like
> archaeology to find missing documentation for something from the dawn of
> the Web! Also, it's a mystery to me what license the original httpd
> was.

It's pretty much a mistery to me too, seems like the original "License" if you could call it that is nothing more than:
"
Copyright (C) 2022 by Jef Poskanzer <j...@mail.acme.com>.
All rights reserved.

You may use this software however you like as long as you keep my name on it and don't sue me.
"
This is the current license (Author:So what does the legalese mean? This is a modified version of the BSD license). I'll try to dig a bit more about original source code license, if any other than the above was ever present :)
Yeah, archeology indeed, I've had the same issue,believe it or not, when porting a certain version of a vintage telnet library from the 80s on modern hardware. Fun times, indeed

Stay safe and good luck !

Alexandru


------- Original Message -------

[Alexandru Mihail]

Hello again Nicholas,
I hope this mail finds you well.

> > remember the original NCSA httpd licence. P.S. It feels like
> > archaeology to find missing documentation for something from the > > dawn of

Eureka !
I present the original NCSA httpd license in its purest form after some software archeology:
https://web.archive.org/web/20060830015540/http://hoohoo.ncsa.uiuc.edu/docs-1.5/Copyright.html

(NCSA HTTPd Development Team / ht...@ncsa.uiuc.edu / Last Modified 08-01-95)
====================== LICENSE START ===========================
NCSA HTTPd Server
Software Development Group
National Center for Supercomputing Applications
University of Illinois at Urbana-Champaign
605 E. Springfield, Champaign IL 61820
ht...@ncsa.uiuc.edu

Copyright (C) 1995, Board of Trustees of the University of Illinois

NCSA HTTPd software, both binary and source (hereafter, Software) is copyrighted by The Board of Trustees of the University of Illinois (UI), and ownership remains with the UI.

The UI grants you (hereafter, Licensee) a license to use the Software for academic, research and internal business purposes only, without a fee. Licensee may distribute the binary and source code (if released) to third parties provided that the copyright notice and this statement appears on all copies and that no charge is associated with such copies.

Licensee may make derivative works. However, if Licensee distributes any derivative work based on or derived from the Software, then Licensee will (1) notify NCSA regarding its distributing of the derivative work, and (2) clearly notify users that such derivative work is a modified version and not the original NCSA HTTPd Server software distributed by the UI by including a statement such as the following:

"Portions developed at the National Center for Supercomputing Applications at the University of Illinois at Urbana-Champaign."

Any Licensee wishing to make commercial use of the Software should contact the UI, c/o NCSA, to negotiate an appropriate license for such commercial use. Commercial use includes (1) integration of all or part of the source code into a product for sale or license by or on behalf of Licensee to third parties, or (2) distribution of the binary code or source code to third parties that need it to utilize a commercial product sold or licensed by or on behalf of Licensee.

Any commercial company wishing to use the software as their commercial World Wide Web server and are not redistributing the software need not commercially license the software but can use it free of charge.

UI MAKES NO REPRESENTATIONS ABOUT THE SUITABILITY OF THIS SOFTWARE FOR ANY PURPOSE. IT IS PROVIDED "AS IS" WITHOUT EXPRESS OR IMPLIED WARRANTY. THE UI SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY THE USERS OF THIS SOFTWARE.

By using or copying this Software, Licensee agrees to abide by the copyright law and all other applicable laws of the U.S. including, but not limited to, export control laws, and the terms of this license. UI shall have the right to terminate this license immediately by written notice upon Licensee's breach of, or non-compliance with, any of its terms. Licensee may be held legally responsible for any copyright infringement that is caused or encouraged by Licensee's failure to abide by the terms of this license.

====================== LICENSE END =============================

Should we include a mention of this under debian/copyright stating
something along the lines of 'parts of mini_httpd.c under NCSA HTTPD
and include a copy of the license somewhere?
As far as I could dig, this is the license which should be attributed in our case. This is the 1.15 htttpd license, and with 99.9999% certainty, this was the chunk of code still found in mini_httpd.c. The logic is, NCSA httpd had, historically, two licenses (chronologically): one open and one proprietary. mini_httpd is a fork of the open one, that we can be sure of. I think there is little reason to involve debian-legal at this point.
What's your opinion here?

Kind regards,

Alexandru

------- Original Message -------

[Nicholas D Steeves]

Hi Alexandru,

Thanks for the ping. I had forgotten that I had a WIP draft.

Alexandru Mihail <alexandr...@protonmail.ch> writes:

>> > remember the original NCSA httpd licence. P.S. It feels like
>> > archaeology to find missing documentation for something from the > > dawn of
>
> Eureka !
> I present the original NCSA httpd license in its purest form after some software archeology:
> https://web.archive.org/web/20060830015540/http://hoohoo.ncsa.uiuc.edu/docs-1.5/Copyright.html

Wow, you are good at this! :D

> (NCSA HTTPd Development Team / ht...@ncsa.uiuc.edu / Last Modified 08-01-95)
> ====================== LICENSE START ===========================
> NCSA HTTPd Server
> Software Development Group
> National Center for Supercomputing Applications
> University of Illinois at Urbana-Champaign
> 605 E. Springfield, Champaign IL 61820
> ht...@ncsa.uiuc.edu
>
> Copyright (C) 1995, Board of Trustees of the University of Illinois
>
> NCSA HTTPd software, both binary and source (hereafter, Software) is copyrighted by The Board of Trustees of the University of Illinois (UI), and ownership remains with the UI.
>
> The UI grants you (hereafter, Licensee) a license to use the Software
> for academic, research and internal business purposes only, without a
> fee.

Hmm, the above grant looks like it may not be DFSG compatible. Do you
see how?

https://www.debian.org/social_contract#guidelines
or https://wiki.debian.org/DebianFreeSoftwareGuidelines
or with a story
https://en.wikipedia.org/wiki/Debian_Free_Software_Guidelines

> Licensee may distribute the binary and source code (if released) to third parties provided that the copyright notice and this statement appears on all copies and that no charge is associated with such copies.

If Rob McCool didn't ever relicense the part of NCSA HTTPd that is part
of mini-httpd, then it looks like we might need to provide this notice,
and upstream mini-httpd should have been doing so.

> Licensee may make derivative works. However, if Licensee distributes any derivative work based on or derived from the Software, then Licensee will (1) notify NCSA regarding its distributing of the derivative work, and (2) clearly notify users that such derivative work is a modified version and not the original NCSA HTTPd Server software distributed by the UI by including a statement such as the following:
>
> "Portions developed at the National Center for Supercomputing Applications at the University of Illinois at Urbana-Champaign."

Is this DFSG compatible?

> Any Licensee wishing to make commercial use of the Software should contact the UI, c/o NCSA, to negotiate an appropriate license for such commercial use. Commercial use includes (1) integration of all or part of the source code into a product for sale or license by or on behalf of Licensee to third parties, or (2) distribution of the binary code or source code to third parties that need it to utilize a commercial product sold or licensed by or on behalf of Licensee.

And is this DFSG compatible?

> Any commercial company wishing to use the software as their commercial World Wide Web server and are not redistributing the software need not commercially license the software but can use it free of charge.

and this? Note the clause "and are not redistributing the software".
So you can't sell copies of this software?

> Should we include a mention of this under debian/copyright stating
> something along the lines of 'parts of mini_httpd.c under NCSA HTTPD
> and include a copy of the license somewhere?

Most likely, yes, but the bigger issue is if this license is not
DFSG-compatible.

> As far as I could dig, this is the license which should be attributed in our case. This is the 1.15 htttpd license, and with 99.9999% certainty, this was the chunk of code still found in mini_httpd.c. The logic is, NCSA httpd had, historically, two licenses (chronologically): one open and one proprietary. mini_httpd is a fork of the open one, that we can be sure of. I think there is little reason to involve debian-legal at this point.
> What's your opinion here?

Thank you for the note about this history. I didn't know NCSA httpd had
two licenses. I wonder if there was later a change to "everything that
was 'open' is now permissively licensed" at some point?

If the chunk of code is still big enough and original enough to meet the
minimum threshold for originality, then yes, the original copyright and
license would apply; however, I think this would mean that we need to
find documentation that someone contacted the U of I (and/or Rob
McCool).

A quick query of tldrlegal shows an NCSA license that is shorter and
more permissive:
https://www.tldrlegal.com/license/university-of-illinois-ncsa-open-source-license-ncsa

I suspect that NCSA httpd may have been relicensed to this shorter
version. Yeah, this seems to be a case where it's worth contacting
debian-legal, especially given those bits that don't look very
DFSG-free.

On the upside, I'm almost totally certain that that mini-httpd will be
ready to upload after this issue is resolved!

Regards,
Nicholas

[Alexandru Mihail]

Hello Nicholas,
Hehe, thanks a lot :D

>
> Wow, you are good at this! :D
>

I mailed debian-legal and am waiting for a reply.
Cheers,
Alex

------- Original Message -------

[Alexandru Mihail]

Hello,
Posting the debian-legal original post link here for easy reference:
https://lists.debian.org/debian-legal/2023/06/msg00019.html

Best,
Alexandru




------- Original Message -------

[Nicholas D Steeves]

Hello Alexandru,

Alexandru Mihail <alexandr...@protonmail.ch> writes:

> Hello Nicholas,

> debian-legal replied, I could only find occurences of Rob McCool's NCSA derived code in htpasswd.c as well. The NCSA license states we might(not must) include a copy of their short legal excerpt on derivative works (and mini-httpd is one)
> Maybe we should include a mention of said excerpt in debian/copyright under htpasswd: and include the excerpt somewhere ?
> Anyway, it seems to me we're in the clear when it comes to DFSG.

Sort of in the clear; however, from what I've read there isn't just one
"The NCSA license"; there seem to be three. Rob McCool is still a
copyright holder, and needs to be documented in debian/copyright.
Because of the ambiguity as to which license (and license version)
applies, and because Debian's copy of mini-httpd is now the defacto
upstream, I insist that the applicable license is also documented.
Also, the way I see it, if you've done the work, you might as well
document your findings as well as the fact that you did the work. This
type of work, while not immediately evident, is nonetheless
copyrightable, so--if you want to--you will be able to add you own claim
to the debian/* section of copyright.

> Attaching debian-legal reply:
>
> On 2023-07-02 16:43, Alexandru Mihail wrote:
>> mini-httpd contains early portions of code commited by Rob
>> McCool which seem to originate from NCSA httpd.
>
> Just htpasswd.c (which is what I get when searching for Rob McCool), or
> something else?
>
>> How do we proceed to clarify this situation?
>
> Figure out (from the history of the code, etc.) if that license applies.
>
> Looking into this a bit, I found this repository (which I am _assuming_,
> but have not verified, is a faithful import of NCSA httpd):
> https://github.com/TooDumbForAName/ncsa-httpd/
>
> I definitely see some code from mini-httpd's htpasswd.c in
> cgi-src/util.c in the HEAD of that repository above.
>
> Looking at git blame on that, it came from auth/htpasswd.c in httpd 1.1:
> https://github.com/TooDumbForAName/ncsa-httpd/commit/9572b626b7f10ab57e4715b3f3ff41b3f0696684#diff-7c5a48b0225b3fd1048000f4dfe2c4d9f56faa29f74876ff724384244d6d099d
>
> So that seems to be the original source of the code in question.
>
> In that same version, the top-level README says:
>
> ----
> This code is in the public domain. Specifically, we give to the public
> domain all rights for future licensing of the source code, all resale
> rights, and all publishing rights.
>
> We ask, but do not require, that the following message be included in
> all derived works:

>
> Portions developed at the National Center for Supercomputing
> Applications at the University of Illinois at Urbana-Champaign.
>

> THE UNIVERSITY OF ILLINOIS GIVES NO WARRANTY, EXPRESSED OR IMPLIED,
> FOR THE SOFTWARE AND/OR DOCUMENTATION PROVIDED, INCLUDING, WITHOUT
> LIMITATION, WARRANTY OF MERCHANTABILITY AND WARRANTY OF FITNESS FOR A
> PARTICULAR PURPOSE.
> ----

Do you think that httpd 1.1, httpd 1.15, or some other version is the
most likely source? If they're identical from the perspective of
mini-httpd, then I think you can make an argument for either, even
though it's probable that mini-httpd inherited whatever license was
active at the NCSA at the time of mini-httpd's creation.

Note that public domain doesn't exist in some countries. In this case
("public domain"), the mini-httpd author would need to have written
mini-httpd (distribution might count too, but I'm not sure) in a country
that recognises public domain; then, the relevant public domain bits
would become implicitly relicensed under the primary license for
mini-httpd. If this is the case, then a note should also be added to
McCool's debian/copyright section.

Cheers,
Nicholas

[Alexandru Mihail]

Hello Nicholas,

> Because of the ambiguity as to which license (and license version)
> applies, and because Debian's copy of mini-httpd is now the defacto
> upstream, I insist that the applicable license is also documented.

I agree, we need to document the NCSA bits.

> Do you think that httpd 1.1, httpd 1.15, or some other version is the
> most likely source? If they're identical from the perspective of
> mini-httpd, then I think you can make an argument for either, even
> though it's probable that mini-httpd inherited whatever license was
> active at the NCSA at the time of mini-httpd's creation.

After yet some more software archaeology, I've uncovered some more
rusty HTML 1.0 documents which are of interest to our dilemma.
Apparently, NCSA HTTPd Acknowledgements as of 7-14-95 state:
"Thanks to:
Robert McCool
For developing NCSA HTTPd till version 1.3 and this documentation."

https://web.archive.org/web/20090416132804/http://hoohoo.ncsa.uiuc.edu/docs/acknowledgement.html

This is the time Robert left the project and the date (and license
release - 1.3) probably aligns best with the code we have in mini-
httpd. After extensive googling, it seems to me that the original mini-
httpd-1.0.0.tar.gz source is lost to time, or at least is buried beyond
my reach.
Anyway, this might settle our ambiguity; I'll come up with a definitive
reply once I diff the sources again.

I transitioned all debian mail-related services to Google, and am using
a good MUA now (PGP signing properly). (BTW, does everything look all
right on your end?)

I've committed to salsa and uploaded to mentors a new .changes which
reflects the change in Maintainer's E-Mail. Naturally, I changed the
key and updated the changelog.

Thanks and have a great day/night !
Alexandru Mihail
------- Original Message -------
On Tuesday, July 4th, 2023 at 5:24 PM, Nicholas D Steeves

assuming,

[Nicholas D Steeves]

Hi Alexandru,

Alexandru Mihail <alexandru....@gmail.com> writes:

> After yet some more software archaeology, I've uncovered some more
> rusty HTML 1.0 documents which are of interest to our dilemma.
> Apparently, NCSA HTTPd Acknowledgements as of 7-14-95 state:
> "Thanks to:
> Robert McCool
> For developing NCSA HTTPd till version 1.3 and this documentation."
>
> https://web.archive.org/web/20090416132804/http://hoohoo.ncsa.uiuc.edu/docs/acknowledgement.html
>
> This is the time Robert left the project and the date (and license
> release - 1.3) probably aligns best with the code we have in mini-
> httpd. After extensive googling, it seems to me that the original mini-
> httpd-1.0.0.tar.gz source is lost to time, or at least is buried beyond
> my reach.

That's ok, you don't need to find the original version. Remember that
it's a fork and child relationship, so anyone, today, can fork httpd
(1.1-1.3, 1.4-1.14, 1.15, etc.) under the license terms specific to a
particular release. So, for a hypothetical case where the file[s] in
question are identical for the following versions ..:

1.1-1.3: "Do what you want but only on continental landmasses" license
|| \\
|| \=Possible fork point. If discriminating against islanders
|| is important, then fork from this point.
\/
1.4-1.14: "Non-commercial use only, except for fishermen" license
|| \\
|| \=Possible fork point. If privileging fishermen and
|| discriminate against everyone else is important, then fork
|| from this point.
\/
1.15: GPL3+
\\
\=Possible fork point. Only discriminates against those who
wish to keep their source private while also distributing their
fork. Fork from this point if that's important.

...then if httpd 1.15 is older then mini-httpd 1.30, you must choose
1.15. Meanwhile, Robert McCool's copyright still exists in 1.15 even if
he hasn't made a contribution since 1.3.

P.S. Please acknowledge: Have you read the DFSG yet, and do you
understand why it's important?
https://wiki.debian.org/DebianFreeSoftwareGuidelines

> I transitioned all debian mail-related services to Google, and am using
> a good MUA now (PGP signing properly). (BTW, does everything look all
> right on your end?)

I confirm receipt of your mail, and I see an attached signature. Where
can I download your public key?

> I've committed to salsa and uploaded to mentors a new .changes which
> reflects the change in Maintainer's E-Mail. Naturally, I changed the
> key and updated the changelog.

Thanks!

> Thanks and have a great day/night !

You too! :)


Regards,
Nicholas

[Alexandru Mihail]

Hello Nicholas,

>That's ok, you don't need to find the original version. Remember
>that
>it's a fork and child relationship,

Yes, I'm terribly sorry, I'm familiar with the fork-child relationship
but I still found your analogy very helpful and concise, I might
present it to my interns (if that's O.K), thanks a lot for the
reminder. I was extremely tired when I wrote the last e-mail.

In short, considering debian-legal's input, should I mention the NCSA
copyright notice in debian/copyright for Files: htpasswd.c, adding a
separate License: NCSA field to clarify the provenance of said source ?


I will fix the /patches issues we discussed in a later commit and
would also like to propose a mechanism for integrating PAM (Pluggable
Authentication Modules) into mini-httpd. I am currently in the
negotiation phase with my employer to grant an exception for this
particular patch in order for it to be upstreamed into debian/patches
(since, remember, we're the de-facto upstream here) and for my code to
become GPL licensed). PAM support (which would be toggled via a
Makefile parameter) could provide tangible improvements for the users
of mini-httpd and might even increase the server's popularity. The AUTH
mechanism in mini-httpd is arguably heavily antiquated and prone to
DDos attacks, MitM, scalability issues, etc. PAM would also enable AAA
solutions to interoperate with mini-httpd almost seamlessly (such as
Radius, TACACS+) which is becoming increasingly relevant in today's
SSO/IoT central trust-based use cases.

>P.S. Please acknowledge: Have you read the DFSG yet, and do you
>understand why it's important?

Yes I have and yes I do, it is one of the main reasons I decided to
start contributing to DebianWiki (and now mini-httpd) to begin with. :)

>I confirm receipt of your mail, and I see an attached signature.
>Where
>can I download your public key?

I'd like to ask you the same question, since I'd like to add your
address to my keyring. I've read a bit of documentation which suggests
using Ubuntu's HKP which seems a bit off-axis. I understand that the
Debian Public Key Server is for DDs and DMs only (I am not yet a DM).
I could perhaps use my DebianWiki personal page to link to my public
key, but I do not know if that solution would be accepted or would
sound absurd. I should find a better solution after some research.

Stay safe and thanks for your time,
Alexandru Mihail

[Alexandru Mihail]

Hello again,

>In short, considering debian-legal's input, should I mention the NCSA
>copyright notice in debian/copyright for Files: htpasswd.c, adding a
>separate License: NCSA field to clarify the provenance of said source
>?

After a bit more research into how other projects treat NCSA bits I'd
propose something along the lines of:

debian/copyright:

Files: htpasswd.c
Copyright: 1993-1994 Rob McCool <ro...@stanford.edu>
Copyright: 1997 Jef Poskanzer <j...@mail.acme.com> ?
License: NCSA


License: NCSA

This code is in the public domain. Specifically, we give to the public
domain all rights for future licensing of the source code, all resale
rights, and all publishing rights.

We ask, but do not require, that the following message be included in
all derived works:

Portions developed at the National Center for Supercomputing
Applications at the University of Illinois at Urbana-Champaign.

THE UNIVERSITY OF ILLINOIS GIVES NO WARRANTY, EXPRESSED OR IMPLIED,
FOR THE SOFTWARE AND/OR DOCUMENTATION PROVIDED, INCLUDING, WITHOUT
LIMITATION, WARRANTY OF MERCHANTABILITY AND WARRANTY OF FITNESS FOR A
PARTICULAR PURPOSE.

Also, looking into your concerns about public domain in other countries
(specifically referring to NCSA's :"This code is in the public
domain"):

Excerpt from https://wiki.debian.org/DFSGLicenses#Public_Domain :

Q: Since Debian is usually quite careful when it comes to legal issues,
I'm wondering what the official view point is here?

A: The official viewpoint is that the software must meet the
requirements of the DFSG. Generally, a CC0-style PD dedication is
viewed as sufficient for all jurisdictions, and can satisfy the DFSG if
source is available.

Q: Jurisdictions for Public Domain?

A: We are unaware of a case where a jurisdiction has upheld a copyright
claim to a work which has been dedicated to the public domain
everywhere. This is a potential theoretical source of problems, but
there's enough actual problems with copyright and licensing for us to
concentrate our limited time on them instead.

Q: Should there be a lintian error if the "license" is Public Domain
and a copyright holder is specified?

A: No.

Q: Should Public Domain perhaps be prohibited in general?

A: Definitely not.

Best,
Alexandru Mihail

[Nicholas D Steeves]

Hellow Alexandru,

Alexandru Mihail <alexandru....@gmail.com> writes:

> Hello Nicholas,
>>That's ok, you don't need to find the original version. Remember
>>that
>>it's a fork and child relationship,
>
> Yes, I'm terribly sorry, I'm familiar with the fork-child relationship
> but I still found your analogy very helpful and concise, I might
> present it to my interns (if that's O.K), thanks a lot for the
> reminder. I was extremely tired when I wrote the last e-mail.

No worries, and yes, go ahead and use that analogy :) If you feel like
citing/attributing it to me, I'd appreciate it, but this isn't required.

> In short, considering debian-legal's input, should I mention the NCSA
> copyright notice in debian/copyright for Files: htpasswd.c, adding a
> separate License: NCSA field to clarify the provenance of said source ?

Yes, and if I remember correctly, you had figured this out by your next
email (once again, sorry for my delays in replying).

> I will fix the /patches issues we discussed in a later commit and
> would also like to propose a mechanism for integrating PAM (Pluggable
> Authentication Modules) into mini-httpd. I am currently in the
> negotiation phase with my employer to grant an exception for this
> particular patch in order for it to be upstreamed into debian/patches
> (since, remember, we're the de-facto upstream here) and for my code to
> become GPL licensed). PAM support (which would be toggled via a
> Makefile parameter) could provide tangible improvements for the users
> of mini-httpd and might even increase the server's popularity. The AUTH
> mechanism in mini-httpd is arguably heavily antiquated and prone to
> DDos attacks, MitM, scalability issues, etc. PAM would also enable AAA
> solutions to interoperate with mini-httpd almost seamlessly (such as
> Radius, TACACS+) which is becoming increasingly relevant in today's
> SSO/IoT central trust-based use cases.

Wow, that's wonderful (and unexpected) news! I hope negotiations go well.

>>P.S. Please acknowledge: Have you read the DFSG yet, and do you
>>understand why it's important?
> Yes I have and yes I do, it is one of the main reasons I decided to
> start contributing to DebianWiki (and now mini-httpd) to begin with. :)

Thanks, much appreciated, and cool story!

>>I confirm receipt of your mail, and I see an attached signature.
>>Where
>>can I download your public key?
>
> I'd like to ask you the same question, since I'd like to add your
> address to my keyring. I've read a bit of documentation which suggests
> using Ubuntu's HKP which seems a bit off-axis. I understand that the
> Debian Public Key Server is for DDs and DMs only (I am not yet a DM).
> I could perhaps use my DebianWiki personal page to link to my public
> key, but I do not know if that solution would be accepted or would
> sound absurd. I should find a better solution after some research.

My key is on both the Debian keyring and public servers

https://wiki.debian.org/DebianKeyring
https://keys.openpgp.org/
and maybe also here
http://pgp.mit.edu/

I haven't checked if pgp.mit.edu auto-updated from keys.openpgp.org how
it used to work with the old SKS network.

P.S. Please make create key revocation certificates for the cases:
no-longer-used, superceded, and compromised, and store them someplace
safe.

Cheers,
Nicholas

[Nicholas D Steeves]

Hi Alexandru,

Alexandru Mihail <alexandru....@gmail.com> writes:

> After a bit more research into how other projects treat NCSA bits I'd
> propose something along the lines of:
>
> debian/copyright:
> Files: htpasswd.c

Yes, and htpasswd.1.

> Copyright: 1993-1994 Rob McCool <ro...@stanford.edu>
> Copyright: 1997 Jef Poskanzer <j...@mail.acme.com> ?

Yes, and you would know the years better than I! Also, you'll need to
say a few words about how you established copyright--a very short too
long didn't read version of this thread. Find out how to do this at
§5.1 of the following (read the short list of fields, and you'll see
which one it is):

https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#file-syntax

> License: NCSA
>
>
> License: NCSA
> This code is in the public domain. Specifically, we give to the public
> domain all rights for future licensing of the source code, all resale
> rights, and all publishing rights.
>
> We ask, but do not require, that the following message be included in
> all derived works:
>
> Portions developed at the National Center for Supercomputing
> Applications at the University of Illinois at Urbana-Champaign.
>
> THE UNIVERSITY OF ILLINOIS GIVES NO WARRANTY, EXPRESSED OR IMPLIED,
> FOR THE SOFTWARE AND/OR DOCUMENTATION PROVIDED, INCLUDING, WITHOUT
> LIMITATION, WARRANTY OF MERCHANTABILITY AND WARRANTY OF FITNESS FOR A
> PARTICULAR PURPOSE.

Looks good to me.

> Also, looking into your concerns about public domain in other countries
> (specifically referring to NCSA's :"This code is in the public
> domain"):
>
> Excerpt from https://wiki.debian.org/DFSGLicenses#Public_Domain :

[snip]

Thank you for looking into this, and for sharing this information.

Regards,
Nicholas

[Alexandru Mihail]

Hello Nicholas,
No problem about the later reply :)

>Also, you'll need to
>say a few words about how you established copyright--a very short too
>long didn't read version of this thread. Find out how to do this at
>§5.1 of the following (read the short list of fields, and you'll see
>which one it is):

debian/copyright:

Files: htpasswd.c htpasswd.1

Copyright: 1993-1994 Rob McCool <ro...@stanford.edu>
Copyright: 1997 Jef Poskanzer <j...@mail.acme.com>

License: NCSA
Comment: htpasswd.c and htpasswd.1 contain significant portions
of code from NCSA httpd (cgi-src/util.c, auth/htpasswd.c).
RobMcCool's copyright was traced from a git repository which
imported NCSA httpd (which was verified to be precise).
Multiple commits by RobMcCool on HEAD
show his contributions on the files specified here.
The files are under the NCSA license which qualifies as DFSG
compatible after inquiry (specifically, from the license text:

"This code is in the public domain. Specifically, we give to the
public
domain all rights for future licensing of the source code, all resale
rights, and all publishing rights"

From DSFGLicenses's Q&A on DebianWiki:

"Software placed in the public domain has all the freedoms
required by the DFSG, and is free software."

git repository: https://github.com/TooDumbForAName/ncsa-httpd/
debian-legal thread:
https://lists.debian.org/debian-legal/2023/07/msg00001.html
DFSGLicenses: https://wiki.debian.org/DFSGLicenses

License: NCSA
This code is in the public domain. Specifically, we give to the public
domain all rights for future licensing of the source code, all resale
rights, and all publishing rights.

We ask, but do not require, that the following message be included in
all derived works:

Portions developed at the National Center for Supercomputing
Applications at the University of Illinois at Urbana-Champaign.

THE UNIVERSITY OF ILLINOIS GIVES NO WARRANTY, EXPRESSED OR IMPLIED,
FOR THE SOFTWARE AND/OR DOCUMENTATION PROVIDED, INCLUDING, WITHOUT
LIMITATION, WARRANTY OF MERCHANTABILITY AND WARRANTY OF FITNESS FOR A
PARTICULAR PURPOSE.

Is my TLDR still a bit TL ? I was trying not to leave out anything
related to discussion on debian-legal or how we traced everything back
to RobMcCool. 
Did i get the right field ?

"6.6. Comment

Formatted text, no synopsis: this field can provide additional
information. For example, it might quote an e-mail from upstream
justifying why the license is acceptable to the main archive, or an
explanation of how this version of the package has been forked from a
version known to be DFSG-free, even though the current upstream version
is not. "

Sounded like a good fit.

Replying to previous untackled mail:

>Wow, that's wonderful (and unexpected) news! I hope negotiations go
well.

Thanks, me too :) I'll have to complete the new maintainer process here
(and actually have an upload by my mentor (you!) before I can discuss
matters more firmly with higher-ups. There's no rush; your patience and
attention to detail are very appreciated btw :)

>My key is on both the Debian keyring and public servers
>
> https://wiki.debian.org/DebianKeyring
> https://keys.openpgp.org/
> and maybe also here
> http://pgp.mit.edu/

OK, thanks, I'll have to find a good place for my key too, then.

I hope I haven't missed any points from the discussion here.

Have a great day,
Alexandru Mihail

[Alexandru Mihail]

Hello again,
Public key is up:
https://keys.openpgp.org/vks/v1/by-fingerprint/CEC2B41FDE5A803B6B08C01471CA8C5A78AA77BB
I also imported your key into my gpg keyring.
Thanks a lot !
Alexandru Mihail

[Nicholas D Steeves]

Hi Alexandru,

For brevity I've omitted the parts that look good.

Alexandru Mihail <alexandru....@gmail.com> writes:

> RobMcCool's copyright was traced from a git repository which
> imported NCSA httpd (which was verified to be precise).
> Multiple commits by RobMcCool on HEAD
> show his contributions on the files specified here.

Thank you you have the right idea about writing how you established
copyright. That said, what you've written is impossible, because Rob
McCool's work was 1993-1994, but git's first release was in 2005 ;)

Also, please revise the text to explain what "verified to be precise"
means. Grammatically, it sounds like you verified that the tags in the
repository match the WayBack Machine's copies of release tarballs. Did
you verify that Jef Poskanzer didn't make edits? If Jef Poskanzer made
edits, they would most likely be under the mini-httpd project license,
thus the effective license would be BSD-2-clause. A simple solution
would be claim these files are BSD-2-clause, but to note that htpasswd*
contain (or are mostly) NCSA licensed, and then shift the NCSA licence
text into the Comment section of Files: htpasswd.* If you run lintian
without shifting the license text you'll learn why I recommend it.

---- \cut this/ ----

> The files are under the NCSA license which qualifies as DFSG
> compatible after inquiry (specifically, from the license text:
>
> "This code is in the public domain. Specifically, we give to the
> public
> domain all rights for future licensing of the source code, all resale
> rights, and all publishing rights"
>
> From DSFGLicenses's Q&A on DebianWiki:
>
> "Software placed in the public domain has all the freedoms
> required by the DFSG, and is free software."

---- /cut this\ ----

I'm still not certain that this wiki contributor's position is legally
sound everywhere in the world. For a counter example see:
https://opensource.stackexchange.com/questions/9871/why-is-there-no-public-domain-licensing-in-europe

> git repository: https://github.com/TooDumbForAName/ncsa-httpd/

Note: If you provide a link that isn't on Debian infrastructure then
you'll also need to summarise what it contains (for various reasons that
I can explain if you're interested). It may be worth noting that
someone else can use this to verify if the htpasswd.* copy in mini-httpd
corresponds to the NCSA copy.

> debian-legal thread:
> https://lists.debian.org/debian-legal/2023/07/msg00001.html
> DFSGLicenses: https://wiki.debian.org/DFSGLicenses

/ \
Nice, but cut the last line of /this\

Thanks again for reading this page, as well as for sharing the story of
how it inspired you to contribute to Debian! :)

> Is my TLDR still a bit TL ? I was trying not to leave out anything
> related to discussion on debian-legal or how we traced everything back
> to RobMcCool. 

Thank you for your attention to detail, and yes, still too long.
There has been far more discussion at this bug than at debian-legal...

> Did i get the right field ?
>
> "6.6. Comment
>
> Formatted text, no synopsis: this field can provide additional
> information. For example, it might quote an e-mail from upstream
> justifying why the license is acceptable to the main archive, or an
> explanation of how this version of the package has been forked from a
> version known to be DFSG-free, even though the current upstream version
> is not. "
>
> Sounded like a good fit.

You're right, yes, that's the one :)

> Replying to previous untackled mail:
>>Wow, that's wonderful (and unexpected) news! I hope negotiations go
> well.
>
> Thanks, me too :) I'll have to complete the new maintainer process here
> (and actually have an upload by my mentor (you!) before I can discuss
> matters more firmly with higher-ups. There's no rush; your patience and
> attention to detail are very appreciated btw :)

Thanks :)

>>My key is on both the Debian keyring and public servers
>>
>> https://wiki.debian.org/DebianKeyring
>> https://keys.openpgp.org/
>> and maybe also here
>> http://pgp.mit.edu/
>
> OK, thanks, I'll have to find a good place for my key too, then.

I confirmed your signature on this email. Here are some key-related
resources:

https://wiki.debian.org/Keysigning
https://wiki.debian.org/Keysigning/Coordination


Best,
Nicholas

P.S. Please consider trimming the irrelevant quotation from
correspondences on the BTS. It's a top-posting convention that takes up
a lot of space and waste time (since we're an in-line posting community)
https://bugs.debian.org/1036751

[Alexandru Mihail]

Hello again, Nicholas !

-----------------------------------------------------------------------

debian/copyright:

Files: htpasswd.c htpasswd.1
Copyright: 1993-1994 Rob McCool <ro...@stanford.edu>
Copyright: 1997 Jef Poskanzer <j...@mail.acme.com>

License: BSD-2-clause
Comment: htpasswd* are mostly NCSA licensed.
RobMcCool's copyright was established by examining original NCSA httpd
source code mirrored here:
https://github.com/TooDumbForAName/ncsa-httpd/
This git repository is a convenient copy of the NCSA HTTPd 1.5.2 source
code which was verified to be accurate and complete by comparing with a
WaybackMachine capture of the original NCSA ftp archive found here:
https://web.archive.org/web/20130120184619/http://ftp.ncsa.uiuc.edu/Web/httpd/Unix/ncsa_httpd/current/httpd_1.5.2a-export_source.tar.Z
Portions of htpasswd* were edited by Jef Poskanzer, thus these files
remain under BSD-2-clause.

NCSA License:

This code is in the public domain. Specifically, we give to the public
domain all rights for future licensing of the source code, all resale

rights, and all publishing rights.

We ask, but do not require, that the following message be included in
all derived works:

Portions developed at the National Center for Supercomputing
Applications at the University of Illinois at Urbana-Champaign.

THE UNIVERSITY OF ILLINOIS GIVES NO WARRANTY, EXPRESSED OR IMPLIED,
FOR THE SOFTWARE AND/OR DOCUMENTATION PROVIDED, INCLUDING, WITHOUT
LIMITATION, WARRANTY OF MERCHANTABILITY AND WARRANTY OF FITNESS FOR A
PARTICULAR PURPOSE.

debian-legal thread:
https://lists.debian.org/debian-legal/2023/07/msg00001.html

-----------------------------------------------------------------------
Nicholas, I've finally found an "original" copy 
of the httpd 1.5.2 src !! (Mentioned in the text above, it's the very
long WaybackMachine link). After diff'ing the github copy and the
original .tar.Z (also, haven't seen that format in years), they seem to
match! Thus, I can confirm the github copy is accurate (previously, we
had no authoritative way to trust the github repo).

>I'm still not certain that this wiki contributor's position is
>legally
>sound everywhere in the world. For a counter example see:
>
https://opensource.stackexchange.com/questions/9871/why-is-there-no-public-domain-licensing-in-europe

I've read the link and I share your concerns. I'm a bit lost
here..maybe another question to legal is the right choice ?

>I confirmed your signature on this email. Here are some key-related
>resources

Thanks !

>P.S. Please consider trimming the irrelevant quotation from
>correspondences on the BTS.

Thank you for the heads up ! :)

Thanks for your time and may you have a great day,
Alexandru

https://bugs.debian.org/1036751

>

[Nicholas D Steeves]

Hello Alexandru,

Thank you for this latest update. Notes follow inline. Please count
the TODO items, resolve 4/4, and file an MR.

Alexandru Mihail <alexandru....@gmail.com> writes:

> Hello again, Nicholas !
>
> -----------------------------------------------------------------------
> debian/copyright:
>
> Files: htpasswd.c htpasswd.1
> Copyright: 1993-1994 Rob McCool <ro...@stanford.edu>
> Copyright: 1997 Jef Poskanzer <j...@mail.acme.com>
> License: BSD-2-clause
> Comment: htpasswd* are mostly NCSA licensed.
> RobMcCool's copyright was established by examining original NCSA httpd

1. Please indent everything in the Comment: field by a single white space
at the beginning of the line.

> source code mirrored here:
> https://github.com/TooDumbForAName/ncsa-httpd/
> This git repository is a convenient copy of the NCSA HTTPd 1.5.2 source
> code which was verified to be accurate and complete by comparing with a
> WaybackMachine capture of the original NCSA ftp archive found here:
> https://web.archive.org/web/20130120184619/http://ftp.ncsa.uiuc.edu/Web/httpd/Unix/ncsa_httpd/current/httpd_1.5.2a-export_source.tar.Z

Does that link really work? Are you sure it's not this one?

https://web.archive.org/web/20160619204223/ftp://ftp.ncsa.uiuc.edu/Web/httpd/Unix/ncsa_httpd/current/httpd_1.5.2a-export_source.tar.Z

I'm surprised the WayBack Machine dates that file June 19, 2016--very
curious.

> Portions of htpasswd* were edited by Jef Poskanzer, thus these files
> remain under BSD-2-clause.

The copyright info you've written in this version is immensely improved :)

2. Beyond this, you'll need to add a on every blank line that

.

so that the paragraphs in the "Comment" field of the "Files: htpasswd.c
htpasswd.1" aren't split by an empty newline; they need to remain part
of the same field. Nagivate to /usr/share/doc/*/copyright for many
examples.

> NCSA License:
> This code is in the public domain. Specifically, we give to the public
> domain all rights for future licensing of the source code, all resale
> rights, and all publishing rights.
.
> We ask, but do not require, that the following message be included in
> all derived works:

.

> Portions developed at the National Center for Supercomputing
> Applications at the University of Illinois at Urbana-Champaign.
.
> THE UNIVERSITY OF ILLINOIS GIVES NO WARRANTY, EXPRESSED OR IMPLIED,
> FOR THE SOFTWARE AND/OR DOCUMENTATION PROVIDED, INCLUDING, WITHOUT
> LIMITATION, WARRANTY OF MERCHANTABILITY AND WARRANTY OF FITNESS FOR A
> PARTICULAR PURPOSE.

/\ It will look something like that (note the new indented periods)

> debian-legal thread:
> https://lists.debian.org/debian-legal/2023/07/msg00001.html
>
> -----------------------------------------------------------------------
> Nicholas, I've finally found an "original" copy 
> of the httpd 1.5.2 src !! (Mentioned in the text above, it's the very
> long WaybackMachine link).

You have exceptional research skills.

> After diff'ing the github copy and the
> original .tar.Z (also, haven't seen that format in years), they seem to
> match! Thus, I can confirm the github copy is accurate (previously, we
> had no authoritative way to trust the github repo).

Oh man, yeah, hello early days of the internet! All you need now is
some MIDI files and GIFs.

3. Please note which version of NCSA httpd matches mini-httpd.

>>I'm still not certain that this wiki contributor's position is
>>legally
>>sound everywhere in the world. For a counter example see:
>>
> https://opensource.stackexchange.com/questions/9871/why-is-there-no-public-domain-licensing-in-europe
>
> I've read the link and I share your concerns. I'm a bit lost
> here..maybe another question to legal is the right choice ?

While I'm not a lawyer, I believe that the approach we're going with is
more legally defensible around the world than the aspirational public
domain one. BSD-2-clause is also better understood than NCSA as far as
I know. I'm relieved that work this didn't end up being a pulp novel
situation where someone stumbles onto a dirty rotten secret at the heart
of the origins of the internet while untangling the roots of a project
like this one.

As an aside, the last release that Robert McCool worked on was v1.3, and
then he left in 1994 [1].

> Thanks for your time and may you have a great day,

You're welcome, you too! Send me that merge request when you have time.


Cheers,
Nicholas

[1] https://web.archive.org/web/20090416132804/http://hoohoo.ncsa.uiuc.edu/docs/acknowledgement.html

[Alexandru Mihail]

Hi Nicholas,
MR filed:
https://salsa.debian.org/debian/mini-httpd/-/merge_requests/2

>Does that link really work? Are you sure it's not this one?

I have no idea what automagically happened, somehow the first one
worked for me, but now does not. :) Using yours (thanks!).

>The copyright info you've written in this version is immensely
>improved :)

Thanks, it was your patience and help that got me here too :D

>Oh man, yeah, hello early days of the internet! All you need now is
>some MIDI files and GIFs.

Haha, your paragraph makes me want to reinstall DOOM/Starcraft for the
nth time now :)

>3. Please note which version of NCSA httpd matches mini-httpd.

After much diff'ing and vim'ing and staring at #ifdefs and trying to
separate Jef's unversioned changes to htpasswd.c from actual NCSA
updates: 
It's 99.999% 1.4.2. I noted that in debian/copyright.

I hope everything is in order with my MR.

Have a great day and may the Debian swirl girate eternally !
Alexandru Mihail

[Nicholas D Steeves]

Hi Alexandru,

Alexandru Mihail <alexandru....@gmail.com> writes:

> MR filed:
> https://salsa.debian.org/debian/mini-httpd/-/merge_requests/2

Thanks. We can rebase and squash at the end, but for now please don't
force push.

>>Oh man, yeah, hello early days of the internet! All you need now is
>>some MIDI files and GIFs.
> Haha, your paragraph makes me want to reinstall DOOM/Starcraft for the
> nth time now :)

:)

>>3. Please note which version of NCSA httpd matches mini-httpd.
> After much diff'ing and vim'ing and staring at #ifdefs and trying to
> separate Jef's unversioned changes to htpasswd.c from actual NCSA
> updates: 
> It's 99.999% 1.4.2. I noted that in debian/copyright.

Remember my Wed, 21 Jun 2023 email (as well as the one with the
diagram)? 1.4.2 still has the "no commercial endeavour" clause.

Here is what I found with
https://github.com/TooDumbForAName/ncsa-httpd/

$ git checkout 1.5.1
$ git diff 1.4.2 -- support/htpasswd.c

diff --git a/support/htpasswd.c b/support/htpasswd.c
index a9263ec..fb3415a 100644
--- a/support/htpasswd.c
+++ b/support/htpasswd.c
@@ -4,12 +4,18 @@
* Rob McCool
*/

+#include "config.h"
+#include "portability.h"
+
#include <sys/types.h>
#include <stdio.h>
#include <string.h>
#include <sys/signal.h>
#include <stdlib.h>
#include <time.h>
+#ifdef NEED_CRYPT_H
+#include <crypt.h>
+#endif /* NEED_CRYPT_H */

#define LF 10
#define CR 13
@@ -79,10 +85,13 @@ to64(s, v, n)
}
}

+#ifdef HEAD_CRYPT
char *crypt(char *pw, char *salt); /* why aren't these prototyped in include */
+#endif /* HEAD_CRYPT */
+
#ifdef HEAD_GETPASS
char *getpass(char *prompt);
-#endif
+#endif /* HEAD_GETPASS */

void add_password(char *user, FILE *f) {
char *pw, *cpw, salt[3];

=====

I compared a couple of versions and found the same diff.

Hint: Read the commit message for 1.5.1. Having read that, what is your
explanation for this diff, and what is your explanation for the changes
between any version of httpd in this range and mini-httpd? There's
another hint in the tarball name that you're comparing with, but that
Jef Poskanzer may not have used.

> I hope everything is in order with my MR.

Yes, your MR looks good. I started a review and noted what looks like
one typo.

> Have a great day and may the Debian swirl girate eternally !

Haha, you too!
Nicholas

[Nicholas D Steeves]

Alexandru Mihail <alexandru....@gmail.com> writes:

> I've redone some diffs, too. Also, my previous statement of 1.4.2 httpd
> makes no sense, because, at a quick glance, I could observe the
> introduction of virtual hosting in httpd 1.5*, which mini-httpd had
> from the beginning. You're right to advise to look at 1.5* again.

+1 and where can I see this new work?

>>I started a review and noted what looks like one typo.

> Where can I view the typo/review info ? I've looked in my original
> merge details and I couldn't find it. Am I affected by temporary
> blindness ? :)

You should have received notifications for the review to the email
address that you used to sign up for Salsa, and those emails included
links to individual items. Alternatively, you can see the full review
here:

https://salsa.debian.org/debian/mini-httpd/-/merge_requests/2/diffs

If you strongly dislike using web interfaces and prefer patches via
email, please let me know and we'll switch back to email.

Regards,
Nicholas

[Nicholas D Steeves]

Hi Alexandru,

Thanks again for your work! I submitted a second (I think we're at the
second one) gitlab review here:

https://salsa.debian.org/debian/mini-httpd/-/merge_requests/2/diffs

Summary:

1. One minor nitpick for multi-maint changelog format

2. Two lines that I can't make sense of within the context of the
changelog. If you haven't already, please follow-up with these two bugs
you've noted on the BTS, and please CC any contributors to those bugs.

After that, let's talk about uploading. Think about whether you'd like
to start gaining practise with dput (or dput-ng), or whether you'd like
me to sponsor directly from git. If there's anything you'd like to
squash either squash it and force push, or let me what what you'd like
help squashing.

Cheers,
Nicholas

[Nicholas D Steeves]

Hi Alexandru,

On Fri, 18 Aug 2023 02:07:46 +0300 Alexandru Mihail <alexandru....@gmail.com> wrote:

> >After that, let's talk about uploading. Think about whether you'd
> >like

> >to start gaining practice with dput (or dput-ng), or whether you'd

> >like
> >me to sponsor directly from git.

> I'm pretty ambivalent to both..are you more comfortable with either one
> ? I'd reckon practice with dput might help me in the case where I
> become an uploading maintainer with full rights?

They're about the same for me. Honestly I'd prefer to do a git upload
at this time, and save the GPG key discussion for your next upload. We
can use dput and mentors then, and I think we'll both agree that we've
both worked hard enough for this first upload haha.

> Cheers, we're getting close :D !

Indeed, I just merged, congratulations!

At this point, please do a "dch -r" and ensure that the changelog entry
is refinalised; this will update the date stamp. Hint: you may have to
make do a noop edit like <space>+<backspace> to make this work properly.
Commit the new changelog entry with a message like:

Release 1.30-4 to unstable.

And push that to the remote we're using for your MR. Then make an
annotated and optionally GPG signed tag. I like to use "gbp tag" for
this, but you can use whatever method you prefer. Please make sure the
annotated tag is on the master branch and not a detached head. Let me
know, and I'll review, and upload when everything looks good, as it no
doubt will.

Then I'll give you push permissions so you can push the release commit
and tag to the actual project repository :)

Cheers,
Nicholas

[Nicholas D Steeves]

Hello Alexandru,

Thank you for the ping :)

Alexandru Mihail <alexandru....@gmail.com> writes:

> I've commited and pushed the changes to the remote I was using for the
> MR so far:
> commit:
> https://salsa.debian.org/alexandru_mihail/mini-httpd/-/commit/fc7c4f664dc1369b1bf5d46c8c9b7aa11de68407
>
>
> But I think I may have not commited where I was supposed to, granted
> you've already closed the MR.

You committed in the right place, and yes, as requested pushed to the
remote in your personal namespace rather than to the collaborative space
where mini-httpd is maintained. Yes, this is what I asked for, because
I wanted to make sure everything was in good order before uploading to
the archive and asking you to push to the actual project (thus making it
permanent). I'm pulling from your remote directly rather than using the
gitlab now. Tags on the actual project are immutable (or
should be treated thus), and should only be pushed after an upload has
been accepted, and this is why I wanted to check that everything was
100% good.

Yes, I had already merged your MR, and MRs are automatically closed when
they're merged.

> I've already created a GPG signed tag accessible at:
> https://salsa.debian.org/alexandru_mihail/mini-httpd/-/tags/debian%2F1.30-4

Thanks!

> The commit is not visible in the previous MR:
> https://salsa.debian.org/debian/mini-httpd/-/merge_requests/2?

This is because the MR was merged already (and thus already closed and
not open for updates).

> Is there something I've glanced over here ?

Did you realise that you're still committing using your protonmail.ch
address (and presumably GPG identity)? Early in this process you
switched to a gmail address, and I understood that that was the one that
you would be using for for your Debian work. You'll need to update your
git config to use the new gmail address and gpg identity (try
#debian-mentors on irc.oftc.net if you can't make sense of the docs).

Also, at this time please base your work on debian/mini-httpd.git rather
than alexandru_mihail/mini-httpd.git.

# Fix git config email and gpg identity, then
git clone g...@salsa.debian.org:debian/mini-httpd.git
cd mini-httpd
git remote add alex g...@salsa.debian.org:alexandru_mihail/mini-httpd.git
git fetch alex # just so you have another backup
dch -r
git commit debian/changelog -m "Release 1.30-4 to unstable."
# do your tagging procedure
git push --delete alex debian/1.30-4
git push -f alex master debian/1.30-4

Sorry I only noticed this when I manually inspected and compared the tag
and release commit on the CLI...I feel like the web-thing hid this
information from me, and that might be confirmation bias, but it seems
like the same thing happened to you ;)


Cheers,
Nicholas

P.S. FYI, to get Salsa's Gitlab instance to show green verified commits
and tags you may also need to update your email address and gpg key
there. I don't care about this so long as the actual git data is
correct, but you (and/or others) might.

[Nicholas D Steeves]

Hi Alexandru,

Alexandru Mihail <alexandru....@gmail.com> writes:

>>   # Fix git config email and gpg identity, then

[snip]
>>
> I fixed my git config and redid the tag as discussed above

Thanks!

>> Sorry I only noticed this when I manually inspected and compared the
>> tag

> Yeah, sorry too :)
> I'll be going on vacation for two weeks so I will be available via mail
> but won't be able to push unless we coordinate that tomorrow (roughly
> 14 Hrs from now would be when I have to leave. If not I'll happily push
> afterwards (14th September).
> Tag is in the usual spot:
> https://salsa.debian.org/alexandru_mihail/mini-httpd/-/tags/debian%2F1.30-4

I just uploaded and sent you an invitation that grants Maintainer
permissions for this repository. You will receive two emails from the
FTP Masters (Debian archive). The first will be a "processing" email
that says the release was uploaded successfully, and the second will be
that mini-httpd was accepted into Debian unstable/sid. Please wait
until you receive the "accepted" email before pushing your tag to
g...@salsa.debian.org:debian/mini-httpd.git, and please push the master
branch there at your earliest convenience.

Congratulations, and enjoy your holidays! :)

Cheers,
Nicholas