Bug 190981 - archivers/kzip possible licensing issue
Summary: archivers/kzip possible licensing issue
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Port Management Team
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-12 21:52 UTC by craig001
Modified: 2018-03-20 00:33 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description craig001 2014-06-12 21:52:17 UTC
On looking into fixing the portsmon fetch issue for this port I was tempted to update to the later binary tarball blob and sort out stage.  However, on the developers website it states;

http://advsys.net/ken/utils.htm

8<---

So here is the license:

    The command line versions of PNGOUT.EXE and KZIP.EXE are free, as are the Mac and Linux ports. You may use PNGOUT- or KZIP-compressed content for non-commercial or commercial purposes.
    Redistributing, repackaging, or reusing the PNGOUT or KZIP executable is prohibited without the express consent of Ardfry Imaging, LLC, and a formal business agreement. 

For business requests (such as bundling), please write directly to my business partner, David Blake. He will be able to answer your question much better than I can. 

--->8

As the ports collection could be interpreted as redistribution should this port exist ??
Comment 1 Bryan Drewery freebsd_committer freebsd_triage 2014-06-13 17:08:10 UTC
"Redistributing, repackaging, or reusing the ... _executable_".

We are already restricting this port from being packaged or distributed in binary/executable form. From what you've shown, the license does not restrict distributing source or meta files that fetch and build the source.

I don't see a problem here.
Comment 2 Bryan Drewery freebsd_committer freebsd_triage 2014-06-13 17:21:32 UTC
It was pointed out to me that we don't build from source, we fetch a binary. I can see how that may be against "reuse" of the executable.
Comment 3 craig001 2014-06-13 17:43:23 UTC
Yes, that was my understanding as well, we fetch the distfile containing the binary executable then just unpack it... no compiling.
As far as I am aware the source code is not in the public domain.
Comment 4 Xin LI freebsd_committer freebsd_triage 2015-05-21 00:30:33 UTC
Can we close this one?  I agree with Bryan that we are merely providing a set of script that helps the user to download and install the binaries, and we specifically disabled packaging and does not distribute the package.
Comment 5 craig001 2015-05-21 12:26:43 UTC
Hello Xin

As mentioned in the previous comments, we effectively redistribute the executable blob which to my understanding is against their license rules.

Kind Regards

Craig Butler
Comment 6 Bryan Drewery freebsd_committer freebsd_triage 2015-05-21 16:54:41 UTC
(In reply to craig001 from comment #5)
> Hello Xin
> 
> As mentioned in the previous comments, we effectively redistribute the
> executable blob which to my understanding is against their license rules.
> 

FreeBSD certainly does not redistribute anything here. We do not mirror the distfiles nor do we provide a package. All we provide is effectively a script to fetch the distfile/binary from the upstream. The intent of the license seems to be respected here. Even an end-user creating a 'package' on their local system or to send to one of their own systems seems perfectly reasonable as they are not violating the intent. They are not implicitly providing that package to the world by using ports. If the user does that with or without ports then it's their own fault.

In context of the full statement from the author on their site I feel we're fine here.

I will mail the author to check.
Comment 7 Walter Schwarzenfeld freebsd_triage 2018-01-12 04:46:27 UTC
No reply since 2015-05-21. I think this could be closed.
Comment 8 craig001 2018-03-20 00:33:02 UTC
closed as per comment