Mailing List Archive

Clarify the "as-is" license?
From time to time cases like the following are brought up to
licenses@gentoo.org, for a package that is labelled with
LICENSE="as-is":

| Permission to use, copy, modify and/or distribute this software in
| both binary and source form, for non-commercial purposes, is hereby
| granted [...]

This is clearly not free/open-source software because of the
non-commercial restriction.

In my understanding, our "as-is" really is what opensource.org lists
as "Historical Permission Notice and Disclaimer" [1]. Obviously it's
very permissive (comparable to MIT or BSD-2). It is also included in
our @OSI-APPROVED license group.

So, either we should only mark free software with the as-is label.
Then it might help if the text was clarified as in the patch below.

Or we continue marking random non-free stuff with as-is. Then we
should IMHO remove as-is from our free license groups, create a
licenses/HPND file (text as in [1]), and move the free packages to it.

Currently, 679 packages have as-is in their LICENSE.

Ulrich

[1] <http://opensource.org/licenses/HPND>

--- as-is 12 Jan 2012 19:03:23 -0000 1.3
+++ as-is 23 Sep 2012 09:43:19 -0000
@@ -1,5 +1,5 @@
-This is a generic place holder for a class of licenses that boil down to do
-no guarantees and all you get is what you have. The language is usually
+This is a generic place holder for a class of licenses that allow you to
+do most anything you want with the software. The language is usually
similar to:

Permission to use, copy, modify, and distribute this software and its
@@ -12,13 +12,11 @@
suitability of this software for any purpose. It is provided "as is"
without express or implied warranty.

-
-You will need to check the license that came with the software for the exact
-specifics. Generally you are free to do most anything you want with "as is"
-software but you should not take this license as legal advice.
+You will need to check the license that came with the software (usually as
+permission notice in the source files themselves) for the exact wording.

Note: Most all license have an "as is" clause. For our purposes this does
-not make all software in this category. This category is for software with
-very little restrictions.
+not make all software in this category. This category is for software that
+complies with the Open Source Definition and has very little restrictions.

The information in this license about licenses is presented "as is". :-P
Re: Clarify the "as-is" license? [ In reply to ]
On Sun, Sep 23, 2012 at 6:56 AM, Ulrich Mueller <ulm@gentoo.org> wrote:
> So, either we should only mark free software with the as-is label.
> Then it might help if the text was clarified as in the patch below.
>
> Or we continue marking random non-free stuff with as-is. Then we
> should IMHO remove as-is from our free license groups, create a
> licenses/HPND file (text as in [1]), and move the free packages to it.

Well, I can see legal problems any time you take a thousand things
that all have a bunch of non-identical, informal licenses and treat
them as the same. However, I don't think it is practical to do
otherwise.

How about having an as-is-free and an as-is-nonfree. The easier thing
on maintainers is to make one of those just "as-is," and if we want to
make sure we check them all the better thing is to not do that.
However, making a new as-is-free and treating anything as-is as not
free is probably good enough. I don't think it is wise to do the
reverse, even though that involves the least amount of work.

Rich
Re: Clarify the "as-is" license? [ In reply to ]
>>>>> On Sun, 23 Sep 2012, Rich Freeman wrote:

> Well, I can see legal problems any time you take a thousand things
> that all have a bunch of non-identical, informal licenses and treat
> them as the same. However, I don't think it is practical to do
> otherwise.

I agree. Creating hundreds of license files because of minor
variations in wording isn't useful.

> How about having an as-is-free and an as-is-nonfree. The easier
> thing on maintainers is to make one of those just "as-is," and if we
> want to make sure we check them all the better thing is to not do
> that. However, making a new as-is-free and treating anything as-is
> as not free is probably good enough. I don't think it is wise to do
> the reverse, even though that involves the least amount of work.

If we really decide to move things to a new license file, then I'd
rather avoid the name "as-is" because it is partly the reason for the
confusion. We should follow the OSI and SPDX [1] naming, unless there
are good reasons against it.

Concerning "as-is-nonfree", we already have the slightly more specific
"freedist" and "free-noncomm".

