Re: OSD #2 (was Re: GPL vs APSL (was: YAPL is bad))
Rick Moen writes: > The existence of a set of guidelines fortunately doesn't bar the Board > -- or the rest of us -- from applying common sense. E.g., "Sorry, but > software without source code cannot be open source." Yup. -- -russ nelson <[EMAIL PROTECTED]> http://russnelson.com Crynwr sells support for free software | PGPok | It's a crime, not an act 521 Pleasant Valley Rd. | +1 315 268 1925 voice | of war. For my take, see: Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | http://quaker.org/crime.html -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: OSD #2 (was Re: GPL vs APSL (was: YAPL is bad))
On Tuesday 25 September 2001 02:31 pm, Greg London wrote: > I am saying the MIT license does not meet OSD #2. > Since OSD #2 says > "the program MUST include source code" > There is nothing in the MIT license to > guarantee OSD#2, so it fails to meet the > definition. Fine. I distribute an MIT licensed proram that includes the source code. I have met every requirement of the OSD and can call the program Open Source. Then I distribute my next program under the same license, but choose not to include the source code or publicize how to obtain it. That specific program would not be Open Source. At times the OSD is placing guidelines upon licenses, and at others upon programs. Clause #2 refers to the "program". -- David Johnson ___ http://www.usermode.org -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: OSD #2 (was Re: GPL vs APSL (was: YAPL is bad))
begin Matthew C. Weigel quotation: > I also think that the OSD contributes to this misunderstanding - I > think the wording of the introduction should be rewritten to not > suggest the distribution terms have to meet the OSD, but the > distribution terms or the distribution itself. Actually, I think it's just a case of some computer geeks amusing themselves be pretending that the OSD is supposed to be a standalone expert system for auto-issuing licence certifications -- while knowing full well that it's actually a set of guidelines for what the Board will or won't likely certify based upon the licence's substance. The existence of a set of guidelines fortunately doesn't bar the Board -- or the rest of us -- from applying common sense. E.g., "Sorry, but software without source code cannot be open source." -- "Is it not the beauty of an asynchronous form of discussion that one can go and make cups of tea, floss the cat, fluff the geraniums, open the kitchen window and scream out it with operatic force, volume, and decorum, and then return to the vexed glowing letters calmer of mind and soul?" -- The Cube, forum3000.org -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: OSD #2 (was Re: GPL vs APSL (was: YAPL is bad))
On Tue, 25 Sep 2001, Greg London wrote: > is it possible to take GPL'ed code, > modify it, relicense it under > a proprietary license, and distribute > it only in binary form? > > my understanding is it is not possible. > but MIT'ed code would allow this. Irrelevant. Is it possible to take APSL'ed code, modify it, and not provide Apple with information on your changes? My understanding is it is not possible. But MIT'ed code would allow this. > The 'bar' to meet GPL is pretty high. > The bar to satisfy the MIT license is on the ground. > The OSD is somewhere in between. No. First, understand that the OSI certifies *software*, in part because of the license under which it is distributed, and in part based upon what is distributed. So, as Bruce indicated, if software is made available under the BSD license and includes source code, it is OSI approved. If not, then not. OSD #2 applies to the software, and not the license. > one can argue about RMS's definition > of free software, but his implementation > (the GPL license) set the bar a LOT > higher than MIT. So? > One could also argue that RMS's definition > is moot to OSI, since OSI has it's own > definition to follow. No, even working from the FSF definition, the BSD/MIT license is free. > > and to change the OSD to exclude them > > would be a travesty. > > travesty smavesty. > I'm not saying exclude GPL. Never did. Please read what he wrote - excluding the BSD or MIT licenses would be a travesty. > I am saying the MIT license does not meet OSD #2. That's correct. Because, strictly speaking, #2 applies to software, and not licenses. A license may preemptively *require* #2 to be met, but it need not - so long as it is met. > Since OSD #2 says > "the program MUST include source code" > There is nothing in the MIT license to > guarantee OSD#2, so it fails to meet the > definition. Go back to the part you had so much difficulty with before - the OSI approves software, based in part upon software licenses. It certifies licenses as being compatible with the OSD. > And OSD#2 requires this, because it uses > the word "MUST". I didn't put it there, > OSI did. So, were you to distribute a derivative of a BSD kernel in binary form without source, you would not be distributing free software (unless you let people know where they could get the source). > It isn't about it being a "travesty". > It's about whether or not OSI followed > its own definition. No, it's a question of reading comprehension. The OSD does not require "the license must guarantee access in source code form," "the license must provide a public location from which to download the source," etc. It says the software must either include source, or have a well-publicized location from which to get source. Now, if you wanted the source to the FreeBSD kernel, included in binary form on your installation floppy... you know where to get it- www.freebsd.org. > If OSI certification gives absolutely > no guarantees about code licensed with > an OSI approved license, then OSI is > moot. Disregarding my own opinions on this, your analysis and the logic that leads to your conclusion are founded upon a misunderstanding. I also think that the OSD contributes to this misunderstanding - I think the wording of the introduction should be rewritten to not suggest the distribution terms have to meet the OSD, but the distribution terms or the distribution itself. -- Matthew Weigel Research Systems Programmer [EMAIL PROTECTED] ne [EMAIL PROTECTED] -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: OSD #2 (was Re: GPL vs APSL (was: YAPL is bad))
begin Greg London quotation: > I am saying the MIT license does not meet OSD #2. Since OSD #2 says > "the program MUST include source code" There is nothing in the MIT > license to guarantee OSD#2, so it fails to meet the definition. Ahem. Nostalgic for freshman philosophy? It would be physically possible to issue a binary without source and claim it to be under the MIT licence, but nobody would be particularly impressed, let alone call that open source. I should point out that the OSD is not intended to be an AI routine, just a set of guidelines that can be understood by reasonable people. In practice, the Board is there, in part, to say "Very creative, and certainly a nice try, but of course the answer is no." -- "Is it not the beauty of an asynchronous form of discussion that one can go and make cups of tea, floss the cat, fluff the geraniums, open the kitchen window and scream out it with operatic force, volume, and decorum, and then return to the vexed glowing letters calmer of mind and soul?" -- The Cube, forum3000.org -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: OSD #2 (was Re: GPL vs APSL (was: YAPL is bad))
Bruce Perens wrote: > Both the MIT license and Public Domain > fit under both the > OSD and RMS's definition of Free Software, is it possible to take GPL'ed code, modify it, relicense it under a proprietary license, and distribute it only in binary form? my understanding is it is not possible. but MIT'ed code would allow this. The 'bar' to meet GPL is pretty high. The bar to satisfy the MIT license is on the ground. The OSD is somewhere in between. one can argue about RMS's definition of free software, but his implementation (the GPL license) set the bar a LOT higher than MIT. One could also argue that RMS's definition is moot to OSI, since OSI has it's own definition to follow. > and to change the OSD to exclude them > would be a travesty. travesty smavesty. I'm not saying exclude GPL. Never did. I said GPL exceeds the minimum requirements given by the OSD. I have no qualms with GPL being OSI approved. You're not talking to that which I am saying. I am saying the MIT license does not meet OSD #2. Since OSD #2 says "the program MUST include source code" There is nothing in the MIT license to guarantee OSD#2, so it fails to meet the definition. And OSD#2 requires this, because it uses the word "MUST". I didn't put it there, OSI did. Therefore OSI should not have approved the MIT license, since MIT does not satisfy this requirement. OSI put the bar at a certain height, and the MIT license limbo'ed right under it. It isn't about it being a "travesty". It's about whether or not OSI followed its own definition. If OSI certification gives absolutely no guarantees about code licensed with an OSI approved license, then OSI is moot. IMHO IANAL TINLA YRMV Greg YRMV=> Your Results May Vary -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: OSD #2 (was Re: GPL vs APSL (was: YAPL is bad))
Greg London <[EMAIL PROTECTED]> 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