Re: OS X package building environment available for testing

Hi all,

An OS X distribution of Privoxy is nearing release. The discussion below pertains to ironing out licensing clarity and documentation changes. Latest comments inserted inline.


On 2012-02-19, at 1:30 PM, Fabian Keil wrote:

> Ian Silvester <[email protected]> wrote:
> 
> Ian, it occurred to me that this discussion could happen in
> public on the mailing list. If you agree to this, please reply
> to the list instead of in private.
> 
>> So I've cleaned up my build environment
<snip>
>> 
>> I'm guessing that David you are in the best position to confirm that it
>> can generate a Privoxy package correctly; Fabian please feel free to
>> confirm that it does not violate the GPL (I am relatively sure it does
>> not).
> 
> I can't. Confirming GPL compliance requires knowledge of the
> targeted platform and the build environment and I'm not familiar
> with Mac OS X and the software required to create the package.

Understood. The only software required outside of the module I've developed is the same as is required for the existing osxsetup module, it being PackageMaker (to build the OS X installation package file). This software is supplied as part of Xcode, the de facto Apple software development environment which, whilst not open source, is a free download and included on OS X distribution media. I trust that this doesn't present any issues; the fact that it's used by an existing Privoxy project module should surely be enough? I recognise the possibility that the existing module could be out of GPL compliance, but how about the hundreds (thousands?) of other open source projects out there that have OS X binary distributions? Surely they can't all be wrong!

Can anyone else make a definitive statement on this? I would hate to see this distribution fail due to it's dependence on the fundamental piece of software that generates the distribution file!

> 
> I skimmed through the package, though, so I've got a couple
> of comments:
> 
> 1)
> Several files have no copyright and license information
> at all and there doesn't seem to be an obvious default
> license. I'm aware that some of the affected files have
> been inherited from another package but it would be preferable
> to fix this.
> 
> 2)
> Some files contain a header like this:
> 
> | # Created by Ian Silvester for the Privoxy project.
> | # See Privoxy's LICENSE file for licensing details.
> | # With thanks to David Schmidt & Mark Miller on whose work this OS X installer is based
> | # and to Fabain Keil for technical guidance.
> 
> The first line doesn't make it clear who the copyright
> holder is. An explicit copyright line would be preferable,
> even if it doesn't mention individuals.
> 
> The second line should at least mention the name of
> the license (if it's GPLv2 or another license whose
> text is rather long).
> 
> Given that your tar file already seems to contains a
> copy of the GPLv2 it would probably preferable to reference
> that instead of "Privoxy's LICENSE file" which may change in
> the future.

I have inserted a new header in all files of the following format (taken from Privoxy's own README file). I believe that it answers all the above concerns:

# File        :  constructPkgContent.sh
#
# Purpose     :  Create the hierarchy of folders and files that will 
#                        comprise the installation package.
#
# Copyright   :  Written by and Copyright (C) 2001-2012 the
#                Privoxy team. http://www.privoxy.org/
#
#                Based on the Internet Junkbuster originally written
#                by and Copyright (C) 1997 Anonymous Coders and
#                Junkbusters Corporation.  http://www.junkbusters.com
#
#                This program is free software; you can redistribute it
#                and/or modify it under the terms of the GNU General
#                Public License as published by the Free Software
#                Foundation; either version 2 of the License, or (at
#                your option) any later version.
#
#                This program is distributed in the hope that it will
#                be useful, but WITHOUT ANY WARRANTY; without even the
#                implied warranty of MERCHANTABILITY or FITNESS FOR A
#                PARTICULAR PURPOSE.  See the GNU General Public
#                License for more details.
#
#                The GNU General Public License should be included with
#                this file.  If not, you can view it at
#                http://www.gnu.org/copyleft/gpl.html
#                or write to the Free Software Foundation, Inc.,
#                51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
#                USA
#
# Modification : If you modify this file please consider whether the change  
#                ought to be passed back to the macsetup module.
#


> Giving credits is appreciated, but putting them in
> the README once (where my name is also spelled correctly)
> is really sufficient if they are given for general help and
> not actual code.

Understood - credits now restricted to README file.

> Where actual copyrighted material has been embedded from
> another package, the copyright line should cover this (and
> the licenses have to be compatible of course).

The macsetup package contains no copyrighting nor licensing information. I reached out to Mark Miller for clarification and he has emailed to say he's happy for me to include parts of his work and redistribute them under the GPLv2; in fact he was keen that his work is licensed in the same way as the main Privoxy project.

> From a maintenance point of view it would also be great if
> a comment would make it clear that fixes to the code may be
> relevant for another package as well.

Done (see proposed file header quoted above).

> 3)
> build.sh references the jarfile directive which
> has been removed a while ago.

