Re: Adaptive Public License review
Carmen Leeming scripsit: > "A Distributor may choose to distribute the Licensed Work, or any > portion thereof, in Executable form (an "EXECUTABLE DISTRIBUTION") to > any third party, under the terms of Section 2 of this License, provided > the Executable Distribution is made available under and accompanied by a > copy of this License ***and is distributed at no more than the cost of > physically performing Executable Distribution***, AND provided at least > ONE of the following conditions is fulfilled:" > > (section between '***' marks to be removed) Excellent. > We used the same definition of Electronic Distribution Mechanism as used > in the MPL. Specifically mentioning CDs and DVDs as Electronic > Distribution Mechanisms leaves out other valid current methods, as well > as future methods that may become standard. I'm open to changing this, > but would invite other comments on how specific we want to get with this > definition. I suggest something like "including, but not limited to, distribution by FTP, HTTP, CD, or DVD". The phrase "including, but not limited to" is very useful, as it provides examples without constraining implementation. > >The requirement to make the source of Subsequent Works available for > >three full years in all cases except internal deployment is burdensome. > > > This clause (3.1a) was to promote the continued availablity of the > Subsequent Works, but we could reduce the time-frame if it is too > burdensome. What time would you suggest as reasonable? In fact, I am not thrilled with the whole idea of compelled publication of Subsequent Works at all: it means, for example, that I can't make changes to the source of an APLed application and then email the source to a friend of mine without also publishing the source on a Web site. Indeed, if it weren't for the internal-deployment provision, I would argue that compelling publication makes the license not open source. I don't know if you care about the FSF's certifying the APL as a free software license: historically, they have considered compelled-publication licenses unfree. See http://www.gnu.org/licenses/license-list.html#NonFreeSoftwareLicense . The redline PDF at http://www.opensource.apple.com/apsl/2.0-redline.pdf shows how the GPL rule was added to the 2.0 version of the APSL, allowing either full publication or source-follows-executable rules. Both this and the earlier 1.2 version of the APSL use 12 months rather than 36 as the maximum required publication period. IMHO the GPL's rule that source must accompany (or follow) executable is really enough. But this is a topic on which reasonable persons can differ. -- Si hoc legere scis, nimium eruditionis habes. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Adaptive Public License review
John, thank you for taking the time to review the entire license. My responses to your comments/suggestions are embedded below: [EMAIL PROTECTED] wrote: ... SHOW-STOPPER: Though the APL is MPL-ish in nature, it has a few provisions modeled after the GPL, but intensified in such a way that I believe they violate OSD #1. In particular, Section 3.2 requires that any distribution of Executable code charge no more than the distribution cost. This means that binary packages of the APLed work can't be put on CD-ROMs that are sold above cost, as most distro makers do. We have held in the past that this sort of thing makes a license not open source. Section 3.3(b) makes the same requirement, but only in respect of source code distributed separately from Executable code. The GPL also makes this restriction, and it is a reasonable one: it prevents people from freely distributing the Executable form and holding the source for ransom. (This could only happen in practice in the case of a Subsequent Work.) The intention of Section 3.2 was to require the "Free Redistribution" of the executable. After reviewing the wording of this section, I can see that it violates OSD #1. I can remove a portion of the offending line to make it conform: "A Distributor may choose to distribute the Licensed Work, or any portion thereof, in Executable form (an "EXECUTABLE DISTRIBUTION") to any third party, under the terms of Section 2 of this License, provided the Executable Distribution is made available under and accompanied by a copy of this License ***and is distributed at no more than the cost of physically performing Executable Distribution***, AND provided at least ONE of the following conditions is fulfilled:" (section between '***' marks to be removed) LESSER POINTS: The license should make clear that CD and DVD distribution count as Electronic Distribution, though they are not performed over a wire. We used the same definition of Electronic Distribution Mechanism as used in the MPL. Specifically mentioning CDs and DVDs as Electronic Distribution Mechanisms leaves out other valid current methods, as well as future methods that may become standard. I'm open to changing this, but would invite other comments on how specific we want to get with this definition. The requirement to make the source of Subsequent Works available for three full years in all cases except internal deployment is burdensome. This clause (3.1a) was to promote the continued availablity of the Subsequent Works, but we could reduce the time-frame if it is too burdensome. What time would you suggest as reasonable? CONCLUSION: If the offending language in Section 3.2 is removed, the AFL should be passed as an open source license. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Adaptive Public License
This is a good point. I also laud the effort by those who spent the past year or so trying to make it easier to use and adapt licenses. Unfortunately, occasionally something meant to be easy is more complex because it bends too many preexisting rules or customs. The easy way to make a modular license is to start out the same way FSF has done; think of the GPL as a base license and the LGPL as a modular adaptation. If there are certain known adaptations of your license, you can create them and distinctly name them; otherwise, you are asking OSI to approve licenses that do not yet exist, but could exist if someone made the adaptation. This brings us full circle to the proliferation of licenses. On the other hand, you can draft a license that can easily be used as a template for others, but you will not have the authority to control how the template is used (but that is the point of a template). Rod On Fri, 16 Apr 2004, Ernest Prabhakar wrote: > Hi Carmen, > > I sympathize with your goal. I think there's really several things > going on: > > a) You want to create a license for your project > > b) You want to make it easy for people to create variations of your > license > > c) You'd like to get OSI approval once to cover all licenses > > In that sense, the APL is really a meta-license, which is intended to > make it trivial to generate various OSI-compliant licenses. Is that a > fair statement? There has been periodic talk of such a Universal > License, and I applaud your willingness to undertake this beast. > > I suspect the problem is that the optional modules make life easier for > the *licensor*, but painfully confusing for the *licensee*. I wonder > if it might be more productive - and simpler - to break the problem > down differently. One approach might be to create a Customizable Public > License rather than an Adaptive one. > > 1. Create a baseline license (with no optional terms, though a few > 'fill-in-the-blanks, like ), which reflects your immediate needs > > 2. As a separate document, define optional modules which could be > used to modify the baseline APL. > > 3. Specify that people need to change the name when using a different > version (and perhaps suggest a naming scheme which reflects the modules > included). > > 4. Obtain OSI approval for the baseline license, and (separately, but > simultaneously) approval that modifications associated with the various > optional modules would NOT impact OSI approval. > > That way, it is still the responsibility of the licensors to create a > coherent document, but if they follow a well-defined path they are > effectively pre-approved of OSI certification. > > Would anyone else find that useful/interesting? > > -- Ernie P. > > > On Apr 15, 2004, at 6:58 PM, Carmen Leeming wrote: > > > I am sorry for the confusion in my previous email regarding our > > application of the Adaptive Public License. We have developed a > > specific program that we wish to distribute as open source. Our > > requirements were not met by any existing license. We therefore hired > > a lawyer to aid in drafting a new license that would fit the needs of > > our product. > > > > In the meantime, I have been promoting open source throughout my > > University and encouraging other groups to release their software as > > open source too. Since the University was spending a lot of money on > > this lawyer, we thought it best to try to meet the needs of the other > > projects that the University would like to release. Due to various > > research group restrictions, patent right clauses were desired in some > > cases and not in others. Different groups had ideas for how they > > wished changes to be documented as well. Another concern with a > > university is about how widespread software could be distributed for > > "internal use" without needing to release the source externally. For > > example, some universities own partial interest in start-up companies > > that spawned from research at the university. In some cases you may > > want to allow sharing of modifications to these entities without > > forcing the changes to be released publicly; in other cases you may > > want to maximize the "openness" of the software and prohibit > > "widespread-internal" distributions of closed source modifications. > > > > Seeing that the University of Victoria could gain more benefit from > > this license if we made it adaptable, that was the route we chose. We > > also had input from other universities about whether or not these > > features would meet their needs. We then added the jurisdictional > > option to allow other universities (or anyone else) to be able to use > > this license. > > > > I hope this clears up the issue of why we are applying. We developed > > a license to meet our needs, which are not limited to a single > > project. We could have submitted several similar licenses with the > > adaptive clauses pre-set, but felt that this would just add needlessly
Re: Adaptive Public License
Hi Carmen, I sympathize with your goal. I think there's really several things going on: a) You want to create a license for your project b) You want to make it easy for people to create variations of your license c) You'd like to get OSI approval once to cover all licenses In that sense, the APL is really a meta-license, which is intended to make it trivial to generate various OSI-compliant licenses. Is that a fair statement? There has been periodic talk of such a Universal License, and I applaud your willingness to undertake this beast. I suspect the problem is that the optional modules make life easier for the *licensor*, but painfully confusing for the *licensee*. I wonder if it might be more productive - and simpler - to break the problem down differently. One approach might be to create a Customizable Public License rather than an Adaptive one. 1. Create a baseline license (with no optional terms, though a few 'fill-in-the-blanks, like ), which reflects your immediate needs 2. As a separate document, define optional modules which could be used to modify the baseline APL. 3. Specify that people need to change the name when using a different version (and perhaps suggest a naming scheme which reflects the modules included). 4. Obtain OSI approval for the baseline license, and (separately, but simultaneously) approval that modifications associated with the various optional modules would NOT impact OSI approval. That way, it is still the responsibility of the licensors to create a coherent document, but if they follow a well-defined path they are effectively pre-approved of OSI certification. Would anyone else find that useful/interesting? -- Ernie P. On Apr 15, 2004, at 6:58 PM, Carmen Leeming wrote: I am sorry for the confusion in my previous email regarding our application of the Adaptive Public License. We have developed a specific program that we wish to distribute as open source. Our requirements were not met by any existing license. We therefore hired a lawyer to aid in drafting a new license that would fit the needs of our product. In the meantime, I have been promoting open source throughout my University and encouraging other groups to release their software as open source too. Since the University was spending a lot of money on this lawyer, we thought it best to try to meet the needs of the other projects that the University would like to release. Due to various research group restrictions, patent right clauses were desired in some cases and not in others. Different groups had ideas for how they wished changes to be documented as well. Another concern with a university is about how widespread software could be distributed for "internal use" without needing to release the source externally. For example, some universities own partial interest in start-up companies that spawned from research at the university. In some cases you may want to allow sharing of modifications to these entities without forcing the changes to be released publicly; in other cases you may want to maximize the "openness" of the software and prohibit "widespread-internal" distributions of closed source modifications. Seeing that the University of Victoria could gain more benefit from this license if we made it adaptable, that was the route we chose. We also had input from other universities about whether or not these features would meet their needs. We then added the jurisdictional option to allow other universities (or anyone else) to be able to use this license. I hope this clears up the issue of why we are applying. We developed a license to meet our needs, which are not limited to a single project. We could have submitted several similar licenses with the adaptive clauses pre-set, but felt that this would just add needlessly to the group of existing licenses. We felt a more elegant solution was to have one license that our various research groups could use by simply modifying a few initial conditions. --Carmen Leeming -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Adaptive Public License
I am sorry for the confusion in my previous email regarding our application of the Adaptive Public License. We have developed a specific program that we wish to distribute as open source. Our requirements were not met by any existing license. We therefore hired a lawyer to aid in drafting a new license that would fit the needs of our product. In the meantime, I have been promoting open source throughout my University and encouraging other groups to release their software as open source too. Since the University was spending a lot of money on this lawyer, we thought it best to try to meet the needs of the other projects that the University would like to release. Due to various research group restrictions, patent right clauses were desired in some cases and not in others. Different groups had ideas for how they wished changes to be documented as well. Another concern with a university is about how widespread software could be distributed for "internal use" without needing to release the source externally. For example, some universities own partial interest in start-up companies that spawned from research at the university. In some cases you may want to allow sharing of modifications to these entities without forcing the changes to be released publicly; in other cases you may want to maximize the "openness" of the software and prohibit "widespread-internal" distributions of closed source modifications. Seeing that the University of Victoria could gain more benefit from this license if we made it adaptable, that was the route we chose. We also had input from other universities about whether or not these features would meet their needs. We then added the jurisdictional option to allow other universities (or anyone else) to be able to use this license. I hope this clears up the issue of why we are applying. We developed a license to meet our needs, which are not limited to a single project. We could have submitted several similar licenses with the adaptive clauses pre-set, but felt that this would just add needlessly to the group of existing licenses. We felt a more elegant solution was to have one license that our various research groups could use by simply modifying a few initial conditions. --Carmen Leeming -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Adaptive Public License
It sounds as if you are attempting both to control the distribution of your license along with your software package and to control the distribution of the license as adapted for others; this is rather strange to me. I think there are, generally, three approaches to drafting open source licenses: you draft a license for a specific open source project regardless of whether someone else may want to use the license as a template, you draft a license for a project and/or that is well-suited to be used by others as a template (e.g., OSL v.2.0), or you adopt a license that already exists on the basis that it meets your needs and that its popularity or well-known status signals its terms to many open source users (e.g., GNU GPL). I do not see the Adaptive Public License fitting the last category since the license is adaptive; in other words, its terms will vary. Nearly any license can be a template so I am unsure why an "adaptive" license is needed. Consequently, it may make better sense to focus the drafting of your license on your software package and the needs of your business model, and leave the adapting to those who adapt. -Rod - Original Message - From: "Carmen Leeming" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, April 15, 2004 4:50 PM Subject: Adaptive Public License : The way the Adaptive Public License is set up, only the Initial : Contributor sets the terms outlined in Exhibit A (all the adaptive : elements). Subsequent Contributors may not alter the variables outlined : by the Initial Contributor. However, Subsequent Contributors are not : bound by those terms if they package their work as an Independent : Module. An Independent Module may be released under a different license : (including a variation of the Adaptive Public License with a different : Exhibit A). : : In regards to combining different variants of the Adaptive Public : License, yes the combined licenses can be severable. One of the : licenses needs to be continued as the Initial Work -- subsequent : contributions would follow this license (unless they are Independent : Modules). The other work(s) being combined can be identified as : Independent Module(s), retaining their original variants of the : license. In a similar manner, an Initial Work with the Adaptive Public : License can be combined with other open source (or closed source) : licenses without absorbing contributions to the separately-licensed : Independent Modules. : : I know that this license is very long, but it is difficult to summarize : parts of it without losing the overall integrity of the document as : various parts are interrelated. The third paragraph in my submission : letter : (http://www.crynwr.com/cgi-bin/ezmlm-cgi?3:mss:6913:200305:bogcdnbbhnfbgpdea hob) : is the briefest way I can summarize the differences between the Adaptive : Public License and the MPL 1.1. Although that is the closest license to : this one, the Adaptive Public License was not directly derived from the : MPL -- it is not simply a matter of a few differing paragraphs. : : There is no existing license that contains all of the features that we : require for our project: able to have the governing jurisdiction in : Canada; able to have the main work as open source, but well-defined : separate modules as closed source or under a different open source : license; not being forced to have a patent license; able to define our : own set of documentation requirements; allowing limited attribution : requirements for the Initial Contributor. This license was not : developed for the sake of adding to the proliferation of licenses. The : University of Victoria has spent close to four years developing a large : software package that it would like to be able to share with the open : source community. The University was not willing to release the : software under one of the existing licenses as none of them could : provide all of the features listed above. We spent a year working with : a license lawyer developing the Adaptive Public License to meet the : requirements of the University. We purposely did not brand the license : with our name or our project title so the license could be useful to : others. We have had others inquire about using our license for their : software products, and there was a comment on this forum in March that : indicated support for use too, so we know that this is not a one-time : application of the license. : : Please let me know if you have any further questions. : : Thank you, : --Carmen Leeming : University of Victoria : -- : license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 : -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Adaptive Public License
Michael - I agree with you regarding whether this license solves a problem that an existing license does not. I think the drafter will have to explain; otherwise, I would not recommend approval of the Adaptive Public License since it is not attached to a specific project and appears to be an example of the undesired proliferation of licenses. Rod On Thu, 15 Apr 2004, Michael Tiemann wrote: > Russ Nelson called for more discuccion of this license, which does look > interesting to me. The OSI board has certainly spent its share of time talking > about license compatibility (or the lack thereof), and this license certainly > encapsulates many of the issues we've discussed. My initial read of this > license is that yes, it does satisfy the letter of the OSD, so that's a Good > Thing. But the larger question that I must always ask is: if/when it becomes > used by multiple third parties, what problems can it solve that other > OSI-approved licenses don't solve. > > What is unclear to me is how this license addresses the question of what > happens when two (or more) parties check the boxes differently in Exhibit A. > Are there any incompatible choices within this framework, or are the "combined" > licenses severable (meaning every individual part remains valid even when some > parts offer different terms)? If the latter, then this is a very interesting > license and I think we should move to approve. If the former, it's not clear > to me that having a name for a license that preserves the incompatibility issue > is all that valuable. In fact, it may be bad. > > Michael Tiemann > > -- > license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 > > -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
