Bug 195807

Summary: [MAINTAINER] Update sysutils/zsd to 2014-12-07-c2d3662
Product: Ports & Packages Reporter: Fabian Keil <fk>
Component: Individual Port(s)Assignee: Bartek Rutkowski <robak>
Status: Closed FIXED    
Severity: Affects Some People CC: riggs, robak, xmj
Priority: ---    
Version: Latest   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
Update sysutils/zsd to 2014-12-07-c2d3662 none

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:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193805
Comment 1 Thomas Zander freebsd_committer freebsd_triage 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:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187926
Comment 3 Thomas Zander freebsd_committer freebsd_triage 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 freebsd_triage 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 freebsd_triage 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:

LICENSE= ISC

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,

https://wiki.freebsd.org/PortsLicenseInfrastructure#For_the_user
)

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 freebsd_triage 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 freebsd_triage 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

Log:
  sysutils/zsd: update 0.0.2014.09.09 -> 0.0.2014.12.07

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

Changes:
  head/sysutils/zsd/Makefile
  head/sysutils/zsd/distinfo
Comment 11 Bartek Rutkowski freebsd_committer freebsd_triage 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:
https://lists.freebsd.org/pipermail/svn-ports-all/2015-May/093367.html
https://lists.freebsd.org/pipermail/svn-ports-all/2015-May/093370.html

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 freebsd_triage 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

Log:
  sysutils/zsd: reset maintainership

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

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