Adaptive Public License

[Rod Dixon]

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
> > 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
>
>
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3