Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 11 Feb 2025 23:33:40 -0800
From:      list_freebsd@bluerosetech.com
To:        Yusuf Yaman <nxjoseph@protonmail.com>, freebsd-ports@freebsd.org
Subject:   Re: How do I specify and attribute multiple licenses?
Message-ID:  <135785ca-8fcf-295c-19be-13df4a77aa3d@bluerosetech.com>
In-Reply-To: <c208f063-5f21-4b6b-8a93-51e72bfccb91@protonmail.com>
References:  <57ce3279-00d5-3a92-38a8-42007ab2b0a8@bluerosetech.com> <33f0c59f-d544-4da1-a8e8-ef5b066e97e7@protonmail.com> <d2b10ea7-76d4-d0c5-05a1-fac5131085e7@bluerosetech.com> <c208f063-5f21-4b6b-8a93-51e72bfccb91@protonmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2025-02-11 12:32, Yusuf Yaman wrote:
> Sorry but I didn't understand what you are trying to do properly but is
> it an option to make a port for every dependency?

Composer-managed dependencies are, to use compiler parlance, 
static-linked when the main application is compiled.  Assuming they're 
even available as ports, I would still need to copy the code into the 
vendor subdirectory and generate the linking code so the main 
application requires (PHP for include) them at run-time.  IOW, port or 
no, I would still need to use Composer to actually install them.  Since 
Composer won't leverage installed ports (it fetches everything from 
Github directly), moving the dependencies into ports is moot.

Thank you for thinking through this and offering alternatives.  These 
are ideas I've worked through previously, and it's nice to be able to 
revisit them and reiterate my understanding for someone else.

Basically I have two options:

1. Leave the Composer run as a step for the user to complete.  This is 
the expected process, but it means what they end up installing is 
potentially something I've haven't test because when they run Composer 
it can select a newer version than what I tested, and now I, the lowly 
port maintainer, am stuck with someone emailing me about their port not 
working when the fix will ultimately mean changing some JSON over which 
I may have no control (6 of the 10 dependencies are indirect dependencies).

2. I can do the Composer run myself, then provided the result as a 
bundle to go with the port.  This lets me deliver the port with the 
dependecies tested and locked for that PORTVERSION/PKGVERSION.  It means 
I can provide the necessary QA for what the user will end up installing 
and am in a better position to provide support.

The first option is less work up front and avoids licensing questions, 
but leaves me with an unknown future support problem.  The second option 
is more work up front, and requires I handle things like licensing 
administrivia, but makes the port more reliable/supportable.

> On 2/11/25 23:20, list_freebsd@bluerosetech.com wrote:
>> On 2025-02-11 11:48, Yusuf Yaman wrote:
>>> Can you see Porter's Handbook 5.8.7 LICENSE_DISTFILES and
>>> LICENSE_DISTFILES_NAME.
>>>
>>> If you have multiple distribution files, then this maybe work for you.
>>>
>>> Example 38. LICENSE_DISTFILES
>>> Used when the distribution files do not all have the same license. For
>>> example, one has a code
>>> license, and another has some artwork that cannot be redistributed:
>>> MASTER_SITES=   SF/some-game
>>> DISTFILES=      ${DISTNAME}${EXTRACT_SUFX} artwork.zip
>>> LICENSE=        BSD3CLAUSE ARTWORK
>>> LICENSE_COMB=   dual
>>> LICENSE_NAME_ARTWORK=      The game artwork license
>>> LICENSE_TEXT_ARTWORK=      The README says that the files cannot be
>>> redistributed
>>> LICENSE_PERMS_ARTWORK=     pkg-mirror pkg-sell auto-accept
>>> LICENSE_DISTFILES_BSD3CLAUSE=   ${DISTNAME}${EXTRACT_SUFX}
>>> LICENSE_DISTFILES_ARTWORK= artwork.zip
>> That won't work in this case, because it's not the port that fetches the
>> dependencies, but Composer.  The port fetches two distfiles:
>>
>> - the main application distfile
>> - a tarball containing the other distributions
>>
>> I make the second distfile by running `composer install` myself then
>> tarballing the vendor subdirectory.  All four licenses apply to its
>> contents.
> 
> 




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?135785ca-8fcf-295c-19be-13df4a77aa3d>