Subject: Re: x11/openmotify license terms
To: None <tech-pkg@netbsd.org>
From: Greg Troxel <gdt@ir.bbn.com>
List: tech-pkg
Date: 05/15/2006 08:27:32
joerg@britannica.bec.de writes:
> On Sun, May 14, 2006 at 04:36:45PM -0400, Greg Troxel wrote:
>> joerg@britannica.bec.de writes:
>>
>> > It could also means that someone setting _ACCEPTABLE, which is still the
>> > standard for bulk builds, is violating the license.
>>
>> Then, why is openmotif different from any other program with a
>> non-free license? (I'm not opposed to having a more general
>> discussion about licensing and bulk builds, but I'd like to be clear
>> if that's the issue, or if it's specifically about x11/openmotif.
>
> I don't think we have any other package in the tree which satisfies the
> following two conditions:
> (a) You can freely and automatically download the distfile(s).
> (b) You cannot build a binary package for personal use.
There are lots of packages (vmware, and something in security the name
I now forget) where you can download a binary distfile and make a
package, and only use it with a license.
>> I object to the use of ONLY_FOR_PLATFORM for anything remotely to do
>> with licensing. I think we should keep technical issues and licensing
>> separate. I don't object to adding mechanisms for platform-specific
>> licensing issues.
>
> The situatiob we have now is:
> (a) bulk builds are uploaded incompletely, since any package using motif
> (and the default openmotif) has a restricted dependency.
> (b) the restriction of redistribution at the very least is platform
> specific.
Are you saying that bulk builds skip anything with LICENSE=, even if
NO_BIN_ON_FTP is unset?
I would respectfully suggest that bulk builds should key off
NO_BIN_ON_FTP, not LICENSE. I don't mean to be critical of bulk
building efforts, since I know that's a lot of work. But we have a
variable that means exactly what we want. Plenty of software has
a non-free license that permits FTP distribution of binary packages.
My make code is buggy, and I'm trying to fix it. But the intent is to
refrain from setting NO_BIN_ON_FTP if OPSYS is open source.
>> As for using openmotif for personal use on Interix, the license text
>> doesn't permit it.
>
> This is something I am not sure about. I'd like to see a clarification
> from the Open Group exactly because first the license says that you can
> use it only on Open Source platforms and second that you must ask for
> permissions to distribute or sublicense it. There's a hole.
That's a fundamental misunderstanding of copyright law, and I'm sorry
for muddying the water above. Two points:
1) "use" is not a right reserved to copyright holders; copyright is
about the creative expression of ideas, and grants authors
certain exclusive rights.
2) If the holder doesn't grant a right and that right is one of the
reserved rights (the right to copy and make derived works are most
important here), and the copying doesn't fall under fair use, one
can't do it. There's no (legal) need for the copyright holder to
explicitly prohibit it.
This gets murky, because it isn't clear if compiling a program on
one's own machine after the open group makes a copy by responding to
the download request is the creation of a derivative work protected by
copyright law, fair use, or something else (see DJB's software law
comments). It also isn't clear who is making a copy when one
downloads a file from an FTP server.
Software licenses such as the GPL recognize this, and say "this is not
a contract since you have not signed it. But nothing else grants you
permission to copy."
The license text at
http://www.opengroup.org/openmotif/license/
says that the license is solely about distribution and sublicensing.
That seems to imply that the open group subscribes to the "use is not
a right controlled by copyright". But, the license file in the
distribution is different.
In any case, it is entirely clear and I believe undisputed that this
is not an open source license. Therefore, given our current
documented guidelines it should have LICENSE set.
--
Greg Troxel <gdt@ir.bbn.com>