Re: Compulsory checkin clauses.
On Sat, 5 Aug 2000, Justin Wells wrote: How about releasing a modification to a GPL'd program which contains no material from the original? Recipients of the modification can "privately" apply it to their GPL'd works, while the authors of the modification can claim that it is not covered by the GPL because it is not a derived work. I brought up this point last year (I think) under the title "How to break the GPL". The trouble is, according to some of the lawyers on this list, that establishing copyright in a patch is very unlikely, since there tends to be a form/content merger (if there is basically only one way to express something, the form in which it is expressed cannot be copyrighted, at least in the U.S., as that would create rights over the content as well). So a proprietary patch to a free program probably won't fly. For example, a GPL'd program contains a file called 'foo.c' among its source code. I write a brand new 'foo.c' containing no material from the original, but compatibly conforming to its API, and release that under some proprietary license. I include a build script which copies my foo.c over top of the original and conveniently builds the modified version for the people who purchased my foo.c from me. This is a stronger case, because "foo" is a genuine module with an exposed API. (Of course, you have to have read only the API documentation, not "foo.c", to have any hope of being clean-room.) If a module] has a released API, I don't see that there's any hope of preventing people from replacing it by another module. Anyway, is that really so bad? Is there some reason why Random Users, Inc. *must* link their GPLed programs against either the operating system libc or glibc? Why should RUI be forbidden to link the program with Fred Foobar's Very Fast Proprietary Assembly Language Version Of strstr(), which just happens to be called in the inner loop of your GPL program? RUI benefits from paying Fred Foobar, but nobody else is *injured* by this, unless RUI distributes their binary, which they cannot do under the GPL. -- John Cowan [EMAIL PROTECTED] C'est la` pourtant que se livre le sens du dire, de ce que, s'y conjuguant le nyania qui bruit des sexes en compagnie, il supplee a ce qu'entre eux, de rapport nyait pas. -- Jacques Lacan, "L'Etourdit"
Re: Compulsory checkin clauses.
At 5:05 PM -0400 8/7/00, John Cowan wrote: There is a cost to keeping your patches under wraps, though, either out of competitiveness or parsimony: you will have to reintegrate the patch into the next release, and the next, and the next Very quickly you get sick of this and make the patch available to the owner/maintainer so that you get it back for free in all future releases. Don't get me started on THAT road... ;-) D
No such thing as GPL for Java (was Re: Compulsory checkin clauses.)
On Mon, Aug 07, 2000 at 05:33:45PM -0400, John Cowan wrote: For example, a GPL'd program contains a file called 'foo.c' among its source code. I write a brand new 'foo.c' containing no material from the original, but compatibly conforming to its API, and release that under some proprietary license. I include a build script which copies my foo.c over top of the original and conveniently builds the modified version for the people who purchased my foo.c from me. This is a stronger case, because "foo" is a genuine module with an exposed API. (Of course, you have to have read only the API documentation, not "foo.c", to have any hope of being clean-room.) If a module] has a released API, I don't see that there's any hope of preventing people from replacing it by another module. This example is particularly relevant to me. I worded it above in terms of the C langauge because everyone is familiar with that--but really what worries me is Java. Java has no concept of static linking--everything is linked at runtime, and almost every class has a well published API thanks to "javadoc", which runs over the code and translates comments into an HTML documentation page. So every GPL'd Java program is susceptible to this: just rewrite a class and ship it in "binary" (.class) format only. It won't be linked with the program until runtime so you haven't distributed a derived work. For Java developers using the GPL is effectively the same as using LGPL. Justin
Re: Compulsory checkin clauses.
At 6:41 PM -0700 5/8/2000, David Johnson wrote: On Sat, 05 Aug 2000, Ross N. Williams wrote: The GPL makes people altruistic by forcing them to share their modifications *if they publish them*. And it works! Yes, if they publish them. Authors have the right to control the publication of their work or its derivative. But they don't normally have the right to compell that publication. Yes, but remember, we're talking about modifications to a work, not a new work. But regardless of your philosophy or mine, is a software license the appropriate vehicle for promoting them? Hell yeah! Rock 'N Roll! (Geez, haven't you read the GPL preamble! :-) :-) Yes, I have read it :-) :-) :-) It's obvious that Mr. Stallman and I disagree You must REALLY disagree if you're calling him "Mr. Stallman". :-) on the appropriateness of legal licenses as a forum for promulgating philosophy. It's sort of his version of a charity kitchen. You want the free meal but you have to listen to the sermon before you get it. :-) But the preamble is not the legal license! The FSF may very well desire that everyone release their original works as Free Software, but they aren't using their licenses to make anyone do it. That's only because they haven't got the legal power to do so! :-) (new original works I mean). But to be constructive for a change, I have a possible solution for you. How about defining distribution as what happens between two individual human beings? If coworker A gives a copy of the modification to coworker B, then the modification has been distributed. This may not be legally sound, as corporations are considered legal persons, but it would be an elegant solution if you can still tolerate individuals creating private modifications. Thanks for the positive idea, but I'm into legal rigor, so I don't want to attempt this. I've written the Free World Licence so it can be used by other people (and in particular uptight other companies), so I've engineered for minimum legal risk. I'm still confused about whether I should put in checkin, but you've made me feel less insecure about feeling confused, so that's a help. Ross. Dr Ross N. Williams ([EMAIL PROTECTED]), +61 8 8232-6262 (fax-6264). Director, Rocksoft Pty Ltd, Adelaide, Australia: http://www.rocksoft.com/ Protect your files with Veracity data integrity: http://www.veracity.com/
Re: Compulsory checkin clauses.
On Sun, 06 Aug 2000, Ross N. Williams wrote: Yes, if they publish them. Authors have the right to control the publication of their work or its derivative. But they don't normally have the right to compell that publication. Yes, but remember, we're talking about modifications to a work, not a new work. Normally, private modifications are not in the purview of the original author. But publication and distribution of them is. It's obvious that Mr. Stallman and I disagree You must REALLY disagree if you're calling him "Mr. Stallman". :-) Sometimes I get tired of typing "RMS", but I don't know him well enough to call him Richard. -- David Johnson _ http://www.usermode.org
Re: Compulsory checkin clauses.
On Sat, Aug 05, 2000 at 04:26:01PM +0930, Ross N. Williams wrote: At 1:56 AM -0400 23/7/2000, John Cowan wrote: ... Hi all. I am just polishing my Free World Licence for release (you might remember it from when I was working on it last year) and am agonizing somewhat over compulsory checkin clauses. Don't agonize. Omit. Better yet -- don't write a new license, use one of several existin models: GNU GPL/LGPL, Mozilla, MIT / BSD (w/o advertising clause). Tried and true, fit many different goals and objectives w/in the free software space. ...which begs the question: what are your goals and objectives. Last year's version (never formally released) had this clause: 5.11 COMPULSORY CHECKIN: Within sixty days of modifying the Module, you must communicate through the internet (e.g. by email or through a web form) to Original Licensor (or its authorized representative) the modified Module (in text form) so that the modifications can be integrated into the Official free version. The communication must contain your name, your email address, your web address (if any), reference to this Licence and clause, a copy of the modified Module, and a brief description of the change(s) made. You must submit each modification even if you do not publish it. Based on some recent feedback, I have deleted it in the current draft. However, now I'm not so sure whether it's best to delete it and am thinking of putting it back in. Here are some examples of why it might be a good thing: * A programmer discovers a bug and fixes it, but doesn't tell anyone! * Two companies A and B in some market are competing. They both install some free software. Company A then modifies the free software to improve productivity, but it doesn't publish the change, so company B can't make use of the change to increase ITS productivity. Seems to me that if one of the aims of free software is to reduce wasteful isometric struggles (via the duplication of development effort in competing proprietary software) then to eliminate compulsory checkins is to forsake an opportunity to avoid some of these struggles. I guess from the FSF perspective, this is a case where the issue of freedom takes precedecence over economic efficiency, but it seems to me to not align with the spirit of free software. In either of the above cases, the general philosophy of the GPL is that, while you can strongly encourage people to act in an intelligent and Pareto-efficient manner, you can't compel the behavior, and in compelling it, you may do far more harm than good by killing the incentive to play the game (use software licensed under such terms) at all. * A company adds 10,000 lines to some free software to make it much better, but simply *couldn't be bothered* checking it in. After having spent $100K on improving the software, they say "Why should we waste a programmer day checking this stuff in just to help OTHER companies?". Many companies are this ruthless. So here's an idea. Why not have a clause that requires checkin if: 1. A bug is fixed. (7 day checkin). or 2. A total of more than 300 lines of code is changes/added (90 day checkin). This will allow people to tool around with the code unhindered, but will ensure that they have to checkin if they find a bug or do some non-trivial development work. Re-read your Greek fables: the Sun, the North Wind, and the Traveller. You are the North Wind -- blowing harder and harder trying to rid the traveller of his cloak. The Sun merely beams down warmer and brighter -- the traveller, warm from his exertions, is more than happy to rid himself of the extra weight. The Sun's strategy in this case is to make it easy for people to continue in their old ways if they really want to, but to realize the compelling benefit of turning in their own bugfixes and extensions of free software to the central maintainer because this is easier than having to maintain fork compatibility down the road. Create compelling benefit for returning bugfixes and enhancements. Don't kudgel people over the head trying to get them to do it. I am under no illusions about the practical enforceability of these kinds of provisions, but I think it's a good idea at least to define what's required so at least people know. Comments? Flames? Your last comment pretty much wraps it up: you are under no illusions of the practical enforceability of these provisions. Look at the problem from the PoV of an independent developer, or a company, which is looking to use software with a bugfix clause. The licensee is pretty much in the same position you're in -- the terms are ambiguous, of dubious enforceability, but could have powerful consequences. My own experience in dealing with negotiations for use or sale of software and/or services based free software is that the other party is much less concerned over the direct costs as they are over the potential l
Compulsory checkin clauses.
At 1:56 AM -0400 23/7/2000, John Cowan wrote: RMS wrote an article on the Plan 9 license, available at http://www.gnu.org/philosophy/plan-nine.html . I have made excerpts from it here as a matter of fair use. First, here are the provisions that make the software non-free. You agree to provide the Original Contributor, at its request, with a copy of the complete Source Code version, Object Code version and related documentation for Modifications created or contributed to by You if used for any purpose. This prohibits modifications for private use, denying the users a basic right I agree with RMS here. Not allowing the private use of private changes is way unreasonable. Hi all. I am just polishing my Free World Licence for release (you might remember it from when I was working on it last year) and am agonizing somewhat over compulsory checkin clauses. Last year's version (never formally released) had this clause: 5.11 COMPULSORY CHECKIN: Within sixty days of modifying the Module, you must communicate through the internet (e.g. by email or through a web form) to Original Licensor (or its authorized representative) the modified Module (in text form) so that the modifications can be integrated into the Official free version. The communication must contain your name, your email address, your web address (if any), reference to this Licence and clause, a copy of the modified Module, and a brief description of the change(s) made. You must submit each modification even if you do not publish it. Based on some recent feedback, I have deleted it in the current draft. However, now I'm not so sure whether it's best to delete it and am thinking of putting it back in. Here are some examples of why it might be a good thing: * A programmer discovers a bug and fixes it, but doesn't tell anyone! * Two companies A and B in some market are competing. They both install some free software. Company A then modifies the free software to improve productivity, but it doesn't publish the change, so company B can't make use of the change to increase ITS productivity. Seems to me that if one of the aims of free software is to reduce wasteful isometric struggles (via the duplication of development effort in competing proprietary software) then to eliminate compulsory checkins is to forsake an opportunity to avoid some of these struggles. I guess from the FSF perspective, this is a case where the issue of freedom takes precedecence over economic efficiency, but it seems to me to not align with the spirit of free software. * A company adds 10,000 lines to some free software to make it much better, but simply *couldn't be bothered* checking it in. After having spent $100K on improving the software, they say "Why should we waste a programmer day checking this stuff in just to help OTHER companies?". Many companies are this ruthless. So here's an idea. Why not have a clause that requires checkin if: 1. A bug is fixed. (7 day checkin). or 2. A total of more than 300 lines of code is changes/added (90 day checkin). This will allow people to tool around with the code unhindered, but will ensure that they have to checkin if they find a bug or do some non-trivial development work. I am under no illusions about the practical enforceability of these kinds of provisions, but I think it's a good idea at least to define what's required so at least people know. Comments? Flames? Ross. Dr Ross N. Williams ([EMAIL PROTECTED]), +61 8 8232-6262 (fax-6264). Director, Rocksoft Pty Ltd, Adelaide, Australia: http://www.rocksoft.com/ Protect your files with Veracity data integrity: http://www.veracity.com/
Re: Compulsory checkin clauses.
On Fri, 04 Aug 2000, Ross N. Williams wrote: Based on some recent feedback, I have deleted it in the current draft. However, now I'm not so sure whether it's best to delete it and am thinking of putting it back in. Here are some examples of why it might be a good thing: * A programmer discovers a bug and fixes it, but doesn't tell anyone! It's a private bug fix. In my opinion, it should be no one's business but the user. No harm to the author can possibly come of it. * Two companies A and B in some market are competing. They both install some free software. Company A then modifies the free software to improve productivity, but it doesn't publish the change, so company B can't make use of the change to increase ITS productivity. Again, it is still a private modification. Even though B is not helped by it, neither is it harmed. Trying to "equalize" the benefits amongst all the users sounds too much like social engineering, and I don't think that's the proper role of a license. Requiring that a developer labor unpaid for his competitor is grossly unfair. * A company adds 10,000 lines to some free software to make it much better, but simply *couldn't be bothered* checking it in. After having spent $100K on improving the software, they say "Why should we waste a programmer day checking this stuff in just to help OTHER companies?". Many companies are this ruthless. If they release the modified software, then they need to release the modified source code. But if they don't release the software, they have already lost $100K, so why punish them any more :-) I really wouldn't consider this "ruthless" by any stretch of my imagination. If this software is for their own private use, then spending $100K to improve it is no different than spending $100K to improve their facilities or buy new equipment or whatever. Basically, the reason I am against restricting private modifications is because it is really restricting *usage*. It's like selling a book but telling the reader that they can't make any margin notes unless they publish them, or selling sheet music but forbidding improvising on it unless it is recorded and uploaded to mp3.com. -- David Johnson _ http://www.usermode.org
Re: Compulsory checkin clauses.
At 1:11 AM -0700 5/8/2000, David Johnson wrote: On Fri, 04 Aug 2000, Ross N. Williams wrote: Based on some recent feedback, I have deleted it in the current draft. However, now I'm not so sure whether it's best to delete it and am thinking of putting it back in. Here are some examples of why it might be a good thing: * A programmer discovers a bug and fixes it, but doesn't tell anyone! It's a private bug fix. In my opinion, it should be no one's business but the user. No harm to the author can possibly come of it. Well, yes and no. It depends on your attitude towards bugs I guess. Think of the case where a bug can cause a user to lose all their work. Not reporting such a bug when you've got as far in understanding it as to actually be able to fix it, seems like a crime of omission against the user community to me. * Two companies A and B in some market are competing. They both install some free software. Company A then modifies the free software to improve productivity, but it doesn't publish the change, so company B can't make use of the change to increase ITS productivity. Again, it is still a private modification. Even though B is not helped by it, neither is it harmed. Trying to "equalize" the benefits amongst all the users sounds too much like social engineering, and I don't think that's the proper role of a license. Requiring that a developer labor unpaid for his competitor is grossly unfair. Which is exactly what happens when we modify free software for a client! Why do you want to protect software developers in non-software industries from such unfairness, but not software developers in the software industry? One consequence of protecting private changes: A manufacturer who outsources the modification of free software suffers a competitive disadvantage relative to a manufacturer who performs the changes in-house. If isometric software battles between software vendors are undesirable, then what makes isometric software battles within other industries any less undesirable? If such battles are all desirable, why don't we all just go back to proprietary licences? :-) * A company adds 10,000 lines to some free software to make it much better, but simply *couldn't be bothered* checking it in. After having spent $100K on improving the software, they say "Why should we waste a programmer day checking this stuff in just to help OTHER companies?". Many companies are this ruthless. If they release the modified software, then they need to release the modified source code. But if they don't release the software, they have already lost $100K, so why punish them any more :-) They haven't been punished because the $100K made them a profit. I really wouldn't consider this "ruthless" by any stretch of my imagination. I think it's a little bit ruthless when a company finds itself in a position where it can perform one unit of work to benefit society to the tune of 100 units and doesn't choose to do that. Clearly the company can't do this to the point where it goes broke, but there's a reasonable level where the win to the public is so much greater to the cost to the company that in my view it is ruthless for the company not to do it, at least to some extent. If this software is for their own private use, then spending $100K to improve it is no different than spending $100K to improve their facilities or buy new equipment or whatever. Yes, but with software, once it's created, there exists the opportunity to benefit others at a near-zero marginal cost. It doesn't work that way when you buy a table, otherwise we'd have open-source furniture wouldn't we? I sort of feel that if the company gets the benefit of 100,000 lines of free software, and adds 2000 lines, then it should share the 2000 in the spirit in which it accepted the original. However, if it has to choose to do this voluntarily, then it will suffer an evolutionary disadvantage for its altruism. Hence the argument for a compulsory checkin clause - to create a level altruistic playing field. Basically, the reason I am against restricting private modifications is because it is really restricting *usage*. It's like selling a book but telling the reader that they can't make any margin notes unless they publish them, or selling sheet music but forbidding improvising on it unless it is recorded and uploaded to mp3.com. Yes, I think that a sound argument can be made on the basis of freedom. And, depending on the software, privacy. But seems to me right now that fixing bugs and digging useful code out of lazy corporations is more important. Hence my bugfix and 300 lines checkin proposal. I don't know what the right answer is. Ross. Dr Ross N. Williams ([EMAIL PROTECTED]), +61 8 8232-6262 (fax-6264). Director, Rocksoft Pty Ltd, Adelaide, Australia: http://www.rocksoft.com/ Protect your files with Veracity data integrity: http://www.veracity.com/
Re: Compulsory checkin clauses.
On Sat, Aug 05, 2000 at 01:11:10AM -0700, David Johnson wrote: It's a private bug fix. In my opinion, it should be no one's business but the user. No harm to the author can possibly come of it. Looking for thoughts on this: How about releasing a modification to a GPL'd program which contains no material from the original? Recipients of the modification can "privately" apply it to their GPL'd works, while the authors of the modification can claim that it is not covered by the GPL because it is not a derived work. For example, a GPL'd program contains a file called 'foo.c' among its source code. I write a brand new 'foo.c' containing no material from the original, but compatibly conforming to its API, and release that under some proprietary license. I include a build script which copies my foo.c over top of the original and conveniently builds the modified version for the people who purchased my foo.c from me. This creates a gray area: maybe my modification has to be GPL'd because I clearly intended it to be linked into a GPL'd program. On the other hand, I will argue that I used a clean-room development approach and that my developers were never exposed to the source code of the original foo.c, and in fact didn't even know that they were developing something for use with a GPL'd program: I simply provided them with a spec. Rather than live with this uncertainty I would like to be able to put something into a license which clarifies it. I would like to force foo.c to be subject to the copyleft. A crude way to do it is to capture private modifications as well: but then you also capture honest private modifications made by an individual or company for their own internal use, which doesn't seem fair. I've been toying with language like "third party deployment of the modification" as a substitute for "distribution to a third party". Thoughts? Justin
Re: Compulsory checkin clauses.
Clever thought, but you can't capture this private development unless you use a license like Ross's which captures changes to the source code. Suppose company A creates some proprietary software the implements some API, call this "prop" (malloc would be a good example of this). Now, company B creates free software the uses the prop interface (say emacs). Later, company C creates a free version of prop (say glibc). Later, company D makes a free software product the merges B C's work (say emacs-20). Now, company E creates an improved proprietary version of prop (say purify_malloc)--presume company E is not aware of the free (glibc) version and only of the original code (and does a clean room implementation of that). Finally, can company F distribute both emacs-20 and purify_malloc on the same disk? Can user G install and build emacs-20 with purify_malloc for their own private work? Which, if either of these situations do you wish to prohibit? Note, you can't prohibit E from their development as they are not using either of the free pieces of code (emacs or glibc) and thus are not bound by the licenses on them. You might be able to prohibit company G from determining the API of prop by reading glibc and hiring company E to build a proprietary version, but not company E from doing it based upon the original proprietary version (or from a public doman spec). Moreover, in that case who would you sue over E's sales of the proprietary version. These are very similar to the restrictions put on Trade Secret information. Non-disclosure agreements have all sort of wording to deal with the case, where someone else has leaked the secret information and the person unser non-disclosure acquires it from the leak. A non-proprietary agreement is in many ways analogous to a non-disclosure agreement. Hope this helps, -Chris * Chris ClarkInternet : [EMAIL PROTECTED] Compiler Resources, Inc. Web Site : http://world.std.com/~compres 3 Proctor Street voice : (508) 435-5016 Hopkinton, MA 01748 USA fax: (508) 435-4847 (24 hours) --
Re: Compulsory checkin clauses.
On Sat, 05 Aug 2000, Justin Wells wrote: Looking for thoughts on this: How about releasing a modification to a GPL'd program which contains no material from the original? Recipients of the modification can "privately" apply it to their GPL'd works, while the authors of the modification can claim that it is not covered by the GPL because it is not a derived work. As I understand it, these are still considered derived works. foo.c is essentially a patch. There may be exceptions in a few cases, but I won't tread there... -- David Johnson _ http://www.usermode.org
Re: Compulsory checkin clauses.
On Sat, Aug 05, 2000 at 11:41:55AM -0700, David Johnson wrote: On Sat, 05 Aug 2000, Justin Wells wrote: Looking for thoughts on this: How about releasing a modification to a GPL'd program which contains no material from the original? Recipients of the modification can "privately" apply it to their GPL'd works, while the authors of the modification can claim that it is not covered by the GPL because it is not a derived work. As I understand it, these are still considered derived works. foo.c is essentially a patch. There may be exceptions in a few cases, but I won't tread there... That's how the FSF considers it, you're right. But my understanding is that this is just an opinion. There's certainly room to differ about it, and I'd rather just write something into the license that makes the whole problem go away. Justin
Re: Compulsory checkin clauses.
At 10:26 AM -0700 5/8/2000, David Johnson wrote: On Sat, 05 Aug 2000, Ross N. Williams wrote: Again, it is still a private modification. Even though B is not helped by it, neither is it harmed. Trying to "equalize" the benefits amongst all the users sounds too much like social engineering, and I don't think that's the proper role of a license. Requiring that a developer labor unpaid for his competitor is grossly unfair. Which is exactly what happens when we modify free software for a client! Why do you want to protect software developers in non-software industries from such unfairness, but not software developers in the software industry? There is a big difference here. In the case of modifying a free software client, the developer is getting paid. By the client. They have to follow your rules because they are distributing and publishing your software. They are profiting from your software. If they kept the modifications for private internal use they are not profiting only benefiting (a small but crucial distinction). Not "your" rules because consultant didn't write the software and didn't ask for it to be GNU. Anyway, let's drop this one. If isometric software battles between software vendors are undesirable, then what makes isometric software battles within other industries any less undesirable? If such battles are all desirable, why don't we all just go back to proprietary licences? :-) People use open source and free licenses because they want to share their creations with others. Some people may want others to share their original works as well, but they aren't using software licensing to do it. Including the FSF. The primary goal of the GPL and other copyleft licenses is to ensure that a *specific* work is always free. It says absolutely nothing about other works that are not in some way derivative. Although Richard Stallman may fervently believe that all software must be free, he did not write the GPL to accomplish it, preferring didactic and evangelical means to accomplish that goal. I don't see your point here, but let's drop it. Once you go beyond your normal rights as a copyright holder, such as regulating the distribution of your works, you encroach upon the rights of the user. Although many proprietary licensing schemes do this, I am aware of no open source license that does. Well, seeing as this list controls the definition of "open source", I'm not surprised ;-) And requiring that the company release its private modifications may actually be a zero gain for society. If the release denies them the means to earn sufficient profit for that $100K, they won't make the modifications to begin with. I thought this was one of the arguments that the FSF is continually bashing about free software. People always say that it won't get written and then it does. If this software is for their own private use, then spending $100K to improve it is no different than spending $100K to improve their facilities or buy new equipment or whatever. Yes, but with software, once it's created, there exists the opportunity to benefit others at a near-zero marginal cost. It doesn't work that way when you buy a table, otherwise we'd have open-source furniture wouldn't we? A fallacious argument. Even if there is a near-zero cost to distributing the modifications, there is a definite cost for releasing it. One example is support. Someone will have to pay for supporting this new nonstandard version of the software. If they do not offer support they may lose sales of their other products simply due to angry customers. And if the software causes damages to the user somehow, then the company may have to pay the costs of a court battle. I don't accept this. Free software licences have lots of legal firewalls to protect authors and no one says that anyone who posts compulsory checkins has to support them or even answer any subsequent email. Making people be altruistic is always a tricky affair. The GPL makes people altruistic by forcing them to share their modifications *if they publish them*. And it works! I don't know of too many situations where it has worked successfully. Philosophically, I feel there is a greater moral gain if one out of ten people voluntarily choose to share than if ten out of ten people are forced to share. Yeah, but do we want to be morally or economically enriched :-) :-) But regardless of your philosophy or mine, is a software license the appropriate vehicle for promoting them? Hell yeah! Rock 'N Roll! (Geez, haven't you read the GPL preamble! :-) :-) Basically, the reason I am against restricting private modifications is because it is really restricting *usage*. It's like selling a book but telling the reader that they can't make any margin notes unless they publish them, or selling sheet music but forbidding improvising on it unless it is recorded and uploaded to mp3.com. Yes, I think that a sound argument can
Re: Compulsory checkin clauses.
On Sat, 05 Aug 2000, Ross N. Williams wrote: Once you go beyond your normal rights as a copyright holder, such as regulating the distribution of your works, you encroach upon the rights of the user. Although many proprietary licensing schemes do this, I am aware of no open source license that does. Well, seeing as this list controls the definition of "open source", I'm not surprised ;-) The list has nothing to do with the definition of open source, although a few members might have that power. I, for one, have absolutely nothing to do with it. And requiring that the company release its private modifications may actually be a zero gain for society. If the release denies them the means to earn sufficient profit for that $100K, they won't make the modifications to begin with. I thought this was one of the arguments that the FSF is continually bashing about free software. People always say that it won't get written and then it does. Creating modifications as a product is a very different thing than creating modifications for internal use. In the case of the former, the intention from the very beginning is to release it. Let me concoct a hypothetical example. Let's say a company is in the midst of designing a new CPU. They have two pieces of Open Source software which they have acquired. One is a compiler and the other is a CAD program. It will be in their best interest to release the compiler modified for use with their new CPU. It will generate a body of software available for their product. But if they have modified the CAD to work with their radically new manufacturing process, releasing it will either A) be of use to no one else, or B) reveal their trade secrets to their competitors. The GPL makes people altruistic by forcing them to share their modifications *if they publish them*. And it works! Yes, if they publish them. Authors have the right to control the publication of their work or its derivative. But they don't normally have the right to compell that publication. But regardless of your philosophy or mine, is a software license the appropriate vehicle for promoting them? Hell yeah! Rock 'N Roll! (Geez, haven't you read the GPL preamble! :-) :-) Yes, I have read it :-) :-) :-) It's obvious that Mr. Stallman and I disagree on the appropriateness of legal licenses as a forum for promulgating philosophy. It's sort of his version of a charity kitchen. You want the free meal but you have to listen to the sermon before you get it. But the preamble is not the legal license! The FSF may very well desire that everyone release their original works as Free Software, but they aren't using their licenses to make anyone do it. But to be constructive for a change, I have a possible solution for you. How about defining distribution as what happens between two individual human beings? If coworker A gives a copy of the modification to coworker B, then the modification has been distributed. This may not be legally sound, as corporations are considered legal persons, but it would be an elegant solution if you can still tolerate individuals creating private modifications. -- David Johnson _ http://www.usermode.org
