The MOTIF license says: "The rights granted under this license are limited solely to distribution and sublicensing of the Contribution(s) on, with, or for operating systems which are themselves Open Source programs. Contact The Open Group for a license allowing distribution and sublicensing of the Original Program on, with, or for operating systems which are not Open Source programs." From which several questions arise: 1. Does this imply that a "fetch" restriction is needed on non-Open-Source systems? Or are we allowed to distribute the sources to e.g. AIX or Interix users? Currently the ebuild has the following restriction: RESTRICT="!kernel_linux? ( !kernel_FreeBSD? ( !kernel_Darwin? ( !kernel_SunOS? ( fetch bindist ) ) ) )" 2. Does discontinuation of the OpenSolaris project imply that Solaris (i.e. its kernel) can no longer be considerd an Open Source system and therefore above exception for kernel_SunOS must be removed?
3. Are any Gentoo mirrors running under proprietary operating systems, and would that be an issue? I.e., should the ebuild have RESTRICT="mirror" in addition?
We don't provide binaries/sources, do we? We only provide a cookbook to build the sources, right? If we can be sued because we mirror sources that potentially can be downloaded by users on non-free platforms, then we should restrict it immediately, even if we would only keyword it for linux. PS. Solaris is still CDDL, nothing changes there, and OpenSolaris is as much SunOS as Solaris is. Besides that, OpenSolaris remains an as open system as it was for eternity, of course.
My take of the problem: ad 1: Yup, I'd say that we're not allowed to distribute MOTIF-licensed works to non-open[1] systems. Since packages can be dual-licensed, it would make more sense to use RESTRIC="!kernel_[...]" on the license itself and not ebuilds. I don't know if that's possible (yet) though. ad 2: No, the code of OpenSolaris is still open and CDDL, just the work has ceased on it. Although CDDL doesn't explicitly state it's irrevocable, it'd be hard to revoke already redistributed versions. In any case no revocation that I know of was called. (BTW, Illumos is its fork being worked on now an is supposed to be free of non-open licenses. It's said to be MIT/BSD/CDDL). ad 3: According to MOTIF license, Gentoo mirrors running non-open[1] systems shouldn't be permitted to distribute or modify stuff under the MOTIF license. In our case this means that we're not allowed to keep distfiles on non-free systems. I don't know of any non-free Gentoo mirror though. I think RESTRICT=mirror should (potentially) be only used if we can find proof that there's non-free/open Gentoo mirrors. BTW, the ebuild mentions also MIT, but after a short search I couldn't find any mention of it in the source tarball or the project website. P.S. Is there a list of all the 'kernel_*' options? I couldn't find any. -.-.- [1] Definition of "open source" in the MOTIF license: "Open Source" programs mean software for which the source code is available without confidential or trade secret restrictions and for which the source code and object code are available for distribution without license charges.
> P.S. Is there a list of all the 'kernel_*' options? I couldn't find any. See $PORTDIR/profiles/desc/kernel.desc for a list of all possible values for the USE-expanded KERNEL variable
@Jonatan: thanks :] Shouldn't the RESTRICT line then read: RESTRICT="!kernel_linux? ( !kernel_FreeBSD? ( !kernel_OpenBSD? ( !kernel_NebBSD? ( !kernel_SunOS? ( !kerne_Darwin? ( !kernel_freemint? ( fetch bindist ) ) ) ) ) )" I've gone a bit through the licenses of all the kernel_* options we have, so I this list matches the MOTIF license's specs. There is still the problem what counts as an operating system... I mean, if we count drivers as part of the OS then Darwin falls out flat and frankly even parts of the Linux kernel. SunOS is kinda tricky here, because it can be either SunOS, Solaris or Illumos (sorted by closed → most open). Interix is a funny beast in this case and brings up the problem of what counts as the OS when emulation and/or virtualisation is taking place. I still feel this should be don on LICENSE-level and not on ebuild-level. BTW, isn't there a nicer way of representing this with logical operators?
hah, yeah, interix is funny :) at our company, we decided to drop openmotif due to license issues and resurrected lesstif (ugh!). we're using hppa-hpux, ia64-hpux, sparc-solaris, x86-solaris, x86-interix, x86-winnt, x86-linux and ppc-aix, so the free systems are a minority ;[
(In reply to comment #5) > Shouldn't the RESTRICT line then read: > > RESTRICT="!kernel_linux? ( > !kernel_FreeBSD? ( > !kernel_OpenBSD? ( > !kernel_NetBSD? ( > !kernel_SunOS? ( > !kernel_Darwin? ( > !kernel_freemint? ( > fetch bindist > ) ) ) ) ) )" In principle yes, but the ebuild doesn't have KEYWORDS for OpenBSD, NetBSD, and freemint yet. Further kernel_* flags can be added when these architectures will be keyworded. (And there's no harm if the list of free systems is incomplete.) > There is still the problem what counts as an operating system... I mean, if > we count drivers as part of the OS then Darwin falls out flat and frankly > even parts of the Linux kernel. SunOS is kinda tricky here, because it can > be either SunOS, Solaris or Illumos (sorted by closed → most open). Interix > is a funny beast in this case and brings up the problem of what counts as > the OS when emulation and/or virtualisation is taking place. Upstream explain their criteria in <http://www.opengroup.org/openmotif/faq.html>: | QUESTION: | How does The Open Group define the term "Operating System" Does this apply | to the kernel or the complete distribution? | | ANSWER: | The Open Group's intent is that this applies only to the kernel of the | operating system, without regard to any bundled utilities or application | software. This includes all known distributions of Linux and BSD | distributions. To find out if an operating system qualifies check whether | kernel sources are available under criteria meeting the OSI's Open Source | Definition. > I still feel this should be don on LICENSE-level and not on ebuild-level. This is currently impossible for technical reasons. So far, license files are simply plain text files. > BTW, isn't there a nicer way of representing this with logical operators? I don't think so. The construction with nested parantheses is ugly, but it may well be that this is the only package in the tree where such a thing in RESTRICT is needed.
I just see that their FAQ also answers the driver question: | QUESTION: | Can an open source operating system kernel include binary modules that do | not have sources available under criteria meeting the OSI's Open Source | Definition? | | ANSWER: | Yes, an operating system kernel that is otherwise open source but includes | a limited number of such binary modules, for example graphics drivers or | wireless card drivers, still meets the requirements. This includes all known | distributions of Linux and BSD distributions.
OK, so their FAQ saves us much trouble then. BTW, what happened to the lesstif ebuild, when and why did it get removed from Portage? Even if it's not perfect, it *is* a relatively working alternative. Could we in the future make licenses in Gentoo more advanced? In the long term I think it would make things easier.
(In reply to comment #9) > BTW, what happened to the lesstif ebuild, when and why did it get removed > from Portage? Even if it's not perfect, it *is* a relatively working > alternative. Oh no, *please* not this again. If you are interested in the reasons (and if you have some time to spare), then read bug 29388 and bug 204249 with all its blockers.
(In reply to comment #10) > (In reply to comment #9) > > BTW, what happened to the lesstif ebuild, when and why did it get removed > > from Portage? Even if it's not perfect, it *is* a relatively working > > alternative. > > Oh no, *please* not this again. If you are interested in the reasons (and if > you have some time to spare), then read bug 29388 and bug 204249 with all its > blockers. Skimmed through it ...hmmm, OK, I get the general reason.
Looks like we have no problems with any of the three mentioned points. Therefore closing.
