License/Use settings

[Mark Bainter]

If we care at all about usability, we need something better than just writing
down a long list of all the licenses that one (does not)accept. I respect
some people are careful and want that sort of control, but I would prefer to
be able just to set a level of openness. Now this will specifically be
something for those who are not so picky. So if I feel like a purist, I only
get the cream, and if I feel utilitarian, I get the lot, and then there
should be a few levels between. The problem unfortunately remains but to a
smaller scale. Some stuck-up is going to go down fighting about how to class
the licenses, but in then he/she can manually write down all licenses he/she
finds acceptable, and be happy.
Freedom it was, and that includes the freedom to be ignorant. If you argue
this last point, be sure you are covered, because that is deep water.

I won't argue that you have the freedom to be ignorant. But that freedom
does not put responsibility on everyone else to put out safeguards for you.
If you choose to be ignorant, then you also choose to accept the potential
consequences of that ignorance.

I was however, thinking that it should be possible to have certain basic
groupings for licenses. I would suggest at least four provided groups,
which could be extended by the user if they wanted to customize these,
or add their own groups to the mix.

FREE: Only OSI-Approved Licenses
SOURCE_AVAILABLE: Anything the source is provided for
NON_COMMERCIAL: Anything freely available. Source might be closed, or
require special hoops to obtain.
ANYTHING_GOES: All licenses.

With this, you could have settings like:
VALID_LICENSES="FREE -GPL2" to get all FREE licenses, except gpl2

I'd personally suggest a default of SOURCE_AVAILABLE, from a usability
perspective, but wouldn't object too strongly to a default setting of
FREE, so that those who want to claim the moral high ground, but not have
to put in any of the intellectual effort could still do so.

Along these lines, I think it might not be a bad idea to have similar
options for USE. So people can specify a common group that has a
default set of parameters for common applications. The obvious
examples being SERVER and WORKSTATION, where something like server
would have more workstation oriented settings (like X, GTK, GTK2, etc)
turned off by default.

Since these would probably require the parser to be able to make
certain assumptions to keep things from getting ugly, I'd suggest
that there might need to be a seperate variable for the group.
Or, we could just require that the first entry in the var be the
group, and if you want to start from scratch and customize the
whole thing you can just put None in the first entry.

[Gareth Buxton]

Post by Mark Bainter
Since these would probably require the parser to be able to make
certain assumptions to keep things from getting ugly, I'd suggest
that there might need to be a seperate variable for the group.
Or, we could just require that the first entry in the var be the
group, and if you want to start from scratch and customize the
whole thing you can just put None in the first entry.

A lot of this could easily be accommodated by implementing licenses as
packages. For the group FREE you could have a package in say sys-license
called osi-licenses which simply contains a list of dependencies on all
the individual OSI licence packages. So when you say emerge osi-licenses
you automatically include all of those.

I don't think people will in general want to tamper with their licenses
very much after install but this would work a treat for someone like
IBM. In order to comply with SCO they could simply do:

emerge unmerge aix-license

And voila! They get rid of the license and all the software that
requires it to run legally :)

[Norbert Bollow]

Post by Mark Bainter
I was however, thinking that it should be possible to have certain basic
groupings for licenses. I would suggest at least four provided groups,
which could be extended by the user if they wanted to customize these,
or add their own groups to the mix.
FREE: Only OSI-Approved Licenses
SOURCE_AVAILABLE: Anything the source is provided for
NON_COMMERCIAL: Anything freely available. Source might be closed, or
require special hoops to obtain.
ANYTHING_GOES: All licenses.

I think the basic idea here is very good, but I don't think that
creating a complicated system for selecting licensing policies is
a very good idea. I'd propose that at installation-time there
should be the choice between four options and an additional fifth
which would be "enter an URL of a configuration file which defines
the licensing policy that you want to use". This allows to create a
company-wide policy and corresponding configuration file that the
company can then use for every Zynot install.

Some nitpicks concerning the proposed category names and definitions:

* There is Free Software with an ok but somewhat non-standard
license that no-one has bothered to get OSI approval for.
(I am here talking of licensing that would be considered
acceptable both by FSF and by OSI but for which no-one has
asked for OSI approval).

* If a program uses a patented algorithm or something, the program
may have an OSI-approved license without the program truly being
Free Software.

