Re: Get ready....
From: Arkin [EMAIL PROTECTED] Copyright was invented to cover literary work and protect the authors of literary work. Legal documents are not literary works. There are so many ways you can express the same contractual agreement. Thus, you may freely copy all portions of the GPL that are strictly legal clauses. That might be true in Israel, but not here. The GPL is, however, subject to trademark restrictions No, it is not. GPL is not a trademark. If you don't believe me, ask Richard Stallman. Bruce
Re: Get ready....
Derek J. Balling writes: Your position seems contradictory. You support "freedom for the people", but you don't support the right of people to pick the pieces of licenses that best suit their needs. The only true freedom you have is choice -- the choice of not using software if you cannot abide by its license agreement, or developing your own application using the license of your choice to compete with the offending product. Allowing someone to use portions of a license does NOT deny people freedom. It is simply not necessarily granting them privileges the same privileges as others choose to. Let's remember that any alteration of a copyrighted work is a PRIVILEGE, not a right. It is something which is granted by the owner of the copyrighted work, NOT something which you inherently have by being alive. Rights CANNOT be taken away, privileges can. I can say that "no future versions of my software will be released under the GPL", and you no longer have the privilege of copying the code. The sooner you stop confusing "rights" and "privileges", you'll be a lot better equipped for the discussion. :) The author of the GPL, as far as I can infer from his writings and talking to him, does not believe that "alteration of a copyrighted work is a PRIVILEGE, not a right", because he does not believe that software should have any owners at all. Without understanding that, you can't understand the language of the GPL in its proper context. To put this another way, if copyright is not a real right (or intellectual property is not real property), then "true freedom" includes the choice to _ignore_ license restrictions altogether. Since copyright law does not provide this, Richard Stallman invented copyleft in an attempt to emulate as far as possible what life would be like if that choice were recognized as a right. If you think it's obvious that intellectual property exists, you'd naturally say that it's essential for software authors to have the choice of what license to use. If you think it's obvious that intellectual property doesn't exist, you'd equally naturally say that it's essential for users to have the freedom to copy (etc.), and that it's wrong to try to use licenses and copyright law to deny these freedoms to users. The philosophy of the GPL, which you don't have to accept in order to use it, and which accounts for Stallman's decision to copyright the GPL itself, presupposes that users have the right to use and copy software, and that software owners do not have the right to stop them: in other words, that IP does not exist. As Martin Pool just wrote in another message: The text of the GPL is not licensed to you under the GPL: you may think that's inconsistent, but it makes sense in terms of the FSF's goals. (And, of course, it doesn't make sense in terms of goals which are at odds with the FSF's goals.) http://www.fsf.org/copyleft/copyleft.html etc. -- Seth David Schoen [EMAIL PROTECTED] They said look at the light we're giving you, / And the darkness that we're saving you from. -- Dar Williams, "The Great Unknown" http://ishmael.geecs.org/~sigma/ (personal) http://www.loyalty.org/ (CAF)
Re: Get ready....
"R. L. Kleeberger" wrote: Quoting Derek J. Balling ([EMAIL PROTECTED]): At 11:29 PM 4/14/99 -0400, R. L. Kleeberger wrote: There is no reason anymore. I was still unsure whether the GNU GPL was able to be legally modified into another license. It seems it is legal, According to the license it is not. According to the instructions at the top, the license may be copied verbatim, but it may NOT be altered. Since excerption can be defined in terms of alteration, you cannot even excerpt 90% of it (with 9% being the part you don't want, and 1% being the title) since that's an alteration of both omission and change. Yes. I would very much like for someone with legal experience who is familiar with the GPL to step in so we can come to a conclusion on the legality of copying/modifying the GNU GPL. We have conflicting posts, and I can't proceed until this is cleared up. OK -- with the caveat that I am not a licensed lawyer, I chose not to practice after getting my law degree, so what i say can't be taken as legal advice. And most of what I say is based on U.S. law, though much copyright law is harmonized internationally theseadays. Copyright is best thought of as a "bag of sticks" where each "stick" is a "exclusive right". These rights include the right to distribute, the right to copy, the right to perform, the right to prepare derivative works, etc. (see the copyright act). There are various standards for determining when these rights are infringed upon by a party which does not have a license to do so and is not with an exception to these exclusive rights called "fair use" (once again, see Title 17 for more details). Generally, what is called "excerption" above would be considered at least copying -- the new work is at least substantially similar in many parts. It would also likely be an unauthorized derivative work. Assuming that copyright would indeed apply to the license (which in an earlier message I state it might not -- depends on originality), it would probably be infringement unless an infringer could show fair use. One of the criteria for fair use is "substantiality" of the portion taken. If I take one sentence of a three page license, that is likely to be at least fair use due to lack of "substantiality". therefore I don't have much of a buttress accept a philosophical one. And this list is ot for philosophical discussion. Agreed, and we have to clearly define the direction we want to go. I think that licenses should be able to be copied in whole or part, which the current GPL explicitly forbid. I will have to think on this. I am an extremely strong proponent of the GNU GPL, and would like to see all open source licenses created to be GPL compatible. On the other hand, I believe a developer should have the freedom to create a license to fit his needs(with his user's freedoms in mind). I suggested a "menu" approach which I think would allow companies to select which terms (all of which are open source compatible to a certain degree) they like for each issue dealt with in the contract. -Gabe
Re: Get ready....
The author of the GPL, as far as I can infer from his writings and talking to him, does not believe that "alteration of a copyrighted work is a PRIVILEGE, not a right", because he does not believe that software should have any owners at all. Without understanding that, you can't understand the language of the GPL in its proper context. To put this another way, if copyright is not a real right (or intellectual property is not real property), then "true freedom" includes the choice to _ignore_ license restrictions altogether. Since copyright law does not provide this, Richard Stallman invented copyleft in an attempt to emulate as far as possible what life would be like if that choice were recognized as a right. The author can believe whatever he likes. Unfortunately, he's placed his work under the laws of the US, where I'm forbidden because of his wording from altering his writing. Ideologies aside, I cannot break the law. If he wanted to grant freedom to people, he should not have explicitly gone out of his way to remove those freedoms. If you think it's obvious that intellectual property exists, you'd naturally say that it's essential for software authors to have the choice of what license to use. If you think it's obvious that intellectual property doesn't exist, you'd equally naturally say that it's essential for users to have the freedom to copy (etc.), and that it's wrong to try to use licenses and copyright law to deny these freedoms to users. The philosophy of the GPL, which you don't have to accept in order to use it, and which accounts for Stallman's decision to copyright the GPL itself, presupposes that users have the right to use and copy software, and that software owners do not have the right to stop them: in other words, that IP does not exist. Right, which means that for all intents and purposes, the GPL is not practical, because very few commercial entities are going to be willing to live strictly and without change within the GPL model. And, since alteration is verboten, a new license must be created which accomplishes the same goals as the GPL, BUT allows alteration for the real-world conditions which exist, so that the REST of the world can take the parts that work for their business model and alter/delete the rest, but leaving intact a "trail" so that users can be familiar with the "parent" license, and look for changes between generations. As Martin Pool just wrote in another message: The text of the GPL is not licensed to you under the GPL: you may think that's inconsistent, but it makes sense in terms of the FSF's goals. (And, of course, it doesn't make sense in terms of goals which are at odds with the FSF's goals.) http://www.fsf.org/copyleft/copyleft.html Agreed. Unfortunately, most of the rest of the commercial world is at odds with the FSF's goals. *I*'m at odds with the FSF's goals. Heck, after the GNU code got co-opt'ed out from under him to get used in Linux [NOT GNU/Linux] I'm surprised that Stallman isn't against the FSF's goals. :) I bet he wishes, secretly deep down in his heart of hearts that he had just a LITTLE say in how the code was used so that he could try and get some recognition for all the work. :) That's not bad, its a natural thing - to want recognition for your work. FSF (and company) have put a lot of effort into GNU, and their license allowed people to take all the work, call it something else and package it up as Linux. D
Re: Get ready....
[EMAIL PROTECTED] wrote: From: Arkin [EMAIL PROTECTED] Copyright was invented to cover literary work and protect the authors of literary work. Legal documents are not literary works. There are so many ways you can express the same contractual agreement. Thus, you may freely copy all portions of the GPL that are strictly legal clauses. That might be true in Israel, but not here. This is true all over the world with only subtle differences. Copyright laws are very similar between nations and automatically apply across borders by international treaties. The GPL is, however, subject to trademark restrictions No, it is not. GPL is not a trademark. If you don't believe me, ask Richard Stallman. The GPL is a trademark. It is not a registered trademark because it was never registered. However, the mere fact that it is associated with a specific license and known in its field makes it a trademark. This is true in the US, as trademark are not shared internationally. Arkin Bruce
Re: Get ready....
On 14 April 1999 at 20:52, "Derek J. Balling" [EMAIL PROTECTED] wrote: [snip] I would FURTHER go so far as to allow alteration of the licenses, but that the "lineage" must be documented, so that people familiar with [for lack of a better term] the OSI-BSD license (whatever they come up with) can say, "Ah, this license from Acme is based on the BSD license, but they changed it somehow. How did they change it I wonder?" and then they'll find out via diff/etc. They'll know all the rest of it as "tried and true" so to speak, and then dig down to the alterations that a particular company needed for their particular business model. [snip] Does ANYONE agree with me here? In spirit, perhaps I do. However, I don't think that it is very sound law practice to review license documents using ``diff'' :-) My thought was that if OSI had these two boiler plate licenses, then organizations could start from one of them. Just using one as the base document would not mean that the derived document would automatically earn an Open Source Certification mark. However, it would certainly make it easier for OSI to determine whether a license meets the requirements of an Open Source Certification mark. In other words, having good starting licenses (which should be complete in their own right, as is the GPL) will encourage organizations to adopt them because: 1. It is less trouble and less confusing than reviewing the large number of ``Open Source'' licenses of today: GPL, BSD, X, Apache, Artistic, NPL, MPL, APSL, IBM's Jikes license, et. al. 2. Because adopting one of these licenses makes it easier to get the Open Source Certification mark (as the licenses would be familiar to OSI). The OSC is crucial. One should not be able to modify an Open Source (cm) license, and claim that the derivative is Open Source (cm). Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED]
Re: Copyright
Copyright laws apply to the actual source code (and thus binary) of the software because it is a literary work, see the test below. If I set on the task of writing a spreadsheet and end up with Excel, what are the chances that I was copying Excel one for one? On the other hand, I might write it all anew, but attempt to mimick some aspects, like the user interface. This issue is still not clearly resolved, and is derived from laws protecting design, which are different than text (the actual code). Last, there are laws that protect an assembly of works, even if these works are not protected by copyright. For example, if I publish a collection of all the works of Shakespear finished on odd years, I can claim copyright to this particular collection, but not the works themselves. As far as algorithms go, neither is good enough. You cannot copyright the source, because there might be a different way of writing the algorithm which does not look alike. You cannot copyright the design, because there is no recognition of algorithms as design. The only course of action is patent. That is why so many software products are protected by patent. The change from literature to non-literature is subject to a very simple test. Suppose the two of us set to write a story about a shared experience. We would end up with completely different texts, unless one of us copied. But if we attempted to write a shopping list for computer parts, we would probably end up with a very similar list. Im the first case, each one is contributing unique experience, knowledge and skill, and thus creating a work that must be protected. In the second case, there is nothing unique and there are so many ways of writing the same shopping list. This is true all over the world with only subtle differences. Copyright laws are very similar between nations and automatically apply across borders by international treaties. In what way are legal documents different from programs (programs are, or were initially, covered by virtue of being literature)? At what point does a piece of writing change from literature to non-literature under the scheme you have? -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/
menu license
OK, I'll open by stating that this is all very new to me, but fun and interesting so far. Thanks for the heavy discussions. Here's my take: Have a few complete licenses set up -- like OSI-restrictive, OSI-public, and OSI-open, each one being progressively more open. People can cut-paste entire sections only. And there may be certain rules that require sections to go hand-in-hand (i.e. Section 3 of OSI-r may require Section 7 of OSI-r or OSI-p, but not OSI-o). This can all be scripted via CGI and done up on the Web. Any license that can be created this way is automatically certified by the OSI, and can be labeled a "restrictive", "public", or "open" license by means of determining (with a script) which version the weightiest sections are from. Also, since each section must be copied in its entirety, each section can be labeled "Section 4, from OSI-public license" or such, making it easy for people who are familiar with that license to skim those sections. Also, people can take entire sections, and label them as such, to be used in their own non-certified licenses. I didn't say this would be easy, legalese is not my area, but how does this sound? -- Greg Pfeil --- Software Engineer --- (pfeilgm@|http://)technomadic.org "PERL: The only language that looks the same before and after RSA encryption." --Keith Bostic
testing due to mail failure
testing NatePuri Certified Law Student Debian GNU/Linux Monk McGeorge School of Law [EMAIL PROTECTED] http://ompages.com
GPL context
qmail seems to think this thread is too long, so I'll at least take a hint and try to trim down my rejected message. Derek J. Balling writes: The author of the GPL, as far as I can infer from his writings and talking to him, does not believe that "alteration of a copyrighted work is a PRIVILEGE, not a right", because he does not believe that software should have any owners at all. The author can believe whatever he likes. Unfortunately, he's placed his work under the laws of the US, where I'm forbidden because of his wording from altering his writing. Ideologies aside, I cannot break the law. Since the purpose for which you want to alter his writing is also a purpose of which he disapproves, it makes sense that he doesn't want to help you that way. :-) If he wanted to grant freedom to people, he should not have explicitly gone out of his way to remove those freedoms. He didn't go out of his way to remove freedoms, though: - If intellectual property exists, then Stallman was perfectly entitled to control the future use of his license by copyright. :-) - If intellectual property doesn't exist, then Stallman's restrictions are (with a few interesting exceptions) only statements of pre-existing facts, and don't really add much in the way of new restrictions. Stallman basically forbids licensees under the GPL to claim any proprietary rights in intellectual property -- because he doesn't think that anyone _has_ any proprietary rights in intellectual property in the first place! Stallman thinks the US law is unjust and restricts people's rights. He found a clever way (consistent with the law) to create a set of restrictions which forbid people to do things that he thinks take away rights. Obviously, you and he have a pretty big difference in what you think are rights and what you think are privileges. Again, that doesn't mean that his position or actions are inconsistent. The philosophy of the GPL, which you don't have to accept in order to use it, and which accounts for Stallman's decision to copyright the GPL itself, presupposes that users have the right to use and copy software, and that software owners do not have the right to stop them: in other words, that IP does not exist. Right, which means that for all intents and purposes, the GPL is not practical, because very few commercial entities are going to be willing to live strictly and without change within the GPL model. And, since alteration is verboten, a new license must be created which accomplishes the same goals as the GPL, BUT allows alteration for the real-world conditions which exist, so that the REST of the world can take the parts that work for their business model and alter/delete the rest, but leaving intact a "trail" so that users can be familiar with the "parent" license, and look for changes between generations. Well, you're right that the GPL isn't practical for everyone (though the GPL was definitely not intended to be practical for everyone). If you want to preserve some of the goals of the GPL, but make concessions to other factors, you still have the problem of how to tell when you've thrown away too much of the original sense of the GPL. The OSI is one attempt at that, as is license-discuss. Everyone here has _some_ concept of what free software or Open Source software is, or else they wouldn't be here to discuss it. So there always remains a question of how to be sure that "practical" licenses actually remain Open Source, since there are no doubt people who'd like to be able to use the term and associated interest and goodwill without retaining any of the freedom or openness that it was supposed to connote. The immutability of the GPL has a definite advantage in automatically preventing people from excising its many good points; there is very little danger of any kind of corruption or confusion. This property isn't essential (there are other free software licenses, including some that aren't immutable this way), but it does provide some benefits. As Martin Pool just wrote in another message: The text of the GPL is not licensed to you under the GPL: you may think that's inconsistent, but it makes sense in terms of the FSF's goals. (And, of course, it doesn't make sense in terms of goals which are at odds with the FSF's goals.) http://www.fsf.org/copyleft/copyleft.html Agreed. Unfortunately, most of the rest of the commercial world is at odds with the FSF's goals. *I*'m at odds with the FSF's goals. So I see. But given that, I think you might want to talk about how the GPL and its terms are not useful for what you want to do, or not readily acceptible to industry, rather than "inconsistent". Heck, after the GNU code got co-opt'ed out from under him to get used in Linux [NOT GNU/Linux] I'm surprised that Stallman isn't against the FSF's goals. :) I bet he wishes, secretly deep down in his heart of hearts that he had just a LITTLE say in how the code was used so that he
Re: menu license
It would be fun to write a grammar for all the licenses that could be produced this way, though. Then you could write a very concise definition of a particular license. This has been lightly discussed on the web communities Slashdot and Segfault: http://www.slashdot.org/comments.pl?sid=99/03/19/0921210cid=244 http://www.slashdot.org/comments.pl?sid=99/04/11/0554227cid=185 http://www.segfault.org/story.phtml?mode=2id=36ff969d-0541ff00 The idea being that a license could be condensed to something akin to the Geek Code, which could then be reexpanded to: 1. A formal definition in legalese 2. A plain english definition 3. A comparison with other licenses, eg. GPL, Apache, BSD The full license would probably accompany the software for legal reasons, but be prefixed by a preamble along the lines of: "This software is licensed according to the Standardised Adaptable License using the following definition: (code here). For an explanation on how to interpret this code, consult RFC- or the website: (insert URL here). The legal license for this software is listed below, and may be clarified by the author." Then a simple web form (that URL) would take you to a page where you could derive the expanded forms as described above. The site would also allow software authors to "roll their own" license using tickboxes, building a license that suits them, but would do so in a formalised standard way to prevent confusion. If possible, the site would calculate which OSI certification marks the license would comply with. An author would thus be able to see what their 'only if your favorite color is blue' clause would do to the freedom of their software. It'd also stop the arguments about whether a license is Open Source or not. It'd just start arguments (on this list!) about what clauses should be added or modified in the database. Standardised License Markup Language, anyone? =) Tom -- Tom Gidden, mailto:[EMAIL PROTECTED]
Re: Platform limitations and GPL clause 3
On Thu, Apr 15, 1999 at 18:32:32 +1000, Martin Pool wrote: I've been wondering about the interactions between GPL clause 3 (requirement to distribute source with modified redistributions) and non-free OSs. gnu.misc.discuss is often viewed as the definitive forum for discussion the GPL; you may want to consider posting there too. Suppose Charles wants to port the driver to non-free platform W. However, on platform W one can't write drivers using a normal compiler, linker, library, and so on: one has to pay $2000 for a developer's license for the "Device Driver Kit" from W's vendor. Let's suppose for the time being there's no NDA involved, but that the DDK can't be redistributed. OK. The DDK doesn't qualify as a "major component" then. This makes your hypothetical example quite similar to the case of KDE, a GPLed piece of software, that requires Qt, a library that's licensed under terms incompatible with the GPL. See http://www.debian.org/News/1998/19981008 for an analysis of that case. If Charles wants to redistribute his version of the driver under the GPL, he can't do so because there's no way to fulfil clause 3's requirement to include all the source necessary to work on the driver on platform W. Clause 3 governs copying and distributing of the Program in object code or executable form. Charles could distribute the driver in source form only. Charles isn't even allowed to make the port for his own use, Charles is allowed to make the port for his own use. Clause 0: "[...] Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. [...]". The GPL explicitly doesn't cover use. Ray -- Tevens ben ik van mening dat Nederland overdekt dient te worden.
Re: SGI OpenVault
Brian Behlendorf wrote: I think it's redundant for a license to specify things that the legal code of a given country already mandates, which is why things like export provisions are generally pretty silly. E.g., if I wrote a program that implemented a crypto algorithm, by (current) U.S. law I can't export that; however, I don't need to put that into my license at all. It's up to me to distribute it only to other US citizens, and up to them to similarly make sure they don't violate US law by exporting it. The question then becomes, do *I* have liability if someone *else* exports my code; and I'm not aware of any court case where that has been tested. Well, it may not be legal liability or anything of that nature. It may be that your main source of distribution (as a software provider) is CDs and the government is going to block all software you sell across the border (open source and otherwise, legal and otherwise) because you are not actively trying to prevent usage of some illegal software (which may be open source). In other words, governments have ways of putting pressure on large corporations that they don't have on smaller, more traditional open source software authors. (Also, governments may refuse to buy software from companies who they perceive as distributing illegal software in their country). This could happen even in the United States. And I imagine there are some countries where a government would directly go after a software producer in a criminal context for "allowing use of" illegal software (yeah, it makes no sense...) So, a large software company *may* have very real desires to put language in the license which allows them to relatively easily yank the license if their software is deemed "illegal". [...] If this term wasn't in the license, then SGI might have to spend more money litigating (they might have to anyway, mind you) the issue -- they'd probably win anyway (who knows), but having the explicit term lays out the risk allocation so that the end user understands better what is going to happen. True; just as, if I put in my license on my crypto code, "you must not violate U.S. law by distributing this outside the U.S.", I would be laying out the risks; but it's redundant for me to make that a condition of the contract. IMHO. But don't forget, this isn't the Apache group we are talking about ;-) SGI, for example, might sell machines and have consulting contracts with the government of New Bad Country. And it may have assets which are reachable by that government.. Its going to want to be able to say to that government that it is doing all it can to comply with the laws of that country. I'm just trying to point out where SGI is coming from. I'm not making a statement about whether or not this is a valid argument (though I do think it has some merit). Now, this argument might be counter to the principles of the Open Source Definition, but we must remember that companies like SGI are doing this not for the public good (they could get sued for that), but because of the business case it makes for them. I would argue that a term like this reduces risks and makes that business case better and thus is beneficial for opensource (balancing, of course, against the increased restrictions on use of software it imposes). I'm not saying the wording is perfect, just that the intent of the term is important. I am also neutral on it; I don't think it violates the DFSG. But I don't think it's necessary. That's not a legal opinion though. Well, the issue is whether its acceptable -- obviously, we'd all like it not there, but is this an accomodation to the large corporate interests that is acceptable? Worthwhile? The clause which requires people to follow "all export and import control laws" is ambiguous, and could be construed as a bizarre inclusion by reference of _all_ trade laws in the entire world. Actually, I think its straightforward and thats exactly what it intends to do. Its another case of SGI covering its rear end. These are fairly standard traditional license terms. I bet if you asked SGI if they intended for the laws of Saudi Arabia to apply to someone in the US giving the code to someone in the UK, they'd say no; Thats not how I interpreted the paragraph I was responding to (see how language can be twisted and interpreted in so many ways? No you know why there are so many lawyers -- language is very very imprecise). I took the only "sensical" interpretation (which is what a court would do absent evidence of an understanding otherwise) of the language which is the one you mention and the one most of us think would apply. 7. Compliance with Laws; Non-Infringement. Recipient shall comply with all applicable laws and regulations in connection with use and distribution of the Subject Software, including but not limited to, all export and import control laws and regulations of the U.S.
Mailing list on ezmlm
By the way, the license-discuss mailing list is now fully managed by ezmlm. Back issues are now available -- ask the robot at -request for help. No, there's no archives on the web, cuz I haven't written the software yet. Any volunteers? All you have to do is expose a directory of directories containing email messages as HTML, with a date index and thread index. -- -russ nelson [EMAIL PROTECTED] http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | There is good evidence 521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace.
Re: GNU GPL and Open Source Definition
Yes, I agree with your point regarding the TIGER CDs. They were in the public domain, but until I put them up on my FTP site, they may not really have been Open Source simply becuase they were not available without an odious distribution fee - even getting them on 5 CD-Writables cost $100 in handling fees. Practice does indeed matter as much as licensing. My DSL is no longer saturated (in fact nobody is downloading this morning) but that 768K bit per second wire ran flat-out for three weeks. Bruce
Re: IBM's XML4C license (or a better alternative to termination)
On Thu, Apr 29, 1999 at 07:23:57PM -0500, Signal 11 wrote: Could you post a link or the original text? Pardon the diabolical href: http://www.alphaworks.ibm.com/reg/xml4c.nsf/commuser?OpenFormlic=FDFB324A58C6B4028825670F00616604file=/g/g.nsf/img/files/$file/xml4c_commercial_license.lictech=xml4c -- ___ Ean SchuesslerDirector of New Products and Technologies Novare International Inc.The Unstoppable Fist of Digital Action --- Some or all of the above signature may be a joke
code and design
can a distinction be made between the code that goes into an opensource project under gnu gpl and the interface and/or artwork that comprises what the user sees and interacts with. if the code specifies a novel interface, how can a gpl'd project protect the design from commercial scavenging? can it? should it? Rick Dietz -- Richard B. Dietz . [EMAIL PROTECTED] . http://php.indiana.edu/~rbdietz The empires of the future are the empires of the mind . Winston Churchill
Re: W3C needs help to defeat a patent!
On Tue, May 04, 1999 at 01:04:23 -0700, Paul Nathan Puri wrote: See the www.w3.org, and check out it's problem with P3P technology. See http://www.wired.com/news/news/politics/story/19452.html for media coverage. http://www.w3.org/P3P/ (the most obvious place), unfortunately has no details on it yet. Ray -- LEADERSHIP A form of self-preservation exhibited by people with auto- destructive imaginations in order to ensure that when it comes to the crunch it'll be someone else's bones which go crack and not their own. - The Hipcrime Vocab by Chad C. Mulligan
Re: new license to review
Mark Rafn wrote: You _CAN_ probably demand that all versions including modified ones with a different name include a custom header like: X-Server-Copyright: Based on WebFoo (c) 1999 Foo Inc. http://www.foo.com This would be no different than the requirement that interactive programs display GNU copyright when the output format isn't a necessary part of the program. Of course, it _IS_ an extra few dozen bytes with each request, and it's going to annoy some people. Those same people probably have never seen how much garbage headers IE4 sends out. ;) Seriously though, why not just have it print a version number / info line when you start the program? Many (most?) GNU programs do this. Also, http headers send the server name/version by default.. so modifying it to say (patched by [EMAIL PROTECTED]) after the version string wouldn't be hard. Would that break any programs? I have no problems with putting the copyright.. a) in the headers of the source b) short one-liners or "for licensing info, press F3" c) auto-generated "version strings" attached to output files d) message on startup. I'm more concerned with seeing some kind of "shareware" virus coming into the community. Very concerned. -- Signal 11
Re: new license to review
No modifications to Server Identification Field. You agree not to remove or modify the Server Identification Field contained in the Response Header as defined in Section 1.6 and 1.7. I'm concerned about the _precedent_ here, which could be used to enforce a more rigid adherence to some communications protocol or API in _another_ _license_. For that reason, I'd suggest that OSI stay away from this form of license clause. From: Russell Nelson [EMAIL PROTECTED] IMHO it's no worse than the Artistic License, which requires you to change the name of the program if you break compatibility, OSD #4, last sentence, explicitly allows that. It's different in that the Artistic license would have you change the name to _anything_but_ one protected name, essentially a trademark, that protects the public perception of the author's version. This gives you a wide latitude for modification. The "Foobar license", however, insists that you use one specific name in a machine communications exchange, which is essentially a total prohibition on one form of modification, and could affect the _function_ of the software, not just its perception of its author. or the BSD License, which requires you to acknowledge original authorship. Do you mean the obnoxious BSD advertising clause? "Acknowledge original authorship" does not affect any client-server communication protocol, though, and is coupled with distribution, not use. Any suggestions on which one [existing license]? Their intentions seem closest to the NPL. Thanks Bruce
Re: new license to review
From: Russell Nelson [EMAIL PROTECTED] Because it doesn't seem all that different from existing licenses, and because license proliferation inhibits code reuse. The major effect of Open Source code is to reduce the transaction cost of using it. Hear, Hear! We are in danger of tying ourselves up in red tape as we are saddled with more licenses, and their incompatibility, every day. The OSI should act to discourage license proliferation when possible, lest it do itself and its community a disservice. Thanks Bruce
Re: new license to review
[EMAIL PROTECTED] wrote: Hear, Hear! We are in danger of tying ourselves up in red tape as we are saddled with more licenses, and their incompatibility, every day. The OSI should act to discourage license proliferation when possible, lest it do itself and its community a disservice. Just some thoughts... Hurray. What would be ideal, is to develop common set of underlying clauses and algebraic rules for combining those clauses. Say that a decomposition lead to 26 clauses, A..Z, Then each OS license would be defined in terms of these clauses. So that Artistic = A, B, C,F, G, Y BSD = A,C, D, F, Y GNU = B D, F, G, H, I, And then you have rules which define how the licenses combine (as you combine the source code they are licensed with) I started to do this about a year ago, it _could_ be done, provided many of the groups participated in a more unified licensing mechanism. It seems OS would be a good way to do this. Best, Clark
Re: new license to review
Hurray. What would be ideal, is to develop common set of underlying clauses and algebraic rules for combining those clauses. Say that a decomposition lead to 26 clauses, A..Z, Then each OS license would be defined in terms of these clauses. So that Artistic = A, B, C,F, G, Y BSD = A,C, D, F, Y GNU = B D, F, G, H, I, And then you have rules which define how the licenses combine (as you combine the source code they are licensed with) I started to do this about a year ago, it _could_ be done, provided many of the groups participated in a more unified licensing mechanism. It seems OS would be a good way to do this. I like the concept--plug and play licensing. Alas, my view is too jaded and cynical to see it as a workable solution. Corporate counsel would react to this how? I suspect some--perhaps many--would feel threatened by a lack of 'value-add' on their part and dismiss C, H and W yielding "alternate language", superfluous changes, and YAOSL. (Yet Another...) --- Creed Erickson (mailto: [EMAIL PROTECTED]) Deckhand, H.M.S. Beagle
Re: A new open source license
[ an anonymized license -russ ] NOTES. These notes do not form part of the license. Preamble. This explains why we have created a new license. The license is based on the NPL version 1.1, with some definitions from the GNU LGPL. The preamble will be included in the license. Section 1.4. We've used Apple's definition of "Deployment" instead of Netscape's definition of "Commercial Use", because it seems more complete. Section 1.7A. This definition is the key to making the library usable by application developers without restriction. The definition is taken from the GNU LGPL, apart from the last clause, which is covering a possible loophole in the GNU definition. Section 1.7B. This definition is ours. It uses the phrase "any other work" to ensure that all Larger Works are covered by these two definitions. Section 1.8. This definition is from the GNU LGPL. Section 1.11C. The intention here is to cover any modifications, provided that they are part of the library itself rather than an application to which it is linked. If Contributors find this clause too restrictive, they can put new files into a new library of their own. Sections 3.2 and 3.6. The key differences from the NPL 1.1 are in the opening sentences of these paragraphs. XXX LIBRARY PUBLIC LICENSE Version 1.0 Preamble. This license permits the use and distribution of the source code for certain XXX libraries under terms intended to satisfy the Open Source Definition (http://www.opensource.org/osd.html). This license sets the terms and conditions for distribution of these libraries either: - as source code, or - as compiled libraries for use with programs such as development tools. These terms and conditions require, among other things, that any such distribution involve the preservation of the copyright notice and license terms, identification of all modifications, and a declaration of no warranty. They also provide for use of XXX's trade names and trade marks in any distribution and govern their use in any advertising, publicity, or other such public use. This license allows the distribution of these libraries in binary form without requiring the distribution of source code, provided such libraries are distributed as part of a larger application, other than development tools, as further set forth below. In this respect it is unlike most open source agreements, which require that the source be made available with all binary distributions. You are not required to accept this license, since you have not signed it. However, nothing else grants you permission to modify or distribute any code, library, or any derivative works thereof. These actions are prohibited by law if you do not accept this license. Therefore, by using, modifying or distributing any code, library (or any work based on the code), you indicate your acceptance of the License set forth below, and all its terms and conditions for copying, distributing or modifying such Code, library, or works based on them. 1. Definitions. 1.1. ``Contributor'' means each entity that creates or contributes to the creation of Modifications. 1.2. ``Contributor Version'' means the combination of the Original Code, prior Modifications used by a Contributor, and the Modifications made by that particular Contributor. 1.3. ``Covered Code'' means the Original Code or Modifications or the combination of the Original Code and Modifications, in each case including portions thereof. 1.4. ``Deploy" means to use, sublicense or distribute Covered Code other than for Your internal research and development (RD), and includes without limitation, any and all internal use or distribution of Covered Code within Your business or organization except for RD use, as well as direct or indirect sublicensing or distribution of Covered Code by You to any third party in any form or manner. 1.5. ``Developer'' means XXX, or its affiliates or licensors, as applicable. 1.6. ``Electronic Distribution Mechanism'' means a mechanism generally accepted in the software development community for the electronic transfer of data. 1.7. ``Executable'' means Covered Code in any form other than Source Code. 1.8. ``Larger Work'' means a work which combines Covered Code or portions thereof with code not governed by the terms of this License. There are two forms of Larger Work relevant to this license: A. A work that Uses Covered Code means software that contains no derivative of any portion of the Covered Code, but is designed to work with the Covered Code by being compiled or linked with it, and is not and has no ability to link to other application programs. B. A work that Includes Covered Code means any other work, including, but not limited to, one that is intended to make Covered Code available as a Library to users of the Larger Work, whether by aggregation, re-export of functionality, or any other method. 1.9.
Re: A new open source license
Perhaps this is a bit of an odd objection, since I'm objecting to something taken verbatim from the GPL, but I've argued about this clause in the GPL before. On 11 May 1999, Russell Nelson wrote: You are not required to accept this license, since you have not signed it. However, nothing else grants you permission to modify or distribute any code, library, or any derivative works thereof. These actions are prohibited by law if you do not accept this license. The logical consequence of this is not "somebody who distributes has accepted the license". It is "somebody who distributes either has accepted the license, or is illegally pirating the Code". This is not trivial, since a distributor might decide that they are better off being a pirate than having accepted the license; for instance, consider what happened to MOSIX, where if the author accepted the GPL he might be violating Israeli export restrictions. I would imagine that violating those would lead to punishment rather more severe than the punishment for pirating software. Therefore, by using, modifying or distributing any code, library (or any work based on the code), you indicate your acceptance of the License set forth below, and all its terms and conditions for copying, distributing or modifying such Code, library, or works based on them. The clause following the "Therefore" doesn't logically follow from the clauses that it is supposed to logically follow from. Someone who copies the code doesn't _automatically_ accept the conditions. If they distribute but don't accept the conditions, then they're a software pirate and you can sue them... but you can't act as if the license has been accepted and can't, for instance, copy the modifications.
RE: A new open source license
-Original Message- From: Paul Crowley [SMTP:[EMAIL PROTECTED]] Sent: Saturday, May 15, 1999 4:14 AM To: Ken Arromdee Cc: [EMAIL PROTECTED] Subject: Re: A new open source license The clause following the "Therefore" doesn't logically follow from the clauses that it is supposed to logically follow from. Someone who copies the code doesn't _automatically_ accept the conditions. If they distribute but don't accept the conditions, then they're a software pirate and you can sue them... but you can't act as if the license has been accepted and can't, for instance, copy the modifications. It sounds to me like you're right. What should GPL v3 say instead? [MCepl] I am not sure, that you are correct. What clause five actually says is, that GNU GPL is accepted by conduct rather than by giving notice of acceptance to offerror (in this case author of software). It is not saying, that you accepted, but rather that you are deemed to accept it. In other words, you cannot do any listed action without permission from author (due to Copyright Act). You would need executing a contract with author, where he would permitt you to do so. However, author is so nice, that he is offering you just this contract, and he says in such contract, that you are deemed to accept the licence when doing any statutorily forbidden action -- distribution, modification or copying. The only problem I have (under the Czech law, I am not sure what is the prevailing doctrine under US law -- I forgott a lot from my Contract clases on USF) is, that contract is valid since the notification about acceptance (by any means -- either actuall promise to accept by offeree or information about acceptance by conduct) is received by offerror. Therefore, GNU GPL is valid for both parties only after that (offerree is bound in the moment he dispatches notice of acceptance or moment of executing the conduct, unless beforce executing a contract he receives a revocation of offerr from offerror -- these are under European law only, Anglo-saxon legal systems -- with exception of Big State of California -- has their mailbox rule). What's wrong with this wording (maybe, that there is something screwed up in my mind -- I am a lawyer and I am used to this formulation)? Have a nice day Matthew Cepl
Re: GPL and LGPL question
Bruce Perens writes: I don't agree. It's just like the public-domain to GPL case. You have the option to distribute the program under the LGPL. You choose the GPL. You re-distribute that. The person to whom you redistribute it has the option to use the GPL, just as you did. Sure, but the current version of OSD 7 doesn't say that. It says that anyone who gets a copy has to have the same legal rights that were originally granted. I don't personally think there's any problem left here, except that OSD 7 is unclear. There are a few possible approaches to fixing it for greater clarity. Anyone who thinks that LGPL 3 is broken is certainly welcome to e-mail [EMAIL PROTECTED] and say so. I don't think there's any problem in it from the perspective of the OSD: the LGPL _allows_ redistribution under the same terms as the software was originally distributed, and developers who write under the LGPL choose to do so, with the knowledge (hopefully) that their efforts could possibly be distributed under the GPL. If they don't like that, they could write a new library public license that did most of what the LGPL does but didn't allow the license of the covered code to be changed. As I see it, license-discuss is intended for discussions of whether the Open Source Initiative should approve or disapprove of licenses under the OSD (and whether it should make improvements and revisions to the OSD). It's not really for discussions about whether particular licenses are wise or unwise, although that's not an unimportant discussion. -- Seth David Schoen [EMAIL PROTECTED] They said look at the light we're giving you, / And the darkness that we're saving you from. -- Dar Williams, "The Great Unknown" http://ishmael.geecs.org/~sigma/ (personal) http://www.loyalty.org/ (CAF)
Re: GPL and LGPL question
Wilfredo Sanchez writes: So this linking business is RMS's interpretation, but is not in the license text. I know certain other licenses get heavily critiqued for being vague, but I don't see the same scrutiny applied to the GPL here. Well, that sort of scrutiny _has_ been applied to the GPL on many lists for many years, so that many people are sick of it. :-) Take a look at gnu.misc.discuss, and you should find such a thread fairly quickly. I personally have seen an interpretation-and-merits-of-GPL thread show up on three mailing lists and two newsgroups, none of which were license-related. That debate has been going on for years, and it's pretty easy to be tired of it already. Since the OSD hasn't existed for as long as the GPL, it's a new opportunity to try to harmonize the GPL with something or something with the GPL; most other GPL topics have already been done to death. Version 3 of the GPL is being written and supposedly close to release. Many people have provided input, and there have been some _huge_ debates about what GPL v3 should contain. I'm very optimistic that it will fix some outstanding problems and ambiguities. The lack of clarity here is the biggest reason I know of why some companies prefer to avoid dealing with the GPL at all costs, even when they are open to the idea of open source in general. There are some very solid arguments for that decision. On the other side, the GPL has been used with tremendous success in the past as the license for a number of projects. One reason that many people trust that GPL is that it has such a long track record in comparison with some other free software licenses. This proves that the developers who worked on those projects, at least, had enough confidence in the GPL to make it useful to them. A particular concern for companies, I know, is whether a license would stand up in court, and whether it can be interpreted easily and clearly. At LinuxWorld, I talked with some license enthusiasts about whether _any_ free software license has ever been an issue in a lawsuit. Apparently, the answer is no. The current version was written with the assistance of a law professor, but it would be an appeal to authority to say that this means that it would hold up. In the absence of litigation over the GPL (o si sic omnes!), each company needs to decide for itself whether the current GPL is enforceable and whether it contains loopholes or ambiguous wording. If you have some proprietary code which may ship alongside GPL'ed code, you may accidentally fall into the "derived work" category. Certainly, it is reasonable to be wary of this. I realize that this is intentional; after all, proprietary code is inherently evil in the eyes of the GPL's authors. But I would argue that this hardly represents freedom. Protecting one's right to share code by removing one's right not to doesn't seem like a Good Thing to me. It's a question of emulation, an extremely old tradition in computing. -- Seth David Schoen [EMAIL PROTECTED] They said look at the light we're giving you, / And the darkness that we're saving you from. -- Dar Williams, "The Great Unknown" http://ishmael.geecs.org/~sigma/ (personal) http://www.loyalty.org/ (CAF)
Re: GPL and LGPL question
Fred: Protecting one's right to share code by removing one's right not to doesn't seem like a Good Thing to me. You're not considering the unpaid contributor. If my only choice was a license like the BSD, I would contribute a lot less. The protective provisions of the GPL are what make the difference between my putting in work for the community and my being the unpaid patsy of anyone who wants to take advantage of my work and not give a thing back to the public or me. There's no sensible reason for me to be a contributor to Apple, Netscape, or Red Hat. The reason I do it is because the GPL guarantees that my work is for the _public_. Think about how different the world would have been if Mosaic had been under the GPL. Thanks Bruce
Re: GPL and LGPL question
On Tue, 18 May 1999, Seth David Schoen wrote: Wilfredo Sanchez writes: Well, that sort of scrutiny _has_ been applied to the GPL on many lists for many years, so that many people are sick of it. :-) Take a look at gnu.misc.discuss, and you should find such a thread fairly quickly. Yeah, and it wasn't my intention. I'm trying to figure out how some clauses in the (L)GPL and the OSD work together. The lack of clarity here is the biggest reason I know of why some companies prefer to avoid dealing with the GPL at all costs, even when they are open to the idea of open source in general. Yep. We're one of them. There are some very solid arguments for that decision. On the other side, the GPL has been used with tremendous success in the past as the license for a number of projects. One reason that many people trust that GPL is that it has such a long track record in comparison with some other free software licenses. How much of that track record is in court. I'm not trying to sound snippy, but most of these licenses don't seem to have had a legal challenge yet. THAT is a HUGE fear for corporate open sourcers. Really, who cares what a license says if it won't hold up in court? Other than the NPL and QPL, most of these documents were drawn up years ago, and case law has grown with different precedents since then. This proves that the developers who worked on those projects, at least, had enough confidence in the GPL to make it useful to them. A particular concern for companies, I know, is whether a license would stand up in court, and whether it can be interpreted easily and clearly. At LinuxWorld, I talked with some license enthusiasts about whether _any_ free software license has ever been an issue in a lawsuit. Apparently, the answer is no. The current version was written with the assistance of a law professor, but it would be an appeal to authority to say that this means that it would hold up. In the absence of litigation over the GPL (o si sic omnes!), each company needs to decide for itself whether the current GPL is enforceable and whether it contains loopholes or ambiguous wording. It's not just the GPL, I don't recall reading about litigation involving any of them. That's too much of a risk for most companies, and it's quite understandable. Which is why you're seeing a proliferation of licenses. If you have some proprietary code which may ship alongside GPL'ed code, you may accidentally fall into the "derived work" category. Certainly, it is reasonable to be wary of this. Yup. You decide to give away a library that you use in other software that is proprietary. No GPL, no LGPL because some competitor of yours could invoke clause 3 and release whiz bang improvements under it. Also, other than the QPL and NPL, I don't think that any of them have been written with international use in mind. The BSD and X licenses are probably exceptions because they say so little... A company, trying to protect its rights to the software that it created, but still benefit the community at large seems forced to draw up YAOSL because every case IS different. I think that some clarification of OSD #3 and #7 would help this immensely. It would be nice to put a non-infecting clause in there. By that I mean that a OS'd chunk of code cannot infect the work it is incorporated into with its license. That is my big gripe with the FSF's licenses, because they're using it to further a political agenda, not help the programming community at large. Leave politics to politicians. Pat -- Patrick St. Jean '97 XLH 883[EMAIL PROTECTED] Programmer Systems Administrator+1 713-977-4177 x115 Larson Software Technologyhttp://www.cgmlarson.com
Re: GPL and LGPL question
On Tue, 18 May 1999, Bruce Perens wrote: Re: the GPL standing up in court: a law student mailed me a 100+ page thesis on that topic. He said it would stand up in court. I have not yet had time to study his arguments thoroughly, too much travel. Hopefully I can do this next week. Did that law student take a look at some of the federal circuit court rulings concerning shrink-wrap licenses? The gist of them is that unless there is a signature on a document, they're pretty much worthless. That means that the legal remedies would amount to copyright infringement. Pat -- Patrick St. Jean '97 XLH 883[EMAIL PROTECTED] Programmer Systems Administrator+1 713-977-4177 x115 Larson Software Technologyhttp://www.cgmlarson.com
making money off your GPL-ed code
From: "Pat St. Jean" [EMAIL PROTECTED] I gave up BECAUSE of the GPL. I can't make any money off of that code with programs that I DON'T want to release the source for. No, you have been given wrong information. You may apply any number of licenses, in parallel, to your own work. You can apply a proprietary license and the GPL to the work at the same time, and distribute them to different customers. If you create a new version under a proprietary license only, the GPL recepients have no right to that version. It is _only_ in the case where you are distributing the work of _other_people_ that you must heed the GPL on the code. You can do anything you want with software for which you own the copyright, except for one thing: if a GPL recepient aswks for source, you must give them source for the _version_they_ _have_. This is a common misconception. Go back to work on the GPL code and make as much money as you want on it with other licenses at the same time. You will not be violating the GPL. Thanks Bruce
Re: making money off your GPL-ed code
Seth David Schoen wrote: Clark Evans writes: I feel that if anyone is trying to make money from software that is GPL'd, then they obviously do not believe in the GPL, thus they really should not be using the GPL. I think you should amend this to "to make money from applying a proprietary license to software that is GPL'd". I've made money from software that was GPL'd -- just not by trying to put it under a proprietary license. With that addition, it's still imaginable that someone believes in the practical benefits of the GPL, but not in the activist program it implements. Quite Right. And so I'm not sure about this point: Personally, I think that practices that have a "basic" version GPL'd, but the "advanced" version proprietary are worse for open source than if you just stayed 100% proprietary. While this does have a "bait and switch" feel to it, it's really only a major problem if the original developer is the _only_ person capable of maintaining the package or adding those features. Otherwise, you have some nice new GPL code that you can use for whatever purposes you like, including purposes unrelated to the original package. Well, it is the user community's mind share that counts. And if the trademark is kept by the developer and not made "open" as well, then they can just as well use it to switch from an open-source license to a proprietary license. And someone else can come along and implement the "advanced" features anew under the GPL. While this is a duplication of effort, the possibility is still present. The only problem is that the new GPL product won't have the trademark of older GPL product. And this loss of mind-share is signifiant and costly. Some of your other points provide other circumstances where the release of software under multiple licenses is problematic, but it would probably be more trouble than it's worth for the GPL to try to preclude people from releasing their code under any other license. I would only suggest that the a requirement for opensource be the addition of provisions for trademark/domain name usage to make it "open" as well. (God knows how to do this). [Distributed Copyright stuff snipped; I'll try to look at the web page soon.] That would be cool. :) Clark Evans
Re: GPL and LGPL question - legal
At 09:09 AM 5/19/99 -0500, Patrick St. Jean wrote: On Tue, 18 May 1999, Bruce Perens wrote: Did that law student take a look at some of the federal circuit court rulings concerning shrink-wrap licenses? The gist of them is that unless there is a signature on a document, they're pretty much worthless. That means that the legal remedies would amount to copyright infringement. This statement might have been correct a few years ago, but the strong recent trend is to uphold the validity of shrinkwrap and clickwrap licenses. The leading case is ProCD v. Zeidenberg in the 7th Circuit, http://laws.findlaw.com/7th/961139.html, but there are other recent decisions from the Illinois U.S. District court, http://www.microsoft.com/presspass/doj/y2k/sld001.htm, the Washington State Court of Appeals, http://www.wa.gov/COURTS/opinions/413040_O01.txt, and the New York Appellate Division in Brower v. Gateway 2000. John Muller [EMAIL PROTECTED] [EMAIL PROTECTED] "The ladder of law has no top and no bottom"
Re: License certification request
You could reduce this to the BSD license, an added attribution sentence, and a separate trademark statement, and thus save us from the evils of "license proliferation" - one more license in the world for programmers to figure out, one more license that is not compatible with other pre-existing licenses. Since the BSD license is already "certified", if you used the straight BSD you'd be able to claim certification right away. Please consider that. Thanks Bruce From: Kevin Kelm [EMAIL PROTECTED] /* === * Copyright (c) 1998-1999 Boulder Software Foundry. All rights reserved. * Trademark rights claimed in "Boulder Software Foundry" and "Flashpoint * Application Server". * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * * 3. All advertising materials mentioning features or use of this *software must display the following acknowledgment: *"This product includes software developed by the Boulder Software Foundry *for the Flashpoint Application Server project *(http://www.BoulderSoftware.com/)." * * 4. The names "Flashpoint Application Server Technology" and "Boulder *Software Foundry" must not be used to endorse or promote products *derived from this software without prior written permission. For *written permission, please contact [EMAIL PROTECTED] Paragraph 4 should exclude the use required in paragraph 3 as something requiring prior written permission. * 5. Products derived from this software may not be called "Flashpoint" *nor may "Flashpoint" appear in their names. * * 6. Redistributions of any form whatsoever must retain the following *acknowledgment: *"This product includes software developed by the Boulder Software *Foundry for the Flashpoint Application Server project *(http://www.BoulderSoftware.com/)." Is this redundant with paragraph 1? Paragraph 1 requires that the license and copyright statement be included. If the license and copyright statement contain the acknowledgement sentence above, paragraph 6 is redundant - unless you want us to put the attribution somewhere else. * * 7. We request (but do not require) that bug fixes, enhancements, and *new features of interest to the general public made in the Flashpoint *Application Server code be submitted free of licensing and in source *form to [EMAIL PROTECTED] * * THIS SOFTWARE IS PROVIDED BY THE BOULDER SOFTWARE FOUNDRY ``AS IS'' AND * ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE BOULDER SOFTWARE FOUNDRY * OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED * OF THE POSSIBILITY OF SUCH DAMAGE. * * * This software consists of voluntary contributions made by many * individuals on behalf of the Boulder Software Foundry and was * originally designed and written by Kevin Kelm and Jonah Safar. * For more information on the Boulder Software Foundry and the * Flashpoint Application Server project, please see * http://www.BoulderSoftware.com/. * */
Re: New Licensing Model?
Charles, You are trying to create an open source license for a technology which is protected by patent and trademark. You are tying the patent use to the trademark? "Charles A. Jolley" wrote: This technology exists as a specification, a set of rules, that we want to license to people and then certify the use of this technology in their products. Will people be able to freely implement use specification without reference to your trademark? Basically, we are working on a license for the technology that gives people free license (as protected by our patents, copyrights, and trademarks) to use the technology in their products and limited use of the technology's name in relation to their product, unless they sell it for commercial use. If they sell the product, then they must get their product certified to be compliant by us. The above sounds like a restriction on the trademark only. Correct? This license will be "viral" in that any derivatives of a product based on this license must also carry it and so on and so forth, as long as the product is still compliant with our technology. Also, we will allow people to charge for the cost of burning CDs, etc. without needing to get certified and we will allow certain people to be exempted from the certification requirement, such as those who are selling shareware. Those making money don't have to be certified? this is not clear. Now, this license only covers use of the technology and its associated name. It will work such that it will go **along-side** any other license for the actual software/hardware. For example, the open-source software that we release will be licensed under our license for use of our technology, but will also be released under a BSD or GPL license for the software itself. GPL seems to be incompatible with any kind of patent license. My concern here is that such a license cannot be combined with GPL, which obviously could be a problem since there is so much software out there based on the GPL and I would want these people to be able to make their products communicate using our technology if they should so choose. So what do you think? Is this a viable strategy as far as creating an open-source compatible license is concerned? Would there be open-source licenses that this technology license could go along-side of? It's traditional for people to be able to implement the specification without regard for any licensing restrictions, is this included? Best, Clark
Re: New Licensing Model?
Basically, we are working on a license for the technology that gives people free license (as protected by our patents, copyrights, and trademarks) to use the technology in their products and limited use of the technology's name in relation to their product, unless they sell it for commercial use. If they sell the product, then they must get their product certified to be compliant by us. Good intention, but there are a few problems I'd like you to work on. If you are explicitly restricting your patents in a way that would constitute a prohibition on sale of the software, that would fail paragraph 1 of the Open Source Definition. You would also run awry of the GPL's language about patents. Please read that. I suggest you blanket-license your patents for use by any program that is licensed entirely under the GPL (I mean a program that has no non-GPL components). Anyone who wants to write proprietary code will have to go to you for a patent license, and thus your revenue stream will be protected while you will also have your system entirely in Open Source and your patents licensed in an OSD and GPL-compliant manner. I'm confident that you can work out a way to do that protects your profits and is OSD and GPL-compliant. If you'd like to have a talk about it, feel free to call me at 510-526-1165. Thanks Bruce
Re: Zeratec Public License
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 13 Jul 1999, Pat St. Jean wrote: On 13 Jul 1999 [EMAIL PROTECTED] wrote: My main criticism is that some of the language is _oblique_ and should be phrased as a "permission" rather than an "understanding". The license is meant to be executed by programmers, not attorneys, and thus should be as clear and unambiguous as possible. I must disagree here. It isn't the programmer in the court room defending your rights from someone violating the license. Clear and unambiguous is a good thing, but in my opinion that should be from a legal standpoint, not necessarily an end user's. If you're in doubt as to what is said, you should contact your attorney and have hir clarify it. I think Bruce mis-stated his point to some extent, but he's right. A license written in terms of 'understandings' rather than specific assignment of permissions to the licensee is ambiguous. This makes it both harder for the end user (as opposed to the lawyers) to understand *and* harder to enforce. When Bruce said that "the license is meant to be executed by programmers, not attorneys", I think he meant that attorneys would know the legal significance of an 'understanding' in a contract, but programmers wouldn't, so to be safe they'd have to hire an attorney. It's one of the effects of ambiguity. Another effect is that the contract may be harder to enforce. It seems that you'd have a hard time proving that someone had the same 'understanding' that you had about the terms of the license. Of course, I'm not a lawyer, so I can't speak with certainty here. See? It really *is* hard for non-attorneys to understand. What, you don't have an attorney? And you're entering in to a legally binding business relationship with someone? I didn't have to have my attorney read the GPL before I agreed to it, because the GPL is unambiguous. It says, "You are allowed to use, modify, and redistribute in original or modified form." It doesn't say anything is 'understood'. It assumes the end user understands nothing at all, and then proceeds to spell it out. Note, I do not practice law. Through my folks I've met quite a few, in many different areas of specialization, usually by working on their networks. This is the one consistent piece of advice I've always gotten: "Always read before you sign. If you don't understand it, have someone who does advise you." That's why it's important for the license to be unambiguous. You don't want the individual programmer who downloads your code and thinks of a new feature to add to have to hire an attorney at $200 per hour to read the license and make sure it would be legal for him to redistribute his modifications under the GPL. -BEGIN PGP SIGNATURE- Version: GnuPG v0.9.7 (GNU/Linux) Comment: PGPEnvelope - http://www.bigfoot.com/~ftobin/resources.html iD8DBQE3i6JO2GOwREX5+xQRAtv0AJ4oyJCq3+meJLO9m16Jm4ECQO17pgCdFX/u wG2IoveBPuxumcxPFLQBNAg= =VWBe -END PGP SIGNATURE-
Re: Zeratec Public License
On Tue, 13 Jul 1999, Mark Wells wrote: I think Bruce mis-stated his point to some extent, but he's right. A license written in terms of 'understandings' rather than specific assignment of permissions to the licensee is ambiguous. This makes it both harder for the end user (as opposed to the lawyers) to understand *and* harder to enforce. When Bruce said that "the license is meant to be executed by programmers, not attorneys", I think he meant that attorneys would know the legal significance of an 'understanding' in a contract, but programmers wouldn't, so to be safe they'd have to hire an attorney. It's one of the effects of ambiguity. Ahhh... That helps, it makes more sense now... I didn't have to have my attorney read the GPL before I agreed to it, because the GPL is unambiguous. It says, "You are allowed to use, modify, and redistribute in original or modified form." It doesn't say anything is 'understood'. It assumes the end user understands nothing at all, and then proceeds to spell it out. Yep, definitely a well written license. I don't agree with some of it, but that's a MUCH different discussion... That's why it's important for the license to be unambiguous. You don't want the individual programmer who downloads your code and thinks of a new feature to add to have to hire an attorney at $200 per hour to read the license and make sure it would be legal for him to redistribute his modifications under the GPL. $200/hr?!?!?! You're getting off cheap! Seriously. But look at it this way. If there is doubt, even $400 an hour is better than the judgement you're likely to have to pay if you do violate the terms... I agree with what Bruce said earlier, a LEGALLY clear and unabiguous license SHOULD be easy for a normal person to read. That's the best of all worlds, and working to get that is a Good Thing. But if you're in doubt, communicate with the other party. In writing, e-mail isn't admissable everywhere. It never hurts to ask questions. Regards, Pat -- Patrick St. Jean '97 XLH 883[EMAIL PROTECTED] Programmer Systems Administrator+1 713-977-4177 x115 Larson Software Technologyhttp://www.cgmlarson.com
Re: Zeratec Public License
Forrest J. Cavalier III wrote: In fact, could you GPL it, and include a notice along the lines of "if you want to use our trademarks, certification marks, etc. contact us for a different agreement." That would clean up the open source license a great deal, I think. The point is that Zeratec has a *patented algorithm*, not a piece of code. (Whether patented algorithms are a Good Thing is out of scope here.) Zeratec's intent, as I understand it, is to license people to use the *patent* when creating software that is covered by the GPL or similar open-source license. Closed-source software creators have to negotiate a separate patent license. So this license is not parallel to the GPL or any existing *copyright* license; it's another thing altogether. -- John Cowan http://www.ccil.org/~cowan [EMAIL PROTECTED] Schlingt dreifach einen Kreis um dies! / Schliesst euer Aug vor heiliger Schau, Denn er genoss vom Honig-Tau / Und trank die Milch vom Paradies. -- Coleridge / Politzer
Re: Zeratec Public License
Charles: Splitting this into two license would simplify the free component, but it would also mean that people buying and using products would have to get to know two separate license... I think that's to your advantage. It helps reinforce the destinction between Degas-certified products and non-certified ones. Also, if you ever go to court about a license, you have less text for the court to interpret. Thanks Bruce
gpl backlash?
Thought I'd mention that the licensing has changed for "php4" aka zend. It was under the GPL, but now it appears to be under the QPL (just like kde). Seems to be a backlash against the GPL lately - slashdot has posted numerous articles on freebsd, which invariably say that "the gpl is evil (blah blah), and use freebsd because it's better. insert holy war here". Anybody else noticed this (and care to comment on it)? -- Signal 11
Re: gpl backlash?
Hi all; ... a maiden poster here. Trust me to pick a holy war to start with, eh? snip Seems to be a backlash against the GPL lately - slashdot has posted numerous articles on freebsd, which invariably say that "the gpl is evil (blah blah), and use freebsd because it's better. insert holy war here". Anybody else noticed this (and care to comment on it)? I've noticed it, yes. To me the issue that invariably crops up is the viral nature of the GPL. Specifically, that inclusion of GPL'd code means that the larger work must in turn be GPL'd. This has pros and cons, which are both monetary *and* ideological. And when money and belief meet head on ... well ... things get messy. Ask the Crusaders. Pros of viral GPL: Ideological: It enforces freedom. User freedom is wholly ensured. The author of the code also has legal resourse if his code is taken for use without his permission (this could be *vaguely* hidden in a compiled program). Monetary: It ensures that GPL'd code will always be available for the cost of a download - essentially free (as in free beer). The low opp. cost of GPL'd code makes it very attractive to purchasers. Some businesses are nervous at the possibility of their code been opened, but may soon realise that it levels the playing field in an absolute way - nobody gains advantage in a GPL'd world. Cons of a viral GPL: Ideological: There are some the GPL is not free at all, that is in fact enforced, top-down "Freedom by Command", not unlike being liberated by the Red Army. Others feel that it is too ideological, full stop. Monetary: Some companies and people may balk at their expensively developed code being made available in an environment where it cannot be sold. They may also feel that they are performing free RD for competitors. The above list is not comprehensive, by any means. I begin to think that this list might wish to work towards a License HOW-TO, which sets out several aspects of the common licenses and how to choose your best choice. For maximum interoperability with the GNU project and low hacker objection, for example, the GPL is the only choice. Signal 11 Be well; JC.
Re: gpl backlash?
| For the software I personally write, there really isn't much choice but the | GPL. That's because I donate my time to increase the amount of available | free software, _not_ non-free software. I absolutely will not tolerate being | treated as an unpaid employee by someone who takes my contribution and | incorporates it into non-free software, without returning the same value to | the community that I put into it when I made my contribution. Thus, I would | not contribute my time to writing free software without the _protection_ of | the GPL. That's a fairly narrow view, Bruce. NeXT used GPL'ed code for years without adding much value to the GNU Project because they made lots of NeXT-specific changes and didn't care at all whether they got folded into the FSF source base. Sure the software remaind "free", but none of it ever made it into the FSF sources and was therefore generally useless to the Community. Had it not been GPL'ed and had they made it "proprietary," there would have been little difference to anyone. What did this "protection" buy you? On the other hand, Apple has contributed a fair bit (not a terrifically great bit, but certainly something) to NetBSD and Apache despite the lack of any requirements to do so. And we're finally getting our act together and submitting a large body of work to gdb. I just met with a pile of gdb developers at a Cygnus-sponsored gdb party, and they were quite exited to be getting this code. The fact that it's been available for years never helped anyone. The fact that we are now actively trying to merge it in upstream is what counts, and the GPL isn't going to get you that. Which isn't to say that "the GPL is evil"; that's yet another narrow view. I'm just saying that you're not looking at the bigger picture. I would say that the GPL isn't necessary, but I just want better software, not some notion of code virtue. I want to be able to run an open system on my computer, and I want it to be the best open system it can possibly be. So I'll write open software to contribute to the value of that system, and I'll hope that lots of other people will use it and see the value in improving it in the same way. If someone else takes it and decides not to contribute, I don't really care. I'm not anyone's "unpaid employee" because they use my code. My belief is that people who take open source and diverge on their own at in the long-term going to lose. I don't have any doubts about the security of open source, and don't need to force my view onto others. I'd rather welcome them and wait for them to get a clue if they don't already have it. Poo-poo-ing them because they don't share my view isn't going to make my software better if it means they go work on something else instead. So if the GPL limits my audience, I see that as a bug, not a feature. | Have you looked at freshmeat.net lately? At least half of the program | announcements there have "GPL" as their license. That's a lot more than | it used to be. The GPL has momentum. So does MS Windows. That doesn't necessarily make it The Best Thing. -Fred #include std_disclaimer.h /* opinion(Fred) != opinion(Apple) */ -- Wilfredo Sanchez, [EMAIL PROTECTED] Apple Computer, Inc., Core Operating Systems / BSD Technical Lead, Darwin Project 1 Infinite Loop, 302-4K, Cupertino, CA 95014
Re: gpl backlash?
1 Infinite Loop, 302-4K, Cupertino, CA This has got to be a joke...? No. It is a circular road in Cupertino which, IIRC, surrounds one of Apple's campuses. (or something like that). The NAMING of the road was certainly a joke, but :) D
Re: gpl backlash?
|NeXT used GPL'ed code for years without adding much value to the
| GNU Project because they made lots of NeXT-specific changes and
| didn't care at all whether they got folded into the FSF source
base.
| Sure the software remaind "free", but none of it ever made it into
| the FSF sources and was therefore generally useless to the
Community.
|
| Except the *NeXT* community.
OK, that's fair.
| Well, different people have different objectives for opening
systems up (or
| making open systems in the first place), of course. My objective is to
| benefit the user, and make the user's life nice.
OK, I like that objective.
| For some things, that means simply ensuring that no one can do
anything to
| the code without letting other people see those changes; the GPL
is nice
| here. From past experience this seems to include compilers, since few
| people can expend the resources to a) write a whole compiler to
introduce a
| new feature or b) write that feature to be portable across every
platform
| the original compiler works for. So the GPL helps to keep people from
| wimping out, and writing in new features for just one platform.
However, it
| also provides the incentive that you don't have to write the rest
of the
| compiler.
Certainly the GPL has worked well here. Writing a compiler is
enough of a pain in the ass that dealing with the GPL, regardless of
your objections, is likely worthwhile.
And I'll grant you that the GPL has done great things for free
software. In times when nobody in business thought free software was
interesting, it kept things moving. To that end, the GPL is a
wonderful thing. On the other hand, people are starting to see real
economic benefit (resource management, compatibility,
standardization) to open source.
The GPL's major flaw is its unbounded viral nature. That scares
(quite reasonable) people away from it, and I think that's a real
bummer. I don't mind the "keep this free" sentiment. (In fact,
Apple's license, which I had some input on, has a similar requirement
to keep derivative works under the same terms, and I think that's
fair.) But you have to at least specify what you mean by derivative
works, and allow for the possibility of integration of open code with
closed code. And yes, you can probably find ways to change the code
such that you don't have to contribute anything of value if you
dance around the license enough, but I can accept that.
With the GNU license, there is no telling whether if I write a
10,000 line program, which has one line:
system("/bin/ls");
and oops, /bin/ls is from GNU fileutils. Well, crap, is my program
infected by the GPL? Does that means I can't run my program on
Linux? Well of course not, you say. But the license doesn't say,
and that's just plain silly. On the other hand, this sort of
confusion might just render the GPL useless in court, and out goes
the "protection" that you're after. Lucky it's never been tried in
court; I'm quite curious about it.
| For other things, the most important thing for the end user is
| compatibility; internet servers, for instance. In those cases,
it's more
| important that *absolutely everything* come from a commnon code base,
| period.
Well, it's important that things interoperate, not that they use
the same code, though sharing code does tend to help that a lot.
| 1 Infinite Loop, 302-4K, Cupertino, CA
|
| This has got to be a joke...?
Yes and no.
-Fred
--
Wilfredo Sanchez, [EMAIL PROTECTED]
Apple Computer, Inc., Core Operating Systems / BSD
Technical Lead, Darwin Project
1 Infinite Loop, 302-4K, Cupertino, CA 95014
Re: gpl backlash?
On Mon, 26 Jul 1999, Wilfredo Sanchez wrote: [for readability I've reformatted some comments] | Except the *NeXT* community. OK, that's fair. | making open systems in the first place), of course. My objective | is to benefit the user, and make the user's life nice. OK, I like that objective. Good! [snip] Certainly the GPL has worked well here. Writing a compiler is enough of a pain in the ass that dealing with the GPL, regardless of your objections, is likely worthwhile. And I'll grant you that the GPL has done great things for free software. In times when nobody in business thought free software was interesting, it kept things moving. To that end, the GPL is a wonderful thing. On the other hand, people are starting to see real economic benefit (resource management, compatibility, standardization) to open source. I disagree -- it looks like people are starting to see the benefits of getting their end users to fix bugs. Which can be a different animal from open source entirely. [note: I'm not sure if I agree with the APSL but I'm not flaming it here; I'm trying to push the idea that there are different degrees of freedom to software, and I happen to like the highest degree possible] Of course, the fastest way to open software up is to provide lots of endearing and attractive open source options, that strongly encourages more open software. The GPL in some cases is overkill (there's a strong encouragement in the BSD family for proprietary vendors to give back), but in some cases its necessary. The GPL's major flaw is its unbounded viral nature. [snip] But you have to at least specify what you mean by derivative works, and allow for the possibility of integration of open code with closed code. Do you mean by this that if the GPL were more specific in its allowances and prohibitions, it would make for more acceptance and a better license? I can agree with that. It's important to put people at ease that their use of a license is doing what they think it's doing, and clear language is important there. And yes, you can probably find ways to change the code such that you don't have to contribute anything of value if you dance around the license enough, but I can accept that. As can I. It would be difficult to add proprietary extensions to gcc, for instance, without making a clearly derivative work (as opposed to the below). the "protection" that you're after. Lucky it's never been tried in court; I'm quite curious about it. As am I. For the rest of it, see above. | For other things, the most important thing for the end user is | compatibility; internet servers, for instance. In those cases, it's more | important that *absolutely everything* come from a commnon code base, | period. Well, it's important that things interoperate, not that they use the same code, though sharing code does tend to help that a lot. The fastest way to push a standard out is to give people the code to implement the standard, so that it will work with some minor tweaks and studying. It looks to me like X won this way, as well as a lot of BSD stuff (I'm almost certain OS/2 uses some BSD code for its networking stuff, for example). | 1 Infinite Loop, 302-4K, Cupertino, CA | | This has got to be a joke...? Yes and no. Those Crazy Californians again, I guess. Yes, my roots go to California too :) On a side note, has anyone been receiving multiple copies of messages? I received the message I'm responding to *thrice*. Matthew Weigel Programmer/Sysadmin [EMAIL PROTECTED] Operating Systems Advocate http://www.pitt.edu/~weigel
Re: gpl backlash?
| I disagree -- it looks like people are starting to see the benefits of | getting their end users to fix bugs. Which can be a different animal | from open source entirely. Not entirely. I don't mind paying for software. What kills me is "that damned bug that's been there forever and why don't they fix it it's so easy if only I could get the code". There is nothing wrong with end users being able to fix bugs, and there is nothing wrong with a business realizing that this can be mutually beneficial. | [note: I'm not sure if I agree with the APSL but I'm not flaming it | here; I'm trying to push the idea that there are different degrees of | freedom to software, and I happen to like the highest degree possible] The APSL is new. I personally think it will need to evolve further, but it's pretty good for where we are today. | Do you mean by this that if the GPL were more specific in its | allowances and prohibitions, it would make for more acceptance and a | better license? Most certainly. For starters, it should define "derived work" if it's going to use that term in its requirements. | The fastest way to push a standard out is to give people the code to | implement the standard, so that it will work with some minor tweaks and | studying. It looks to me like X won this way Yeah, sometimes this backfires. | On a side note, has anyone been receiving multiple copies of messages? I | received the message I'm responding to *thrice*. Not I. -Fred #include std_disclaimer.h /* opinion(Fred) != opinion(Apple) */ -- Wilfredo Sanchez, [EMAIL PROTECTED] Apple Computer, Inc., Core Operating Systems / BSD Technical Lead, Darwin Project 1 Infinite Loop, 302-4K, Cupertino, CA 95014
Re: gpl backlash?
On Mon, 26 Jul 1999, Wilfredo Sanchez wrote: snip Certainly the GPL has worked well here. Writing a compiler is enough of a pain in the ass that dealing with the GPL, regardless of your objections, is likely worthwhile. The GPL has had many areas of success. I wonder, out of sheer curiousity, whether there will emerge a *technical* or *quantitative* case for any of the licenses. However, as I pointed out in an earlier posting, selection of a license is an act with both monetary/business/financial *and* ideological implications. The two are joined at the waist. I think it would be foolish to try and consider the money and the beliefs seperately; the two are now irreversibly entangled. Tread carefully, dear traveller. An interesting point arises from the quote, however. I'd never really though about how a person choosing among competing software is affected by the license. I've always looked from the licensor's view, not the licensee's. Obviously, the GPL is aimed at being "user-protective" rather than "business-protective". It distinctly expempts the author from liability, and enforces their ownership, but it essentially throws *control* of that code out to the community. In economics, *ownership* and *control* are very different propositions. In the Galbraithian world-view, they are the basis of economic Power ... and I'm wandering. Pardon me. And I'll grant you that the GPL has done great things for free software. In times when nobody in business thought free software was interesting, it kept things moving. To that end, the GPL is a wonderful thing. On the other hand, people are starting to see real economic benefit (resource management, compatibility, standardization) to open source. The business case. "The marketing campaign", which I believe is one of the descriptions that ESR gave the whole "open source" push. I disagree -- it looks like people are starting to see the benefits of getting their end users to fix bugs. Which can be a different animal from open source entirely. They'll just as quickly discover that customers can honestly tell how shitty their software is. Relying on your customer to fix bugs is like a car company expecting customers to repair the faulty seat-belt designs on a new model. It's not going to last: companies with shitty source will lose both rep. and business if they go open source. [note: I'm not sure if I agree with the APSL but I'm not flaming it here; I'm trying to push the idea that there are different degrees of freedom to software, and I happen to like the highest degree possible] That's why a plurality of licenses exist. Diversity is healthy. But some wonder if the GPL's virality is really a play at a kind of monopoly; dominance over the licensing ecosystem. One of the principle reasons for choosing the GPL in my brief review was being "approved for use" with the vast body of already GPL'd code. This is very much like buying Microsoft Word because ... well ... everyone else uses it. So much easier to conform than to choose another option. Of course, the fastest way to open software up is to provide lots of endearing and attractive open source options, that strongly encourages more open software. The GPL in some cases is overkill (there's a strong encouragement in the BSD family for proprietary vendors to give back), but in some cases its necessary. The GPL is a good license. The viral clause is like an ideological agreement button: "By selecting this license, you agree that the FSF is correct in protecting user freedom ..." The GPL's major flaw is its unbounded viral nature. [snip] But you have to at least specify what you mean by derivative works, and allow for the possibility of integration of open code with closed code. This will be where the license fails in court. A new version - a 2.1 - needs to *explicitly* define the limits of the viral clause, or there will be hell to pay. Microsoft could kill business interest in the GPL by deliberate infringement, followed by a huge, protracted courtcase during which time all GPL'd code enters legal limbo in the eyes of the business community. The GPL needs more fire-proofing, in my view. Do you mean by this that if the GPL were more specific in its allowances and prohibitions, it would make for more acceptance and a better license? I can agree with that. It's important to put people at ease that their use of a license is doing what they think it's doing, and clear language is important there. The clear language is good. I suspect the GPL is popular partially because it is *simple*. The MPL is complex. The APSL is complex. The SCSL is complex. But the GPL and the BSDL and XL are all simple non-legalistic licenses. Hackers don't have time to be lawyers. And yes, you can probably find ways to change the code such that you don't have to contribute anything of value if you dance around the license enough, but I can accept that. If people want
Re: gpl backlash?
| Obviously, the GPL is aimed at being "user-protective" rather than | "business-protective". No. It's "author-protective". You write software. You want people to use it (for whatever reasons), but you have certain restrictions you use on usage to protect you as the author. This is that case with pretty much every license. In the GPL's case, the restriction is that derivative works are also GPL'ed. Now I'm the user, and I want to write some software which maybe uses a snippet of code from bash. For example, maybe I want to use readline. Well, now I'm forced to GPL my work. That's not protecting me as the user; that's "protecting" the authors of readline. Even so, it's hardly "protecting" the author: his code remains free no matter what I do with it. It's more of a trade. I use that code in exchange for making my code GPL'ed as well. For some code I may be willing to do that. On the other hand, for some code, maybe I'm not. This is not tied to me being a business. Maybe I don't agree with that philosophy, and would rather write and use code that is less restrictive, and although I think software should be open, I don't feel the need to impose that view on my users. So maybe the GPL doesn't work for me. -Fred -- Wilfredo Sanchez, [EMAIL PROTECTED] Apple Computer, Inc., Core Operating Systems / BSD Technical Lead, Darwin Project 1 Infinite Loop, 302-4K, Cupertino, CA 95014
Re: gpl backlash?
Date: Mon, 26 Jul 1999 20:13:25 -0700 From: Wilfredo Sanchez [EMAIL PROTECTED] | Do you mean by this that if the GPL were more specific in its | allowances and prohibitions, it would make for more acceptance and a | better license? Most certainly. For starters, it should define "derived work" if it's going to use that term in its requirements. My understanding is that ``derived work'' has a defined legal meaning in the context of copyrights. There is no pressing need for the GPL to define it. You can find more information by poking around under http://www.loc.gov, e.g., http://www.loc.gov/copyright/circs/ (Of course this only applies to U.S. law.) It's certainly true that the notion of derived work becomes very murky when it comes to computer programs, just as it does in other fields such as music. But that is not a fault of the GPL. It is reasonable and, I think, correct for the GPL to defer to copyright law and the federal courts when it comes to the meaning of ``derived work.'' It leaves us confused right now, but it avoids creating a definition which may become meaningless or invalid as programming technology advances. Ian
Re: gpl backlash?
[EMAIL PROTECTED] scripsit: For example, I'd submit that _reference_ is derivation where software is concerned. If you call into my library from your program, it's a derived work. Then in your view, only GPL-compatible programs can be run under Linux? -- John Cowan [EMAIL PROTECTED] I am a member of a civilization. --David Brin
Re: gpl backlash?
Kyle Rose scripsit: [T]he LGPL, the license under which the major libraries are released, specifically allows non-free programs to link to binaries under that license. The kernel, however (which is just another library), is under the GPL. I know that Linus explicitly states that the GPL's viral properties do not spread from the kernel to user-mode code, but I don't see how that can be made consistent with the GPL's claim that "changing it [the GPL] is not allowed." -- John Cowan [EMAIL PROTECTED] I am a member of a civilization. --David Brin
Re: gpl backlash?
John Cowan writes: Kyle Rose scripsit: [T]he LGPL, the license under which the major libraries are released, specifically allows non-free programs to link to binaries under that license. The kernel, however (which is just another library), is under the GPL. I know that Linus explicitly states that the GPL's viral properties do not spread from the kernel to user-mode code, but I don't see how that can be made consistent with the GPL's claim that "changing it [the GPL] is not allowed." It could be viewed as an additional permission, making Linux dual-licensed, except that Linus doesn't have authority to grant that permission on behalf of all of the other developers -- who presumably have the right to assert that this is either (1) merely Linus's personal opinion, and factually incorrect; or (2) merely Linus's personal decision to dual-license _his own_ code, and therefore not applicable to their own code, which, in compliance with the terms of the GPL, was released under the GPL (so that Linus lacks the authority to unilaterally re-license their work); or (3) a copyright violation on Linus's part, because he made an unauthorized derived work from the GPL, which is copyrighted by the Free Software Foundation; or (4) a mistake on Richard Stallman's part, because Linus's change to the GPL is fair use, and not a copyright violation. (I think most, if not all, people who contribute to the kernel are willing to accept Linus's judgment on this point, but that doesn't mean that it might not be an issue in the future.) -- Seth David Schoen [EMAIL PROTECTED] They said look at the light we're giving you, / And the darkness that we're saving you from. -- Dar Williams, "The Great Unknown" http://ishmael.geecs.org/~sigma/ (personal) http://www.loyalty.org/ (CAF)
Re: gpl backlash?
Matthew C. Weigel writes: On Tue, 27 Jul 1999, Seth David Schoen wrote: It could be viewed as an additional permission, making Linux dual-licensed, except that Linus doesn't have authority to grant that permission on behalf of all of the other developers -- who presumably have the right to assert that this is either No, he only has the authority to grant that on the code he originally wrote -- but that is part of the license, which by the GPL's viral nature ensures that all code distributed which is a derivative work of the kernel is, then, under the same license. _If_ Linus is allowed to modify the GPL, and actually did so (or if he modified it despite being forbidden to do so). It's not totally obvious that the sentence there is intended to be "part of the license", as opposed to a non-binding observation by Linus, or an expression of his wishes. (2) merely Linus's personal decision to dual-license _his own_ code, and therefore not applicable to their own code, which, in compliance with the terms of the GPL, was released under the GPL (so that Linus lacks the authority to unilaterally re-license their work); or But it wasn't released under the pristine GPL. _If_ Linus is allowed to modify the GPL, and actually did so (or if he modified it despite being forbidden to do so). (3) a copyright violation on Linus's part, because he made an unauthorized derived work from the GPL, which is copyrighted by the Free Software Foundation; or Except that such additions are authorized -- hence it's not "...an unauthorized derived work..." They're not authorized, so far as we can tell from what's stated in public: Copyright (C) 1989, 1991 Free Software Foundation, Inc. [...] Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. It's possible that the FSF explicitly gave Linus permission to modify the GPL, but we don't have any way of knowing that. (4) a mistake on Richard Stallman's part, because Linus's change to the GPL is fair use, and not a copyright violation. ??? How is it a mistake on RMS' part, even given that your above statements are true? Each of these possibilities, (1) through (4), is meant to be mutually exclusive with all the others. The "mistake" would be if fair use allows Linus to modify the GPL by adding to it (as opposed to "mere aggregation" with another, separate license :-) additional terms or permissions, since Stallman certainly did _not_ want people to be able to do so as a general rule. In that case, Stallman's claim that "changing it is not allowed" is not correct, and this would be the "mistake" to which (4) refers. -- Seth David Schoen [EMAIL PROTECTED] They said look at the light we're giving you, / And the darkness that we're saving you from. -- Dar Williams, "The Great Unknown" http://ishmael.geecs.org/~sigma/ (personal) http://www.loyalty.org/ (CAF)
Re: gpl backlash?
| For example, I'd submit that _reference_ is derivation where software is | concerned. If you call into my library from your program, it's a derived | work. However, copyright law doesn't take that into account and is only | concerned with copying. And therein lies a serious problem, because I think your assertion is a load of hooey. Just becuase I have code that make calls to a certain API, which you happen to have implemented, doesn't mean that I'm deriving from your code. I might write code against the POSIX foobar() API, and maybe someone drops a GPL'ed implementation of libfoobar in place of the dylib (with a free implementation) that I was using, doesn't make my code derived. And it doesn't matter who is right here; my point is we can't know. -Fred -- Wilfredo Sanchez, [EMAIL PROTECTED] Apple Computer, Inc., Core Operating Systems / BSD Technical Lead, Darwin Project 1 Infinite Loop, 302-4K, Cupertino, CA 95014
Re: gpl backlash?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Postulate that you write an application that works with a library full of no-op stubs. That library just happens to match the interface of a GPL-ed product I've written, and with that library it is a functioning product. Then you ship that application with the _intent_ that the user combine it with my library to run it, which is demonstrated by the fact that it doesn't do useful work any other way or you haven't shipped an alternative library to that same user. I think I'd have a legitimate complaint. Unfortunately, as much as I love the GPL, I don't think this is enforcable. Remember that the GPL covers only distribution, not use; hence, if the distribution of a work linked against a library interface (even that for which only a GPL'ed implementation exists) does not contain any actual code from that library, it cannot be considered a derived work. Although IANAL, it would be like suing critics for reviews which contain "hooks" into the book (e.g., character names, chapter and/or event references, etc.) Kyle - -- Kyle R. Rose "They can try to bind our arms, Laboratory for Computer ScienceBut they cannot chain our minds MIT NE43-309, 617-253-5883 or hearts..." http://web.mit.edu/krr/www/ Stratovarius [EMAIL PROTECTED] Forever Free -BEGIN PGP SIGNATURE- Version: GnuPG v0.9.5 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE3nlT766jzSko6g9wRAmTsAKD46FhexYayhxIINjpBIQL+cuPWiACgoxGT UAPnBJ5uRJN2s6s0aNlUN74= =WIA+ -END PGP SIGNATURE-
Re: gpl backlash?
From: Kyle Rose [EMAIL PROTECTED] Unfortunately, as much as I love the GPL, I don't think this is enforcable. Remember that the GPL covers only distribution, not use; hence, if the distribution of a work linked against a library interface (even that for which only a GPL'ed implementation exists) does not contain any actual code from that library, it cannot be considered a derived work. Remember, we're talking about how the concept of a derived product has not kept up with software. So, I agree that this may not be enforcable today, but I might work toward making it enforcable. In the meantime, I'd hope that good citizens would comply with the intent of my license even if the possibility for successful enforcement is low. Although IANAL, it would be like suing critics for reviews which contain "hooks" into the book (e.g., character names, chapter and/or event references, etc.) A closer metaphor might be cross-linking of web sites. For example, say I took the site that you spent a lot to produce, and presented it inside of a frame with all of my own ads around the border. You'd have a right to object. This is another area where copyright law _has_not_kept_up_. Thanks Bruce
Re: gpl backlash?
Postulate that you write an application that works with a library full of no-op stubs. That library just happens to match the interface of a GPL-ed product I've written, and with that library it is a functioning product. Then you ship that application with the _intent_ that the user combine it with my library to run it, which is demonstrated by the fact that it doesn't do useful work any other way or you haven't shipped an alternative library to that same user. I think I'd have a legitimate complaint. If the application was created without ever using the GPL-ed code, it is clearly not a derivative work until the end user combines it with the GPL-ed code. Even if the GPL-ed code was used for testing purposes, I believe the courts consider that "fair use" and not creating a derivative work. Forrest J. Cavalier III, Mib Software Voice 570-992-8824 The Reuse RKT: Efficient awareness for software reuse: Free WWW site lists over 6000 of the most popular open source libraries, functions, and applications. http://www.mibsoftware.com/reuse/
Re: gpl backlash?
Date:Wed, 28 Jul 1999 12:01:12 +0200 (CEST) From: Martin Konold [EMAIL PROTECTED] On 28 Jul 1999 [EMAIL PROTECTED] wrote: 1. If an alternate implementation from mine exists 2. and is available for the user to run with your application on that platform 3. and the user actually has to have it to run your application. Postulate that you write an application that works with a library full of no-op stubs. That library just happens to match the interface of a GPL-ed product I've written, and with that library it is a functioning product. Then you ship that application with the _intent_ that the user combine it with my library to run it, which is demonstrated by the fact that it doesn't do useful work any other way or you haven't shipped an alternative library to that same user. I think I'd have a legitimate complaint. Bruce: Are you shure that "intent" has any legal meaning? In U.S. law, ``intent'' has a legal meaning in a number of contexts. For example, the difference between manslaughter and homicide is one of intent. I believe that in the copyright arena, intent goes by names such as ``contributory infringement.'' Ian
keeping patentable algorithm free
I have a basic patent question that is possibly license related. I apologize in advance if this is the wrong forum. I wrote some software in my free time. I think one of the algorithms is patentable. It's not earth shattering by any means, but that hardly seems to be a requirement these days. Here's the scenario: 1) I don't want to spend a lot of money or do a lot of work. (i.e. I don't want to go through the hassle of applying for a patent myself.) 2) I don't care if other people use the algorithm. 3) Somebody, somewhere else may re-invent the algorithm and try to patent it, and then perhaps keep me and others from using it. I'm afraid of this and don't want it to happen. Why should I do? Forget about the whole thing? Wait for someone to sue me? Stick the source on my website and it will automatically become prior art? Release the source under a free software license (which one?) and stick an announcement on freshmeat? Do I contact some organization with a name like "Patents in the Public Interest?" Basically, I want to know how to keep this "invention" free. Thank you, Jeff PS Not that it matters, but the algorithm is the automatic list sorting routine used at mail-archive.com, which is a web service I run. Apparently, license-discuss is one of the users of this service.
Revised Degas License
Hi all:
Well, we've finally got people back in town long enough to revise the
license for "Degas". I have posted the revised version below.
You will notice that we did not split this license into two licenses (or
a license + commercial addendum). This was done for several reasons:
1. The total amount of the license that could be pulled consists of maybe
one or two sections plus Annex B (which is just some sample text). The
"verbiage needed to make it legally enforceable" actually constitutes most
of the document, sections 3-8 to be precise, which could not be taken out of
the license anyway.
2. There are really three ways that this license can be used:
non-commercially and uncertified, non-commercially and certified, and
commercially and certified. The only thing we could pull out would be that
which deals with the last case. In order to do this, we would still have to
add some verbiage to "link" to the additional addendum that would need to be
signed when used commercially, so the overall complexity of the license
would go up in doing this.
3. We've already spent more money on this license than we had initially
planned and at this stage we just can't justify the cost of restructuring
the whole thing.
We did, however, add a provision near the end of the license giving us
the ability to revise it later on. If there is sufficient demand from users
of our technology (and this license) to split it into two licenses or to
make any other changes in an effort to make is more user-friendly, then we
will be able to do so.
A few other changes: We added headers to each section to make it easier
to identify what each portion of the license is discussing. We also added
some definitions to the Grant of License section and we adjusted some of the
language to make it more precise.
So without further ado:
(Names have been changed to protect the innocent... :)
ZERATEC DEGAS PUBLIC LICENSE AGREEMENT
CONTRACTUAL TERMS OF USE AND NOTICES
IMPORTANT Â READ THIS ENTIRE AGREEMENT FULLY AND CAREFULLY BEFORE
DOWNLOADING OR USING ZERATEC¹S Degas ARCHITECTURE, SPECIFICATION AND
DOCUMENTATION: This following Agreement sets forth the terms and conditions
under which you will have Zeratec¹s permission to implement or make use of
Zeratec¹s Degas Architecture and Specification, more fully described later
in this License Agreement. In order to obtain or use Zeratec¹s Degas
Architecture and Specification, you must accept each and every term and
condition of this License Agreement, which is a binding legal contract
between you (either as an individual or entity) and Zeratec, Inc. By
clicking on the "I Accept" button, installing, copying, modifying,
redistributing, or otherwise using Zeratec¹s Degas Architecture and
Specification, you agree to be bound by the contractual terms of this
License Agreement. If you do not agree to the terms of this License
Agreement, click on the "I Do Not Accept" button and/or do not download,
copy or install the Degas Architecture, Specification and/or Documentation.
YOU AGREE THAT YOUR DOWNLOADING, COPYING, USE, PURCHASE, MODIFYING OR
REDISTRIBUTING OF THE ZERATEC Degas ARCHITECTURE, SPECIFICATION AND/OR
DOCUMENTATION ACKNOWLEDGES THAT YOU HAVE READ THIS LICENSE AGREEMENT,
UNDERSTAND IT, AND AGREE TO BE BOUND BY ITS CONTRACTUAL TERMS AND
CONDITIONS.
1. GRANT OF LICENSES:
Subject to the provisions of this License Agreement, Zeratec hereby grants
you permission under the terms of the following, world-wide, royalty free,
non-exclusive license, to the extent of Zeratec¹s own present and/or future
statutory and/or common law rights associated with patents and patent
applications, works of authorship including copyrights, copyright
applications and/or registration or "moral rights," and confidential
information including industrial and/or trade secrets ("Intellectual
Property Rights"), to use, implement, distribute and/or redistribute any
product, specification, or any derivatives of any products ("Licensed
Product") implementing and/or utilizing the proprietary Zeratec Degas
algorithm defined in any version of Zeratec¹s Degas Architecture
Specification ("Degas Architecture").
2. LICENSE RESTRICTIONS:
The permission and rights granted to you under Section 1 above are
conditioned upon your express consent and agreement to comply with the
following terms.
2.1 CAVEAT: This license does not give you permission or cover any right to
use Zeratec¹s trademarks, service marks and/or the words "Zeratec,"
"Degas," "Degas Certified," "Degas Compliant" or similar in connection with
Licensed Product.
2.2 PERMISSIONS FOR NON-COMMERCIAL USE : This license grants you permission
to conduct research and development utilizing Zeratec¹s Degas Architecture,
and to redistribute Licensed Product at (a) no cost to the recipient, (b)
only reasonable costs associated with the physical act of transferring a
copy and for the media involved, or (c) under a GNU General Public
Re: keeping patentable algorithm free
From: John Cowan [EMAIL PROTECTED] Date: Thu, 29 Jul 1999 08:29:54 -0400 (EDT) [EMAIL PROTECTED] scripsit: 1) I don't want to spend a lot of money or do a lot of work. (i.e. I don't want to go through the hassle of applying for a patent myself.) 2) I don't care if other people use the algorithm. 3) Somebody, somewhere else may re-invent the algorithm and try to patent it, and then perhaps keep me and others from using it. I'm afraid of this and don't want it to happen. Publish a description of the algorithm, openly dedicating it to the public domain. Make sure the publication is dated. That won't help you if a patent is already pending, but otherwise it makes the algorithm prior art. One easy and relatively inexpensive way to publish an algorithm with a legally verifiable date in the U.S. is to register it with the U.S. copyright office. You can send them a program listing, and they will basically file it with a timestamp. (Note that you are not required to register in order to obtain copyright--these days everything you write is automatically copyrighted--but it can help settle any legal disputes). You can then invoke the registration if you ever need to. The details should be somewhere under www.loc.gov (I first looked into this over 20 years ago--wow). Ian
Re: Notes on a license how-to
On Wed, Jul 28, 1999 at 20:07:40 -0600, Jacques Chester wrote: I got to thinking some about the license how-to thing. I *do* believe that a guide to selecting licenses *would* be useful. Have you taken a look at Mark Koek, "Free Software Licensing"? (See http://linuxtoday.com/stories/7414.html) Ray -- PATRIOTISM A great British writer once said that if he had to choose between betraying his country and betraying a friend he hoped he would have the decency to betray his country. - The Hipcrime Vocab by Chad C. Mulligan
Re: keeping patentable algorithm free
Ian Lance Taylor wrote: One easy and relatively inexpensive way to publish an algorithm with a legally verifiable date in the U.S. is to register it with the U.S. copyright office. You can send them a program listing, and they will basically file it with a timestamp. Sorry, not enough. For patent purposes, the invention must be described in openly available literature. Registration with a government agency doesn't cut it, as nobody (in practice) can obtain the listing. Publication on Usenet or the Web serves the necessary purposes: the algorithm must be *available* to persons learned in the art. -- John Cowan http://www.ccil.org/~cowan [EMAIL PROTECTED] Schlingt dreifach einen Kreis um dies! / Schliesst euer Aug vor heiliger Schau, Denn er genoss vom Honig-Tau / Und trank die Milch vom Paradies. -- Coleridge / Politzer
Re: keeping patentable algorithm free
Date: Fri, 30 Jul 1999 09:43:04 -0400 From: John Cowan [EMAIL PROTECTED] Ian Lance Taylor wrote: One easy and relatively inexpensive way to publish an algorithm with a legally verifiable date in the U.S. is to register it with the U.S. copyright office. You can send them a program listing, and they will basically file it with a timestamp. Sorry, not enough. For patent purposes, the invention must be described in openly available literature. Registration with a government agency doesn't cut it, as nobody (in practice) can obtain the listing. Publication on Usenet or the Web serves the necessary purposes: the algorithm must be *available* to persons learned in the art. Yes, you do need to do more than merely register it with the copyright office, and you are correct to point that out. I assumed that that had already been taken care of in this case since the algorithm in question is part of a free software package. However, as far as I know, publication on Usenet or the Web rarely provides a legally verifiable date. It's not like an appearance in a published magazine. I suppose you could try subpoenaing the records of deja.com or google.com. Ian
Re: keeping patentable algorithm free
Ian Lance Taylor wrote: Date: Fri, 30 Jul 1999 09:43:04 -0400 From: John Cowan [EMAIL PROTECTED] Ian Lance Taylor wrote: One easy and relatively inexpensive way to publish an algorithm with a legally verifiable date in the U.S. is to register it with the U.S. copyright office. You can send them a program listing, and they will basically file it with a timestamp. Sorry, not enough. For patent purposes, the invention must be described in openly available literature. Registration with a government agency doesn't cut it, as nobody (in practice) can obtain the listing. Publication on Usenet or the Web serves the necessary purposes: the algorithm must be *available* to persons learned in the art. Yes, you do need to do more than merely register it with the copyright office, and you are correct to point that out. I assumed that that had already been taken care of in this case since the algorithm in question is part of a free software package. However, as far as I know, publication on Usenet or the Web rarely provides a legally verifiable date. It's not like an appearance in a published magazine. I suppose you could try subpoenaing the records of deja.com or google.com. Ian Here is the answers from what I understand There are 2 problems 1- Prove that you are the first inventor In order to do so, you need something which gives you an official date. A simple way to do that is to register with any kind of copyrigh office. There are other protections. In France, you can send some kind of sealed envelope (enveloppe Soleau) to the Patent office. They will make a whole in the middle and never open it. It can be used as a very strong proof in case of trial. There are other ways to get the same result. This has been used by ATT. Take an article describing your invention. Compute an MD5 code from it. Then publish a list of MD5 codes in any newspaper. Even better : compute a big MD5 code from a list of MD5 codes and publish it as a classified (that's really cheap). Being the first inventor in the US enables to cancel a patent filed by someone else later (first to invent principle) Being the first inventor in Europe anables to use the process in case someone else files a patent later but does not allow to cancel it (first to file principle) 2- Make a document public Well, this is much easier actually. Just print the document and go to your local library. Give it to them and get some paper to prove later that you gave the document to your local library. If the title of the document includes some MD5 number, it makes it easier to proove that the content was what is is intended to be in case the local library loses the document. This trick is used quite often by multinational companies which go to Senegal (Africa) and put some kind of book, which looks normal outside but actually includes some secret patentable process, in very small libraries. The intent of such behavior is to keep things secret (patents force to publish), while still being protected in case someone gets a patent later. Because the document is public (a library is public), the process it decsribes will be considered as public prior art and any patent filed on the process will be cancelled in case of trial. There is a famous story saying that one day, Sony, Philips and Thomson representatives went the same day at a local library in the belgian countryside to ask the librart manager to certify that a certain article was displayed in the library a certain day. Jean-Paul. webmaster of freepatents.org and other sites PS. MD5 is a coding technique which generates a big number from a long article. It is very hard to generated a different article with same MD5 number. begin:vcard n:Smets;Jean-Paul tel;cell:+33-(0)662 05 76 14 x-mozilla-html:FALSE url:www.smets.com adr:;; version:2.1 email;internet:[EMAIL PROTECTED] x-mozilla-cpt:;0 fn:Jean-Paul Smets end:vcard
List archives
Are there any archives for this list? I'm particularly interested in discussion of not-quite-free licenses such as the BitKeeper license. -- J C Lawrence Life: http://www.kanga.nu/ Home: [EMAIL PROTECTED] -(*)Work (Linux/IA64): [EMAIL PROTECTED] ... Beware of cromagnons wearing chewing gum and palm pilots ...
Re: Notes on a license how-to
I got to thinking some about the license how-to thing. I *do* believe that a guide to selecting licenses *would* be useful. I was planning on writing that document. The following is the table of contents I thought it should have, as I wrote it two days ago: 1 Introduction Just stating the reasons for writing the HOWTO and some other metainfo. Stating that the author personally preffers to use GPL but tried to be completely unbiased and objective in this document. 2 What is free software? This section attempts to define free software. Being gratis and being free are different things. The typical stuff. 2.1 Debian Free Software Guidelines Just a short mention of DFSG. Links provided to Debian's web site. 2.2 Open Source Initiative Explaining that Open Source and free software are the very same thing, and telling the motivations and history behind OSI. Links to OSI's site. 2.3 Free Software Foundation Covering the FSF and explaining their views and motivations. Links to FSF's site. 2.4 Freeware and Public Domain software Mentioning how being freeware and public domain is not the same as being free. 2.5 Why Free Software? Just a short section explaining both the ethical and practical reasons why free software is superior. Links to The Cathedral and the Bazaar, The Magic Cauldron and similar essays (send me suggestions). 3 Free Software Licenses This section attempts to explain popular licenses. It also provides examples of the most popular programs that use a given license. 3.1 GNU General Public License Explains the GPL. After that, mentions common arguments used against it: linking with non GPL software, is it really freedom, it is a virus, it does not define derivative works clearly (or: will it hold in court?). 3.3 BSDish licenses Explaining them. Mentioning the problems with the advertising clauses and the usual `anyone can fork and go propietary' problem. 3.4 Other licenses Covering briefly the Perl Artistic License. What other licenses should we include? 4 Comercial free software A common topic of discussion. Using/developing/supporting free software for monetary gain. Also mentioning cases and the licenses used when free software has been used comercially. What other Licenses should we conver? 4.1 Netscape Public License Explaining their license and problems with it. 4.2 Apple Public Source License Same as 4.1 for Apple's case. 4.3 Comercial software around the GPL Mentioning the classical cases such a Linux distributions or Cygnus. 5. Practical considerations Just some suggestions for people choosing licenses. The conclusions of the HOWTO. What else would you add here? 5.1 Problems with the GPL Just a short note so people avoid problems with it. This could mention the situation with KDE. 5.2 Don't create your own license Just asking people to try to use an already existing license instead of creating their own. That is it. Did I leave any important things out? * "Ranking": popularity in terms of percentage representation in licenses I believe this would be hard to measure. All I can think about is checking those percentages in Freshmeat, but I am not sure how representative it would be. Besides, that is information that is constantly changing. In my opinion, the HOWTO should not include such information. I believe it would be very interesting to have it, but I think it belongs more to independent studies than to the License HOWTO. Is someone currently working on the HOWTO? I will continue working on it unless someone else is doing it already. Please let me know. Alejo. -- The mere formulation of a problem is far more essential than its solution. -- Albert Einstein.
Put it in laymen's terms
Hello all!
Would someone be so kind as to make clear for me what the difference is
between a system call, and the use of a function in a program.
These terms are used to describe when something is or isn't a derived work
for purposes of copyright.
Bruce has stated that copyright law recognizes this distinction. I haven't
read this in any cases. After you all have defined what these terms mean,
can someone point me to case law that makes this distinction? Thank you.
--
NatePuri ("natedawg")
Certified Law Student
McGeorge School of Law
Sacramento, CA
[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.ompages.com
PGP: http://www.ompages.com/PGP.html
UIN: 43504034
IRC: ompages.com #ompages
PGP signature
Re: Put it in laymen's terms
Would someone be so kind as to make clear for me what the difference is between a system call, and the use of a function in a program. These terms are used to describe when something is or isn't a derived work for purposes of copyright. Bruce has stated that copyright law recognizes this distinction. I haven't read this in any cases. After you all have defined what these terms mean, can someone point me to case law that makes this distinction? Thank you. Layman's terms are inadequate to express legal realities. Surely you know that (based on your sig.) Maybe I can explain the basic aspects... Copyright law concerns distributing copies of published works in portion or entirety. Cutting and pasting a function (or even retyping from a book) when writing a program creates a "derived work." The GPL says, "this license lets you use the software only if you agree to place the GPL on all derived works." That's all pretty sinple and clear. As Bruce replied in one of the Slashdot responses, it is possible to take copyrighted, GPL'ed source material, put it into a "library", and then create a program which makes use of that library. (By "makes use" meaning "calls functions in that library.") This creates unclear, debatable issues legally and ethically. Frankly, I'm interested in learning more about the ethical opinions of Bruce, because we can debate the legal issues a long time before any court system will render a stable opinionAnd most members of civilization should be making decisions on ethical grounds, not legal ones... Legally, the application making calls into the GPL'ed library may or may not be a derived work, depending on how it was developed. If you copied any software from the GPL'ed software, from a legal standpoint, it is clearly a derived work. It is illegal and unethical to not comply with the terms of the GPL. But, if you did not copy the GPL'ed software, and further, even if you did not even touch or see the GPL'ed software when developling your application, then legally it is clearly not a derived work. This is sometimes called "cleanroom" development. There is some legal fuzziness if you used the GPL'ed software for testing purposes. Then it may or may not be seen by the courts as a derived work. Ethically, there are some issues for cleanroom developed software, even if there are no legal onesAnd I posed some ethical questions to Bruce in a message to this list several days ago, in the "gpl backlash" thread. Bruce's opinions are very well respected, and I want to know how he thinks about the situations I posed. Then he was rudely :-) interrupted by the Ask Slashdot activity, and having his servers slashdotted... Nothing like trial by fire to keep programmers on their toes :-) Hopefully, he will get a chance to get back to my questions. I'll repost them next week if I don't see a reply.
Re: Put it in laymen's terms
Copyright law concerns distributing copies of published works
in portion or entirety.
Thanks for the lesson ;).
Cutting and pasting a function (or even retyping from a book)
when writing a program creates a "derived work."
You haven't answered my question. What is a function?
The GPL says, "this license lets you use the software only if
you agree to place the GPL on all derived works."
You're telling me about law again. What is a function? What is a system
call?
Thank you.
--
NatePuri ("natedawg")
Certified Law Student
McGeorge School of Law
Sacramento, CA
[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.ompages.com
PGP: http://www.ompages.com/PGP.html
UIN: 43504034
IRC: ompages.com #ompages
PGP signature
Re: keeping patentable algorithm free
If you want to ensure the algorithm is prior art against any future patents, the strongest (but more expensive) solution is to use something called a "statutory invention registry" provided by the patent office. Its essentially a purely defensive patent--look at the PTO web site for a bit more information. You can't use it to sue, but can use it to invalidate or prevent anyone else from getting a patent on the same or similar subject matter. You need to make sure there isn't a patent out there that already covers it, but you can do that free at the IBM site (www.patents.ibm.com) or at the PTO web site (www.uspto.gov). Otherwise, its (relatively) cheap and self-enforcing. This may be useful for other underlying patentable algorithms still out there in GNUland. (I know they --shouldn't-- be patentable, but its happening whether we like it or not.) There is a more serious concern that the algorithms everyone thought were free could start popping up as patents over the next few years given recent changes in the law, and that could spell big trouble for free licensing. Doug -- Student, The George Washington Univ. Law School [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Put it in laymen's terms
On Sat, 31 Jul 1999, Nate wrote: You're telling me about law again. What is a function? What is a system call? Thank you. Sorry about that. Sometimes people do miss the question. A function is a contained piece of code called by some other piece of code. A system call is a request made to the operating system to perform some action. It may ultimately call a function inside the operating system, but system call "functionality" is generally hidden from the user. Rob Levin Head of operations, Open Projects "Open Source, Open Technology, Open Information"
Re: Notes on a license how-to
Hello all; I got to thinking some about the license how-to thing. I *do* believe that a guide to selecting licenses *would* be useful. It's a reasonable thing to look at. As I've said before: there's no reason why hackers should *have* to be lawyers too. Of course, some of us enjoy the fiddly grey technicalities that are the very soul of the Law, as this list demonstrates. But I doubt that all hackers would. I was planning on writing that document. Good to see. The following is the table of contents I thought it should have, as I wrote it two days ago: Two days ago? 1 Introduction Just stating the reasons for writing the HOWTO and some other metainfo. There is a standard, generally accepted format for HOW-TOs which is expected by the LDP. I note that metainfo is usually top of most HOW-TOs (whereas I would have put them at the bottom ... oh well ... hackers thinking that readers are computers :). Alas, I do not know sweet buckley about SGML or the LinuxDoc/Thingamajig DTD that is used. Stating that the author personally preffers to use GPL but tried to be completely unbiased and objective in this document. Fair enough. 2 What is free software? This section attempts to define free software. Being gratis and being free are different things. The typical stuff. I don't think this absolutely necessary. Might be better to include "more information" links right up the top in the intro, along the lines of "if you are a suit or lawyer unfamiliar with the history, philosophy or general hackishness of Free Software and Open source, press 2 now ..." A HOW-TO is (IMHO!) *meant* to be a pared-down source of information. It presents a set of information aimed at informing the reader on how to achieve no more than a very small handful of goals (connect to the net, set up printing, etc). I think we need to avoid bloat and vision erosion by asking ourselves: "What *exactly* does a License HOW-TO do?". And I venture the opinion that it might well be that a License HOW-TO would be a sharp, concise guide to the issues of licensing to openness/freedom and to the licenses themselves. 2.1 Debian Free Software Guidelines Just a short mention of DFSG. Links provided to Debian's web site. Again, this can be moved into an introduction or just cut out altogether. 2.2 Open Source Initiative snip 2.3 Free Software Foundation snip A sure way to attract the licking toungues of flame, I suspect ... again, these might be better as references than as entire subjects. Remember, we are striving to assist hackers chose the ideal license for their code. We can partially assume that they are aware of the ideological landscape of the hacker world. If they are not, some carefully-selected references will enlighten them. This is the web - think reference, not replication. 2.4 Freeware and Public Domain software Mentioning how being freeware and public domain is not the same as being free. This can be folded into a larger section on the legal underpinnings of OSS licenses (into OSS I fold Free Software from herein, apologies to purists). The FSF has some excellent (if somewhat GPL-centric) material on the many *wares and how they relate to Stallmanist capital-F Free Software. 2.5 Why Free Software? Just a short section explaining both the ethical and practical reasons why free software is superior. Links to The Cathedral and the Bazaar, The Magic Cauldron and similar essays (send me suggestions). Again, cull this and fold a link or two into the intro. I note in passing that I will soon publish an essay that does a very rough quantitative examination of ESR's largely qualitative claim. 3 Free Software Licenses This section attempts to explain popular licenses. It also provides examples of the most popular programs that use a given license. Yes ... no problems with introducing the licenses. But remember that *all* of the licenses are written with one eye on a particular strain of hacker ideology, and another one on The Law. Really, every license that is Gee-It's-Free-But-Just-Not-Exactly-The-Same-And-Almost- Wholly-Incompatible-With-Uhm-Er-The-GPL-Say has just found a combination of ideology and legal laxity or strength that suited the author(s). That means it may be worth introducing these things briefly. Ideology can be referenced out, as I have already noted. There exists hacker ideology in volumes that would level several mid-sized forests in its printing. But the legal stuff is trickier, and less easy to find material on. A License HOW-TO might be just the document of most use in defining these legal issues and explaining them to the Need-To-Know Hacker. As an aside, a matrix-style classification of licenses may be more effective than multiple lists. Put on one axis Ideology (from "Free, dammit" to "Microsoft") and on the other, Legal Principles (Copyleft to EULA). It's not quantitative, but it might give a feel for the licensing
Re: Put it in laymen's terms
On 1 Aug 1999 [EMAIL PROTECTED] wrote: However, you can also take Linus' note as an interpretation of the scope of the GPL and not an exception at all. If you accept that another person can reinterpret phrases like "dervived work", and you also accept that this reinterpretation can apply to code written by other people, then the GPL is for all practical purposes nonexistent. If someone wants to violate it, they just have to redefine "redistribution", "derived work", etc. so that their violation is not really a violation. It doesn't make sense that one person can reinterpret what a phrase in someone else's license means.
Is this license open source?
I've been thinking about a license I've been tempted to use: This program is under the GPL, v2. You may also use it under the XFree license as long as you aren't Theo de Raadt or Tom Christianson. * I would guess that it's non-free, which leads me to the weird conclusion that adding further permissions to a free license can make it non-free. * Yes, I've stopped reading gnu.misc.discuss. And I'm better now. Mostly. -- David Starner - [EMAIL PROTECTED] (alternately [EMAIL PROTECTED]) "I would weep, but my tears have been stolen; I would shout, but my voice has been taken. Thus, I write." - Tragic Poet
Re: Is this license open source?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 1 Aug 1999, David Starner wrote: I've been thinking about a license I've been tempted to use: This program is under the GPL, v2. You may also use it under the XFree license as long as you aren't Theo de Raadt or Tom Christianson. * I would guess that it's non-free, which leads me to the weird conclusion that adding further permissions to a free license can make it non-free. The GPL is a free software license, so if you can use it under the GPL, it *is* free. Restricting who can use it under the XFree license doesn't diminish any of the permissions granted under the GPL. The interesting thing is that this license is *not* an open source license. (The OSD specifically prohibits discrimination against individuals or groups.) So the set of open-source licenses is not quite a superset of the set of free software licenses. -BEGIN PGP SIGNATURE- Version: GnuPG v0.9.7 (GNU/Linux) Comment: PGPEnvelope - http://www.bigfoot.com/~ftobin/resources.html iD8DBQE3pQvb2GOwREX5+xQRAsPBAJ9hND9FID2x9gDtlRA2yWo+pIlJ5gCfdu+L 151wCKQtMWRONGsuqDogcek= =hOB5 -END PGP SIGNATURE-
Re: Is this license open source?
From: Mark Wells [EMAIL PROTECTED] The interesting thing is that this license is *not* an open source license. (The OSD specifically prohibits discrimination against individuals or groups.) So the set of open-source licenses is not quite a superset of the set of free software licenses. No, sorry. Although the Open Source campaign differs from the ideals of free software, the Open Source _Definition_ defines a free software license. The Open Source Definition was written as the "Debian Free Software Guidelines" (DFSG). The DFSG was part of Debian's social contract with the free software community, which was drafted by me and refined with the help of the Debian developers until it was voted their project policy. We had decided that Debian would be 100% free software, so we needed a definition of free software. OSI was formed 8 months after this. Once you say "You may use this software under the terms of the GPL.", you have an Open Source license, the GPL. Any additional text is part of another license entirely, a modified BSD license that is not compliant with the Open Source definition. But we allow any number of licenses, it only matters that _one_ of them is an Open Source license. Thanks Bruce
RFC soon on essay Does Free Software Production in a Bazaar obey the Law of Diminishing Returns?
Hello there; I'm sending this email to a number of people. The majority of you have already been asked in the past about what I am going to describe. Namely, I have asked most of you to perform a peer review of an essay about economics and free software. Some of you have *not* been asked before. This may have been because I have not thought before to contact you, because I have been unable to reach you, or because you are receiving this message on a public forum. If this irks you or if you feel I have unnecessarily wasted your time, I would like to apologise, and invite you to email me saying "don't email again, dammit!" :) As a student in the International Baccalaureate program, I am required to complete an "Extended Essay"; a mini-thesis of sorts. The body of this essay is limited to 4000 words. I dithered around with a number of topics in planning for this essay, many of them wishy-washy and poorly defined. I've arrived at a point where I am combining two of my great interests - Economics and Free Software - into a clearly defined, quantitative research paper. The topic of this essay is "Does Free Software Production in a Bazaar obey the Law of Diminishing Returns?". Essentially, the essay seeks to establish a chain of reasoning that links some of Eric S. Raymond's qualitative hypotheses with standard Economic theory to allow for quantitative testing. First, Brook's Law is introduced. Through comparison of statements, analogical comparison and graphical comparison, Brook's Law is taken to be *equivalent* to the Law of Diminishing Returns. In Economics, the LODR has a very specific meaning, and has been thoroughly analysed. There are key traits which are easy to identify in appropriate sourse of data, which makes it an ideal subject of study in relation to OSS. Secondly, Raymond's Bazaar hypothesis is introduced. The Bazaar itself is outlined, a list of "signature traits" (which may be incomplete or incorrect) was extracted from the CB paper. Raymond's assertion that a project following a Bazaar methodology can break Brook's Law is introduced. It is explicitly reasoned that this means, in turn, that Raymond's hypothesis implies that Bazaar projects can break the LODR. Thirdly, the GNOME project is identified as the source of data. It is established as being a large-scale Bazaar-style project. Fourthly, data extracted from GNOME's CVS system is used to generate a series of graphs for analysis. These graphs can help to demonstrate the possible conclusions. Fifthly, the possible conclusions so far are: * That ESR is completely correct, that Free Software *does* break the LODR and that it represents a new economic phenomenon in production * That ESR is completely wrong, that Free Software *does* obey the LODR, it just happens to be far more 'scaleable' than the traditional "Cathedral" * That ESR, unaware of the economic framework in which this can be viewed, does not realise that Brook's Law is the same as the LODR; and has therefore failed to distinguish between production in the Short Run (where the LODR applies) and the Long Run (where it does not). On a preliminary viewing of the data, there is significant ambiguity. As I complete my set of graphs in the next few days, I may find that one or the other alternatives is true (or indeed, come to a completely unexpected conclusion), but I suspect that the ambiguity will remain because the GNOME project is too small to test the limits of Bazaar scalability. My own personal view - and this cannot yet be backed by numbers, so caveat emptor - is that the second and third conclusions are true. This is because marginal costs *do* exist in Free Software, because they *do* rise steadily. Also, the LODR does not apply in Long-Run situations, but frankly, defining the difference between the Short and Long Run in Free Software is difficult, as it relies on the mapping of the Economic categories of Land, Labour, Capital and Enterprise to the resources being manipulated. These issues will be shunted into an appendix for deeper discussion, in order to help reinforce the necessary economic framework. So what does this have to do with *you*? Well, if you've read *this* far without snoozing, thanks :). I feel that as well as helping me complete my course, this paper will act as a first step towards more rigorous, solid and dependable research into the free software movement. In particular, it will do a first, rudimentary test of ESR's wholly qualitative theories. Several of those assisting me or who have agreed to review this work expressed interest on those grounds alone! What I have done so far is to brief you on the essay itself. You now know what to expect, so hopefully you will have some time for the core ideas to bounce back and forth in your heads. I also suspect that you will be prepared to answer many of my claims and chains of reason with good critiques. I am hoping that, when you receive my "beta draft" next week, you will be
RFC soon posting
Hello all; So far, license-discuss has yielded my best response. I've posted to several newsgroups, but usenet being as it is I don't expect too many timely responses. To answer a mild criticism, which has already arisen; namely, "such a paper is off-topic to this list". I emailed the RFC notice from a list I have been compiling over the lifetime of the paper. On reflection, I believe license-discuss was added primarily because there are sections of the essay that try to explain the legal foundations of Free Software licensing. These sections need to be complete and concise, and I know of no better forum to vet those sections. As for other components, my profuse apologies for being a bad list-citizen. I didn't fully grok the consequences of posting to the wrong forum, so if I have wasted anybody's time I'm sorry for doing so. Thanks to everyone who has written so far; JC. - Sent using MailStart.com ( http://MailStart.Com/welcome.html ) The FREE way to access your mailbox via any web browser, anywhere!
RFC soon posting
Hello all; So far, license-discuss has yielded my best response. I've posted to several newsgroups, but usenet being as it is I don't expect too many timely responses. To answer a mild criticism, which has already arisen; namely, "such a paper is off-topic to this list". I emailed the RFC notice from a list I have been compiling over the lifetime of the paper. On reflection, I believe license-discuss was added primarily because there are sections of the essay that try to explain the legal foundations of Free Software licensing. These sections need to be complete and concise, and I know of no better forum to vet those sections. As for other components, my profuse apologies for being a bad list-citizen. I didn't fully grok the consequences of posting to the wrong forum, so if I have wasted anybody's time I'm sorry for doing so. Thanks to everyone who has written so far; JC. - Sent using MailStart.com ( http://MailStart.Com/welcome.html ) The FREE way to access your mailbox via any web browser, anywhere!
Essay RFC delayed.
Hello again; As it happens, I have been unable to meet my goal of delivering the completed essay this weekend. This was a result of classic scheduling errors - the time-vacuum and the job underestimation. Instead of the complete essay, I have instead included those sections which *are* ready for critique and review. Please note that these are not the *meat* of the essay. They are merely the qualititative framework from which the quantitative will hang. I will strive to deliver the rest of the essay this week. As my programming skills are poor to minimal, I cannot predict when I will work out the means by which the needed data will be coaxed into a usable form. I am currently punting on the "sleep on the problem" approach to some currently intractable problems. Of course, they are of the "one step forward, two steps back" variety. In any case, enjoy and review. Thankyou all again; JC. Title: Does Free Software Production in a Bazaar Obey the Law of Diminishing Returns? Abstract Free Software is defined. Brook's Law is introduced as a limiting factor in software production. A parallel is drawn between Brook's Law and the Law of Diminishing Returns. Eric S. Raymond's "Bazaar" model is introduced as a possible exception to the rule. Statistics gathered from an existing Free Software project are used to demonstrate the nonadherence of "Bazaars" to the law of diminishing returns. A possible flaw in Raymond's hypothesis is identified, and an economic alternative is offered. Contents Those items with an asterisk next to them are included in this copy of the essay. Abstract * Contents * Introduction * Free Software Defined * Brook's Law and The Law of Diminishing Returns * The "Bazaar" Introduced * The GNOME Project * Examination and Discussion of GNOME Data Conclusion Endnotes * Bibliography Appendices Acknowledgements and Thanks The Opensource Definition Caveats Economic Principles in Free Software Introduction This essay seeks to examine the rapidly emerging production method of "Free Software" or "Opensource Software". It outlines analogues between Economic theory and Software Engineering in order to bring economic analysis to bear on the area. Specifically, it aims to provide a quantitative analysis of what has until now been primarily examined in a qualititative way. Free Software has existed in one form or another since the very early days of computing, but very little attention has been paid to it until recently. Many Free Software projects have achieved significant or even dominant positions in their marketplace, and more firms are starting to utilise or release Free Software. Free Software Defined Definitions of Free Software (also know as "OSS", for Open Source Software) are typically framed in two perspectives: Ideological and Legal. The two major ideological principles underlying Free Software are the protection of user/programmer choice, and the belief that the best solutions must be shared. The first principle arose from Richard M. Stallman's dismay at the rise of proprietary software as the dominant format. Stallman believes that proprietary (also known as closed-source) software is a violation of the individual's right to choose other packages. He argues that access to the sourcecode grants freedoms to modify and augment without being "locked in" to one company's whims. Further, he argues that sourcecode access gives users a choice to go their own way, in defiance of the company's wishes should they be detrimental. The second principle, that good solutions should be shared, arises from the so-called "Hacker Culture". Within this culture, brainpower is seen as a limited resource, which should not be wasted on unnecessarily reinventing the wheel. It is reasonable, therefore, that all solutions (embodied in sourcecode) should be available for anyone to use. The corrollary is that withholding solutions (or source) is effectively evil, inasmuch as it is wasteful of resources. The legal foundations of Free Software stem from a careful blend of Contract and Copyright laws. Free Software Licenses use the principles of Contract law to create their terms. Typically, these ensure that an author's version of the source is always available and that any modification made by anyone is likewise available under the same terms. Some licenses go so far as to impose these terms onto software where opensource code has been added as an external source. If the user doesn't agree to the License, the law of Contract renders the terms of the License effectively powerless without punitive terms. However, at this point, standard Copyright laws take effect, and the user is granted no rights whatsoever. There is significant coercion, then, to accept the terms of the License on a contractual basis. To place Free Software in an economic framework is considerably more difficult, but quite
Re: RFC soon on essay Does Free Software Production in a Bazaarobey the Law of Diminishing Returns?
On Sun, 15 Aug 1999, Eric S. Raymond wrote: 2. Brooks's Law is not precisely *equivalent* to LODR, but is rather a special case of it involving *particular* nonlinear scaling phenomena. Accordingly, one may assert that the bazaar mode repeals Brooks's Law without making any commitment about the applicability of the LODR in general. One interesting implication of Brooks's Law is that as N (the number of developers) gets sufficiently large, the cost of management and coordination (which is a function of N^2) ends up exceeding the productivity of the developers (which is a function of N) and nobody produces anything. I suppose the developers spend all their time sitting in meetings trying to explain Brooks's Law to their boss. The issue of quadratic paths of communications. It's one of the suggested causes of Brook's Law. If we look at the real-world experience of bazaar-style projects, this doesn't happen. Adding more developers, or even more end users, * always* benefits the project--if nothing else, they'll find bugs faster. This suggests three possibilities: 'Always' is a dangerous word. 'So far' might be a safer bet for now. So far the favoured solution is the Bazaar being a highly scalable means of production. This means it has limits; but where one goes after creating entire operating systems is beyond me. 1. Bazaar-style projects really are immune to Brooks's Law, because someone sprinkled pixie dust over them or something. I seriously doubt this. Seems akin to saying that "Friends" gets higher ratings for happy peppy reasons; which is patently rubbish. "Friends" gets high ratings because it has highly attractive people behaving like children. 2. Bazaar-style development is so scaleable that we've never even approached the kind of 'critical mass' that it would take for the cost of management to exceed the productivity of development. Internet technologies make the bazaar scale even better. We'd need millions of developers to start to notice the management overhead that Brooks predicted. I don't know about *millions*. But this seems to be the best bet at the moment. It may well be that true Bazaar projects will never reach this point: pressures of organisational overhead will cause fragmentation into smaller projects. Rather than everything being subsumed by the GNU project as a single hierarchy, for example, a typical linux distro is the result of endless autonomous units. The pressure to subdivide spontaneously creates a structure that seems not unlike a mandelbrot fractal. 3. It's so easy for a bazaar project to divide up the labor involved in a project that the largest bazaars tend to break up into smaller task-oriented teams. (For example, instead of porting Linux to the PowerPC chip by having Linus say "OK, all you kernel hackers out there, I want you all to buy a PowerPC and start porting the kernel", the Linux developers handed the task off to a team that had PowerPC experience.) Well, there you go. If I got ESR right, the labour-division thing is handled by independent action and the parallel handling of vertical problems. So a large bazaar never reaches critical mass; it recognizes, in an adaptive-system way, that it's trying to do too much, and breaks up. One disadvantage of this process is that if the pre-breakup stresses in the group are aligned the wrong way, it may lead to forking. Forking is important and healthy, in my view. Indeed, if nanotechnology delivers on its promises, forking offers a glimpse of how future society will work. Don't like your government's laws? Space colonies are cheap. Fork off from your current one to a new one. Enough dreaming. JC.
Re: Essay RFC delayed.
Oh, and btw: As wild as this sounds, I am starting to get ground into the dirt by the programming involved in getting this project to Just Work, dammit. If anyone can help me, email me, quick! :) JC.
Re: RFC soon on essay Does Free Software Production in a Bazaar obey the Law of Diminishing Returns?
X-Eric-Conspiracy: There is no conspiracy *Coughs politely* Jacques Chester [EMAIL PROTECTED]: Fifthly, the possible conclusions so far are: * That ESR is completely correct, that Free Software *does* break the LODR and that it represents a new economic phenomenon in production * That ESR is completely wrong, that Free Software *does* obey the LODR, it just happens to be far more 'scaleable' than the traditional "Cathedral" * That ESR, unaware of the economic framework in which this can be viewed, does not realise that Brook's Law is the same as the LODR; and has therefore failed to distinguish between production in the Short Run (where the LODR applies) and the Long Run (where it does not). My take on the situation differs from any of these three :-). I was wondering how you'd view an outsider's slant of your specialty. Those possible conclusions were, of course, *possible*. The caveat still stands that they may be wholly incorrect (for several reasons). I'm not familiar enough with the technical literature on LODR to form a firm judgement on whether Brooks's Law is equivalent to LODR. My gut reaction is one of skepticism. I'm afraid that, having delivered a sermon on quantitatively testing your qualitative assertions, my own attempt to draw approximation between Brook's Law and the LODR is itself qualititative. Hypocrisy of the highest level, and great fodder for the Caveats appendix. I also want to point out that I do not assert anywhere in my writings that open-source development is immune to LODR -- for the very good reason that I would coinsider any such claim patently ridiculous! So would I, and so would any economist. That's why, if a relationship between Brook's Law and the LODR is established, the subject ought to be investigated. Even if the answer is deadly dull, it's worth checking anyway :) I'll put the case more positively. I strongly suspect the following things: 1. Bazaar-mode development *is* susceptible to LODR effects, but (in your own words) "happens to be far more 'scaleable' than the traditional cathedral". This, in fact, is almost exactly how I would have phrased my own answer if the question had come up before. The preliminary Total Programmers vs Average Total Output seems to concur with the "highly scalable" conclusion. To the naked eye, it seems to be a slight curve upwards, and this curve itself seems to match the beginnings of a stock-standard LODR curve. But the gotcha is simple to pick. We cannot say at all that it *is* the beginning of an LODR graph, because for all we know it could be any of an infinite set of graphs with that beginning. It is just that we *expect* to see what we are seeing. And that's all I can say. Despite the selection of GNOME as a data source, I am afraid that my conclusions will be tentative, at best. While some elementary guesses might be hazarded, the data set is just too small to make any concrete statements. Alas, GNOME is one of the largest community-based OSS projects that uses CVS. I would have liked to have used GNU or Linux data, but such data is not available in the high resolution of a CVS logfile. 2. Brooks's Law is not precisely *equivalent* to LODR, but is rather a special case of it involving *particular* nonlinear scaling phenomena. Accordingly, one may assert that the bazaar mode repeals Brooks's Law without making any commitment about the applicability of the LODR in general. And, conscious of the theory of knowledge, I too would suspect that Brook's Law is a special case. In an earlier draft, I said so. For simplicity, however, such a reference is removed from the main body of the essay and into the Caveats section. This is for efficiency of reason. Logic, of course, is the act of creating perfect structures from imperfect ones, which implies a certain degree of fitting fuzzy cubes into velcro circles. It doesn't always work cleanly, and stuff sticks where it shouldn't. For convenience, and in a conscious decision, we choose to carve off the edges so that the basics fit. With the essay, I seek to create an equivalency between the LODR and Brook's Law. While I do think Brook's Law is one special instance of the LODR, I also think it inherits enough of the core function to be "approaching equivalence". No, it is not the same. But, for the purposes of the main body of the essay, it will be. Why? Because this allows us to bring to bear some of the economic analysis that we use when dealing with the LODR. I am only a student of the most elementary and fundamental economic theories, but even I have a toolkit that seems to fit the problem at hand. This issue will most certainly be addressed in the Caveats. Indeed, the Caveats might be more numerous than any other part of the essay. Thanks again; JC.
Re: Essay RFC delayed.
Jacques Chester wrote: [...] Brook's Law [...] BTW, it's Brooks's law (not Brook's law or Brooks' law); the current draft consistently gets this wrong. Projects So what are projects, and what are their factors? Brooks example can be characterised as a project with two factors, being programmers and managers. If we hold managers constant, and increase programmers, LODR tells us that productivity will increase less each time another programmer is added. Actually, Brooks's law says that productivity will *decrease* after a certain point, not just increase less. With the n**2 communications costs, eventually you reach a point where adding resources is bad not just relatively but absolutely. -- John Cowan http://www.ccil.org/~cowan [EMAIL PROTECTED] Schlingt dreifach einen Kreis um dies! / Schliesst euer Aug vor heiliger Schau, Denn er genoss vom Honig-Tau / Und trank die Milch vom Paradies. -- Coleridge / Politzer
Re: RFC soon on essay Does Free Software Production in a Bazaarobey the Law of Diminishing Returns?
Jacques Chester wrote: Forking is important and healthy, in my view. The trouble with forking is that it divides attention, which is the true scarce resource. The World Wide Web Consortium, for example, is fiddling around with its structure now, experimenting with subdividing and re-merging, but the fact is that it can only do so much with the available minds. (The fact that other minds aren't available is a separate problem). -- John Cowan http://www.ccil.org/~cowan [EMAIL PROTECTED] Schlingt dreifach einen Kreis um dies! / Schliesst euer Aug vor heiliger Schau, Denn er genoss vom Honig-Tau / Und trank die Milch vom Paradies. -- Coleridge / Politzer
Re: RFC soon on essay Does Free Software Production in a Bazaarobeythe Law of Diminishing Returns?
On Tue, 17 Aug 1999, Jacques Chester wrote: The issue of quadratic paths of communications. It's one of the suggested causes of Brook's Law. Mathematically, N^2-N is only the number of *two-ended* communication paths. I could see several situations in which what would matter would be the number of possible *subsets* of the number of developers, which would be a much scarier 2^N. One extremely important effect we're not considering is the collaborative amplification of creativity: when people work on a project together instead of breaking it into pieces and taking one piece each, they share ideas that would otherwise never be implemented. As someone else who's name I don't remember said, "If I give you my idea and you give me your idea, we each have two ideas, and together we have four." This could turn out to be an even more significant contributor to bazaar-style development than the scaleability issue. 'Always' is a dangerous word. 'So far' might be a safer bet for now. So far the favoured solution is the Bazaar being a What I meant was that adding more people will never slow down development. (My interesting observation about Brooks's Law was specifically that for sufficiently high values of N, the developers will produce *nothing at all*.) The new people might turn out to be totally useless, but the additional cost per new person is so small that the free-rider problem is negligible. If one out of a hundred people on the project's mailing list actually contributes anything to the project, the mailing list is doing its job. The only cases in which this becomes a problem are those in which the free riders actively interfere with development by, for example, starting flame wars on the mailing list, spamming the newsgroup, wasting bandwidth on the FTP site, etc. In that case, the core development group (once it realizes it can't restore order) will typically adapt to the situation by moving to a new mailing list, for example. 3. It's so easy for a bazaar project to divide up the labor involved in a project that the largest bazaars tend to break up into smaller task-oriented teams. (For example, instead of porting Linux to the PowerPC chip by having Linus say "OK, all you kernel hackers out there, I want you all to buy a PowerPC and start porting the kernel", the Linux developers handed the task off to a team that had PowerPC experience.) Well, there you go. If I got ESR right, the labour-division thing is handled by independent action and the parallel handling of vertical problems. I didn't know ESR said that. I was thinking that in a group that's not being forced (by a phalanx of whip-cracking PHBs) to build an entire project from the ground up, it would be natural to build it in pieces that communicate with well-defined APIs. The *interpersonal* communication paths only exist within each subgroup. So if N developers break into M subgroups, they go from N^2 two-ended paths to N^2/M paths. The communication between groups is handled by the APIs in their respective projects, as well as some higher-level coordination through Freshmeat-style shared resources. Forking is important and healthy, in my view. Indeed, if nanotechnology delivers on its promises, forking offers a glimpse of how future society will work. Don't like your government's laws? Space colonies are cheap. Fork off from your current one to a new one. Or, as Heinlein said, "The best thing about space travel is that it made it possible to go elsewhere."
Re: RFC soon on essay Does Free Software Production in a Bazaarobey the Law of Diminishing Returns?
Richard Stallman wrote: Some of us have other goals. My principal goal in writing GNU Emacs, GCC and various other programs was to produce a complete free operating system, so that we could have the freedom to form a community. A complete free operating system *of sufficiently high quality* (not the highest possible quality, but better than Windows, anyway). Otherwise, any old hack would have done the job. -- John Cowan http://www.ccil.org/~cowan [EMAIL PROTECTED] Schlingt dreifach einen Kreis um dies! / Schliesst euer Aug vor heiliger Schau, Denn er genoss vom Honig-Tau / Und trank die Milch vom Paradies. -- Coleridge / Politzer
Re: RFC soon on essay Does Free Software Production in a Bazaarobeythe Law of Diminishing Returns?
Back to it!
Mark wrote:
On Tue, 17 Aug 1999, Jacques Chester wrote:
The issue of quadratic paths of communications. It's one of the
suggested causes of Brook's Law.
Mathematically, N^2-N is only the number of *two-ended* communication
paths. I could see several situations in which what would matter
would be
the number of possible *subsets* of the number of developers, which
would
be a much scarier 2^N.
It gets hairy and fast. Hello, Chinese Whispers. But on
the other hand, network systems work better than
hierarchical systems in many situations. While they
are not as (apparently) transparent or (apparently)
efficient, they are inherently more effective. Think
market versus command economy, think open source
project versus command-system corporations, think
Bazaar versus Cathedral.
A general lesson that may be learned from Bazaar
projects is that the blurring of Enterprise and
Labour is healthy. Deferral to a Greater Vision is
still necessary, but so is everyone having a chance
to contribute themselves to it.
One extremely important effect we're not considering is the
collaborative
amplification of creativity: when people work on a project together
instead of breaking it into pieces and taking one piece each, they
share
ideas that would otherwise never be implemented. As someone else
who's
name I don't remember said, "If I give you my idea and you give me
your
idea, we each have two ideas, and together we have four." This could
turn
out to be an even more significant contributor to bazaar-style
development
than the scaleability issue.
Ahhh, now I am reminded of the corpses of the endless
Theory of Knowledge essays I have churned out.
An useful method of classifying laws is to divide them into
"Predictive" and "Descriptive" laws. In short, some laws are
more about How things will behave, some are more about Why
they behave as they do.
Consider Newtonian physics. It is largely "How". It allows
you to fairly accurately predict how an apple will fall
when it falls off of a tree. But as far *why* the apple
falls, it only goes as far as saying "because there is an
attractive force between the apple in the ground".
Enter relativity. Einstein created a set of theories that
gave a "Why" basis to Newton's how. As well as predictive
powers (how much energy in an atom? why, e = mc^2 of
course) it provided a description of spacetime which helped
to explain Why gravity happened.
The Law of Diminishing Returns is a How law. The causes
of the effect are really beyond the scope of this essay
and my own current course of study. Here is a summary of
possible reasons that have been generated *so far* for
free software alone:
* Pixie dust
* Lack of 'target date'
* The drive to produce good code
* Stallmanist ideology
* Creative idea flows
And so on. BTW, "Stallmanist" will be a legit '-ist' word
some day, I'm betting: remember, you saw it here first! :)
The point is that my scope does not cover "Why". If I
were to try and investigate "Whys" I could be at it
forever. Indeed, I *do* nod in the direction of "Whys",
but only in the summary of CB which I provided.
BTW, ESR, CB is all over the place. A great speech, but
it took a few readings to get what I wanted from it. Any
chance of a companion paper ("Faces of the Bazaar", say?)
in the future? CB is to serious attempts at understanding
what the bible is to plain english: technically there
but it takes a few passes to get what is being said.
'Always' is a dangerous word. 'So far' might be a safer bet
for now. So far the favoured solution is the Bazaar being a
What I meant was that adding more people will never slow down
development.
Again - *never*?
(My interesting observation about Brooks's Law was specifically that
for
sufficiently high values of N, the developers will produce *nothing at
all*.) The new people might turn out to be totally useless, but the
additional cost per new person is so small that the free-rider problem
is
negligible. If one out of a hundred people on the project's mailing
list
actually contributes anything to the project, the mailing list is
doing
its job.
That's an interesting point. It's hard to phrase, so I'll fiddle with
it for the Caveats section.
The only cases in which this becomes a problem are those in which the
free
riders actively interfere with development by, for example, starting
flame
wars on the mailing list, spamming the newsgroup, wasting bandwidth on
the
FTP site, etc. In that case, the core development group (once it
realizes
it can't restore order) will typically adapt to the situation by
moving to
a new mailing list, for example.
*never*, wasn't it?
Well, there you go. If I got ESR right, the labour-division
thing is handled by independent action and the parallel
handling of vertical problems.
I didn't know ESR said that. I was thinking that in a group that's
not
being forced (by a phalanx of whip-cracking PHBs) to build an entire
project from the ground up, it would be
Re: Essay RFC delayed.
Hello all, again. Jacques Chester wrote: [...] Brook's Law [...] BTW, it's Brooks's law (not Brook's law or Brooks' law); the current draft consistently gets this wrong. Bugger. I spotted this myself at one point, whereupon it was promptly forgotten. It's rude for me to do so, as the same rule of grammar applies to my name (Jacques/Jacques'). Projects So what are projects, and what are their factors? Brooks example can be characterised as a project with two factors, being programmers and managers. If we hold managers constant, and increase programmers, LODR tells us that productivity will increase less each time another programmer is added. Actually, Brooks's law says that productivity will *decrease* after a certain point, not just increase less. With the n**2 communications costs, eventually you reach a point where adding resources is bad not just relatively but absolutely. I no longer have Mythical Man-Month on me, so what follows may be wrong. But what you have described is the same as the LODR. After certain point, not only does the marginal output become negative, but the average total output noses over and begins to fall. Indeed, a better (and rarely-used) name for the LODR is "the Law of Increasing Costs". JC.
Re: RFC soon on essay Does Free Software Production in a Bazaarobey the Law of Diminishing Returns?
There was a time that the GNU/Linux system was not of "sufficiently high quality" to do much of anything useful. If that had been the deciding factor we would have never made it to this point. Speak for yourself. I have been using GNU software and Linux since its very early ages to do useful work. 7 years so far of using free software. Miguel.
License certification question
I'm getting frustrated. I'm hoping someone here can help me out. On 7/16, I sent an email to [EMAIL PROTECTED] about an Artistic License variant I wanted to get certified. That's where the OSI Certification Mark page said to send it. A week or so later, I discovered that the page had been changed, and now said I should send it to [EMAIL PROTECTED], so I re-sent it. When I returned from vacation at the beginning of August, I subscribed to this list to see if there was any discussion of it. I have yet to hear so much as a "got-your-message" acknowledgement from anyone at opensource.org. Is there something else I need to do to get the license reviewed? - Sam Samuel Reynolds [EMAIL PROTECTED] [EMAIL PROTECTED] Frontier Scripting: http://www.spinwardstars.com/frontier/ Reynolds Virtual Workshop: http://www.primenet.com/~reynol/
Re: Essay RFC delayed.
How do Open Source projects differ from the above? In two very important ways. Firstly, OSPs have no time-bound. That is, there is no deadline whereby the next version of GNOME has to be delivered, "or I agree entirely with your argument, but the words raise a background issue so important I have to make a correction. GNOME is part of the GNU Project, and we are part of the Free Software movement, not the Open Source movement. We and they do similar things, and we can work together in practice, but our philosophical reasons are as different as could be. Could you kindly cite GNOME as an example of the Free Software movement, not one of the Open Source movement? Please don't spread the idea that the latter one includes all of us. See http://www.gnu.org/philosophy/free-software-for-freedom.html for more explanation of the difference between the two movements.
Re: Essay RFC delayed.
Or alternatively, simply list another project so as not to confuse the issue midstream. As Richard points out, the FSF doesn't want the terms "Open Source" and "Free Software" lumped together. Rather than switching to a different terminology mid-stream, it would make more sense to simply select a non-FSF project there to avoid confusion to the reader. At 01:04 PM 8/18/99 -0600, Richard Stallman wrote: How do Open Source projects differ from the above? In two very important ways. Firstly, OSPs have no time-bound. That is, there is no deadline whereby the next version of GNOME has to be delivered, "or I agree entirely with your argument, but the words raise a background issue so important I have to make a correction. GNOME is part of the GNU Project, and we are part of the Free Software movement, not the Open Source movement. We and they do similar things, and we can work together in practice, but our philosophical reasons are as different as could be. Could you kindly cite GNOME as an example of the Free Software movement, not one of the Open Source movement? Please don't spread the idea that the latter one includes all of us. See http://www.gnu.org/philosophy/free-software-for-freedom.html for more explanation of the difference between the two movements.
Re: RFC soon on essay Does Free Software Production in a Bazaarobey the Law of Diminishing Returns?
Speak for yourself. I have been using GNU software and Linux since its very early ages to do useful work. 7 years so far of using free software. This really depends on what you want to use the computer for. Not everybody does kernel development. For a lot of people useful work depends on certain types of software to be available. Otherwise we wouldn't need (for example) GNOME ;) ---Csaba
Fw: remove
- Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, August 01, 1999 7:24 PM Subject: remove please remove me from the dist list thanks
Re: Essay RFC delayed.
On Thu, 19 Aug 1999, NotZed wrote: It just happens to be a little difficult to talk about another project in this case, because Gnome is the project under study. I would have to agree with Richard, it is part of the free software movement, not the "open source" one. Although the means are often identical, the goals are not the same at all. If anything, GNOME is part of the "GNOME movement" - any other group trying to take credit for it or call it their own, should reconsider their position. Not that this has anything to do with license-discuss. Brian
Re: Essay RFC delayed.
On Wed, Aug 18, 1999 at 03:50:54PM -0400, Eric S. Raymond wrote: Richard, you should be careful what you wish for; you might get it. In your zeal to distance your doctrinal purity from the OSI's filthy but effective pragmatism, you are mainly succeeding in marginalizing both the FSF and yourself. If you keep this up, you're going to end up ranting to an audience of one, in the mirror. I would not view this as a happy outcome; you have given far too much to our community, and have far too much more to give in the future. Can't you learn to accept your victory and your allies more gracefully? Frankly Richard, I agree. You should be more of a sport. Think of the benefits you would recieve. Look at all your other colleagues that grew rich while you were splitting these philosophical hairs. Its not too late! If you "play ball" the establishment can probably still arrange for a retainer of some type, or maybe even an equity position in some hot "Open Source" IPO! Stop torturing yourself with these troublesome ideological positions! What if a few companies get rich at the expense of the people? It's inevitable anyway. Capitalize on your "brand name recognition" before its hopelessly marginalized. Maybe Eric could be your agent! He has certainly proven himself an adept promoter. Just look at what he has done for his own reputation. Why, he invented "Open Source"! In every country and in every age, the priest has been hostile to liberty. He is always in alliance with the despot, abetting his abuses in return for protection to his own. -- Thomas Jefferson, 1814 E -- ___ Ean SchuesslerNovare International Inc. "He who permits himself to tell a lie once, finds it much easier to do it a second and third time, till at length it becomes habitual; he tells lies without attending to it, and truths without the world's believing him. This falsehood of the tongue leads to that of the heart, and in time depraves all its good dispositions." -- Thomas Jefferson
