Re: Apache vs. BSD licenses
On Wed, 21 Mar 2001 [EMAIL PROTECTED] wrote: on Tue, Mar 20, 2001 at 11:13:22PM +, David Johnson ([EMAIL PROTECTED]) wrote: On Wednesday March 21 2001 06:41 am, [EMAIL PROTECTED] wrote: There's a difference between aligning and coinciding. If my goals coincided exactly with the FSF, you would be completely right. What differences, specifically? Coincide means to occupy equivalent positions, while align means to be on the same line. The first is a location and the latter a direction. I had in mind a discussion of degrees of freedom in software licensing which are of interest to you. I've had my own internal debates over the GNU GPL, whether it's "the one true way", or merely good enough. I have yet to provide myself an answer I'm satisfied with. I'll reiterate: what Copyleft objectives do you have which are not met or satisfied with the current GPL v.2? I can't answer for David, but I will answer this for myself. There are three areas were the GPL could be improved, IMO. One is not very controversial, I hope. The other two are more controverisal, and there's a case that they could be put into separate licenses. (1) compatibility with other Free Software licenses. (I'm not using the term Open Source here, because the FSF aren't going to use it). At the moment, the GPL is incompatible with any license that in any way is more restrictive than the GPL. This includes licenses that the FSF is happy to accept as "Free Software". (2) allowing time-delayed open source. The BSDL allows code to be embedded into closed source programs, and the result remaining unfree forever. I propose that a new license allow embedding into closed source products, but only if the result becomes open source after a time delay, say 3-5 years. This is plenty of time for a company to gain revenue from the sale value of software, and should result in more software becoming freed, albeit after a time delay. This license can be thought of as a compromise between the BSDL and GPL. (3) threats to the legality of free software At the moment, people who can rightly be considered the enemies of free software are trying to make free software illegal for some applications, by using patents or anti-circumvention provisions of copyright laws. Imagine if they win -- we don't be able to write or use oepn source media streaming software, for example. Companies like Microsoft could use this to keep their stranglehold on the desktop. I see this as the biggest threat to Free Software: they can't beat us on technical quality, so they are going to attempt to use force to stop us. One remedy might be an open source license which says that you can use this software, provided you don't use software patents or anti-circumvention laws to stop people using free software. I've expanded on this idea on my website at http://www.vision25.demon.co.uk/ip/proposal2.html I share this concern. I do believe, strongly, that a very conservative approach to licensing is healthy, and that a proliferation of licenses, compatible or otherwise, is bad -- though incompatible licenses are naturally worse. IMO compatible license are OK. Imagine a world were all Free Software / Open Source licenses are compatible with each other. That's the world I'd like to see. A proliferation of licenses is bad. But how many do we really need? IMO, about 5: (i) BSDL-like. Allows encapsulation in non-free programs (ii) LGPL-like. Copylefts the library, but allows the library's use in non-free applications (iii) time-delayed copyleft. See my proposal above (iv) full copyleft. Like the GPL or QPL. (v) Copyleft with provisions against agressive use of software patents and/or anti-circumvention laws I think this covers most possibilities. If all open source licenses were compatible with each other, then it wouldn't matter much, as anyone could mix and match code from all these types of licenses, happy that the result was legal and open source. People wishing to put open source code into proprietary products would have to be more careful, but that's no different from the present situation. Under this scheme, core, immutable, licensing language is defined. Would this be based on the language used by the DFSG/OSD? Items of variance, which I envision as largely pertaining to identity, authoring/versioning authority, and jurisdiction or venue, would be identified. So you could have one license, with optional paragraphs? That sounds a good idea. -- * Phil Hunt * "An unforseen issue has arisen with your computer. Don't worry your silly little head about what has gone wrong; here's a pretty animation of a paperclip to look at instead." -- Windows2007 error message
RE: Apache vs. BSD licenses
From: phil hunt [SMTP:[EMAIL PROTECTED]] source products, but only if the result becomes open source after a time delay, say 3-5 years. This is plenty of time for a company to gain revenue from the sale value of software, and should [DJW:] That sort of time figure agrees with my idea as to the time limit that should be applied to most software patents, and for similar reasons. -- --- DISCLAIMER - Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of BTS.
Re: Apache vs. BSD licenses
on Tue, Mar 20, 2001 at 11:13:22PM +, David Johnson ([EMAIL PROTECTED]) wrote: On Wednesday March 21 2001 06:41 am, [EMAIL PROTECTED] wrote: There's a difference between aligning and coinciding. If my goals coincided exactly with the FSF, you would be completely right. But if they differ even a tiny fraction, then the possibility exists that another license is more suited to my purposes. That's why multiple political parties exist in free nations, and why multiple free licenses should exist for Free Software. What differences, specifically? Coincide means to occupy equivalent positions, while align means to be on the same line. The first is a location and the latter a direction. I had in mind a discussion of degrees of freedom in software licensing which are of interest to you. I've had my own internal debates over the GNU GPL, whether it's "the one true way", or merely good enough. I have yet to provide myself an answer I'm satisfied with. I'll reiterate: what Copyleft objectives do you have which are not met or satisfied with the current GPL v.2? There are others (lurking on this list, and you know who you are) who've expressed a concern with the fact that the current state of free software licensing makes it difficult to introduce new ideas into play. I share this concern. I do believe, strongly, that a very conservative approach to licensing is healthy, and that a proliferation of licenses, compatible or otherwise, is bad -- though incompatible licenses are naturally worse. This leads to increasing complexity on the legal landscape, a landscape which a current near-exclusive focus on three fundamental licenses -- GNU GPL, MIT/BSD, and MozPL -- has kept relatively streamlined. Though some have complained about the OSI license approval pipeline and process, I remain half-convinced that a slow process is a feature, not a bug. Though I've suggested previously steps which might help streamline it, as have others. I've suggested previously and will reiterate a proposal for using a reference in a system which might allow for evolution. The original suggestion was aimed at the MozPL and its kin (SCSSL, Jabber), though it could be adapted. Under this scheme, core, immutable, licensing language is defined. Items of variance, which I envision as largely pertaining to identity, authoring/versioning authority, and jurisdiction or venue, would be identified. Parties wishing to adapt and adopt the license could do so. Variants meeting guidelines would be considered equivalent. Parties would be free to propose changes to licensing terms -- having authorship/versioning authority over their variant, they'd be free to do so. However, the standard revised licensing terms would have to be agreed upon by some plurality [1] of parties. Any of these pluralities might decide to go their separate way. There is a benefit, of course, in maintaining compatibility between valuable code bases. And there is always the possibility that after one or more generations of divergence, terms might later come to coincide (analogous to temporary forking of a software development branch). Independently of versioning authority, maintainers of works which had already incorporated code under terms of other licenses would (if required by these licenses) be constrained to remain in coordination with any changes to terms of these licenses. Easy? No. Unwieldy? Maybe. But this is about the only proposal I've seen which remotely addresses to issues of integrity (not ceding versioning authority to another organization or some trusted party as the FSF), *and* of keeping legal language in concert. Notes: 1. I've been reading too many patent claims -- Karsten M. Self [EMAIL PROTECTED]http://kmself.home.netcom.com/ What part of "Gestalt" don't you understand? There is no K5 cabal http://gestalt-system.sourceforge.net/ http://www.kuro5hin.org PGP signature
Re: Apache vs. BSD licenses
On Wednesday March 21 2001 09:06 am, [EMAIL PROTECTED] wrote: I'll reiterate: what Copyleft objectives do you have which are not met or satisfied with the current GPL v.2? Well, since I don't use copyleft for my own works, this is kind of hard to answer :-) I prefer the LGPL over the GPL simply because I won't get into trouble if I dynamically link to it. As a user (one who does not modify the source code), the linkage problems with most copyleft licenses are problematic. Under this scheme, core, immutable, licensing language is defined. Items of variance, which I envision as largely pertaining to identity, authoring/versioning authority, and jurisdiction or venue, would be identified. Parties wishing to adapt and adopt the license could do so. Variants meeting guidelines would be considered equivalent. If you could keep compatibility between the variants, it would be a very good idea. But incompatibilities between variants would be a nightmare, much worse than the current version since it would be all to easy to get the variants confused. It's a good idea. -- David Johnson ___ http://www.usermode.org
Re: Apache vs. BSD licenses
on Wed, Mar 21, 2001 at 02:23:32AM +, David Johnson ([EMAIL PROTECTED]) wrote: On Wednesday March 21 2001 09:06 am, [EMAIL PROTECTED] wrote: I'll reiterate: what Copyleft objectives do you have which are not met or satisfied with the current GPL v.2? Well, since I don't use copyleft for my own works, this is kind of hard to answer :-) I prefer the LGPL over the GPL simply because I won't get into trouble if I dynamically link to it. As a user (one who does not modify the source code), the linkage problems with most copyleft licenses are problematic. Under this scheme, core, immutable, licensing language is defined. Items of variance, which I envision as largely pertaining to identity, authoring/versioning authority, and jurisdiction or venue, would be identified. Parties wishing to adapt and adopt the license could do so. Variants meeting guidelines would be considered equivalent. If you could keep compatibility between the variants, it would be a very good idea. But incompatibilities between variants would be a nightmare, much worse than the current version since it would be all to easy to get the variants confused. Consider that a strong disincentive among the participants to create incompatibilities, and an incentive among the cooperating parties to disassociate themselves from defecting parties. The scheme as presented doesn't call for any voting or unanimity -- typical failure points of collaborative organizations. The standard is as the standard does. It's a good idea. Thanks. I'm happy now to know that at least one other person's read it -- Karsten M. Self [EMAIL PROTECTED]http://kmself.home.netcom.com/ What part of "Gestalt" don't you understand? There is no K5 cabal http://gestalt-system.sourceforge.net/ http://www.kuro5hin.org PGP signature
Re: Apache vs. BSD licenses
Ian Stokes-Rees wrote: We are looking at open sourcing a software project and are currently trying to evaluate BSD vs. Apache. The issue is that our code base includes Xerces-C (XML parser) which is under Apache Public License. The implication, then, is that for both subsequent source and binary distributions there is the requirement to a) include the APL (this makes sense and isn't a problem), and b) include credits in binary only distributions (more annoying). What clause of the Apache licence (which is *not* the Apache 'Public' licence, btw) requires you to accrete credit? All it says is that if you use stuff from the ASF, you need to say so. A one-liner, plus the Apache licence file, ought to be sufficient. I understand that the FSF position on this is that the APL is GPL incompatible because otherwise the required list of creditors grows and grows with every person who makes individual contributions which are not signed over to one of the current "owners". That is not the case. Nothing in the Apache licence requires anything of the kind. -- #kenP-)} Ken Coarhttp://Golux.Com/coar/ Apache Software Foundation http://www.apache.org/ "Apache Server for Dummies" http://Apache-Server.Com/ "Apache Server Unleashed" http://ApacheUnleashed.Com/ ApacheCon 2001! Four tracks with over 70+ sessions. Free admission to exhibits and special events - keynote presentations by John 'maddog' Hall and David Brin. Special thanks to our Platinum Sponsors IBM and Covalent, Gold Sponsor Thawte, and Silver Sponsor Compaq. Attend the only Apache event designed and fully supported by the members of the ASF. See more information and register at http://ApacheCon.Com/!
Re: Apache vs. BSD licenses
To clarify: Please refer to the "GPL-Incompatible, Free Software Licenses" section on the GNU web site at: http://www.gnu.org/philosophy/license-list.html#GPLIncompatibleLicenses Second, my mistake was in wording: We are not going to turn over our software to Apache, therefore when I say we are considering releasing it under the Apache License, I mean that we are considering releasing it under an Apache _style_ license, basically using v1.1 as the template. If we were to do this, and subsequent developers were to do the same, then each developer who redistributed the accumulated code base with new files and entirely new code which they put under _their_ version of Apache License, the credits list would grow and grow. This is my _understanding_ of what happens when people use Apache, and that it was the major criticism of the original BSD license, hence the new BSD license. I fully accept that I may have a misguided impression of how Apache and Apache style licenses work, hence my posts to this discussion list. I would appreciate any clarification. We do not want there to be run away licenses on the code base we are distributing. If we release it under BSD and other people do the same, then their will only be two licenses: One for Xerces (Apache License), and one for everything else (BSD). Finally, it was mentioned that (to quote): "... the Apache licence (which is *not* the Apache 'Public' licence, btw) ...". I was under the impression that the Apache License was, at times, refered to as the Apache Public License. The following links somewhat support that claim (both on apache.org): http://jakarta.apache.org/turbine/license.html http://xml.apache.org/batik/license.html Cheers, Ian. Rodent of Unusual Size wrote: Ian Stokes-Rees wrote: We are looking at open sourcing a software project and are currently trying to evaluate BSD vs. Apache. The issue is that our code base includes Xerces-C (XML parser) which is under Apache Public License. The implication, then, is that for both subsequent source and binary distributions there is the requirement to a) include the APL (this makes sense and isn't a problem), and b) include credits in binary only distributions (more annoying). What clause of the Apache licence (which is *not* the Apache 'Public' licence, btw) requires you to accrete credit? All it says is that if you use stuff from the ASF, you need to say so. A one-liner, plus the Apache licence file, ought to be sufficient. I understand that the FSF position on this is that the APL is GPL incompatible because otherwise the required list of creditors grows and grows with every person who makes individual contributions which are not signed over to one of the current "owners". That is not the case. Nothing in the Apache licence requires anything of the kind. -- #kenP-)} Ken Coarhttp://Golux.Com/coar/ Apache Software Foundation http://www.apache.org/ "Apache Server for Dummies" http://Apache-Server.Com/ "Apache Server Unleashed" http://ApacheUnleashed.Com/ ApacheCon 2001! Four tracks with over 70+ sessions. Free admission to exhibits and special events - keynote presentations by John 'maddog' Hall and David Brin. Special thanks to our Platinum Sponsors IBM and Covalent, Gold Sponsor Thawte, and Silver Sponsor Compaq. Attend the only Apache event designed and fully supported by the members of the ASF. See more information and register at http://ApacheCon.Com/! -- Ian Stokes-Rees, Engineering Manager DecisionSoft Ltd. Telephone: +44-1865-203192http://www.decisionsoft.com
Re: Apache vs. BSD licenses
Rodent of Unusual Size wrote: This is my _understanding_ of what happens when people use Apache, and that it was the major criticism of the original BSD license, hence the new BSD license. And hence the Apache 1.1 licence revision, which mirrored that change in the BSD licence. I understood that AL 1.1 was an *old* BSD license, with the advertising clause, as appears from the apache.org web site. -- There is / one art || John Cowan [EMAIL PROTECTED] no more / no less || http://www.reutershealth.com to do / all things || http://www.ccil.org/~cowan with art- / lessness \\ -- Piet Hein
Re: Apache vs. BSD licenses
On Tue, 20 Mar 2001, Rodent of Unusual Size wrote:
Ian Stokes-Rees wrote:
If we were to do this, and subsequent developers were to do the
same, then each developer who redistributed the accumulated code
base with new files and entirely new code which they put under
_their_ version of Apache License, the credits list would grow
and grow.
That is a consequence of the ASFisms or their replacements, not
the licence terms themselves..
Actually, Ken, Ian is right. If there is a bundle of code that contains
ASF code, which has an Apache License 1.1-style license on it requiring
attribution to this other party, then both the ASF and this other party
need to have their credits remain. The license terms do require this, and
it's not likely to change in the near future, since people in the ASF
believe pretty strongly in attributing credit where earned. If you have a
string of derivative works, you have a string of attributions. You can
remove an attribution from that list only if you're sure none of that
contributor's work is being used anymore.
Personally, I think this is a pretty small thing to ask. Even with 1000
contributors representing a chain of 1000 derivations (whereas these days
you rarely have two or three) such an atribution would take under 100K of
text, or 10K compressed. Giving credit is an inexpensive way of spread
the benefits of participation in an open source project, and costs the
current developers essentially nothing.
Note that this "advertising clause" is much different in 1.1 than in 1.0.
In fact, it was carefully written to *be* GPL compatible. The clause
"Alternately, this acknowledgment may appear in the software itself,
if and wherever such third-party acknowledgments normally appear" can
apply to sourcecode as well - that is, if you have a GPL tarball that
contains Xerces code, you are of course distributing source, and that
acknowlegement appears in the source to the Xerces code, where such a
"third-party acknowledgment normally appears". I've discussed this with
Stallman and he agrees, grudgingly, that clause 3 is not GPL-incompatible.
Such notices will persist, as well, because the GPL does not allow you to
remove copyright notices on included code (I believe...).
He still has an issue with clauses 4 and 5, though, which are a device to
help protect us against someone creating a proprietary fork and calling it
"ApachePro", or "Apache++" or whatever. Stallman believes such things
should be enforced through trademark law. I think anyone who's been
through trademark law proceedings would tell you to avoid it at all costs
- trademark law is all about who has the more expensive lawyers arguing
your case. :/ By making it a term of copyright, we protect that interest
in a much more direct way.
Stallman has indicated to me that clause 4 ("Apache" may not be used to
endorse) will be compatible with the GPL v3, but clause 5 ("Apache" may
not appear in the product name) will not. I think this is unfortunate, as
in a digital environment, your good name is your only asset, and
protecting it shouldn't be hard. I don't see asking someone to choose a
different name for a derivative work as not qualifying as "free" as the
FSF defines it.
Brian
Re: Apache vs. BSD licenses
On Tue, 20 Mar 2001, Brian Behlendorf wrote:
Stallman has indicated to me that clause 4 ("Apache" may not be used to
endorse) will be compatible with the GPL v3,
That's a good change.
but clause 5 ("Apache" may
not appear in the product name) will not.
That isn't good, and is IMO puzzling. Putting "Apache" in a product's name
could be done in order to use the Apache developers' reputation and
good name to endorse (indirectly) the product.
I think this is unfortunate, as
in a digital environment, your good name is your only asset, and
protecting it shouldn't be hard. I don't see asking someone to choose a
different name for a derivative work as not qualifying as "free" as the
FSF defines it.
It would be nice if there was a license like the GPL, but compatible
with all open source / free software licenses. I have suggested this
to RMS; he replied that legal difficulties prevented this.
--
* Phil Hunt *
"An unforseen issue has arisen with your computer. Don't worry your silly
little head about what has gone wrong; here's a pretty animation of a
paperclip to look at instead."
-- Windows2007 error message
Re: Apache vs. BSD licenses
On Tuesday March 20 2001 06:12 pm, Brian Behlendorf wrote:
Stallman has indicated to me that clause 4 ("Apache" may not be used to
endorse) will be compatible with the GPL v3, but clause 5 ("Apache" may
not appear in the product name) will not.
Why is it always the non-GPL license that must conform? Why is the GPL never
criticized for being incompatible?
--
David Johnson
___
http://www.usermode.org
Re: Apache vs. BSD licenses
On Tue, 20 Mar 2001, David Johnson wrote:
On Tuesday March 20 2001 06:12 pm, Brian Behlendorf wrote:
Stallman has indicated to me that clause 4 ("Apache" may not be used to
endorse) will be compatible with the GPL v3, but clause 5 ("Apache" may
not appear in the product name) will not.
Why is it always the non-GPL license that must conform? Why is the GPL never
criticized for being incompatible?
Er, actually, it sounds like he's considering substantive changes in
GPLv3, or at least "clarifications" for the pragmatic purpose of
explaining or reconciling compatibility issues, so long as it doesn't
change his core beliefs about what constitutes "free".
Since the Apache community's views on IP are not incompatible with the
FSF's (Apache developers are already comfortable with the idea that
commercial entities can use the code in proprietary products without
contributing anything back; the idea of someone using Apache code in a
GPL-licensed derivative work is no worse) I've been attempting to
reconcile our licenses to allow GPL derived works. The
managing-our-identity-through-copyright-law-instead-of-trademark-law
issue is now all that separates us.
Brian
Re: Apache vs. BSD licenses
on Tue, Mar 20, 2001 at 07:43:31PM +, David Johnson ([EMAIL PROTECTED]) wrote:
On Tuesday March 20 2001 06:12 pm, Brian Behlendorf wrote:
Stallman has indicated to me that clause 4 ("Apache" may not be used to
endorse) will be compatible with the GPL v3, but clause 5 ("Apache" may
not appear in the product name) will not.
Why is it always the non-GPL license that must conform? Why is the GPL never
criticized for being incompatible?
The GPL specifies a set of requirements, and, to further its objectives,
requires that they be adhered to -- they cannot be increased or
diminished. If you think about it, any more flexible approach is likely
to lead to loopholes.
The other question is: if your objectives align with those of the GPL
(copyleft, promotion of free software), why would you need a different
license? This isn't an entirely rhetorical question.
Practically, one alternative that's being practiced with greatre
frequency is mutliple licensing, with the GPL or a GPL-compatible
license (usually the LGPL -- compatibility being accomplished by
deferring to the GPL when used in combination with other GPLd code).
I'm not sure what alternative constructs exist, one option might be a
license which specifies some sort of legal test. The OSD is a possible
instance of same (though it's a meta license). The IBM public license
also provides a somewhat similar test.
The problem with such a construct is you now have to go through and
legally analyze all licenses to see whether or not they satisfy the
test. And come up with a way to deal with the possibility you'll have
to change your mind on such a decision down the road.
By specifying an immutable set of text (the GPL), the test is greatly
simplified. Though some licenses are compatible by virtue of not adding
additional requirements to those of the GPL (revised BSD, MIT,
Artistic). Meaning that a bit of analysis may be necessary even under
the current regime.
--
Karsten M. Self [EMAIL PROTECTED]http://kmself.home.netcom.com/
What part of "Gestalt" don't you understand? There is no K5 cabal
http://gestalt-system.sourceforge.net/ http://www.kuro5hin.org
PGP signature
Re: Apache vs. BSD licenses
On Wednesday March 21 2001 05:19 am, Brian Behlendorf wrote: Why is it always the non-GPL license that must conform? Why is the GPL never criticized for being incompatible? Er, actually, it sounds like he's considering substantive changes in GPLv3, or at least "clarifications" for the pragmatic purpose of explaining or reconciling compatibility issues, so long as it doesn't change his core beliefs about what constitutes "free". That's good to hear. The process of devising the GPLv3 is a mystery to myself and most others, so it's nice to know that he's thinking about how it will interact with other free licenses. -- David Johnson ___ http://www.usermode.org
Re: Apache vs. BSD licenses
On Wednesday March 21 2001 05:43 am, [EMAIL PROTECTED] wrote: The other question is: if your objectives align with those of the GPL (copyleft, promotion of free software), why would you need a different license? This isn't an entirely rhetorical question. There's a difference between aligning and coinciding. If my goals coincided exactly with the FSF, you would be completely right. But if they differ even a tiny fraction, then the possibility exists that another license is more suited to my purposes. That's why multiple political parties exist in free nations, and why multiple free licenses should exist for Free Software. -- David Johnson ___ http://www.usermode.org
Re: Apache vs. BSD licenses
On Wednesday March 21 2001 06:41 am, [EMAIL PROTECTED] wrote: There's a difference between aligning and coinciding. If my goals coincided exactly with the FSF, you would be completely right. But if they differ even a tiny fraction, then the possibility exists that another license is more suited to my purposes. That's why multiple political parties exist in free nations, and why multiple free licenses should exist for Free Software. What differences, specifically? You mean between the Republican and Reform parties? Between the GPL and the BSDL? Between the FSF and myself? Or between "aligning" and "coinciding"? Assuming you meant the latter... Coincide means to occupy equivalent positions, while align means to be on the same line. The first is a location and the latter a direction. -- David Johnson ___ http://www.usermode.org