* Any license can be used for commercial software. For example the
GNU GPL is a good choice for commercial Free Software (see
http.//FreeStrategy.info for more information about this). For
this reason I think that "NON_COMMERCIAL" should be avoided as a
description of licensing terms.

So here is my suggestion of categories:


OSI-Approved: Programs with OSI-approved license and no known patent
related issues.

FREE: Programs which satisfy the criteria of OSI's "open source
definition" and FSF's "free software definition".

SOURCE_AVAILABLE: Anything the source is provided for.

ANYTHING_GOES: All licenses. Source might be closed, or require
special hoops to obtain.


This set of categories has the nice property that OSI-Approved is
a subset of FREE, wich is a subset of SOURCE_AVAILABLE, which is a
subset of ANYTHING_GOES.

Post by Mark Bainter
I'd personally suggest a default of SOURCE_AVAILABLE, from a usability
perspective, but wouldn't object too strongly to a default setting of
FREE, so that those who want to claim the moral high ground, but not have
to put in any of the intellectual effort could still do so.

I'd argue that *if* there has to be a default, it should be FREE
instead of SOURCE_AVAILABLE in order to avoid encouraging the
creation of non-free source-available programs which are wrongly
marketed as "open source".

Alternatively, choice of licensing policy could be a required step
at installation-time. Users still have the freedom to click on
ANYTHING_GOES without considering the issue (so the freedom to remain
ignorant is not violated by this approach) but people would be
encouraged to look into the matter and learn what Free Software is
all about.

Greetings, Norbert.

[Gareth Buxton]

I've put a page on wiki for anyone who is interested in producing an
audio distribution targeted and recording studios. Just add yourself to
the relevant part of the page and feel free to add ideas etc to it.
This will be a specific distro of the Zynot meta-distro and will require
people to do various things from ebuilds/QA/docs/artwork but also could
attract audio developers (LADSPA etc...). But the emphasis is on an easy
to install system that does audio - for the professional.

[Daniel Armyr]

Could it perhaps be extended to audio/video. I have done a bit of both, and I find they tie in with each other a lot. Of course, this will make the whole thing bigger, but still.

//Daniel Armyr

[Gareth Buxton]

Post by Daniel Armyr
Could it perhaps be extended to audio/video. I have done a bit of both, and I find they tie in with each other a lot. Of course, this will make the whole thing bigger, but still.

Well after an interesting discussion with Emmett on IRC it seems that a
good way to go might be a 'family' of projects. Emmett pointed out a lot
of needs that I think would be useful in either audio or video
environment (and possibly others). Perhaps something like
ZynotStudioServer, ZynotAudioStudio ZynotVideoStudio with the
flexibility to run all three distros on the same workstation - audio and
video may share some of the same apps and could each integrate with
ZynotStudioServer. ZynotStudioServer would provide typical studio
infrastructure such as
data-backup/online-publishing/online-streaming/messaging etc.. and would
ideally be integrable with current studio solutions such as (take a deep
breath) windows and mac software that is already entrenched in the
industry. There are a lot of notes to be written up from the discussion
with Emmett which I will get onto the wiki as soon as possible (but
prolly not for a few days cos I gonna be off-line for a bit).

My personal preference is for separate audio-distro and video-distro
that integrate rather than an audio-video-distro because I think some
will want one without the other if you're targeting dedicated
operations. However I'm sure there are compelling arguments for both
approaches.

- Galik

[Zenaan Harkness]

I agree that having only four or five options is ideal from a "keep it
simple" point of view. And if we are targetting end-users (/corporates)
then you probably want it relatively simple.

Post by Norbert Bollow
OSI-Approved: Programs with OSI-approved license and no known patent
related issues.
FREE: Programs which satisfy the criteria of OSI's "open source
definition" and FSF's "free software definition".
SOURCE_AVAILABLE: Anything the source is provided for.

I'd call this category PROPRIETARY_WITH_SOURCE.

Post by Norbert Bollow
ANYTHING_GOES: All licenses. Source might be closed, or require
special hoops to obtain.

I'd call this last category PROPRIETARY_NO_SOURCE.

I think those names convery more clearly the nature of the software in
those categories, and also shows to the user that they are similar in
categories, other than with one, source is available. I think that there
is enough confusion around Open Source ("source available") vs.
OSI_Approved vs. FSF_Approved vs DFSG (debian free software guidelines),
that we should try to not add to that confusion.

There is probably the possibility that OSI_APPROVED and FREE will get
confused. There should perhaps be URLs to the definitions presented when
the user has to make a choice, or a "more info" button so that they can
read immediately and make an informed choice.

Post by Norbert Bollow
This set of categories has the nice property that OSI-Approved is
a subset of FREE

This statement would be correct if category FREE read osi-approved _OR_
fsf-approved. Perhaps you intended it to read "packages that satisfy A,
as well as packages that satisfy B"?

Perhaps it would be better to have checkboxes against "osi approved",
"fsf approved", "proprietary with source", "proprietary".

I actually think that technically fsf approved is a subset of osi
approved. But since those definitions may change over time, there's not
much point worrying about what is a subset of what. Just provide
checkboxes and let the user decide.

Personally, I'd be happy with dfsg-approved. I would like that as an
option because I've already put the effort into reading (in detail) what
dfsg compliant means, and if you ask me I couldn't remember the details,
but I know I made that decision a few years ago, and so it would be an
effort for me to make a new decision (if I want to be fully informed
about that decision). Why put such users through that? Perhaps there
could be an "advanced" button which provides such additional options
(eg. DFSG compliant", BSD compliant, whatever options the community
feels strongly enough about).

To me, that would be pretty "slick"/professional, as it is catering to
my needs and understanding of the effort that is otherwise being asked
of me.

Post by Norbert Bollow

Post by Mark Bainter
I'd personally suggest a default of SOURCE_AVAILABLE, from a usability
perspective, but wouldn't object too strongly to a default setting of
FREE, so that those who want to claim the moral high ground, but not have
to put in any of the intellectual effort could still do so.

I'd argue that *if* there has to be a default, it should be FREE
instead of SOURCE_AVAILABLE in order to avoid encouraging the
creation of non-free source-available programs which are wrongly
marketed as "open source".

I agree with this. So would you make the default osi, fsf, dfsg, bsd or
X-based free? :)

cheers
zen