port "cask" -- installing prebuilt binaries

[Jason Liu]

>
> 2) My impression is that developers of commercial software would, in many
> cases, NOT want a third party (like MacPorts) to be distributing their
> software.  From their perspective, a third party introduces considerably
> more risk that users may end up with maliciously altered software.  Can we
> not expect to get takedown notices from certain publishers?
>

At a university where I used to work as a systems administrator, they
managed software on their fleet of Macs using a combination of Munki and
Jenkins. This included commercial software, including such titles such as
Autodesk AutoCAD, Adobe Creative Suite (before it became Creative Cloud),
Microsoft Office (before it became 365), and EndNote.

There were never any takedown notices from any of the commercial
publishers. In fact, the central IT group that developed and maintained the
Munki+Jenkins framework was frequently in contact with the software
companies, and worked with them on how to better deploy their software
titles using the framework. Their discussions typically revolved around how
to push out the licenses together with the software installers during
installations and (sometimes) remote updates.

As far as I know, the companies never, ever complained about our usage of
Munki and Jenkins. The commercial companies are typically only worried
about whether or not a customer has purchased the correct number of
licenses from them to cover the number of seats. They don't care how the
customer goes about deploying their software (or in fact are willing to
help customers with figuring out ways to better deploy their software using
the customers' deployment frameworks).

In theory, proprietary software could be deployed using MacPorts as well. I
have in fact done this. Our department had research groups that purchased
some proprietary Mac software that happened to be fairly Unix-like in terms
of its installation process. My fellow Mac admin colleague and I set up a
local MacPorts server (maybe it would be considered a mirror?), and we
wrote our own portfile for this proprietary software. We even contacted the
company to troubleshoot how we could make sure that our port contacted the
software's license server (which we set up on a different machine than our
local MacPorts server) during the installation process. The company never
complained about our using MacPorts to deploy their software. Their support
engineers even commented about how "awesome" and innovative it was that we
were using MacPorts to deploy commercial software. They thought that
MacPorts could only be used to deploy open source software.

-- 
Jason Liu


On Thu, Aug 6, 2020 at 11:04 AM Craig Treleaven <ctreleaven at macports.org>
wrote:

> > On Aug 6, 2020, at 10:10 AM, Ken Cunningham <
> ken.cunningham.webuse at gmail.com> wrote:
> >
> > How about I float a suggestion? We could append "_binary" to the name.
> Otherwise leave the categories, notes, etc as they are now.
> >
> > So a port that installs the Zoom teleconferencing application would be
> called "zoom_binary". (We can't use "zoom-binary" because variants us the +
> and - to do their thing.) You could find all your installed binaries with a
> simple grep...
> >
> > Open to a more descriptive, shorter suffix if anyone is thinking of one.
> >
> > Once we find metadata we agree on, then two more points to work out.
> > 1. Should we mirror the binary installers (no, I'd say)?
> > 2. We should require a mechanism to remove all traces of the software
> when uninstalling it, I think.
> >
>
> So, pretend I don’t know how Homebrew’s cask system works.  (I don’t.)
>
> 1) As a user, what is the advantage of this kind of system versus other
> avenues for software (i.e. the Mac App Store or direct download of a dmg
> from the developer web site)?  Doesn’t most such software include an
> auto-updater?  If so, won’t that conflict with MacPorts update handling?  A
> potential disadvantage would be the time lag from a new version being
> released until a new ‘cask’ is available, right?
>
> 2) My impression is that developers of commercial software would, in many
> cases, NOT want a third party (like MacPorts) to be distributing their
> software.  From their perspective, a third party introduces considerably
> more risk that users may end up with maliciously altered software.  Can we
> not expect to get takedown notices from certain publishers?
>
> 3) Is the MacPorts mirror network willing to contribute bandwidth for
> distributing non-open source software?  Will we sour our relations with
> some of the mirrors if we use/abuse their bandwidth this way?  Why do we
> want to use our bandwidth that way?
>
> Craig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20200806/f9e91d00/attachment.htm>