Bug 195807 - [MAINTAINER] Update sysutils/zsd to 2014-12-07-c2d3662
Summary: [MAINTAINER] Update sysutils/zsd to 2014-12-07-c2d3662
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Bartek Rutkowski
Depends on:
Reported: 2014-12-08 12:19 UTC by Fabian Keil
Modified: 2016-04-17 13:14 UTC (History)
3 users (show)

See Also:

Update sysutils/zsd to 2014-12-07-c2d3662 (1.33 KB, patch)
2014-12-08 12:19 UTC, Bugzilla Automation
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Fabian Keil 2014-12-08 12:19:01 UTC
Created attachment 150349 [details]
Update sysutils/zsd to 2014-12-07-c2d3662

This update fixes the version string in the --help output
and removes incorrect LICENSE goo that was added without
my approval:
Comment 1 Thomas Zander freebsd_committer 2014-12-14 13:22:46 UTC
Could you add a suitable set of LICENSE-* tags?
Comment 2 Fabian Keil 2014-12-14 13:34:19 UTC
I prefer not to use the optional LICENSE "framework" in my
ports until it's properly maintained and documented.

For details see:
Comment 3 Thomas Zander freebsd_committer 2014-12-14 15:12:16 UTC
(In reply to fk from comment #2)
> I prefer not to use the optional LICENSE "framework" in my
> ports until it's properly maintained and documented.

It may not be perfect(ly documented) yet, but it's quite widely adopted already, including a de-facto default for ports with non-standard license conditions, see e.g. archivers/rar. Can I persuade you to include something like this for now? Thanks for considering.
Comment 4 Fabian Keil 2014-12-14 16:26:29 UTC
No, thanks.

BTW, zsd actually has standard license conditions, so the
"de-facto default" used by archivers/rar probably wouldn't
be appropriate anyway.
Comment 5 Thomas Zander freebsd_committer 2014-12-14 16:47:08 UTC
If it does have a standard license, where is the harm in adding the tags?
Comment 6 Fabian Keil 2014-12-14 17:46:14 UTC
The tags have undocumented legal implications.

Until that changes I prefer not to use them.
Comment 7 Johannes Jost Meixner freebsd_committer 2015-02-24 12:05:45 UTC
Hi Fabian,

given that you're both maintainer and upstream, this shouldn't be much of a problem to resolve. You've put the license inside zsd itself, and it's an ISC one.
Documenting that choice has no effect on end users, given that your 'zsd' tool is licensed as ISC regardless of whether ports/packages know off it.

ISC being among the most permissive licenses, I propose a single license tag like so:


ISC is known to the ports framework, and hence attributes like 
 LICENSE_PERMS, LICENSE_GROUPS and LICENSE_NAME are set by the framework.

LICENSE_FILE is typically used in cases where there's a separate file (usually called LICENSE, or COPYING), but again this isn't the current case with zsd. 
And the ISC license is common enough not to require setting LICENSE_TEXT.

(For reference on attributes,


All consequences of licensing arise with the choice to publish a version of the software. Documenting this choice in ports is a must to ensure users know what they're getting: some people (or, FreeBSD derivatives) may have a policy of not using non-permissive licenses (including all those not explicitly documented), and in cases like this one no harm will come from documenting what was intended at publication.
Comment 8 Fabian Keil 2015-02-25 13:54:25 UTC
Did I miss a policy change that made the LICENSE "framework" mandatory?

If not, please do not try to force it on my ports until it's documented and maintained (at which point I may even use it voluntarily).
Comment 9 Bartek Rutkowski freebsd_committer 2015-03-01 17:33:18 UTC
You're correct, you're missing the fact that using LICENSE is in fact, mandatory. I agree, it is not documented and it should be, but that doesnt change the fact, that it is required and is slowly being used wherever possible.

As a sidenote, the ports are not 'yours' - you've been granted the right to be their maintainer and be the first person to update/fix them, to approve or disapprove other people patches, but it doesnt mean you're the owner of the port and you can decide which parts of best practices or ports frameworks to use (or not).

We're very grateful for the work you're doing and we're appreciating it a lot, but we'd need to to cooperate with us on the good will assumption, if we're proposing a change to your commit, or doing it, its not because we just like to enforce stuff on our users.

Hope it helps!
Comment 10 commit-hook freebsd_committer 2015-05-14 11:25:31 UTC
A commit references this bug:

Author: robak
Date: Thu May 14 11:24:47 UTC 2015
New revision: 386317
URL: https://svnweb.freebsd.org/changeset/ports/386317

  sysutils/zsd: update 0.0.2014.09.09 -> 0.0.2014.12.07

  PR:		195807
  Submitted by:	Fabian Keil <fk@fabiankeil.de> (maintainer)

Comment 11 Bartek Rutkowski freebsd_committer 2015-05-14 11:27:28 UTC
Committed with minor change, thanks for your work!
Comment 12 Fabian Keil 2016-02-02 15:58:35 UTC
Reopening as I'm still listed as maintainer despite the fact
that I lost control of the port:

As far as I'm concerned, there's no need to continue the discussion,
but please assign the port to ports@.
Comment 13 commit-hook freebsd_committer 2016-04-17 13:13:28 UTC
A commit references this bug:

Author: robak
Date: Sun Apr 17 13:13:17 UTC 2016
New revision: 413508
URL: https://svnweb.freebsd.org/changeset/ports/413508

  sysutils/zsd: reset maintainership

  PR:		195807
  Submitted by:	Fabian Keil <fk@fabiankeil.de> (maintainer)

Comment 14 Bartek Rutkowski freebsd_committer 2016-04-17 13:14:25 UTC
Thanks for your work and maintainership so far, hope to see you back in the future!