Re: dpkg/license related proposal
On Mon, 1 Nov 1999 14:57:00 -0500, Ben Collins <bcollins@debian.org> wrote:
>On Mon, Nov 01, 1999 at 02:48:46PM -0500, Amy Fong wrote:
>> A short while ago, I was pondering on all the things that happen
>> consequences of people being "whatever (fill in the blanks)" of licensing
>> situations and I have a bit of a proposition to make.
>I don't like the idea of forcing people to look at licenses for stuff in
>main (perhaps non-free or contrib, but not main).
>
>I do think we need a license field in the control/package fields.
I think Amy's intent was that these licenses should be presented to users
_especially_ for packages in main. Based on my conversations with her,
I think she is specifically trying to increase awareness of licenses in
the main section, in particular the very significant restrictions that
the GPL may impose upon users, e.g. that you can't distribute anything
GPL linked against anything QPL without an exception clause.
That said, we should select a mechanism that has the following properties:
1. Allow for re-use of licenses, and machine recognition of
such re-use.
It should be possible to install many packages that use the same license
terms while only agreeing to the text of the license once. Example text:
22 packages use the following software license:
[GPL text here]
L)ist of packages that this agreement refers to,
A)ccept license for all listed packages,
R)eject license for all listed packages,
S)how license text again,
select I)ndividual packages,
H)elp:
This may be tricky to implement legally, since the user would be making
an agreement with many licensors at the same time using license text
that is written with one licensor and one licensee in mind.
This would still be a lot of prompting...I count (with md5sum) 160
different licenses on my system, from 504 installed packages. Many of
these licenses are substantially identical except for the names of
copyright holders, copyright dates, _compilation_ dates, and other
trivial differences. In order to be feasible at all, we'd have to have
separate statements of copyright ownership, distribution, and end-user
licenses, and we'd have to group them together.
2. Allow upgrades of a package without requiring new agreement
each time.
This may be a contentious issue. I would allow it; others would not.
Ideally, if you had agreed to GPL 2 for package 'hello' version 1.14-3,
you would not have to agree to the same GPL for version 1.14-4, or 1.15-1.
'apt-get upgrade' would be very painful otherwise.
But then you get into murky legal issues: each new revision of a package
is a separate entity, and must be licensed separately. Is it OK to have
a notice that reads:
you have upgraded 50 packages:
[list of package names]
These packages are licensed to you under certain specific terms.
In the past, you have agreed to identical license terms for
earlier versions of these packages.
Do you wish to accept the same terms again for the new revisions
of these packages?
A)ccept terms, R)eject terms, S)how terms, L)ist packages, H)elp:
3. Allow upgrades of a license without a new release of the
package.
Some licenses allow this. "You may use the GPL version 2, or at your
option, any later version" becomes "Pre-depends: license-gpl (>= 2)".
I do think that the user should be presented with the new license text
and given the option to accept it or not. The "hold" state would be
good for those who disagree with new license terms but still want old
packages.
4. Allow all of this prompting to be turned off, but only if
the license text has been read and agreed to.
Another potentially contentious issue. I'd like to require end users to
read licenses, but I'm not sure how to put that into code.
To me, the important thing about bulk-installs and user-friendly installs
is that someone, somewhere, reads and understands the license, and agrees
to abide by its terms. In a corporate setting, that agreement can be made
with the corporation on behalf of all of its employees (who are in
turn obligated by employment agreement to act in accordance with the
instructions of their employer). In a beowulf cluster, that agreement
can be made with the one or two actual human beings who will be operating
the dozens, hundreds, or thousands of machines in the cluster. In a
consumer-oriented product, that agreement has to be made with the end
user.
All of these are very difficult to deal with from the point of view of
code running on the machine that the software is being installed on, so
perhaps the best answer is to set up the boot floppies so that they
prompt for licenses, and provide a straightforward and documented way to
do bulk installations (e.g. a bulk installer may rebuild the base system
tarball with the license packages "pre-configured", i.e. licenses
accepted).
.
Reply to: