OSD #2 (was Re: GPL vs APSL (was: YAPL is bad))
Bruce Perens
bruce at perens.com
Tue Sep 25 19:18:11 UTC 2001
Greg London <greglondon at oaktech.com> wrote (in part)
> It seems to me that the MIT does not meet
> item #2 of the OSD, then.
An Open Source license is _not_ required to prohibit someone from making
a version of the software that is closed source. And since someone can
do that without changing the license, simply by refusing to distribute
source, we needed to talk about more than just the license.
The MIT license very definitely allows source code to be passed on,
and if a version of a MIT-licensed program includes source code, it is
an Open Source program. In general, people who don't distribute the source
change the license to "All Rights Reserved", but they don't have to. So,
it's pretty clear that there can be MIT-licensed programs that are not
Open Source.
Thus, we really do need to make a distinction between the _license_ and the
_product_.
> In my reading (and yours too), it is possible to
> distribute software under an OSI certified license,
> and fail to meet OSD #2.
That is correct. Having source code is a required condition, over and
above the license language, for a program to be Open Source.
> That seems like a problem which should be discussed somewhere.
Not really. The license is OSI-certified. The fact that available source code
does not exist means the program is not Open Source, despite the fact that the
license which has been applied to it is OSI-certified. This is also the case for
Public Domain software, for which we clearly _can_not_ change the license, because
there is no license. Both the MIT license and Public Domain fit under both the
OSD and RMS's definition of Free Software, and to change the OSD to exclude them
would be a travesty.
> What should be done about it?
Explain this issue in the OSD commentary.
> Is the OSI going to certifying distribution mechanisms
> as well as licenses? (Unlikely)
I don't think it's necessary over and above the current simple statement that
there must be source. It's pretty clear that if the program doesn't include
Source, it's not Open.
> It hardly seems likely that the BSD and MIT, (et al)
> licenses which don't guarantee downstream source are
> going to be decertified.
Remember that the definition was written to fit the licenses, not the other
way around. We had the BSD, GPL, Artistic and Public Domain, and we were sure
they were Free Software. Then we needed to set down what Free Software was so
that we could figure out what other licenses were suitable for inclusion in
Debian.
> Does OSD #2 need to be reworked?
I don't think so.
> I hope that Bruce can comment on this point.
Be careful what you wish for :-)
Actually, even the GPL does not prohibit a particular form of proprietary work.
If you _never_distribute_ your GPL derivative, it can be proprietary.
Thanks
Bruce
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
More information about the License-discuss
mailing list