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).