<div dir="ltr"><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>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?</div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>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).</div><div><br></div><div>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.<br></div><div><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>-- </div><div>Jason Liu<br></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 6, 2020 at 11:04 AM Craig Treleaven <<a href="mailto:ctreleaven@macports.org">ctreleaven@macports.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> On Aug 6, 2020, at 10:10 AM, Ken Cunningham <<a href="mailto:ken.cunningham.webuse@gmail.com" target="_blank">ken.cunningham.webuse@gmail.com</a>> wrote:<br>
> <br>
> How about I float a suggestion? We could append "_binary" to the name. Otherwise leave the categories, notes, etc as they are now. <br>
> <br>
> 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...<br>
> <br>
> Open to a more descriptive, shorter suffix if anyone is thinking of one.<br>
> <br>
> Once we find metadata we agree on, then two more points to work out. <br>
> 1. Should we mirror the binary installers (no, I'd say)?<br>
> 2. We should require a mechanism to remove all traces of the software when uninstalling it, I think.<br>
> <br>
<br>
So, pretend I don’t know how Homebrew’s cask system works.  (I don’t.)  <br>
<br>
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?<br>
<br>
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?<br>
<br>
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?<br>
<br>
Craig<br>
<br>
</blockquote></div></div>