RE: Academic Free License
Just as a side note - not important enough IMHO to send to the list - Larry, you hold the copyright whether or not you include a copyright notice. In legalese, copyright 'arises', it is not claimed or granted. The notice is no longer required under law, although it has definite utility in informing others of *who* believes that they have the rights to the work, as well as reminding people that the creation of derivative works or copies are not permitted (or in your case Larry, not encouraged, to reduce confusion surrounding multiple extant copies). Perhaps it might serve the same utility to include a clause pointing to the canonical copy? I fully acknowledge the concerns over the validity of a copyright on a software license, but in all actuality, the only real hurdle the courts tend to impose for most instances for copyrightability is a modicum of expression. This very dicussion surrounding the license would indicate to me that you are 'expressing' yourself. Respectfully, Ryan Ismert -Original Message- From: Lawrence E. Rosen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 25, 2002 11:37 PM To: 'Rod Dixon'; [EMAIL PROTECTED] Subject: RE: Academic Free License Hi Rod, Thanks as always for your cogent questions and comments. Well worthy of a reply Larry, I like the simplicity of the AFL, but there are two general issues I would like to raise as questions more than an expression of an opinion. 1) Why copyright the license text? Assuming that the text of a license is copyrightable, does the accompanying notice introduce confusion? Aside from the well-intentioned insistence on the adoption of the list of conditions, for distribution of software with the AFL, is it consistent with the objectives of open source to constrain (withhold permission for) modifications of the license? I have always puzzled over whether a suit for copyright infringement of the license text accomplishes anything that a software license does not accomplish in the context of open source??? I personally have no intention of ultimately holding copyright in that license. Perhaps an organization like Creative Commons, or an academic licensing organization, might accept copyright assignment from me of the Academic Free License (or an improved version of it). What I am concerned about is having multiple versions circulating around the web while we discuss and improve upon this draft. There is no effective means other than the copyright law to prevent people from circulating non-redlined modifications of my draft license that otherwise might become self-effectuating by a simple notice in software. So, which draft of the Academic Free License is currently the official one? Mine! under the authority of the Copyright Act. Assuming that the text of a license is copyrightable You may well raise that important issue. Copyrightability is a problem for any document that purports to both have utility (and legal effects) and is expressive. Can a software license be copyrighted? Can a set of rules for calculating your income tax? Can a specification for software be copyrighted if the only purpose of the document is to permit implementation of that specification? Can a published technical standard be copyrighted so as to prevent implementers from modifying their programs? Can a standard that is adopted as a statute by reference be copyrighted? (See the important Veeck case.) Why don't we take these questions to the cni-copyright list where attorneys can debate this to their hearts' content? In the meantime, I elected to claim copyright in the Academic Free License to guarantee some semblance of version control while people suggest improvements. 2) The AFL seems to be targeted for those licensors who need an open source license from Original Licensor -tolicensee, but not necessarily subsequent end-users. Is this correct or, does the 2 list of conditions clauses ostensibly impose a copyleft constraint? The Academic Free License is not intended to impose copyleft. I make no political statement here. I would personally probably prefer a license that imposed source code reciprocity for all derivative works. What I was trying to do in the Academic Free License was merely to clean up some problems I perceived to exist in the BSD, MIT, UoI/NCSA and Apache licenses. Under the AFL, Software is fully licensed for the creation of derivative works that may be either proprietary or open source. The original copyright notices in the Software must be displayed on all copies and derivative works. Other than that, there is no requirement to publish source code of derivative works (or of copies). The license is intended to be available directly from the licensor to anyone who obtains a copy of the Software. A sublicense is not required. /Larry
Re: Approval request for BXAPL
Dear all, With Nathan Kelley I have had a discussion, that has halfway turned private, i.e. we both forgot to cc the list. Since Nathan agreed with me that it would be a good idea to let you all in on the discussion, I have made a surmise of the various mails that have not yet been on this list, and adding comments to the last mail I just received from Nathan. Nathan, should you detect any errors, just holler and put all the blame on me. I've already shown how fallible I am, so it's quite ok ;-) Hope you'll all enjoy. Abe F. Kornelis. === From: Nathan Kelley [EMAIL PROTECTED] I have read the Bixoft Public License (proposal version). I believe that it is consistent with the Open Source Definition, and meets the requirements for OSI certification. However, I do have a few questions on it: Item 10: The stated intention is to denote software items that use the Software, but that are not Derivatives of it. But do the provisions of 10 achieve that? What modifications to the programming tools, as stipulated in c), are sufficient to make the output a derived work? Modifications to the Programming Tools will create a Derived work, as dictated by Copyright Law. When I started out, no such thing as Dependent Software existed, neither in my mind nor anywhere else. In the process of refining however, it dawned upon me, that regarding any software made with a programming tool as a Derivative imposes unrealistic restrictions on the author of such 'derived' software. So I introduced the term 'Dependent Software' and tried to define it as software that makes use of the programming tools without modifying them. The distinction thus draws upon the Copyright Holder designating Programming Tools as such. I tried other approached for making the distinction but could not find anything that satisfied. So, as long as Dependent Software contains no Modifications to the Programming Tools in the Software, it is just that; otherwise it becomes a Derivative and must be subjected to the more stringent redistribution rules in the license. OK. You might then want to use the term Modifications, capitalised as shown, to indicate it refers to modifications as per your glossary definition. Otherwise, it *might* technically indicate that even things like changing configurations for compilation, like the output path, could be classified as modifying the Programming Tools, which would make the output derived. Abe: Such options would normally be passed as invocation parameters, passed on the command line or through a script of some kind. This in no way constitutes a modification. On the other hand, since by copyright law definitions any translation yields a derived work, I wonder how relevant this might be? Output of a compilation or assembly is *always* a derived work, no matter how the compile was done, by which compiler (version), of how it was invoked. Nathan: Yes, it does. And this is a *big* practical problem with Item 10. Use of programming tools licensed under the Bixoft Public License would be very low, because not only could developers be required to distribute their work under the Bixoft Public License (even if they don't want to), but as their software would be a derived work, they could be required to send it to the copyright holders, gratis, at any time, even if they built the entire thing from scratch. This should be fixed in a revised version of the Bixoft Public License. I believe this can be done in one of two ways: 1. Change c) to read they do not make Modifications to the Programming Tools or their function in any way. Since Modifications as per the glossary is limited to source code, c) would only take effect if the programming tools were actually modified at the source level, or Abe: That looks like a very good idea. I don't know why I never put in Modifications as defined. I think it should have been formulated that way. Thanks for suggesting this. Nathan: Great! :-) Nathan: (continued from previous remark) 2. Remove c) altogether, and add a requirement that any Modifications to the Programming Tools are distributed along with the source of the software, along with a notice stating which version of what software from what vendor the modifications apply to. Abe: If I leave it in, the choice is the author's either distribute it as dependent software, including any mod's to the tools, or keep the two separate and enjoy the much larger freedom granted for dependent software. I might make a choice for 'all whom it may concern' but it will never satisfy all of them, so I prefer to leave the decision to those who will bear the 'burden' of living by the consequences of that decision... Nathan: I think you meant ...either distribute it as dependent software, including any mod's to the tools, or keep the two separate and enjoy the much larger freedom granted for
Re: Approval request for BXAPL
From: Steve Lhomme [EMAIL PROTECTED] Forrest J. Cavalier III wrote: Abe Kornelius wrote, in part: It was intended that Distributor designate anyone who redistributes the Software, with or without stuff of his/her own. This would include the Copyright Holder. A Contributor was intended to designate anyone who either redistributes the Software, with or without stuff of his/her own, or who supplies home-grown stuff to the Copyright Holder. Thus, as I intended it, a Distributor is *by definition* always a Contributor also, but a Contributor would not be a Distributor if that Contributor does not distribute the Software and/or the homegrown stuff associated with it. Seems to go in circle here : - A Contributor was intended to designate anyone who either redistributes the Software... - that Distributor designate anyone who redistributes the Software... -- Not in a circle. As defined at the moment a Distributor is anyone distributing the Software, and a Contributor is anyone contributing to the Software, either by supplying additional 'stuff' of by distributing it. And I would rather say a Contributor is a Distributor, but not the opposite. -- I concur that the definitions are prone to misunderstanding. This very discussion proves the point. At some time in the forging of the BXAPL I noticed that nearly all occurrences of Contributor came in the phrase 'Contributors and/or Distributors'. Since the license always has been larger than I wanted it to be it seemed like a good idea to define Contributors as including any Distributors. So that's what I did. Apparently it was not a very good decision. I think I'll have to untangle the definitions and accept an even more unwieldy license text... Anybody got a better idea? If so, why did Steve Lhomme write in his message of 4 July: A Distributor can be (or not) a Contributor. (I thought you were working together on writing this license and getting OSI approval. Are you disagreeing with each other on this point?) Yeah we just hoped we clarified all the obscure points together. It doesn't seem to be the case on this one. -- If it causes confusion so easily, then it really needs mending! Is it your position that contributing software to the original copyright holder is not distribution.? -- Exactly. See the definition in paragraph 2, Contributor. http://www.bixoft.nl/english/license.htm#par02a What happens when there is more than one original copyright holder? Can I send a copy to each and still not have it be Distribution.? Sounds a bit tricky. -- Quite indeed. I think the answer is yes since you're not supplying it to any User, as defined in par. 2 But I must admit that such a scenario has not crossed my mind when setting up the license. I think there shouldn't be a link between Contributor and Distributor. Anyone can be one, the other or both. -- As *currently* defined, you cannot be a Distributor without also being a Contributor, but you might be a Contributor either with or without being a Distributor at the same time. I must admit it is quite counter-intuitive, I nearly put my foot in it myself... Thanks for all of your Contributions, which you have so lavishly Distributed to all the readers of the list ;-) Kind regards, Abe F. Kornelis. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
