public inbox for cygwin-licensing@cygwin.com
 help / color / mirror / Atom feed
From: Luke Kendall <luke.kendall@cisra.canon.com.au>
To: cygwin-licensing@cygwin.com
Subject: Software license check for commercial use of Cygwin
Date: Fri, 02 Oct 2009 09:52:00 -0000	[thread overview]
Message-ID: <4AC5A6EE.8010007@cisra.canon.com.au> (raw)

The URL http://cygwin.com/licensing.html (in summary) says that most 
Cygwin software is licensed under GNU GPL, X11 copyright (not sure how 
that's a license), and some are public domain.

I looked through all the cygwin-licensing mail archives.  I saw that in 
August 2008 Marvin faced the same situation I have.  I didn't see a 
result for that.  I discussed this on the general mailing list, and 
summarise the results here.

This email summarises my understanding of what a company would have to 
do to check that their internal use of Cygwin (no re-distribution) 
complies with all the licenses.


1.  Finding all the licenses

There in so 100% guaranteed complete list of all the licenses used by 
all the packages (rather than the above broad statement about an 
incomplete set of the licenses)?

To find all the licenses, Corinna pointed out that:

 > A list of licenses used in Cygwin packages is in the cygwin-docs
 > package, plus, every package with a non-standard license typically
 > provides it under /usr/share/doc/<packagename>.  However, there's no
 > guarantee that the list is complete.

- That's enough to work with, although the idea that the list I create 
could be incomplete is worrying.

- Using the information above, I can create a script that produces a 
list of all the licenses.  I guess if the license files themselves have 
varying names (ideally they'd all be just "license.txt"), I may need to 
then add some heuristics to pick the license file out.  From that I can 
then create something that produces just a set of the unique licenses. 
And then I can pass that to our legal department.

- I can also flexibly diff the constructed license text against new 
Cygwin releases, to identify changes to licenses and new licenses added 
for new packages.

2. Checking that the licenses are compatible with each other.

- Each company has to do this themselves. Cygwin is basically a 
volunteer effort, and no one has tried to do this.

(This contrasts to Debian/Ubuntu which do check the compatibility of the 
licenses in their distribution.)

3. Are all the package allowed to be used commercially?

- Again, this has to be checked by each company.   Cygwin is basically a 
volunteer effort, and no one has checked this.

- The package submission process does not attempt to screen for such 
packages and record such information.

4. Does each package have a license?

- Unknown.  You would find out by doing step 1.

- I don't think the package submission process tries to screen for 
packages that have no license, and record that fact.


5. Selecting the packages you can use

- The best suggestion for this is to mirror a download, identify which 
packages are okay, or which are not okay, and then create a secondary 
mirror that just contains the packages you want to use, or that you feel 
are safe to use.  Allow users to install from that pruned mirror.


And here are some questions that are more about processes within the 
Cygwin community:

Does anyone here know if any company has ever performed due diligence 
and tried to comply with all the licenses for all the Cygwin packages?

I can think of ways to capture some extra information when new packages 
are submitted to Cygwin, to make it easy to answer questions 3 and 4, 
and how to guarantee the list of licenses in the cygwin-docs package is 
complete.  Might someone be interested in making changes to the Cygwin 
new package acceptance process?

If I wrote some scripts that help support the legal check process, and 
submitted them here, do you think they might be considered for use to 
ease the burden on others?

Regards,

luke

                 reply	other threads:[~2009-10-02  9:52 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4AC5A6EE.8010007@cisra.canon.com.au \
    --to=luke.kendall@cisra.canon.com.au \
    --cc=cygwin-licensing@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).