Reference removed.

> 4)
> A typo in constructPkgContent.sh is repeated several times.
> s@prixovy@privoxy@

Corrected.

> 5)
> Regarding the uninstaller: is uninstalling everything including
> possibly modified configuration files and log files the expected
> behaviour for a Mac OS X package?
> 
> Given that I don't remember complaints from Mac users in the past
> the answer may well be yes.

Hmmm, interesting point that one. The average OS X user has no concept of the separation between code and configuration and the location for an Objective-C package's configuration files would be ~/Library/Preferences. The uninstallation method usually understood by said average user is to simply drag the application to the Trash. Consequently the effective behaviour is to leave configuration in place when uninstalling, though no doubt the user's *intended* behaviour was to remove all trace of the application.

Regardless, I've modified the uninstall script to offer the option of leaving the configuration folder in place, for the benefit of what the Mac community would refer to as power users.

> 
>> One question to you all regarding the existing CVS modules for
>> Macintosh. Am I correct in my understanding that osxsetup is your work
>> David and that macsetup was created by Mark Miller? I would like to be
>> sure my attribution is correct since I took some elements of both
>> modules and developed them further for my system.
> 
> John Daniels contributed to the osxsetup module as well before he left:
> https://sourceforge.net/tracker/?func=detail&atid=211118&aid=1876629&group_id=11118

Added John to attribution in README.

> 
>> Separately from the above, I have made one modification to the content
>> of the 'current' module (and one is still pending). I have modified
>> doc/webserver/user-manual/installation.html with regards to installing
>> on OS X

<snip>
>> 
>> Please let me know if you would prefer a straight diff of changes rather
>> than git's output.
> 
> In general I prefer git format-patch output like this,
> but it seems to me that long lines have been truncated
> here.
> 
> In this case it would also have made sense to squash
> the two commits into one.
> 
> As the manual is generated from the sgml files in
> doc/source, changes to the HTML will be overwritten
> the next time the docs are generated, so the source
> files need to be updated as well.
> 
> As this is a change were a file in the binary package
> differs from the source tarball (until the next release
> which hopefully will contain your adjustments), the diff
> for the source file should then also be either included
> in the package or the URL referenced.
> 
> It's unlikely that any user cares about this, but it's
> important from a GPL point of view.

To simplify workflow and remove this impediment to release I've reverted my distribution to use the documentation from the source tarball.

I'll re-submit the documentation diffs separately, correcting my mistakes and supplying them as source diffs rather than those for the resulting HTML, such that they might be included in the next release.

> 
>> The only other change I propose to make will be to
>> doc/webserver/developer-manual/newrelease.html since this refers
>> currently only to the osxsetup module. I have not yet made any
>> modifications because:
>> 
>> - I am not clear on the process for submitting the completed binary to
>> the sourceforge project and the existing instructions seem incorrect.
> 
> The existing instructions seem to be out of date for all
> the packages.
> 
> Given that there's already a generic "Uploading and Releasing Your Package"
> section (currently also out of date), that seems to be sufficient to me
> for the Mac OS X package which doesn't have a specific GNUmakefile target
> for the upload.
> 
>> - I feel that the manual should reference all three modules since each
>> has it's good points
>> 
>> Please let me know what the official route should be for submitting a
>> binary back to the project and creating a release for it and also what
>> you think about including all three modules in the documentation (or
>> whether mine should become the sole entry!).
> 
> It's unlikely that we will be able to maintain three separate
> modules in the future. Assuming yours is the only one that currently
> works out of the box the documentation should probably concentrate
> on that.
> 
> It doesn't hurt to mention the others as well (if you are willing
> to do this), but their current state should be made obvious.
> A list of the advantages of each package would be great, too.

On balance I think I'll include mine (OSXPackageBuilder) and macsetup and deprecate osxsetup. Mine entirely supersedes osxsetup in that it targets the same output (an OS X installer package) and is significantly more complete, supporting a far wider range of OS X versions. macsetup on the other hand has the advantage that it's target is installing to OS X direct from the source code rather than building a distribution. I'll make that clear in the documentation.


Back to the business at hand. I've placed updated OS X packages and a tar of the OSXPackageBuilder in the same locations as before, respecting all the changes referred to in this email (excepting the documentation changes of course). If these items now pass muster, please upload the two packages to Sourceforge and make releases for them (or give me the rights to do so) and check the OSXPackageBuilder module into CVS. Let's get this out there!


Cheers,

Ian
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d