Re: an open source model code: osd 2002
On Thursday 23 May 2002 4:03 am, Rod Dixon wrote: Please take a moment or two to download a draft of the framework for our work on the OSD. We have only posted Article 1. We would like to hear your thoughts on the framework. It is our view that a model code is the most helpful framework for augmenting the Open Source Definition (OSD), but we would like to hear what the folks on license-discuss have to say. 1-1 The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale This could be changed to: 1-1 The license shall not restrict any party from selling or giving away the software, EITHER ON ITS OWN, OR as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale -- Philip Hunt [EMAIL PROTECTED] I would guess that he really believes whatever is politically advantageous for him to believe. -- Alison Brooks, referring to Michael Portillo, on soc.history.what-if -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Lines of Code
On Monday 06 May 2002 8:12 am, Ken Brown wrote: Hello, Does anyone know approximately how many lines of code are in Unix and Linux? Have a look at http://www.dwheeler.com/sloc/ -- Philip Hunt [EMAIL PROTECTED] I would guess that he really believes whatever is politically advantageous for him to believe. -- Alison Brooks, referring to Michael Portillo, on soc.history.what-if -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: OSD modification regarding what license can require of user
On Tuesday 19 March 2002 3:48 pm, Ean Schuessler wrote: On Mon, 2002-03-18 at 18:01, phil hunt wrote: This ties it to a specific technology. For all anyone knows, no-one will be using http in 109 years time. Once HTTP goes away (which will probably be 109 years) OK, I meant 10 years. Slip of the finger. change the protocol in the license. The point is that we want to enforce distribution of source Then have some words to the effect bthat the system uses usual and convenient technological methods to distribute it. -- Philip Hunt [EMAIL PROTECTED] I would guess that he really believes whatever is politically advantageous for him to believe. -- Alison Brooks, referring to Michael Portillo, on soc.history.what-if -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: OSD modification regarding what license can require of user
On Monday 18 March 2002 5:14 pm, Ean Schuessler wrote: What if you simply added a requirement that: http://[service host name]:80/gnu-sources Must always either supply the sources or a redirect to the sources? This ties it to a specific technology. For all anyone knows, no-one will be using http in 109 years time. -- Philip Hunt [EMAIL PROTECTED] I would guess that he really believes whatever is politically advantageous for him to believe. -- Alison Brooks, referring to Michael Portillo, on soc.history.what-if -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Discuss: BSD Protection License
On Tuesday 12 March 2002 8:14 pm, Andy Tai wrote: The only point in this license seems to be the GPL incompatibility. And you then blame the GPL? If the GPL is guilty of anything, then you are guilty of the same. So this license creates walls in open source code and divides the community, on purpose. Maybe this license should be discouraged just for this. I agree. The entire intent behind this license is to be deliberately incompatible with the most commonly used open source license. IMO this calls into question whether the proponent is acting in good faith. -- Philip Hunt [EMAIL PROTECTED] I would guess that he really believes whatever is politically advantageous for him to believe. -- Alison Brooks, referring to Michael Portillo, on soc.history.what-if -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Discuss: BSD Protection License
On Wednesday 13 March 2002 1:55 pm, Colin Percival wrote: At 14:04 13/03/2002 +, phil hunt wrote: I agree. The entire intent behind this license is to be deliberately incompatible with the most commonly used open source license. No, it isn't. The intent is to ensure that a free for both open and closed source use body of code can't be turned into a free for open source use only body of code. Yes, and you're doing that by deliberate GPL-incompatibility. I mention GPL-taint because the GPL is the most common example of an (from my point of view) overly restrictive license. So, you admit that it is deliberately incompatible with the GPL. Do you also admit (as can be easily demonstrated by looking at Freshmeat) that the GPL is the most popular open source license? Because, IMO, you must either admit that I am right, or deny something that is blatently obvious. I also notice your word taint used to describe the GPL. Here, you seem to be implying that you dislike the most popular open source license, and by implication, people who choose to write software under this license; thus it seems to me therefore that you dislike a large part of the OS/FS community. There is a tradition that once a project has adopted a given license (eg, the BSD operating systems and the BSD license), further work is incorporated under the same license. Indeed so. This merely formalizes that. That is not true. -- Philip Hunt [EMAIL PROTECTED] I would guess that he really believes whatever is politically advantageous for him to believe. -- Alison Brooks, referring to Michael Portillo, on soc.history.what-if -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Discuss: BSD Protection License
On Wednesday 13 March 2002 7:55 pm, Colin Percival wrote: To save time, can we just agree that I have absolutely horrible motives, that I'm a Microsoft plant, and that I'm reporting to the Illuminati, and get back to discussing the license? You are not interested in defending your motives; others must make of that what they will. -- Philip Hunt [EMAIL PROTECTED] I would guess that he really believes whatever is politically advantageous for him to believe. -- Alison Brooks, referring to Michael Portillo, on soc.history.what-if -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Discuss: BSD Protection License
On Tuesday 12 March 2002 4:07 am, Andy Tai wrote: While this license probably is open source, My reading of the license and the OSD suggests to me that it isn't. OSD, para 1: The license shall not restrict any party from selling or giving away the software [...] License, 3 (c): The license under which the derivative work is distributed must expressly prohibit the distribution of further derivative works. This restricts people from selling or giving away the software, because it imposes a restrictive term on how they can give it away. (One could even say this license is not open source because it discriminates against people doing GPL development, but this argument may not be very strong.) You could equally argue that the GPL discriminates against people writing proprietary software. That clause isn't intended to be read that way. -- Philip Hunt [EMAIL PROTECTED] I would guess that he really believes whatever is politically advantageous for him to believe. -- Alison Brooks, referring to Michael Portillo, on soc.history.what-if -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Discuss: BSD Protection License
On Tuesday 12 March 2002 1:16 am, Colin Percival wrote: At 11 Mar 2002 20:57:24 -, [EMAIL PROTECTED] resent my email to this mailing list and added the line: [ Please discuss this license. Is he reinventing the LGPL? ] No, I'm not. To start with, the LGPL only applies to libraries. That's not true, you can license any code with it. -- Philip Hunt [EMAIL PROTECTED] I would guess that he really believes whatever is politically advantageous for him to believe. -- Alison Brooks, referring to Michael Portillo, on soc.history.what-if -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Discuss: BSD Protection License
On Tuesday 12 March 2002 3:53 pm, Colin Percival wrote: At 15:37 12/03/2002 +, phil hunt wrote: OSD, para 1: The license shall not restrict any party from selling or giving away the software [...] License, 3 (c): The license under which the derivative work is distributed must expressly prohibit the distribution of further derivative works. This restricts people from selling or giving away the software, because it imposes a restrictive term on how they can give it away. 2. Verbatim copies. You may copy and distribute verbatim copies of the Program as you receive it... Good point. It appears I was wrong here. There are no restrictions on how licensed code can be copied or distributed; the only restrictions are on how derivative works are distributed. It seems as though there might be some confusion (see David Johnson's earlier note on this) resulting from the juxtaposition of sections 2,3, and 4, each of which states that You may I don't personally see any problem here -- section 2 grants you some rights, section 3 grants you some rights, section 4 grants you some rights -- but would people be happier if I explicitly pointed out that the three sections cover different actions, and obviously the restrictions attached to each section only apply to that section? Yes. If the current wording is confusing, it is obviously better to word it in a way people don't find ambiguous. -- Philip Hunt [EMAIL PROTECTED] I would guess that he really believes whatever is politically advantageous for him to believe. -- Alison Brooks, referring to Michael Portillo, on soc.history.what-if -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: request for approval of APPOSL - going by the numbers.
On Wednesday 06 March 2002 9:59 pm, dave sag wrote: The intent of clause 4 is that people are encouraged to think about and to describe their work as being pronoic, ie as being part of a greater conspiracy to make life better. we encourage developers do this before, or if ever, seeking permission to use the term. What people are encouraged to do isn't really part of a license as such -- though it could reasonably be part of a preamble to a license. A license should describe what licensees are intended to be compelled by law to do / not do. -- Philip Hunt [EMAIL PROTECTED] I would guess that he really believes whatever is politically advantageous for him to believe. -- Alison Brooks, referring to Michael Portillo, on soc.history.what-if -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: open source licenses and algorithms
On Monday 21 January 2002 12:07 pm, Patrik Wallstrom wrote: I know this has been up for discussion before, but I didn't really follow the thread, and I want to know some extra things. Is there any current open source licenses that can enforce the software to follow an exact algorithm (as provided by the copyright owner) and protocol? This would restrict the ability to fork the code, and is clearly against the spirit of the OSD. Does any of the licenses also prohibit a name change of the software package? I think this too would restrict the ability to fork the code. -- *** Philip Hunt *** [EMAIL PROTECTED] *** -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Is the Guile license OSI approved?
On Friday 30 November 2001 4:23 am, J C Lawrence wrote: On Thu, 29 Nov 2001 17:10:42 -0800 (PST) Andy Tai [EMAIL PROTECTED] wrote: Given the history of Free Software and Open Source (that Open Source is a marketing name (Bruce Perens) or marketing program (Eric Raymond) for Free Software), can there be any question that a software license the Free Software Foundation published is not Open Source? If the FSF published licenses that didn't meet the OSD, then they wouldn't be open source licenses. And in fact the FSF do just that; on their webh site many of their documents are marked: Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. Which prohibits changing and is thus not an open source license. Yes, tho for political reasons you're unlikely to ever see that response by OSI. It is relatively easy to argue, for instance, that the viral properties of the GPL are excessively restrictive and violate the spirit if not intent of the OSS definition Only in the sense that it's easy to argue that 2 plus 2 is 5. When the OSD was written (in its original incarnation the, DFSG) the GPL was in mind specifically as one of the licenses that should meet this definition. -- *** Philip Hunt *** [EMAIL PROTECTED] *** -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: MrNet has a non compliant opensource license
On Sunday 28 October 2001 10:43 pm, Karsten M. Self wrote: What can be done more to this effect? The Open Source trademark was not certified. Have you contacted the company? If this has not already been done, I'd suggest a *polite* note sent to them pointing out their error and suggesting that they either refrain from calling it open source or change their license so it complies with the Open Source Definition. It may be an honest mistake, and their is no point in accusing and annoying people unnecessarily. If their response is not considered sufficient, I'd submit the usual: a Slashdot story that makes clear that the company is trying to free-ride the OSI Open Source Certified Software® mark, that the true mark is as shown above, not Open Source, and that the company's claims fail the OSD on multiple points. Indeed. But firstly, contact the company. -- *** Philip Hunt *** [EMAIL PROTECTED] *** -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: YAPL is bad (was: Re: Backlog assistance?)
On Saturday 22 September 2001 11:39 pm, Karsten M. Self wrote: Yet Another Public License (YAPL) is a bad trend. Ceterus paribus, more licenses are bad. As the number of licenses increases, the disruption caused by an additional license increases. This is because interaction effects of licenses must be considered on a combinatorial basis. That is, effects grow in a factorial manner. The terms of each license must be understood independently. The interactions of each license pair, *and each combination of licences*, must be considered. What if, as part of the porcess of approving a new licence, the proposer of the license had to write a rationale of why a new license is necessary, and why no existing OSI-certified licence exists that does the job. Is this a good idea? -- *** Philip Hunt *** [EMAIL PROTECTED] *** -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: GPLv2 'web-app loophole'
On Wednesday 08 August 2001 2:15 am, David Johnson wrote: My point is not whether a thing can be done, but whether it should be done at all. I don't believe that Open Source licenses should regulate in any way the actual execution of the software. Are you saying that the Open Source Definition should include a clause forbidding restrictions on the execution of the software? -- #= Philip Hunt == [EMAIL PROTECTED] ==# Herbivore: effort-free public key email encryption. See: http://www.vision25.demon.co.uk/oss/herbivore/intro.html *** herbrip software now released ***
command-line calls of GPL'd executables
Consider this situation: Alice writes a program, aprog, which she licenses under the GPL. Bob writes another program, which invokes the aprog executable, using the POSIX system() call. Does Bob's program have to be released under a GPL-compatible license? (Assume for the sake of argument that there is no other program that does the same as aprog). What if aprog is, instead, licensed under the BSDL with advertising clause. Can be GPL his program? -- #= Philip Hunt == [EMAIL PROTECTED] ==# Herbivore: effort-free public key encryption. See: http://www.vision25.demon.co.uk/oss/herbivore/intro.html ** First software release coming soon! **
Re: Real-World Copyright Assignment
On Thursday 21 June 2001 12:58 am, Henningsen wrote: Currently that is the rule no doubt, but I think we could get open source code written faster and probably better if people could actually expect getting paid for their work. In exchange for giving up his/her copyrights, a contributor to my code who has written 10% of the code (counted by lines of code, assuming that every contributing author writes entire file modules, and small patches are disregarded) would get paid something like 5% of any profits from commercial licenses. If you are counting strictly by code size, won't that tend to produce bloated code? If I was being paid according to LOCs I'd written, I could write some shitty bloated rubbish. -- ## Philip Hunt ## ## [EMAIL PROTECTED] ##
Re: Common Public License
On Wednesday 23 May 2001 8:40 pm, Ravicher, Daniel B. wrote: Michael, The clause only says which law applies, it doesn't limit where cases can be held. It is not uncommon for courts in , say California, to decide a case under New York law. Lastly, the enforceability of such governing law provisions depends upon the Choice of Law rules of the particular jurisdiction where litigation is filed. Also, the enforceability of the other provisions within the CPL depends upon contract law, which differs significantly from state to state. Therefore, there may have been specific reasons why New York law was chosen over other states. What if a case is held outside the USA, for example in England? Is an English court likely to use US law? Surely it would prefer to use English law?
Suggestion for OSI website (was: Newly approved licenses)
On Thu, 10 May 2001, Lawrence E. Rosen wrote: I am pleased to report that a majority of the OSI board has voted to approve the following open source licenses: Common Public License: http://oss.software.ibm.com/developerworks/opensource/license-cpl.html APSL 1.2: http://www.opensource.apple.com/apsl/ These licenses will be posted to the OSI website's approved license list as soon as possible. I think it would be a nice idea if the OSI webpage that contained a list of open soure licenses, instead of simply listing them, contained a paragraph or two about each one's properties. For example, it could say that the GPL and QPL are both strong copyleft licenses, with the peculiarity in the GPL's case that to link to it, you have to license your code under the GPL (the QPL allows any open source license). The QPL has the peculiarity that changes must be released as patches. Similarly the LGPL and MPL are both weak copyleft licenses, with [blah blah blah]... you get the idea. -- * Phil Hunt *
Re: copyrightable APIs? (was RE: namespace protection compatiblewit
On Sun, 22 Apr 2001, Angelo Schneider wrote: phil hunt wrote: On Fri, 20 Apr 2001, Angelo Schneider wrote: Hi! In Europe APIs are not copyright able. No idea about the US. However if you publich them in a book, the book of course is copyrighted. However you can not prevent anyone to write a software against a given API. Same is true for data formats. (In Europe dataformats e.g. a flat file format for a word processor are not copyright able) This will change under the new EU copyright law, where it will be illegal to decrypt any encrypted file format (e.g. DVD) without the copyright holder's permission. Thats a misunderstanding. Just for simplicity lets talk about MS Word. The file format is proprietary. I do not know it. However I'm free to analyze Word files and discover it. I'm free to write Word files after I have discovered how they look like. Now you have two possibilities: Encrypt the whole word file - decryption is illegal if the decrypter has to asume the file contains private data(right of private speech is broken). The EU copyright directive says *nothing* AFAIK about private speech, or rights thereto. Encrypt the content of the file BEFORE you write it in Word format (e.g. by keeping the paragraph structure and encrypting each paragraph) - decryption is covered by the new law and considered illegal (the law has not passed the houses so far). The EU copyright directive (which you are right isn't law yet) makes it illegal to circumvent a technological measure. A technological measure includes any encryption put on a file. Both points don't touch the fact that the API or the format it self is not copyrightable, how should one be able to WRITE a DVD then? My understanding is that it is illegal to write an encoded DVD in the USA without the permission of the DVD-CCA. -- * 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: namespace protection compatible with the OSD?
On Fri, 20 Apr 2001, Brian Behlendorf wrote: On Thu, 19 Apr 2001, Rod Dixon, J.D., LL.M. wrote: I am sorry about joining the discussion late. This sounds interesting. Brian, do you mind clarifying your question without rehashing what has been discussed? I do not want to bore those who have followed the thread, but what do you mean by implement and what is the concern you are raising? I was wondering if there was a way, compatible with the Open Source Definition as well as acceptable to others in the community, to create a copyright license for an API specification that helps ensure compatibility of derivative works. If by ensure compatibility of derivative works you mean forbid thre creation of incompatible derived works, then I think the answer is no. From the OSD: 3. Derived Works The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software. However, since any derivative works of a strong copylefted license must also be open source, it is difficult to impossible for an unscrupulous person to use software under a strong copyleft license to do an embrace, extend, and extinguish strategy. I personally am not all that bothered about obfuscated interfaces, *provided* that open source programmers are legally permitted to reverse-engineer them. Unfortunately, due to iniquitous copyright and patent laws, this is sometimes not the case. So perhaps there should be an open source license, which says that if a company uses software under that license, then they must allow people to use all their proprietary interfaces. (Imagine if Amazon was forced to either abandon their 1-click patent, or wipe all the open source software off all their hard disks). -- * 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: copyrightable APIs? (was RE: namespace protection compatiblewit
On Fri, 20 Apr 2001, Angelo Schneider wrote: Hi! In Europe APIs are not "copyright able". No idea about the US. However if you publich them in a book, the book of course is copyrighted. However you can not prevent anyone to write a software against a given API. Same is true for data formats. (In Europe dataformats e.g. a flat file format for a word processor are not copyright able) This will change under the new EU copyright law, where it will be illegal to decrypt any encrypted file format (e.g. DVD) without the copyright holder's permission. -- * 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: namespace protection compatible with the OSD?
On Wed, 18 Apr 2001, Brian Behlendorf wrote: On Wed, 18 Apr 2001, phil hunt wrote: I'm not familiar with Perl, so I'll attempt to translate this into C for clarification. OK. I create a library in C. The interface is defined in mylibrary.h. For someone to use my library, they must: #include "mylibrary.h" The license for mylibrary contains a clause "if you create a derivative work, you must rename mylibrary.h to something like yourlibrary.h". Is this this the gist of what you are saying wrt Perl? Not exactly. I'm saying two things: if you create a derivative work from my code, then the license says if you change the behavior of the functions or macros, etc., defined in my .h, that you must call it something else. However, if you keep the same interface (keep the .h consistant, but change the .c, though it's more accurate to say "API" and "implementation") then you may continue to call it "mylibrary.h". IMO it could be hard to define what is or isn't the same behaviour. Example (1): You write a library to access data from a disk file, like in a DBM-style database. This includes the call (in your header file): DataHandle getData(FileHandle fh, Key k); I now re-implement your library so that the getData() function exists as before, but tries to cache in RAM rather than reading the field on disk every time. Furthermore, I decide to include a getData_lowLevel() function that does the same as your original getData() function, and which my getData() function uses. Example (2): (This example makes more sense in a language that allows variables to have any datatype, such as Python or Smalltalk (or C++)). You write a library that performs math functions such as exp(), log(), sin(), cos(), tan(), et, taking floating-point arguments. I write a library with a superset of your library's functions, and in which all the functions can take complex-number arguments too. This behaves differently to your library, because in your library, using complex number arguments produces a return value signalling an error (or an error exception, or suchlike). It seems to me that the spirit of the Open Source Definition allows me to do that, and allows users of your original library to be able to use my library as a plug-in replacement to your library, if they wish to do so. A plugin replacement might well imply things like having the same filename(s), depending on the language in question. Secondarily, I'm saying even if you didn't implement my code, but followed the published document that describes the spec (which I also put under this license), you'd have to follow the same rules. Clearly this has nothing to do with Open Source as such, and IMO is morally dubious to say the least. I'm not sure what "incompatible" means here? What if my new improved version was intended as a replacement, but which added new features in a way that necessitated a degree of incompatibility? If you make a change that introduces any degree of incompatibility, even if it's "fixing a bug", then it would have to be renamed. Hopefully I'm reasonable enough to change my API should I be notified of bugs in it, but if I'm not, fork. But the requiremnt of changing filenames could prohibit forking, to some extent. I don't know. In some cases I could see (if I have understood you correctly), the restriction could be a way of preventing a fork of the code. IMO, the ability to fork is a necessary part of an open source license. It doesn't limit the right to fork at all, but it does somewhat carve out an API namespace; So it limits the right to fork something that's plug-in compatible with the original? Users would have to make an extra effort to use the forked version. -- * 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: namespace protection compatible with the OSD?
On Tue, 17 Apr 2001, Brian Behlendorf wrote: Let's say I created a specification for an interface in Perl; call it Foo::Bar. Let's further say I published the specification, and a collection of code that implemented it, under a BSD-style license, with the sole added clause that any derivative work that changed the implementation in a way incompatible with the specification for that interface, needed to call its interface something else; it couldn't be Foo::Bar, but it could be Foo::Baz, or whatever. I'm not familiar with Perl, so I'll attempt to translate this into C for clarification. I create a library in C. The interface is defined in mylibrary.h. For someone to use my library, they must: #include "mylibrary.h" The license for mylibrary contains a clause "if you create a derivative work, you must rename mylibrary.h to something like yourlibrary.h". Is this this the gist of what you are saying wrt Perl? The point of this is that any derivative work cannot be a plug-in compatible, because users must change #include "mylibrary.h" to something else. Why do this? Because I wanted to make sure someone didn't take my code, slightly modify it in an incompatible way, and try to confuse the public about what the API Foo::Bar was supposed to do, whether intentional or unintentional. I'm not sure what "incompatible" means here? What if my new improved version was intended as a replacement, but which added new features in a way that necessitated a degree of incompatibility? I suspect this would pass the OSD tests, but I wanted some validation of that. I see it as a cross between the trademark-related covenants of the Apache license and the interface-changing clauses of the SISSL. I don't know. In some cases I could see (if I have understood you correctly), the restriction could be a way of preventing a fork of the code. IMO, the ability to fork is a necessary part of an open source license. -- * 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: APSL 1.2
On Wed, 4 Apr 2001, David Johnson wrote: On Thursday April 05 2001 04:02 am, Russell Nelson wrote: Is there a pressing need or interest for private use to be disclosed? Apple wants it in there, and there's nothing in the Open Source Definition that allows us to require them to remove it. "No Discrimination Against Fields of Endeavor". The license could possibly be construed as discriminating against fields of endeavor. The APSL places restrictions upon commercial usage that it does not place upon personal usage. The word "commercial" is specifically used as a criteria in determining which restrictions and conditions apply. IANAL. Two question that spring to mind: If someone is using internally a modification of APSL software, why would they want to not disclose it? If someone is using internally a modification of APSL software, why would Apple mind them not disclosing it? -- * 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: APSL 1.2
On Wed, 4 Apr 2001, David Johnson wrote:
I would definitely try to get Stallman's approval. So far, all Open Source
licenses are also Free Software licenses(*). It would be sad if the APSL was
the one to fall through the crack between the definitions.
[...]
(*) The Artistic License might be an exception, but it does meet the
definition in letter and spirit.
According to http://www.gnu.org/philosophy/license-list.html
the new ("Clarified") version of the Artistic License is Free Software.
--
* 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: APSL 1.2
On Thu, 5 Apr 2001, Nick Moffitt wrote: begin phil hunt quotation: Two question that spring to mind: If someone is using internally a modification of APSL software, why would they want to not disclose it? Assuming that this question was not *purely* rhetorical: Not at all. There are many people who are NOT on the Internet OR in the United States. If cut off from communication, the requirement to distribute the software could be prohibitively expensive. That's a point I hadn't thought of. -- * 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: APSL 1.2
I wrote: Two question that spring to mind: If someone is using internally a modification of APSL software, why would they want to not disclose it? If someone is using internally a modification of APSL software, why would Apple mind them not disclosing it? On Thu, 5 Apr 2001, Ron Dumont wrote: We are trying to encourage companies who deploy APSL software to share their modifications with the broader community. Typically, companies will adapt software to meet the broader needs of people across their organization. An example is the use of our Streaming Server software, where changes made to serve an organization can be of direct benefit to other users in the community. Indeed. And if a company releases their changes, the changes can get incorporated into the latest version, and kept up-to-date. The APSL, however, doesn't give companies the option of *not* releasing their changes. IMO this provision is unlikely to benefit Apple much, because: (i) most companies that produce significant changes will want to release them, for the reason I give above (ii) companies that *don't* want to contribute their changes are likely to just not release them; no-one will find out what they are doing, because they won't tell anyone. If a company doesn't want to play nice, I don't think this provision is likely to persuade them otherwise. So I don't think this clause helps Apple much; it just seems to irk some people (such as RMS) -- and Apple has no interest in alienating part of the open source / free software developer community. Lastly, IANAL but I think this license as it stands isn't open source, because it discriminates against a field of activity, in that the rules for disclosure of internal modifications differ depending on whether its being used for commercial or non commercial purposes. -- * 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: Subscription/Service Fees - OSD Intent
On 28 Mar 2001, Ian Lance Taylor wrote: I myself am uncertain, which is why I would be happier if the OSD had an explicit statement that a recipient of a program was permitted to run it. That seems a good idea. Also, OSD #1 says that you can redistribute "as a component of an aggregate software distribution containing programs from several different sources" but doesn't explicitly says you can redistribute a program on its own. To me this implies that you have no such automatic right, and suggests the bizarre scenario that if you want to redistribute, you have to bundle it up with a trivial "hello world" program. -- * 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: Subscription/Service Fees - OSD Intent
On 28 Mar 2001, Ian Lance Taylor wrote: the recipient is permitted to run the program. The last time this was discussed, Russ Nelson (who is on the OSI board) said this: | If you have legally received a copy of a program (and | OSD #1 guarantees the right of the person giving you a copy to do so), | you are free to use it or not, as you wish. Copyright law only | restricts copying. You could only restrict the activities of a | *recipient* if you could require them to execute a license, but OSD #7 | prohibits that. Perhaps I'm being stupid, but that doesn't make much sense to me. Say I write a program and distribute it under the GPL, then any of the recipients of the program may only use it under the terms of the GPL; they may not do anything that the GPL prohibits. So they are not "free to use it as [they] wish". Or does #7 only apply to usage *other than* copying? If so, does this mean that if someone illegally encapsulates my GPL'd code then they can still legally run my program? -- * 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: Subscription/Service Fees - OSD Intent
On Wed, 28 Mar 2001, Eric Jacobs wrote: Plainly, this is not what #7 means. OK, what does #7 mean? -- * 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: Subscription/Service Fees - OSD Intent
On Wed, 28 Mar 2001, David Johnson wrote: On Thursday March 29 2001 03:25 am, Eric Jacobs wrote: It is this sort of illogical argument that will prevent this issue from ever coming to rest. Let me offer an analogy. I did manage to pass logic in college. However, I don't always do so well in English. Let me restate what I meant: Software that requires a registration fee is possible, and exists. Such software cannot be considered Open Source, however. What about software that require registration (e.g. by email), but not a registration *fee*? Can that be Open Source? -- * 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: Subscription/Service Fees - OSD Intent
On Thu, 29 Mar 2001, Smith, Devin wrote: My experience (as a lawyer) with open/free licenses is that many of them are not properly drafted. The GNU GPL is particularly difficult to interpret, probably because it was written by a non-lawyer. The resulting legal uncertainty makes it very difficult for me to give sound advice to my clients, and makes licensing rights in or out under the GNU GPL very risky. What particular problems do you have with the GPL? IMO it is quite clearly written, as licenses go. I also think the Mozilla license is quite clear. -- * 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: Subscription/Service Fees
On Thu, 29 Mar 2001, SamBC wrote: I'm sorry if someone has already said this, or something similar, but why can't people who want to distribute source, as they say, but keep a financial gain from it, use conditions like: 1) On paying the license fee, you have access to the source code - you may not distribute it in whole or in part, except illustrative excerpts not more then [x] lines long 2) You may modify the source code as you wish, and distribute you modifications only to other license holders. 3) On receiving a modified version of the source code, or any form of instructions as to its modification, you may not redistribute them to any unlicensed party, but may distribute freely to other license holders No reason at all. In fact, this sort of "gated community" license may well be advantagous for some purposes. And then not bother trying to claim it is Open Source, as it is clearly not Indeed. I (and I suspect most people on this list) have no problem with software that isn't open source, as long as they don't try to pass it off as open source. The sort of license you suggest above, if it included the proviso that it becomes open source (e.g. GPL'd) after a time delay, would be one I would approve of -- I'd be happy to buy software under that license. -- * 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 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: licenses for RPGs
On Mon, 19 Mar 2001, David Johnson wrote: The only licenses halfway-acceptable for me are the OOGl and OGL. What do you like about these licenses? I have two issues with them. First, they are lengthy and potentially confusing (to the user) licenses. Second, they are copyleft, and I am not desiring a copyleft license for this project. Unfortunately, the Open Gaming License will only approve copylefted licenses and games. In other words, I can release a public domain game and they would refuse to call it free and open. That seems bizarre to me. -- * 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 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
