Proposed license from AT&T

[Rod Dixon, J.D., LL.M.]

Justin, I read this version and it seems like a substantial improvement!
Congratulations. The only phrase I found unclear was "substantial
functionality" in section 2. I am not suggesting that you add it to the
definitions sections since that section is already rather extensive. I would
just make a mental note that a better phrase could help (It may be the best
choice available, however).

Rod
___________________________________
Rod Dixon
Visiting Assistant Professor of Law
Rutgers University School of Law - Camden
www.cyberspaces.org
rod at cyberspaces.org

Chief Counsel
FreeBuyers Net, LLC
www.freebuyersnet.com
dixon at freebuyersnet.com



> -----Original Message-----
> From: Justin Wells [mailto:jread at semiotek.com]
> Sent: Friday, May 05, 2000 4:23 AM
> To: Rod Dixon, J.D., LL.M.
> Cc: Justin Wells; license-discuss at opensource.org
> Subject: Re: Proposed license from AT&T
>
>
> On Sat, Apr 29, 2000 at 10:24:36AM -0400, Rod Dixon, J.D., LL.M. wrote:
> > I agree that the ATT license is a bit legalistic and could be written in
> > clearer language, but there is much to be learned from there draft.
>
> OK. Well, I'm trying to learn from it, so I went through the AT&T license
> and copied a lot of the ideas, and some of the language, into my
> SPL license. I've also received some comments from the Apache people,
> and have modified the license in response to those comments too.
>
> Unfortunately it also grew a third page, full of definitions, but
> hopefully
> that material earns its keep and makes it a stronger and clearer license.
>
> I have a FSF worldview, but the people most interested in my code are in
> the Apache camp. So I am trying to make this a "compatibility" license
> which bridges the gap between the two opposing worldviews. It's a tricky
> balancing act.
>
> Right now I am especially interested in whether my use of definitions
> is sensible, but as always I am interested in anything that is unclear
> and/or dangerous in my license.
>
> Major changes:
>
>    -- Clarified that the section on combined software does not impose any
>       conditions or restrictions on the other code that gets combined
>       with ours, and rewrote the section for clarity and correctness.
>
>    -- Definition of "modify" no longer uses the scary term "link" but
>       instead states that modifications at execution time are included,
>       with a better definition of what a modification is.
>
>    -- Clarified that "depending on" an operating system does not mean
>       simply functioning on that operating system.
>
>    -- Better definition of "Source code" and of "our software"
>
>    -- Moved definitions to their own section, and expanded the number of
>       terms defined. Now we have definitions for "deploy" (specifying what
>       you can do with the software, rather than the vague term "use"),
>       "distribute" (stating that transmission is included, and requiring
>       distribution as a whole), "electronically publish" (meaning putting
>       software up essentially for free on the internet),
>
>    -- Rewrote the opening section to have a clear acceptance clause
>
>    -- Restored language suggesting that the user perform acceptance
>       tests ("prove to yourself") before using the software.
>
>    -- Tightened up GENERAL TERMS: state what the consideration is, refuse
>       to give up trademarks and other IP, prevent infringement suits being
>       launched against us, strengthen the termination language to make
>       it enforceable.
>
> I've attached an annotated and a non-annotated copy. You can read it in
> HTML or postscript or PDF here:
>
>    http://shimari.com/SPL/
>
> Thanks again for your help!
>
> Justin
>
>