Re: [ANNOUNCEMENT] cygport 0.35.2-1

Re: [ANNOUNCEMENT] cygport 0.35.2-1

[Brian Inglis]

On 2022-07-04 10:30, Andrey Repin wrote:
>> Jon Turney wrote:
>>> The following packages have been uploaded to the Cygwin distribution:
>>> * cygport-0.35.2-1
>>> cygport is the standard method for building and maintaining
>>> packages for the Cygwin distribution.
>>> Jon Turney (7):
>>>        Add LICENSE variable

>> I would suggest to print a note or warning if LICENSE is missing.
>> This may encourage maintainers to add it.

> I second that emotion.
> For those unconvinced, here's a friendly detailed explanation:
> https://blog.codinghorror.com/pick-a-license-any-license/
Good article! Great quote from comments:
"Most developers will spend more time deciding on which license to use 
and figuring out the difference between all of the licenses than they 
will developing the app they want to license."

I would suggest not yet, as there is no other documentation that it 
exists, what it should contain, or suggestions for use, and it would be 
annoying to maintainers if it appeared every time the .cygport is parsed 
during a build! It needs to be discussed some more on cygwin-apps.

Perhaps a reminder at scallywag build or cygport upload, once the 
requirements have been documented?

I am one of the initial users and am still short of 50% of my packages, 
as it is non-trivial to decide what to call a licence if not (and even 
sometimes if) explicitly documented in the package.
Most packages contain some file called something like COPYING sometimes 
LICEN[CS]E which contains a bunch of clauses often without any label or 
name, which the maintainer has to match against known licences, possibly 
catalogued and named at the SPDX, CC, OSI, FSF/GNU sites, or another 
such as Beerware.

For example, curl had a licence which is now called the "curl license": 
not sure if that is even valid in most English-speaking jurisdictions 
where the noun is "licenCe": IANAL!
Similar issue to the legal basis of time being solar or GMT where UTC is 
not defined in any legislation.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

LICENSE in cygport (was Re: [ANNOUNCEMENT] cygport 0.35.2-1)

[Jon Turney]

On 04/07/2022 20:41, Brian Inglis wrote:
> On 2022-07-04 10:30, Andrey Repin wrote:
>>> Jon Turney wrote:
>>>> The following packages have been uploaded to the Cygwin distribution:
>>>> * cygport-0.35.2-1
>>>> cygport is the standard method for building and maintaining
>>>> packages for the Cygwin distribution.
>>>> Jon Turney (7):
>>>>        Add LICENSE variable
> 
>>> I would suggest to print a note or warning if LICENSE is missing.
>>> This may encourage maintainers to add it.
> 
>> I second that emotion.
>> For those unconvinced, here's a friendly detailed explanation:
>> https://blog.codinghorror.com/pick-a-license-any-license/
> Good article! Great quote from comments:
> "Most developers will spend more time deciding on which license to use 
> and figuring out the difference between all of the licenses than they 
> will developing the app they want to license."

That is an orthogonal discussion:  We already require that packages have 
a definite license, and that it's an OSI approved one, so we know that 
we can distribute it.

We just don't record that information in the package currently.

> I would suggest not yet, as there is no other documentation that it 
> exists, what it should contain, or suggestions for use, and it would be 
> annoying to maintainers if it appeared every time the .cygport is parsed 
> during a build! It needs to be discussed some more on cygwin-apps.
> 
> Perhaps a reminder at scallywag build or cygport upload, once the 
> requirements have been documented?

Yes, the first step would be to warn at upload if license: is missing, 
but we're not there yet.

I am proposing that the value of LICENSE should be a SPDX license 
expression, and the documentation should now reflect that.