Ulrich

[1] <http://www.spdx.org/licenses/HPND>
Re: Clarify the "as-is" license? [ In reply to ]
On 09/23/2012 02:04 PM, Ulrich Mueller wrote:
> If we really decide to move things to a new license file, then I'd
> rather avoid the name "as-is" because it is partly the reason for the
> confusion.

I agree on that. I saw it more than once that people use "as-is" for the
license, just because there is an "as is" clause.
Re: Clarify the "as-is" license? [ In reply to ]
>>>>> On Sun, 23 Sep 2012, hasufell wrote:

>> If we really decide to move things to a new license file, then I'd
>> rather avoid the name "as-is" because it is partly the reason for
>> the confusion.

> I agree on that. I saw it more than once that people use "as-is" for
> the license, just because there is an "as is" clause.

Right. Here's a small (but prominent) sample, namely all "as-is"
packages from the amd64 livecd and stage3:

- net-misc/ntp: "as-is" looks fine as main license, although some
parts of the code are under different licenses like GPL (but I
haven't checked in detail what gets installed).

- sys-apps/hdparm: "as-is" approximates it (but different wording).
Debian lists this package as "BSD".

- dev-util/yacc: "public-domain" according to README.

- media-libs/libpng: Comes with its own license. Free.

- media-libs/portaudio: "MIT"

- net-misc/openssh: BSD-ish, something like "BSD BSD-2 as-is BEER-WARE
public-domain" would be close.

- net-wireless/rfkill: "ISC"

- sys-apps/man-pages: Patchwork of files with different free
licenses. "as-is GPL-2+ BSD MIT LDP-1 public-domain" would cover
most of it.

While the above are at least free software (mostly BSD/MIT like),
I think that as-is is completely wrong for the following:

- app-admin/passook: Seems to have no license at all.

- net-wireless/zd1201-firmware: No license in tarball or on homepage.

- net-wireless/prism54-firmware: Ditto, and package is mirror
restricted. (How can it be on our install media then?)

Ulrich
Re: Clarify the "as-is" license? [ In reply to ]
On Sun, Sep 23, 2012 at 5:37 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
> - net-misc/ntp: "as-is" looks fine as main license, although some
> parts of the code are under different licenses like GPL (but I
> haven't checked in detail what gets installed).

Uh, if we're distributing the sources, and they contain GPL content,
then the only valid answer is GPL, or nomirror.

> While the above are at least free software (mostly BSD/MIT like),
> I think that as-is is completely wrong for the following:
>
> - app-admin/passook: Seems to have no license at all.
>
> - net-wireless/zd1201-firmware: No license in tarball or on homepage.
>
> - net-wireless/prism54-firmware: Ditto, and package is mirror
> restricted. (How can it be on our install media then?)
>

No license, no distribution, unless there is a declaration that it is
in the public domain, in which case that is the "license."

Thanks for checking!

Rich
Re: Clarify the "as-is" license? [ In reply to ]
On Sun, 2012-09-23 at 23:37 +0200, Ulrich Mueller wrote:
> - net-wireless/zd1201-firmware: No license in tarball or on homepage.

Ubuntu distributes it in their linux-firmware package with the following
LICENCE.zd1201 file:

The firmware was originally distributed by Zydas in their original driver package.

(You can still find it at http://linux-lc100020.sourceforge.net/ )
This package was distributed under both the GPL and MPL.
The firmware was in it in the form of a large array in a header file.

More precisely, if you download the old Zydas driver source from
http://sourceforge.net/projects/linux-lc100020/files/%28OLD%29%20wlan-ng%20based%20driver/
the license terms are

The contents of this file are subject to the Mozilla Public
License Version 1.1 (the "License"); you may not use this file
except in compliance with the License. You may obtain a copy of
the License at http://www.mozilla.org/MPL/

Software distributed under the License is distributed on an "AS
IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
implied. See the License for the specific language governing
rights and limitations under the License.

Alternatively, the contents of this file may be used under the
terms of the GNU Public License version 2 (the "GPL"), in which
case the provisions of the GPL are applicable instead of the
above. If you wish to allow the use of your version of this file
only under the terms of the GPL and not to allow others to use
your version of this file under the MPL, indicate your decision
by deleting the provisions above and replace them with the notice
and other provisions required by the GPL. If you do not delete
the provisions above, a recipient may use your version of this
file under either the MPL or the GPL.

tl;dr: LICENSE="|| ( MPL-1.1 GPL-2 )"

-Alexandre.
Re: Clarify the "as-is" license? [ In reply to ]
>>>>> On Sun, 23 Sep 2012, Rich Freeman wrote:

>> - net-misc/ntp: "as-is" looks fine as main license, although some
>> parts of the code are under different licenses like GPL (but I
>> haven't checked in detail what gets installed).

> Uh, if we're distributing the sources, and they contain GPL content,
> then the only valid answer is GPL,

Unfortunately, it's not clear from our documentation if the LICENSE
variable applies to the source tarball or to the files that the
package installs on the user's system.

I tend to interpret it in the latter sense. To illustrate why, let's
look at sci-visualization/gnuplot-4.6.0 as an example:

LICENSE="gnuplot GPL-2 bitmap? ( free-noncomm )"

The bulk of the package is free software, distributed under the
gnuplot license or the GPL-2. However, there's an additional notice
with a no-sale clause in a single source file (src/bitmap.c).
If LICENSE applies to installed files, than we can disable the
functionality via USE=-bitmap and we're done.

However, if we say that LICENSE covers the source tarball, then we
either need to change it to an unconditional "gnuplot GPL-2
free-noncomm", which has the consequence that gnuplot is no longer
installable for users who have ACCEPT_LICENSE="-* @FREE".

Or, we must no longer distribute pristine source from upstream, but
repack them into a new tarball with bitmap.c removed. This would have
to be done for every release, which isn't feasible.

Similar reasoning applies to the various Linux kernel packages that
have LICENSE="GPL-2 !deblob? ( freedist )".

> or nomirror.

That's a different issue. In the case of RESTRICT="mirror" it is clear
that it applies to the sources that we distribute.

Ulrich
Re: Clarify the "as-is" license? [ In reply to ]
On Mon, Sep 24, 2012 at 3:02 AM, Ulrich Mueller <ulm@gentoo.org> wrote:
> Unfortunately, it's not clear from our documentation if the LICENSE
> variable applies to the source tarball or to the files that the
> package installs on the user's system.

Hmm, if these aren't the same, then more likely than not something is
wrong, but perhaps we'll have to confront this issue at some point.

>
> I tend to interpret it in the latter sense. To illustrate why, let's
> look at sci-visualization/gnuplot-4.6.0 as an example:
>
> LICENSE="gnuplot GPL-2 bitmap? ( free-noncomm )"
>
> The bulk of the package is free software, distributed under the
> gnuplot license or the GPL-2. However, there's an additional notice
> with a no-sale clause in a single source file (src/bitmap.c).
> If LICENSE applies to installed files, than we can disable the
> functionality via USE=-bitmap and we're done.

I guess we can get away with redistributing the source files each
under their respective license, since there is no "derived work" at
this point. However, any binaries built from such a thing would not
be redistributable. None of those licenses are GPL-compatible.

>
> However, if we say that LICENSE covers the source tarball, then we
> either need to change it to an unconditional "gnuplot GPL-2
> free-noncomm", which has the consequence that gnuplot is no longer
> installable for users who have ACCEPT_LICENSE="-* @FREE".

Here is the thing - suppose somebody runs a Gentoo mirror but has ads
on their page and is a commercial organization. They can't even
MIRROR that source legally because of the presence of that one file,
unless its license allows for-profit redistribution of the source.

>
> Or, we must no longer distribute pristine source from upstream, but
> repack them into a new tarball with bitmap.c removed. This would have
> to be done for every release, which isn't feasible.

Not necessarily the end of the world to be honest - how many things do
we have in the tree for which upstream only has an scm and no source
tarballs, so we have to roll our own on every release anyway due to
the prohibition on live scm packages being unmasked?

>
> Similar reasoning applies to the various Linux kernel packages that
> have LICENSE="GPL-2 !deblob? ( freedist )".
>
>> or nomirror.
>
> That's a different issue. In the case of RESTRICT="mirror" it is clear
> that it applies to the sources that we distribute.

I think the key is to make sure that the sources at least can be
distributed without getting anybody into trouble. If so we don't need
to restrict them. However, I don't think the final thing can be @FREE
- it isn't binary redistributable as the final built code isn't
licensed at all. We should point this out somehow.

Rich
Re: Clarify the "as-is" license? [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 23/09/12 08:10 AM, hasufell wrote:
> On 09/23/2012 02:04 PM, Ulrich Mueller wrote:
>> If we really decide to move things to a new license file, then
>> I'd rather avoid the name "as-is" because it is partly the reason
>> for the confusion.
>
> I agree on that. I saw it more than once that people use "as-is"
> for the license, just because there is an "as is" clause.
>


What about having some "snippet" licenses that could be amalgomated
as-needed for a package?

IE:
- -'as-is' would be the generic "as-is" statement
- -'free-non-commercial' would be a "free/unrestricted for
non-commercial use" statement
- -'free-unrestricted' would be a statement of more or less public domain

- -..etc...


..and then ebuilds can include the particular phrases that apply? ie,
LICENSE="(as-is free-non-commercial)" , essentially an
'assemble-your-own-license' from the snippets.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBgWagACgkQ2ugaI38ACPDY2wD9EnVU9c1E6xW7o2pOhJbj8ocW
KHdXq0qiK156X4RFPCEBAJ4aNaEsF0cy615RLOjFm1r/vqNRcX5t91g+1psaNbiC
=gwvg
-----END PGP SIGNATURE-----
Re: Clarify the "as-is" license? [ In reply to ]
>>>>> On Mon, 24 Sep 2012, Rich Freeman wrote:

>> I tend to interpret it in the latter sense. To illustrate why, let's
>> look at sci-visualization/gnuplot-4.6.0 as an example:
>>
>> LICENSE="gnuplot GPL-2 bitmap? ( free-noncomm )"
>>
>> The bulk of the package is free software, distributed under the
>> gnuplot license or the GPL-2. However, there's an additional notice
>> with a no-sale clause in a single source file (src/bitmap.c).
>> If LICENSE applies to installed files, than we can disable the
>> functionality via USE=-bitmap and we're done.

> I guess we can get away with redistributing the source files each
> under their respective license, since there is no "derived work" at
> this point. However, any binaries built from such a thing would not
> be redistributable. None of those licenses are GPL-compatible.

This is not a problem here. Gnuplot itself is licensed under the
gnuplot license. The GPL licensed parts (e.g. Gnuplot mode for Emacs)
are not linked with it but installed separately. The GPL doesn't
forbid mere accumulation of things, so redistribution of the binary
isn't an issue.

> [...]

> Not necessarily the end of the world to be honest - how many things
> do we have in the tree for which upstream only has an scm and no
> source tarballs, so we have to roll our own on every release anyway
> due to the prohibition on live scm packages being unmasked?

Too many already, so we shouldn't add more when it's not necessary.

Ulrich
Re: Clarify the "as-is" license? [ In reply to ]
Ian Stakenvicius schrieb:
> IE: - -'as-is' would be the generic "as-is" statement -
> -'free-non-commercial' would be a "free/unrestricted for
> non-commercial use" statement - -'free-unrestricted' would be a
> statement of more or less public domain
>
> - -..etc...

Why not directly use the FSF freedoms:
The freedom to run the program, for any purpose (freedom 0).
The freedom to study how the program works, and change it so it does
your computing as you wish (freedom 1).
The freedom to redistribute copies so you can help your neighbor
(freedom 2).
The freedom to distribute copies of your modified versions to others
(freedom 3).

I think when combined appropriately, they nicely cover most of the
cases of current "as-is" packages.

> ..and then ebuilds can include the particular phrases that apply?
> ie, LICENSE="(as-is free-non-commercial)" , essentially an
> 'assemble-your-own-license' from the snippets.

We would maybe have to find a different operator for license
concatenation.


Best regards,
Chí-Thanh Christopher Nguyễn
Re: Clarify the "as-is" license? [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 24/09/12 06:46 AM, Rich Freeman wrote:
> On Mon, Sep 24, 2012 at 3:02 AM, Ulrich Mueller <ulm@gentoo.org>
> wrote:
>> Unfortunately, it's not clear from our documentation if the
>> LICENSE variable applies to the source tarball or to the files
>> that the package installs on the user's system.
>
> Hmm, if these aren't the same, then more likely than not something
> is wrong, but perhaps we'll have to confront this issue at some
> point.
>

After the debate on IRC that spawn the request to add GPL-2 to LICENSE
for all the packages that install init scripts, I would expect that
the LICENSE applies primarily to the installed-image but when
necessary/different would also apply to an upstream distfile and its
contents. However, it is safe to exclude licenses of patches,
contributed files, etc. that are stored in ${FILESDIR}.

Is this interpretation correct?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBgXgoACgkQ2ugaI38ACPCxkgEAqydntc6k6YcC3lce2aaxMUSy
csX3CfTcsKA04TDeZskA/30v+V6G1JXaTUocI4BszvzYqUvt6b+go3uJI+I0LUnn
=8B/x
-----END PGP SIGNATURE-----
Re: Clarify the "as-is" license? [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 24/09/12 09:15 AM, Chí-Thanh Christopher Nguyễn wrote:
> Ian Stakenvicius schrieb:
>> IE: - -'as-is' would be the generic "as-is" statement -
>> -'free-non-commercial' would be a "free/unrestricted for
>> non-commercial use" statement - -'free-unrestricted' would be a
>> statement of more or less public domain
>>
>> - -..etc...
>
> Why not directly use the FSF freedoms: The freedom to run the
> program, for any purpose (freedom 0). The freedom to study how the
> program works, and change it so it does your computing as you wish
> (freedom 1). The freedom to redistribute copies so you can help
> your neighbor (freedom 2). The freedom to distribute copies of your
> modified versions to others (freedom 3).
>
> I think when combined appropriately, they nicely cover most of the
> cases of current "as-is" packages.

Yep, it would. Still, however, need the standard "Provided 'AS-IS'
with no disclaimer of warranty blah blah" statement which afaik would
not be included in any way in the FSF list (unless one of those
freedoms would actually be 'The freedom of the author to have no
repercussions whatsoever brought against them as a result of the
program's use or mis-use', of course)



>
>> ..and then ebuilds can include the particular phrases that
>> apply? ie, LICENSE="(as-is free-non-commercial)" , essentially an
>> 'assemble-your-own-license' from the snippets.
>
> We would maybe have to find a different operator for license
> concatenation.
>

I don't know if an operator would actually be necessary; i just
figured ()-wrapping would asthetically differentiate these from
additional licenses that might be tagged on (ie if part of the package
was also GPL-2)


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBgX0sACgkQ2ugaI38ACPBdtwD9HVqCMlBKh6dNvylp+6bC5PMx
GezaE4DdeEU7n86E4JcBAJ+GG+zQ4MkMAj9cjP1qBXD3MkpzocjNz+u4OlRI1AU4
=waBv
-----END PGP SIGNATURE-----
Re: Clarify the "as-is" license? [ In reply to ]
>>>>> On Mon, 24 Sep 2012, Chí-Thanh Christopher Nguyễn wrote:

> Ian Stakenvicius schrieb:
>> IE: - -'as-is' would be the generic "as-is" statement -
>> -'free-non-commercial' would be a "free/unrestricted for
>> non-commercial use" statement - -'free-unrestricted' would be a
>> statement of more or less public domain
>>
>> - -..etc...

> Why not directly use the FSF freedoms:
> The freedom to run the program, for any purpose (freedom 0).
> The freedom to study how the program works, and change it so it does
> your computing as you wish (freedom 1).
> The freedom to redistribute copies so you can help your neighbor
> (freedom 2).
> The freedom to distribute copies of your modified versions to others
> (freedom 3).

> I think when combined appropriately, they nicely cover most of the
> cases of current "as-is" packages.

This has been suggested before, but for license groups. The problem
is that the four freedoms are good criteria for Free Software, but
there's no good mapping to the elements of most non-free licenses.

Try it yourself for a few concrete cases (of non-free licenses in our
tree), and you'll see what I mean.

Ulrich
Re: Clarify the "as-is" license? [ In reply to ]
I've created licenses/HPND [1] now, and added it to the @OSI-APPROVED
group. So packages whose license matches this template can be changed
from as-is to HPND. (And please, _only_ OSD-compliant packages.
We don't want the same mess again, as we have with as-is.)

I'll also remove as-is from @GPL-COMPATIBLE and @OSI-APPROVED again,
as soon as all packages in the system set have been fixed (only
net-misc/openssh and sys-apps/man-pages). It shouldn't have been added
to these groups, in the first place.

Ulrich

[1] <http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/licenses/HPND>
Re: Re: Clarify the "as-is" license? [ In reply to ]
On 25/09/2012 04:04, Ulrich Mueller wrote:
> I've created licenses/HPND [1] now, and added it to the @OSI-APPROVED
> group. So packages whose license matches this template can be changed
> from as-is to HPND. (And please, _only_ OSD-compliant packages.
> We don't want the same mess again, as we have with as-is.)

Thanks! I guess for me it's time to go fix all the ruby packages that have

LICENSE="as-is" # really

:P

--
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/
Re: Re: Clarify the "as-is" license? [ In reply to ]
On Tue, 2012-09-25 at 13:04 +0200, Ulrich Mueller wrote:
> I'll also remove as-is from @GPL-COMPATIBLE and @OSI-APPROVED again,
> as soon as all packages in the system set have been fixed (only
> net-misc/openssh and sys-apps/man-pages). It shouldn't have been added
> to these groups, in the first place.

I have been using "as-is" to mean licenses that allow anything and
everything as long as the copyright notice is preserved. For example,

# This file is free software; the author(s) gives unlimited
# permission to copy and/or distribute it, with or without
# modifications, as long as this notice is preserved.

If "as-is" will be removed from @GPL_COMPATIBLE, what gpl-compatible
license should I use instead for such packages?
Re: Re: Clarify the "as-is" license? [ In reply to ]
On Tue, Sep 25, 2012 at 11:55 AM, Alexandre Rostovtsev
<tetromino@gentoo.org> wrote:
>
> If "as-is" will be removed from @GPL_COMPATIBLE, what gpl-compatible
> license should I use instead for such packages?

HPND as long as the license meets the description within the file. If
you've been applying the logic you stated that should generally be the
case.

Making the default to not be @gpl_compatible is a good move. That way
we ensure everything gets positive review. The only alternative would
be to do a scan and log a bazillion bugs for everybody to do a check
and then take some kind of action for those that don't respond.

Rich
Re: Re: Clarify the "as-is" license? [ In reply to ]
>>>>> On Tue, 25 Sep 2012, Diego Elio Pettenò wrote:

>> I've created licenses/HPND [1] now, and added it to the @OSI-APPROVED
>> group. So packages whose license matches this template can be changed
>> from as-is to HPND. (And please, _only_ OSD-compliant packages.
>> We don't want the same mess again, as we have with as-is.)

> Thanks! I guess for me it's time to go fix all the ruby packages that have

> LICENSE="as-is" # really

Sounds good. :-) Bug 436214 if you need a tracker for them.

Ulrich
Re: Re: Clarify the "as-is" license? [ In reply to ]
Ulrich Mueller schrieb:
> I've created licenses/HPND [1] now, and added it to the @OSI-APPROVED
> group. So packages whose license matches this template can be changed
> from as-is to HPND. (And please, _only_ OSD-compliant packages.
> We don't want the same mess again, as we have with as-is.)

I have one question: The license can be GPL-compatible but the software
itself non-free. So binary-only packages distributed under e.g. BSD
license should remain BSD or not?

If we start to measure the software freedom of the code inside the
package, then maybe LICENSE is the wrong variable to express this.


Best regards,
Chí-Thanh Christopher Nguyễn
Re: Clarify the "as-is" license? [ In reply to ]
Ulrich Mueller schrieb:
>> Why not directly use the FSF freedoms:
>> The freedom to run the program, for any purpose (freedom 0).
>> The freedom to study how the program works, and change it so it does
>> your computing as you wish (freedom 1).
>> The freedom to redistribute copies so you can help your neighbor
>> (freedom 2).
>> The freedom to distribute copies of your modified versions to others
>> (freedom 3).
>
>> I think when combined appropriately, they nicely cover most of the
>> cases of current "as-is" packages.
>
> This has been suggested before, but for license groups. The problem
> is that the four freedoms are good criteria for Free Software, but
> there's no good mapping to the elements of most non-free licenses.
>
> Try it yourself for a few concrete cases (of non-free licenses in our
> tree), and you'll see what I mean.

I tried it on two non-free packages that I maintain (bitstream-cyberbit
and radeon-ucode) and it works well there:

bitstream-cyberbit: 0 but not 1, 2 or 3.
radeon-ucode: 0 and 2 but not 1 or 3.


Best regards,
Chí-Thanh Christopher Nguyễn
Re: Re: Clarify the "as-is" license? [ In reply to ]
>>>>> On Sat, 29 Sep 2012, Chí-Thanh Christopher Nguyễn wrote:

> I have one question: The license can be GPL-compatible but the
> software itself non-free. So binary-only packages distributed under
> e.g. BSD license should remain BSD or not?

Yes, if it's BSD licensed then it should have LICENSE="BSD".

> If we start to measure the software freedom of the code inside the
> package, then maybe LICENSE is the wrong variable to express this.

I'm aware that we can't distinguish the two cases. Should we have a
"binary-only" license to catch it?

Ulrich
Re: Re: Clarify the "as-is" license? [ In reply to ]
On Sat, Sep 29, 2012 at 5:21 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>> On Sat, 29 Sep 2012, Chí-Thanh Christopher Nguyễn wrote:
>> If we start to measure the software freedom of the code inside the
>> package, then maybe LICENSE is the wrong variable to express this.
>
> I'm aware that we can't distinguish the two cases. Should we have a
> "binary-only" license to catch it?

The license isn't binary-only. The license is BSD. It just happens
that the thing they're licensing is the binary and not the source.

Does it really matter? Before we start overloading the LICENSE flag
to represent something other than the license we should probably have
a problem to actually fix.

As far as freedom of code goes, arguably the code is perfectly free -
it just isn't open source. You could legally decompile, modify,
recompile, and redistribute it and your assembly language sources as
much as you like.

Rich
Re: Re: Clarify the "as-is" license? [ In reply to ]
On Sat, 29 Sep 2012 19:38:50 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Sat, Sep 29, 2012 at 5:21 PM, Ulrich Mueller <ulm@gentoo.org>
> wrote:
> The license isn't binary-only. The license is BSD. It just happens
> that the thing they're licensing is the binary and not the source.
>
> Does it really matter? Before we start overloading the LICENSE flag
> to represent something other than the license we should probably have
> a problem to actually fix.
>
> As far as freedom of code goes, arguably the code is perfectly free -
> it just isn't open source. You could legally decompile, modify,
> recompile, and redistribute it and your assembly language sources as
> much as you like.

Imho software as it's described here shouldn't get a LICENSE which is
in @FREE, such as BSD.

For a software to be free, it has to be possible to change it in any
way you want. And "to be possible" and "to be allowed" really aren't
the same here! (Except if you are either masochistic or one of these
gurus which eat assembly code for breakfast).

I have an ACCEPT_LICENSE="-* @FREE" in my make.conf, so I expect that
there's only free software on my system (except for those packages I
explicitly allowed via package.license, for sure). I couldn't make this
assumption anymore if software as you describe it would get a @FREE
LICENSE.

Cheers,
aranea

1 2  View All