Re: License Approval Process
On Thu, 17 Aug 2000, Alexandra White wrote: I wanted to get some feedback about the best way to assist in streamlining OSI license approval for customers. OSI is doing what we can to approve licenses; in fact we approved a couple at a meeting this week during Linuxworld, once we get our meeting minutes together we'll post the results. At the same time, we don't want to be rushed and make a bad decision, like we did once. Some of these licenses also really push us on what OSD conformance means - the OSD is not as clear as it could be (what does it mean to not discriminate against a "group of people" - how about the "group of people who refuse to accept the license"?) So I don't know the right answer to give you, other than, we're busy but we're trying. 1) For instance, we have a number of customers who we are helping to take their code to the open source and thus are assisting in getting OSI approval for them. While we encourage them to use existing open source licenses rather than creating their own, many want to simply rename the license with their product name but keep the license identical. Thus, they could label it "Acme Software License (BSD)" In this case, can we assume that the license is OSI-approved? Simple renaming is fine; but then I have to ask, why rename? Why not just call it the BSD license? 2) What minor changes to an existing OSI license are acceptable without seeking approval? Changing the name is about the only one I'd consider. And it must be clear that we didn't approve "Acme Software License", we only approved a *similar* license. I've proposed to the board that we genericize the licenses and allow people to change entries in a header at the top, we're considering it. I know Vovida's license has only a few minor changes from BSD; to me they look fine, but they still require discussion amongst the board and potentially people on os-discuss. I.e., what does it mean to disclaim liability, "in excess of $1000"? I've talked with Alan about it, and it sounds like a formality associated with the UCC, but why it's $1000 and not $1, I still don't understand. Still, that may not matter w/r/t OSD conformance, but it's still worth pondering. 3) In the cases where a customer does need OSI approval, how can I help them expedite the process to get a timely response? For example, I submitted a license on June 9 for Cadence and have not heard any feedback on its progress. You're right - it's not on the long list that Larry posted last week. Larry, could you make sure it's on the list? Brian
Re: License Approval Process
On Thu, 17 Aug 2000, Alexandra White wrote: 2) What minor changes to an existing OSI license are acceptable without seeking approval? Personal opinion, I am in no way associated with OSI... I would say that changing the name is perfectly acceptable. Changing the warranty disclaimer is also hunky-dory, if that's all the change is. Beyond that it's tough to know without considering the license in question. I like Brian's idea of having templatized licenses. The BSD license already is in a way. -- David Johnson _ http://www.usermode.org
Re: License Approval Process
Something to keep in mind. For a company, when it comes down to 1.) Pay nobody for advice and have your open-source license fall into a black hole", or 2.) Pay nobody and have your staff lawyers who were going to be there anyway draft up a nice closed-source license from all the boiler-plate they have lying around" ... businesses are going to choose the latter, rather than end up waiting forever and not hearing back. (At least a smart business would... smart businesses don't lodge their product up their ass while waiting for some group of geeks to tell them they're ok.) We _REALLY_ need to take a more serious attitude towards the MANY people who have submitted licenses and to which TPTB have (basically) ignored over the past year. (And yes, I think this has been going on about a year now). My $.02 worth ... D At 7:30 AM -0700 8/10/00, Rick Moen wrote: begin Dave Stanley quotation: ...For 6 weeks ago, I waited patiently to no avail At the risk of hurting my chances of a prompt review, I'm not impressed at all. And you paid so much for all this, too! I suggest you demand a 30% discount. It's only fair. -- Cheers, "Open your present" Rick Moen"No, you open your present" rick (at) linuxmafia.com Kaczinski Christmas. -- Unabomber Haiku Contest, CyberLaw mailing list
Re: License Approval Process
begin Derek J. Balling quotation: Something to keep in mind. For a company, when it comes down to 1.) Pay nobody for advice and have your open-source license fall into a black hole", or 2.) Pay nobody and have your staff lawyers who were going to be there anyway draft up a nice closed-source license from all the boiler-plate they have lying around" ... businesses are going to choose the latter, rather than end up waiting forever and not hearing back. You know, I don't speak for anyone else (which is why I can speak my mind) -- but, _if_ I were a volunteer OSI Board member, busy with an otherwise productive life, and I saw the time-wastage, the endless recapitulation of eminently FAQable material, and the proliferation of new proposed licences that are mostly ill-thought-out, have little reason for existence other than as exercises in creative writing, and show a stunning lack of concern for their tendency to ghetto-ise code into hermetically sealed, tiny licence communities that cannot use or be used by others, I think I'd mostly ignore this list, too. In my estimation, the current OSI offer of gratis evaluation of any old casually-drafted licence from anyone, while well-intended and perhaps necessary, has the unfortunate side-effect of encouraging gratuitous proliferation of mutually incompatible licences, and wastage of the OSI's time by people who do not respect or value it. (Note that I am _not_ saying everyone here commits that sin. But many have.) Reply-to has been set, since meta-discussions can be pernicious. -- Cheers, "Open your present" Rick Moen"No, you open your present" rick (at) linuxmafia.com Kaczinski Christmas. -- Unabomber Haiku Contest, CyberLaw mailing list
Re: License Approval Process
Rick Moen wrote: You know, I don't speak for anyone else (which is why I can speak my mind) -- but, _if_ I were a volunteer OSI Board member, busy with an otherwise productive life, and I saw the time-wastage, the endless recapitulation of eminently FAQable material, [...] Good idea. Where is the FAQ? -- /* * Tom Hull -- [EMAIL PROTECTED] * http://www.ocston.org/~thull */
Re: License Approval Process
begin Tom Hull quotation: Good idea. Where is the FAQ? There isn't yet one. Ideally, such a FAQ should be maintained by someone who can act/speak _for_ OSI. I have no standing with that group. (An advertised, searchable list archive would also be helpful.) -- Cheers, "Open your present" Rick Moen"No, you open your present" rick (at) linuxmafia.com Kaczinski Christmas. -- Unabomber Haiku Contest, CyberLaw mailing list
RE: License Approval Process
I've seen may requests for OSI license certification over the past year. I would be helpful if you could publish a list of licenses pending review, and their priority, so those of us that have submitted a license can know where it is in the process. Richard Brice WSDOT -Original Message- From: Lawrence E. Rosen [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, August 08, 2000 6:10 PM To: [EMAIL PROTECTED] Subject:License Approval Process To the Open Source community: The board of directors of OSI, which has responsibility to approve licenses, is composed of volunteers. They are doing their best to catch up with the backlog of submitted licenses. Given their other activities, this is taking more time than we'd like. I hope you can all be patient. As OSI's new executive director, I am taking seriously the job of processing license review requests in a timely manner. At last month's board meeting, six licenses were discussed and two approved (the CNRI license submitted by Python and the Apache license submitted by the Apache Software Foundation). The board has scheduled a meeting later this month to review licenses, and they plan to meet on a regular basis in coming months to try to work their way through the backlog of submitted licenses. The community can help by considering carefully whether a new license is really needed. There are several very good licenses already approved. Will "yet another" license help? Make sure you clearly explain your objectives for creating your new license when you submit it for approval, so that the OSI board can prioritize appropriately. We're also trying to improve our procedures so that we can update our web site more frequently as new licenses are submitted for review and then either approved or disapproved. If any of you know of someone in the California Bay Area who'd like to be OSI's webmaster, please let me know. OSI always welcomes suggestions for improvement. Please feel free to contact me, or you may write directly to members of the board of directors. /Larry Rosen Executive Director, OSI 650-366-3457 [EMAIL PROTECTED] www.rosenlaw.com www.opensource.org
RE: License Approval Process
-Original Message- From: Brice, Richard [mailto:[EMAIL PROTECTED]] I've seen may requests for OSI license certification over the past year. I would be helpful if you could publish a list of licenses pending review, and their priority, so those of us that have submitted a license can know where it is in the process. I agree. I appreciate that the OSI panel are busy people, but it would be nice to have received even an acknowledgement of receipt for my license submission. The only time I received any mail was when I sent an (accidentally) ratty follow-up enquiring what was going on, had it been received, etc. I then got a much more ratty response from ESR, replied with an apology, and have heard nothing since. It would certainly be nice to see what is going on with my license, publicly or emailed to me. Any chance of this little bit of extra work even if it slows down processing, OSI-people? SamBC
Re: License Approval Process
"Dennis E. Hamilton" wrote: I think I understand how this works. You do. AA. The Angels right to make their own derivative works of X is diminished to the extent that the Angels do not have an automatic license to take additions and modifications from the derivative works produced by others. I wouldn't use the word "diminished"; there is *never* any such "automatic license" to reuse other people's works. Only an explicit license can make that possible. In doing so, there needs to be care to avoid infringing the intellectual property rights of Borg, Inc. and the Cavaliers. A clean-room approach is essentially always sufficient, and may be more than is required. (The FSF uses such an approach w.r.t. Unix source code; if you've seen the ATT source, you can't work on the GNU version.) Let's have "M admits-derivative N" represent that license N is automatically admissible on derivatives of works for which license M is automatically available. Then MIT admits-derivative GPL MIT admits-derivative MIT MIT admits-derivative closed GPL admits-derivative x if-and-only-if x = GPL MPL admits-derivative MPL MPL admits-derivative closed A good summary, to which I have added the MPL conditions To extend the summary to the LGPL, you have to have two relations, because LGPLed works admit two kinds of derivatives -- informally speaking, the "extension of library" type and the "use of library" type. LGPL works like GPL for the former, and like MIT for the latter. Trying to distinguish between these in an architecture-neutral way is what makes the LGPL so lengthy. -- Schlingt dreifach einen Kreis vom dies! || John Cowan [EMAIL PROTECTED] Schliesst euer Aug vor heiliger Schau, || http://www.reutershealth.com Denn er genoss vom Honig-Tau, || http://www.ccil.org/~cowan Und trank die Milch vom Paradies.-- Coleridge (tr. Politzer)
Re: License Approval Process
I agree with most of the points made on this discussion. The more licenses that exist, the more splintered the open source community will become. You can't use source code licensed with License X with source code licensed with License Z (ok, that's a generalization but I don't think it is too far off the mark). I too have submitted a license for approval with no luck. The Alternate Route Open Source License, drafted by the Washington State Attorney General's Office, is simply a modification of the GPL. We based this license on the GPL with the permission of the Free Software Foundation. We support all of the concepts of in the GPL, however the disclaimers and "lack of warranty" statements aren't specific enough (at least that is what the lawyer told me). This is why we drafted our own license. I can appreciate why OSI hasn't certified our license. Does the world really need another GPL derivative? However, I fail to see why the OSI does not take the time to tell me that the Alternate Route Open Source License will not be certified. I have taken considerable time and effort to embrace open source concepts and to make open source software a reality in government. As a minimum, I expect a notice of rejection that details why a license that satisfied all the requirements of the OSD is not worthy of OSI certification. Richard Brice, Software Applications Engineer WSDOT Bridge and Structures Office
Re: License Approval Process
Michael Stutz wrote: Is it *possible* for a license to be compatible with another? Offhand I can think of just two possibilities for the GPL: the LGPL, and code that has no license and is in the public domain. The "new BSD" and the equivalent MIT license are compatible with the GPL; the "old BSD" license with the advertising requirement is not. In general, a license is compatible with the GPL if it imposes the same, or fewer, restrictions than the GPL. -- Schlingt dreifach einen Kreis vom dies! || John Cowan [EMAIL PROTECTED] Schliesst euer Aug vor heiliger Schau, || http://www.reutershealth.com Denn er genoss vom Honig-Tau, || http://www.ccil.org/~cowan Und trank die Milch vom Paradies.-- Coleridge (tr. Politzer)
Re: License Approval Process
On Tue, 15 Feb 2000, John Cowan wrote: The "new BSD" and the equivalent MIT license are compatible with the GPL; the "old BSD" license with the advertising requirement is not. In general, a license is compatible with the GPL if it imposes the same, or fewer, restrictions than the GPL. Ummm... I don't think so. For one, Nothing is commutatively compatible with the GPL -- software can't be redistributed under different terms[1]. Also, if another license is as restrictive as the GPL, you probably can't license it under different terms either, and thus you can't redistribute under the GPL. As far as I know only software licensed under the X and new BSD licenses can be redistributed under the GPL without changes, but I thought some software licensed under the old BSD had been redistributed under the GPL with a caveat. Matthew Weigel Programmer/Sysadmin/Student [EMAIL PROTECTED]
Re: License Approval Process
"Matthew C. Weigel" wrote: On Tue, 15 Feb 2000, John Cowan wrote: The "new BSD" and the equivalent MIT license are compatible with the GPL; the "old BSD" license with the advertising requirement is not. In general, a license is compatible with the GPL if it imposes the same, or fewer, restrictions than the GPL. Ummm... I don't think so. For one, Nothing is commutatively compatible with the GPL -- software can't be redistributed under different terms[1]. Also, if another license is as restrictive as the GPL, you probably can't license it under different terms either, and thus you can't redistribute under the GPL. Oh, you are talking about relicensing. I was using "compatibility" in the sense of distributing a derived work parts of which are under two different licenses. Thus, no derived work can be partly under the GPL and partly under the MPL (or at least you can make such a thing, but not distribute it): thus GPL and MPL are incompatible. Not so GPL and MIT/new BSD. -- Schlingt dreifach einen Kreis vom dies! || John Cowan [EMAIL PROTECTED] Schliesst euer Aug vor heiliger Schau, || http://www.reutershealth.com Denn er genoss vom Honig-Tau, || http://www.ccil.org/~cowan Und trank die Milch vom Paradies.-- Coleridge (tr. Politzer)
Re: License Approval Process
snip The only other reason I can think of to get OSI approval for your license is for advertising purposes. In that case, I guess you'll just have to wait until somebody from the OSI speaks up. I'm no expert, but, personally, I don't think it's worth the trouble. So you can't put ``open source'' on your ads. Just say ``source code available'' instead. Big deal. Ian /snip I'm not certain this is the case. I recall something a few months ago suggesting the application for a trademark on open source was rejected. Can anyone confirm this? If so it would certainly explain the lack of certifications. Rob
Re: License Approval Process
Rob Edgeworth writes: snip The only other reason I can think of to get OSI approval for your license is for advertising purposes. In that case, I guess you'll just have to wait until somebody from the OSI speaks up. I'm no expert, but, personally, I don't think it's worth the trouble. So you can't put ``open source'' on your ads. Just say ``source code available'' instead. Big deal. Ian /snip I'm not certain this is the case. I recall something a few months ago suggesting the application for a trademark on open source was rejected. Can anyone confirm this? If so it would certainly explain the lack of certifications. "Open Source" was not accepted as a registered trademark. Because there is an Open Source Definition, and for other historical reasons, it is still in most cases meaningful to say that it's factually correct that a particular license (and distribution practice!) "is Open Source" or "is not Open Source". When someone says "I have an Open Source license", that claim can be _false_ (and people can point out that it's false), but it can't be a trademark infringement. The OSI's new trademark is "OSI Certified Open Source". OSI certification is not necessarily important to everyone, and there are other ways to have an open source license. I don't believe that OSI certification is _necessary_ to anyone (it's _always_ been possible to use an existing open source license, including traditional and useful ones from long before the term "Open Source" existed; and goodness knows that all sorts of people have written Open Source licenses or attempts at Open Source licenses without any comment from the OSI). I do believe that OSI certification can be, and has been, useful in many cases. Among other things, the OSI certification process has helped identify and eliminate problems in some proposed licenses before projects were released under them. This is not to say, of course, that the certification process is free of problems, including most obviously significant delays. I'm going to be talking to the OSI Board about some of the problems which people have for some time identified in the OSI's certification process. -- Seth David Schoen [EMAIL PROTECTED] | And do not say, I will study when I Temp. http://www.loyalty.org/~schoen/ | have leisure; for perhaps you will down: http://www.loyalty.org/ (CAF) | not have leisure. -- Pirke Avot 2:5
Re: License Approval Process
Hello all; Martin Konold wrote: [..] The only acceptable license for RMS is finally the GPL. This means that according to RMS in the end everything shall be licensed under the GPL without exceptions. I look on this as a bit of a strawman. It's easy to be confused by Richard's subtle distinction between "Free Software" and "Copyleft Software". Free Software means you may redistribute, alter etc the software at will. This includes the BSD, MIT, X, Artistic licenses, amongst others. Copyleft is the 'next level', adding the two major conditions of the GPL: that if you distribute a changed version of the software, you must also distribute the changes; and that software including copylefted code must itself be copylefted. Just as a copyright protects the holder from their property being abused, copyleft is meant to prevent abuse of free software code. Everyone has motivations for their licenses. The GPL has a valid motivation, as do the BSD and MPL (and other) crowds. This is the reason why all other currently (according to RMS) compatible licenses allow for non reversal converting to the GPL at any time. RMS is RMS. I suspect he'll be banging on the lid of his coffin if it wasn't designed with copylefted software :) Yours, -- martin be well; JC.
Re: License Approval Process
G'day all. On Tue, 15 Feb 2000, Michael Stutz wrote: Is it *possible* for a license to be compatible with another? Offhand I can think of just two possibilities for the GPL: the LGPL, and code that has no license and is in the public domain. On Tue, Feb 15, 2000 at 07:35:57PM -0500, [EMAIL PROTECTED] wrote: It's certainly possible. The GPL is particularly restrictive in this sense. soapbox Contrary to popular belief, "free speech" (as RMS describes it) is not the same as "free time". "Free time" has no strings attached, whereas "free speech" has implied responsibilities. Unfortunately, the FSF have never AFAIK noted that English has at least _three_ definitions of the word "free", which makes the term "free software" that much more confusing. /soapbox What I would like to see as a variation of the GPL is one which allows modifications to be placed under any certified Open Source license (this is assuming a good certification process, which is being called into question). I think this would make a good license to allow your code to be used with the maximum amount of open source software, but still disallow closed source software. (This would be a middle ground between the GPL and the LGPL.) This sounds like inserting another condition into the MIT licence would do the trick. I'm not good at legal wording, but how about this? Any distributed or published work which is, in whole or in part, derived from the Software shall be licensed as a whole under an OSI Certified Open Source licence. Cheers, Andrew Bromage
Re: License Approval Process
On Tue, 15 Feb 2000, John Cowan wrote: The "new BSD" and the equivalent MIT license are compatible with the GPL; the "old BSD" license with the advertising requirement is not. In general, a license is compatible with the GPL if it imposes the same, or fewer, restrictions than the GPL. To be specific, I think you mean fewer of the *same* restrictions than the GPL. If a license had absolutely no restrictions except for an advertisment clause, most would not consider it compatible, even though it was less restrictive overall. However, "compatibility" with the GPL is still being debated in some quarters. Although RMS considers the BSD and MIT licenses to be compatible, some legalists question this. And then there are some BSD and MIT adherents who claim that their licenses do not allow relicensing their original code under the GPL. Although everyone agrees on the broad points of the GPL, there are a thousand interpretations of its finer points. -- Arandir... _ http://www.meer.net/~arandir/
Re: License Approval Process
On Tue, 15 Feb 2000, Andrew J Bromage wrote: soapbox Contrary to popular belief, "free speech" (as RMS describes it) is not the same as "free time". "Free time" has no strings attached, whereas "free speech" has implied responsibilities. Unfortunately, the FSF have never AFAIK noted that English has at least _three_ definitions of the word "free", which makes the term "free software" that much more confusing. /soapbox Actually, my dictionary has 17 definitions. Consider "free verse", "free electon", "free nation", "free to use", etc. Although most of these 17 definitions are only slight variations of others, there are certainly more than three broad definitions of "free" in the english language. Using Richard's definitions, "Free Software" is as unrelated to "Free Speech" as it is to "Free Beer". -- Arandir... _ http://www.meer.net/~arandir/
Re: License Approval Process
"Brice, Richard" wrote: I agree with most of the points made on this discussion. The more licenses that exist, the more splintered the open source community will become. You can't use source code licensed with License X with source code licensed with License Z (ok, that's a generalization but I don't think it is too far off the mark). This is indeed an argument that has been posted against many open source licenses, but I'm afraid that it holds little water. First and foremost, if the software is released under a license that allows combination with other software written under different licenses, there's no real problem. The BSD/MIT style licenses are pretty liberal in this regard. In fact, most of the licenses are pretty liberal in this regard except for the GPL/LGPL. My own SOS license attempts to be very liberal in this regard, but is seen as "not offering any value over the GPL" - meaning that licenses that don't enforce copyleft don't add value? But I digress. Secondly, the main point of "free software" is to preserve the user's ability to read, understand, and fix the software. These goals don't require mixing codebases from different sources ... isn't everyone's ideal to have a lot of .so files that each provide some services and mix them together at runtime? Even if you actually need to merge two pieces of source for some reason, there's nothing stopping you from going back to the copyright holder to get permission to include License X code in your License Z code, which seems likely to be a request that will easily be granted. Finally, and perhaps most amusingly, the point of OSI Certified Open Source is to allow the end user to use software with varying licenses that all conform to the same underlying principles (the OSD). If diversity is a problem, then why have a certification process at all? It's contradictory to say "We have certification to support diversity, but we oppose diversity because it's bad". My conclusion: skip the certification. Write your code. If people want it, they'll read your license after they're using it and send you complaints. Spend the time on the important part ... the software. alex
Re: License Approval Process
David Johnson wrote: And you're also forgetting the "idiot filter" quality of this list. Someone submits a license. Everyone proceeds to call in the question the submitter's ancestry or proclivities. The submitters leaves in disgust. Those that do manage to stick around after the first two rounds of abuse end up getting a good hearing. Let's add the idiot filter comment to the opensource.org WWW pages. That way the filter won't even have to process any input ... Please name two licenses that have received what you consider a "good hearing" on this mailing list. thanks, alex
Re: License Approval Process
On Tue, 15 Feb 2000, Alex Nicolaou wrote: My conclusion: skip the certification. Write your code. If people want it, they'll read your license after they're using it and send you complaints. Spend the time on the important part ... the software. We in the Eiffel community have struck a problem with our `open source' licence (note it has not been through OSI certification) called the Eiffel Forum Freeware Licence (EFFL): http://www.eiffel-forum.org/license/ under which the bulk of `open source' Eiffel software is released. See the Eiffel Forum Archive: http://www.eiffel-forum.org/archive/ The EFFL was created to workaround a problem with the LGPL which as the licence page above states: Sometimes you will see software released under the Gnu Library GPL. This license is designed to be less restrictive than the Gnu GPL. However, its wording is based on the compilation and linkage model used for C, and I cannot see how it can be applied to Eiffel software. We have now struck a problem with sourceForge who are keen to see the EFFL certified through the OSI processes, which are now being discussed on this list. What has happened with sourceForge is they ultimately accept the library into the sourceForge facilities after some negotiating with the library maintainer. Obviously it would be better for everyone if we could get the EFFL OSI certified, but based on the discussion on this list it seems like the OSI has stalled. Hopefully, we will be putting our EFFL through the processes as described on this page: http://www.opensource.org/certification-mark.html Just one situation where an alternative licence to the main stream is required. BTW, the EFFL was drafted in early 1998 around the time of the popularising of the term open source. The EFFL has been incredibly successful in motivating Eiffel library writers to release their code so that others can use their efforts and at the same time ensure that improvements are fedback into the library. Geoff Eldridge -- [EMAIL PROTECTED]
RE: License Approval Process
I think I understand how this works. Let me check it with your thinking: A. The Angels group produces a software work, X, distributing it under an OSD-consistent copyright license that permits derivative works and does not require that they be distributed under the same license or even be licensed at all. There is no back-licensing requirement in the license that accompanies copies of X. B. Borg, Inc., makes a derived work Y:X as a closed-source commercial product. They distribute the commercial product. Distribution of Y satisfies any other conditions that might govern the use of X and the Angels license is satisfied. C. The Cavaliers create Z:X as an open-source derivative and Z is distributed under the GPL. Again, all conditions of the Angels license on X are satisfied. AB. The Angels have nothing to say about Y. Furthermore, absent a specific separate agreement, the Angels have no right in Y different than anyone else who legitimately possesses a copy of work Y. In particular, they cannot do anything with aspects of Y not in X that conflicts with the terms of any copyright and licensing of Y. AC. The Angels also have nothing to say about Z. Furthermore, absent a specific separate agreement, the Angels have no right in Z different than anyone else who possesses a copy of work Z. In particular, they cannot do anything with aspects of Z not in X that conflicts with the GPL. AA. The Angels right to make their own derivative works of X is diminished to the extent that the Angels do not have an automatic license to take additions and modifications from the derivative works produced by others. The Angels can certainly make new, original derivative works of X, under cover of the original license form. In doing so, there needs to be care to avoid infringing the intellectual property rights of Borg, Inc. and the Cavaliers. Such care to avoid infringement is always warranted, but it would now seem somewhat easier for there to be an appearance of infringement considering that all are building derivatives of X. (AD. When the Dogmatics make a derivative work U:X, and license it in a way that is consistent with the Angel license, there is no such problem. The Angels and the Dogmatics can mutually derive from each others stuff and it all works.) Interesting, huh? Let's have "M admits-derivative N" represent that license N is automatically admissible on derivatives of works for which license M is automatically available. Then MIT admits-derivative GPL MIT admits-derivative MIT MIT admits-derivative closed GPL admits-derivative x if-and-only-if x = GPL where closed is an exit state [the chain is ended], and GPL is clearly a steady state [the chain is trapped]. I suppose this illustrates what is meant by the viral nature of GPL. For me, it also illustrates the cooperative nature of the MIT license and all of those, x, for which MIT admits-derivative x is a symmetrical relationship. Relation admits-derivative is transitive; it is neither reflexive nor symmetrical. -- Dennis -- Dennis E. Hamilton InfoNuovo mailto:[EMAIL PROTECTED] tel. +1-206-779-9430 (gsm) fax. +1-425-793-0283 http://www.infonuovo.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of John Cowan Sent: Tuesday, February 15, 2000 13:06 To: [EMAIL PROTECTED] Subject: Re: License Approval Process "Matthew C. Weigel" wrote: On Tue, 15 Feb 2000, John Cowan wrote: The "new BSD" and the equivalent MIT license are compatible with the GPL; the "old BSD" license with the advertising requirement is not. In general, a license is compatible with the GPL if it imposes the same, or fewer, restrictions than the GPL. Ummm... I don't think so. For one, Nothing is commutatively compatible with the GPL -- software can't be redistributed under different terms[1]. Also, if another license is as restrictive as the GPL, you probably can't license it under different terms either, and thus you can't redistribute under the GPL. Oh, you are talking about relicensing. I was using "compatibility" in the sense of distributing a derived work parts of which are under two different licenses. Thus, no derived work can be partly under the GPL and partly under the MPL (or at least you can make such a thing, but not distribute it): thus GPL and MPL are incompatible. Not so GPL and MIT/new BSD. -- Schlingt dreifach einen Kreis vom dies! || John Cowan [EMAIL PROTECTED] Schliesst euer Aug vor heiliger Schau, || http://www.reutershealth.com Denn er genoss vom Honig-Tau, || http://www.ccil.org/~cowan Und trank die Milch vom Paradies.-- Coleridge (tr. Politzer)
RE: License Approval Process
Dual licensing makes perfect sense, it all depends on why you are licensing your software. I believe there's a discussion somewhere online as to the "whys and wherefores" that Larry Wall chose to license Perl (for example) under multiple licenses. (Where to find it is left as an exercise to the reader because in my quick search I could not locate it after 2 minutes). :) D At 10:56 AM 2/15/00 -0800, Brice, Richard wrote: Dual licensing doesn't make sense. If a licensee can choose which license to use, the will chose the one to their advantage. The software we are producing is used for the design of highway bridge structures. Our lawyer though the GPL didn't provide us enough protection against tort claims from third parties. If someone had the choice of GPL and Alternate Route, and they wanted to sue us, they would choose GPL. So what good is the dual license? None. -Original Message- From: Michael Stutz [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, February 15, 2000 10:49 AM To: '[EMAIL PROTECTED]' Subject: Re: License Approval Process Richard Brice wrote: You can't use source code licensed with License X with source code licensed with License Z (ok, that's a generalization but I don't think it is too far off the mark). Is it *possible* for a license to be compatible with another? Offhand I can think of just two possibilities for the GPL: the LGPL, and code that has no license and is in the public domain. Might dual-licensing apply for some of the organizations who are toying with writing a GPL clone -- as copyright holder, couldn't they release their code under both the GPL (or whatever license they chose), and also license the program under some other terms as needed? [Can anyone point me to any resources on the issue of license compatibility?] We support all of the concepts of in the GPL, however the disclaimers and "lack of warranty" statements aren't specific enough (at least that is what the lawyer told me). Did the lawyer mean that it was not specific enough about your particular organization or software, or that it was not specific enough about exactly what is being disclaimed? If the latter, I'd like to hear what the lawyer had to say!
Re: License Approval Process
On Tue, 15 Feb 2000, Michael Stutz wrote: Richard Brice wrote: You can't use source code licensed with License X with source code licensed with License Z (ok, that's a generalization but I don't think it is too far off the mark). Is it *possible* for a license to be compatible with another? Offhand I can think of just two possibilities for the GPL: the LGPL, and code that has no license and is in the public domain. It's certainly possible. The GPL is particularly restrictive in this sense. What I would like to see as a variation of the GPL is one which allows modifications to be placed under any certified Open Source license (this is assuming a good certification process, which is being called into question). I think this would make a good license to allow your code to be used with the maximum amount of open source software, but still disallow closed source software. (This would be a middle ground between the GPL and the LGPL.) Might dual-licensing apply for some of the organizations who are toying with writing a GPL clone -- as copyright holder, couldn't they release their code under both the GPL (or whatever license they chose), and also license the program under some other terms as needed? One problem with this is that a lot of organizations wish to specifically avoid the GPL, since there's some concern that it isn't clear enough to stand up in court. For instance, it uses many terms without defining them, and it's often not clear just want counts as a modification or derivative work. So dual-licensing with the GPL seems kind of pointless to me - might as well just release your code under the GPL in the first place. Joe
Re: License Approval Process
Richard Brice wrote: You can't use source code licensed with License X with source code licensed with License Z (ok, that's a generalization but I don't think it is too far off the mark). Is it *possible* for a license to be compatible with another? Offhand I can think of just two possibilities for the GPL: the LGPL, and code that has no license and is in the public domain. Might dual-licensing apply for some of the organizations who are toying with writing a GPL clone -- as copyright holder, couldn't they release their code under both the GPL (or whatever license they chose), and also license the program under some other terms as needed? [Can anyone point me to any resources on the issue of license compatibility?] We support all of the concepts of in the GPL, however the disclaimers and "lack of warranty" statements aren't specific enough (at least that is what the lawyer told me). Did the lawyer mean that it was not specific enough about your particular organization or software, or that it was not specific enough about exactly what is being disclaimed? If the latter, I'd like to hear what the lawyer had to say!
RE: License Approval Process
Thanks for the suggestions. I just sent a copy directly to both Eric and Richard and will report back if I hear anything. Scott Hollenbeck (mailto:[EMAIL PROTECTED]) Network Solutions, Inc. Registry -Original Message- From: Jacques Chester [mailto:[EMAIL PROTECTED]] Sent: Sunday, February 13, 2000 9:55 PM To: [EMAIL PROTECTED] Subject: Re: License Approval Process Hello again all; J C Lawrence wrote: On Sun, 13 Feb 2000 18:40:26 -0500 Rafi M Goldberg [EMAIL PROTECTED] wrote: [..] It is unfortunate that the powers that be @ opensource.org only seem to be interested in gaining the support of large corporations and those who decide to just use an existing license... I hope that's not actually the case, but it doesn't look good. ESR certainly receives considerable flammage to this effect, I am sure. Hopefully he's reading this and is prepared to defend himself. Hello, Eric! *waves* I'm not immune from my share of throwing stones from glass houses myself, so I guess I'll take the position as Devil's Advocate(1) on this one. I'm not prepared to hand Eric the prize for making the hacker community rise as fast and as far as it has. I *will* say that his impact in the process cannot be discounted. Whether you agree with his message or not, I think it's clear that the messenger certainly brought some of the memes into the corporate intelligences. I would suggest emailling the principles directly (ESR and Perens) in the case of slow response. With the caveat that Perens isn't at the OSI anymore. And, to give your license a baptism of fire, you may prefer to email it to Richard Stallman instead ([EMAIL PROTECTED]). You will have few email conversations quite as challenging, I assure you. be well; J C Lawrence Home: [EMAIL PROTECTED] JC. (1) Just a note on where that term comes from. The Catholic church, in deciding on whether to make someone into a saint, appoints a "Devil's Advocate", whose job it is to fight the approval of that person to sainthood. Your pointless trivia for the day.
Re: License Approval Process
I see a lot of people asking on this list why their licenses are not being approved. I think I've been on this list since it was created--in some small way I may have encouraged its creation-- but I don't actually remember seeing any license receive official OSI approval. I may well have forgotten a few in the early days. As I recall, the most active contributor and license commentator on this list has been Bruce Perens, who at the time the list was created was no longer officially an OSI member and thus presumably can not grant official OSI approval. I don't speak for anybody but myself. I'm not an OSI supporter. I can't say that it really saddens me to see this silence. However, I also don't like seeing people feeling rebuffed when they try to open up their software. So here are a few quick notes from my own personal perspective. First I'll note that you don't need OSI approval to put your code out there. Just do it. If people object to the license, fix it. Or don't. Continuing that, why do you want to put the code out there? If you want to get contributions from the net, then you should know that there are already too many licenses out there. Hackers hack code, not the law. If your license is different from standard licenses, you are putting up a barrier to any contributions. Rather than try to figure out your license, hackers won't use or contribute to your code. So if you want to get contributions, don't invent a new license. Use an existing one: GPL, LGPL, MPL, Artistic License, MIT, public domain. If you absolutely can not stomach that, then use an existing license with a caveat. Say: this code is under the GPL, with the additional exception that if you modify it, you must remove our trademarks unless we give you explicit permission to the contrary. (Don't lose too much sleep over legal issues, such as whether you can enforce your license. Most people will obey your license if they can understand it. The people who won't, would probably have ignored a much more restrictive license also.) If your code is exceptional, people will use it whatever the license is. However, most code is not exceptional. You will normally be best served by using an existing license. Don't create a new license merely because you can. That will not help you, and it will not help the free software community. I know a lot of people aren't going to listen to this advice, and that's too bad. Do yourself a favor and listen to what I'm saying. You may not think it applies to you, but it almost certainly does. (I feel I must add a note about getting contributions from the net. The OSI web pages at opensource.org make it sound as though just putting code out there will cause a flood of contributed patches and will make your code stronger, better, faster than it was before. It ain't so. It can happen. I've seen it happen with my own code. But, these days, most of the time, it doesn't. There's a lot of free software out there already, and there are only so many free software hackers.) Now, let's say that you don't really care about getting contributions. Perhaps you want to open up your code to help your customers, or to get a competitive advantage. Perhaps you simply want to help the free software community, although you don't expect any return. In that case, it doesn't much matter what license you use, and it doesn't much matter whether your license is approved by the OSI. Just do something reasonable, something which does not prevent your existing customers do what they need to do. Your goals will be satisfied, and you won't have to worry about the OSI's license approval process. The only other reason I can think of to get OSI approval for your license is for advertising purposes. In that case, I guess you'll just have to wait until somebody from the OSI speaks up. I'm no expert, but, personally, I don't think it's worth the trouble. So you can't put ``open source'' on your ads. Just say ``source code available'' instead. Big deal. Ian
Re: License Approval Process
On Mon, 14 Feb 2000, Ian Lance Taylor wrote: I see a lot of people asking on this list why their licenses are not being approved. I have to agree with most if not all of your points. There are getting to be too many licenses. And most of the ones being submitted are merely minor modifications of existing licenses. If you don't have a pressing need for a new license, don't create one! If you're a corporation and your lawyer says that the MPL, Jikes, etc., aren't suitable, make him explain why he's smarter than the Netscape or IBM lawyers. If you find that none of the existing licenses work for your project, be prepared to explain to others why your new license is any better than the existing. And please understand what Open Source software really is. There's been more than one time here where someone has submitted a license that fails the OSS definition on numerous points. That said, I will grant that there are a few large holes in the Free Software licensing spectrum. If your license manages to plug one of these holes, it will be welcomed. But if it is just another rewrite of the GPL or yet another one-product license, don't bother submitting it. -- Arandir... _ http://www.meer.net/~arandir/
Re: License Approval Process
On Mon, 14 Feb 2000, Chris F Clark wrote: The list is supposedly part of a process to certify licenses as "open source". There seems to be no indication that they will ever certify any new licenses (other than from "very large corporations") as qualifying. Among the licenses that have not been certified were ones that were essentially trivial modifications to already approved licenses. The "trivial modifications" are probably the very reason why they aren't getting approved. Bruce and Eric have always attempted to convince the VLC's to use the existing licenses. Why should they be any different with all the GPL and MIT clones? And you're also forgetting the "idiot filter" quality of this list. Someone submits a license. Everyone proceeds to call in the question the submitter's ancestry or proclivities. The submitters leaves in disgust. Those that do manage to stick around after the first two rounds of abuse end up getting a good hearing. I do recall a new certification within the past six months, and it was not from one of the VLC's. Just because there is no fanfare on this list does not mean that some aren't getting approved. What OSI really needs to do is keep the list updated better. -- Arandir... _ http://www.meer.net/~arandir/
Re: License Approval Process
At 6:32 PM -0500 2/13/00, Hollenbeck, Scott wrote: Can someone clarify the license approval process for me, please? I sent a draft license to license-approval last week and again a few moments ago, but there does not appear to be a way to confirm that the request has been received or is being considered Join the club, Scott. I submitted a license months ago and haven't heard a thing. Others have had similar experiences as well. In fact, I don't think any new licenses have been approved under the certification program. It is unfortunate that the powers that be @ opensource.org only seem to be interested in gaining the support of large corporations and those who decide to just use an existing license... I hope that's not actually the case, but it doesn't look good. -Rafi Goldberg -- Rafi M. Goldberg [EMAIL PROTECTED] PGP Key: 0xA39B4E14 - Keys are at http://pgp5.ai.mit.edu/
Re: License Approval Process
On Sun, 13 Feb 2000 18:40:26 -0500 Rafi M Goldberg [EMAIL PROTECTED] wrote: Join the club, Scott. I submitted a license months ago and haven't heard a thing. Others have had similar experiences as well. In fact, I don't think any new licenses have been approved under the certification program. It is unfortunate that the powers that be @ opensource.org only seem to be interested in gaining the support of large corporations and those who decide to just use an existing license... I hope that's not actually the case, but it doesn't look good. I would suggest emailling the principles directly (ESR and Perens) in the case of slow response. -- J C Lawrence Home: [EMAIL PROTECTED] --(*) Other: [EMAIL PROTECTED] --=| A man is as sane as he is dangerous to his environment |=--
Re: License Approval Process
Hello again all; J C Lawrence wrote: On Sun, 13 Feb 2000 18:40:26 -0500 Rafi M Goldberg [EMAIL PROTECTED] wrote: [..] It is unfortunate that the powers that be @ opensource.org only seem to be interested in gaining the support of large corporations and those who decide to just use an existing license... I hope that's not actually the case, but it doesn't look good. ESR certainly receives considerable flammage to this effect, I am sure. Hopefully he's reading this and is prepared to defend himself. Hello, Eric! *waves* I'm not immune from my share of throwing stones from glass houses myself, so I guess I'll take the position as Devil's Advocate(1) on this one. I'm not prepared to hand Eric the prize for making the hacker community rise as fast and as far as it has. I *will* say that his impact in the process cannot be discounted. Whether you agree with his message or not, I think it's clear that the messenger certainly brought some of the memes into the corporate intelligences. I would suggest emailling the principles directly (ESR and Perens) in the case of slow response. With the caveat that Perens isn't at the OSI anymore. And, to give your license a baptism of fire, you may prefer to email it to Richard Stallman instead ([EMAIL PROTECTED]). You will have few email conversations quite as challenging, I assure you. be well; J C Lawrence Home: [EMAIL PROTECTED] JC. (1) Just a note on where that term comes from. The Catholic church, in deciding on whether to make someone into a saint, appoints a "Devil's Advocate", whose job it is to fight the approval of that person to sainthood. Your pointless trivia for the day.
Re: License Approval Process
ESR certainly receives considerable flammage to this effect, I am sure. Hopefully he's reading this and is prepared to defend himself. Hello, Eric! *waves* I'm not looking to flame him, but I would appreciate some acknowledgement. FWIW, I'm trying to get a license certified for some web site maintenance tools I'm working on for my high school. One would think that Open Source in the schools would be something Mr. Raymond would go for... I'm not prepared to hand Eric the prize for making the hacker community rise as fast and as far as it has. I *will* say that his impact in the process cannot be discounted. Whether you agree with his message or not, I think it's clear that the messenger certainly brought some of the memes into the corporate intelligences. Absolutely. And I happen to agree with him on many accounts, more so than Perens and certainly more than RMS. But that's neither here nor there... It's good to get companies on the bandwagon, but not at the expense of us little people. I would suggest emailling the principles directly (ESR and Perens) in the case of slow response. Does this imply that anyone has experienced a not-slow response, or a better response directly from ESR? I'm willing to give it another try... -Rafi -- Rafi M. Goldberg [EMAIL PROTECTED] PGP Key: 0xA39B4E14 - Keys are at http://pgp5.ai.mit.edu/
Re: License Approval Process
+ Join the club, Scott. I submitted a license months ago and haven't + heard a thing. Others have had similar experiences as well. In + fact, I don't think any new licenses have been approved under the + certification program. my experience has been the same, with the addition that a second note was sent directly to ESR, along with dates of initial release for the open source project. there has been absolutely no response whatsoever. a thought: what if, after a careful and honestly critical review of the OSI terms of use, you decide that your license meets the criteria, you were go ahead and use the OSI mark? would you be in violation of the letter of the law? in other words, does one need a "yes you may use the mark" from OSI prior to use? will they enforce it? (i've not read the opensource.org web pages in the past few weeks, and don't recall specifics). in other words, let's assume that you have a clean license and a pure heart ;-), will some proactive use of the OSI mark cause them to wake up and fulfill the obligation they have incurred, but are currently not fulfilling, or will the OSI mark become meaningless (or has it become meaningless) because OSI doesn't function? 1/2 a ;-) wes //\/\\//\\//\\/\//\\/\\//\\//\\/\\/\//\\//\\//\\//\\//\/\\//\\//\\//\\ Wes Bethel, R3vis Corporation [EMAIL PROTECTED] - http://www.r3vis.com/ Phone: 415-898-0814 FAX: 415-898-2814 //\/\\//\\//\\/\//\\/\\//\\//\\/\\/\//\\//\\//\\//\\//\/\\//\\//\\//\\