Re: testing kit conformance as a condition of distribution
Hmmm, curious responses to something I would have seen as an attempt at a field of endeavor control. While it does not explicitly restrict the use of the software in such instances, it still could have that effect, since most workers in such fields are required to get bonds that guarantee the quality of their work, and such bonds require reasonable professional standards to be met, and using something that is explicitly not designed to be used in that context would seem to violate those professional standards. Isn't that the whole problem with million-$ hammers and the likes, that they have been certified to be useful under the exact conditions where one cares about the outcome (e.g. working on a space ship or a nuclear power plant or a bio-weapons lab), where if the tool isn't designed to precise specs and the tool fails as a result the results are catastrophic. Isn't the requirement of such an acknowledgement in the license to use the tool, thus an ipso facto restriction against the tools use in such circumstances. If I lived in the area affected by a nuclear power plant and found that one of its contractors was using a tool that they freely acknowledged as inappropriate to the task, I would be certainly interested in joining the class-action suit against said contractor. -Chris -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: OSD #6 (fields of endeavor) and research vs commercial rights
Bob Scheifler asked: So the word restrict in OSD#6 (and the word prevent in the rationale) should be interpreted narrowly to mean completely preclude? Meaning, there's no obligation for all fields of endeavor to be on equal footing; I think completely preclude would be *too* narrow. My sense is that you can impose restrictions that require end users to make available (e.g. publish or return copies to the author) and to attribute or not attribute authorship (e.g. you must keep copyright notices marking some work as having come from some source, but you may not use the name of that source otherwise), but not much more. Those restrictions don't have to be levelled equally. However, other types of restrictions are going to be more problematic, e.g. fees to any one group (or even equally levelled) will definitely not fly. Other restrictions that I don't think could be made to fly are restrictions that the software must be (or may not be) used in conjunction with other software. My rule of thumb is that restrictions that preserve authorship are likely to pass, but restrictions that preserve ownership are not. That is, you can place restrictions that protect your rights as an author of the software, but not restrictions that protect your rights as an owner. However, that is just a personal rule of thumb, based upon my model of what rights are related to authorship and what ones come from ownership--a strict legal interpretation of those words would invalidate the rule of thumb entirely, as copyright law reserves some rights to an author that would not likely be acceptible in an open source license. One area where I think things are gray is in whether restrictions on how derivative works can be made are acceptible. For example, licenses have passed that require special handling of changes to the code (e.g. segregation into patches and keeping the original work intact). However, licesnes that prohibit making derivative works have not (and will not). Not knowing how this list works, are there people who speak authoritatively on interpretations of the OSD? There are definitely those who speak more authoritatively than others as they are members of the OSI board, me *not* being among them. No one speaks with absolute authority though, as it is a committee that does the approval and this list is simply advisory, trying to raise issues in specific licenses so that the board can make a more informed decision. There is certainly no requirement that the board listen to the discussion on the list or abide by any of the results of the discussions. -Chris -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Dual licensing
I'm sorry, Marius, I'm confused. How can be it open source, and yet if used commercially, the authors get a cut? The thing is, we don't see how that hurts the basic tenets of the free software philosophy. ... I know this, and this is the single 'wrong' thing about free software in the view on many people (SDC, UUU, Alladin...) Putting the authors out of the loop is silly and unfair. It may be wrong (silly, unjfair, etc.) but it *is* the definition of both free software and open source. The *intent* is to take the author out of the loop. Once your software is free or open source, you don't own it any more. It belongs to its users. You are not the first to propose some form of limited sharing, with some amount of ability to return profits to the author when users themselves are making profits. However, each and every time, such ideas have floundered on this basic principle--the principle that the author cannot restrict(*) the end users rights to use and redistribute the software for any purpose once they have obtained a copy. (*Some forms of restriction are allowed if they facilitate the principle of non-restriction, e.g. the GPL requiring that if you distribute a non-human readable form, you must also desribute a human readable form.) The ability to enforce a limited sharing is considered a monopoly rent. You as the author are inherently a monopoly, as you (perhaps a collective you if the software was written by a group) are the author and conceptually no one else can be that. Thus, any ability you have to control the software puts you in the position of a controlling monopoly. If that control prohibits others from using the software without returning something to you, then what those users must return to you is a monopoly rent. And if that cotrol (either through a monopoly rent) or through some other mechanism prevents some group of users from using (or redistributing to whoever they want) the software after they have obtained it, then it makes the software non-open source. (And the key point is that the users must be able to redistibute the software to anyone, including users who the original author would not give the software to and that those redistributed to users must have equal rights even if the original author would not have given them such rights and also cannot be restricted in their use or redistribution.) If you want to make a profit from selling open source software, you are free to attempt to do so, and there appear to be mechanisms to do so. However, you can't do it through a monopoly rent system and call it open source. The closest one can come to collecting a monopoly rent is finding some way to make oneself the preferred provider of the software and collecting such rents on the first sale--that is sometimes called selling the brand. My company has developed a strategy for doing just that, and we'll see over time whether it is successful. However, we recognize that in doing so, our ability to extract income form the software is only proportional to the extra value we continue to add (or at least that our customers perceive we add). The fact that some form of our software is open source means that there will always be the threat that users who don't perceive the value we add can find a way to get the software for a lower cost than what we charge, so there will always be a downward force on our prices that we will have to compensate for by adding the perceived value. However, we can't add that value through a license clause that requires payment under some conditions. That simply makes the software not open source. Violating a key part of open source as I tried to explain above. Other forms of limited sharing may be good, right, correct, laudable, etc. However, the definition of open source is that the author is out of the loop once the software is obtained by the users and it is the users that have control. No amount of arguing will ever change that. There are very smart people involved in the open source movement and they understand that principle and what it entails and have chosen to accept it. And while you may not think that some other form of limited sharing does not hurt the free software philosophy, they will never agree, because they consider the end user's rights (even if the end user is the evil empire) to be paramount. It is a matter of principle, and at some level it defines the free software philosophy--which isn't as much about sharing as some people think, as it is about *not being able to restrict* sharing, which is a slightly different thing. Excuse my long-windedness, -Chris * Chris ClarkInternet : [EMAIL PROTECTED] Compiler Resources, Inc. Web Site : http://world.std.com/~compres 23 Bailey Rd voice : (508) 435-5016 Berlin, MA 01503 USA fax: (978) 838-0263 (24 hours)
Re: the provide, license verbs
The problem is that corporations like to define their coproprate self, including all those that they hire or sub-contract from as a single entity, just like the end user you (which may by the same extension be a family all sharing one computer). Now, traditionally, companies have not tracked down individual users of copyrighted materials and tried to enforce non-infringement clauses upon them. However, traditionally, the mechanism for making quality duplication of originals was by itself prohibitively expensive. So, if I took out my cassette deck and recorded a song that was playing on the radio, it wasn't much harm to their profits--I would probably eventually buy the same material (on an LP record or a 45) to get a durable copy of decent quality. Equally importantly, if some money making concern, say a dentists office wanted to play the music, companies *would* charge them for individual use--e.g. Muzak. Now, in constrast, things have changed. Everyone can make high qualtiy copies with an effectively infinite life-span. The music and movie industries have started suing individual users. It isn't a far stretch to see the same things applying to software. As a result, I think at some point someone will sue someone over the fact that the party being sued internally distributed software violating the suing party's license which had requirements on distribution that the party being sued did not meet. -Chris * Chris ClarkInternet : [EMAIL PROTECTED] Compiler Resources, Inc. Web Site : http://world.std.com/~compres 23 Bailey Rd voice : (508) 435-5016 Berlin, MA 01503 USA fax: (978) 838-0263 (24 hours) -- -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: the provide, license verbs
Sorry to follow-up to myself, but As a result, I think at some point someone will sue someone over the fact that the party being sued internally distributed software violating the suing party's license which had requirements on distribution that the party being sued did not meet. I think that someone will also sue over making a private derivative version too. However, I don't know if such a suit is possible under an open source license as I believe all current open source licenses reserve the right to make derivatives to the recipient, and I believe further that to be OSI-compatible they must do so. I have often contemplated writing an open source license that requires derivatives to be made publicly available (either by publishing or by sending back to the author who can then publish). However, working with a lawyer to get such a license drafted is an expensive proposition and would only result in yet-one-more-incompatible open source license, which is not a good thing in my eyes. -Chris * Chris ClarkInternet : [EMAIL PROTECTED] Compiler Resources, Inc. Web Site : http://world.std.com/~compres 23 Bailey Rd voice : (508) 435-5016 Berlin, MA 01503 USA fax: (978) 838-0263 (24 hours) -- -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Dual licensing
While it is not done in practise yet, (we are still arranging to make it possible) Compiler Resources, Inc. does intend to sell open source software (and at some level the FSF does so today or at least did in the past). We have a currently closed source product, Yacc++, that we intend to release an open source version of. Truly open source, under the GPL, and other developers may fork, resell, or do whatever the GPL allows them to do with it. We will also sell that exact same version (at a reduced price from other closed source versions). We hope that some distributions of open source software may in fact begin incorporating the open source version into their distributions and that copies of the open source software gets given away for free. Now, as noted, we will also be selling closed source versions (and support for the open source version). This is where we intend to continue making the majority of our profits. However, there will be some clients who wish to buy the open source version from us, perhaps because they will then get it in combination with a proprietary version or to get support or just to get the latest open source copy we have released in a timely fashion. Thus, we will be *selling* the open source version. As I mentioned, (at least at one time) the FSF did the same. One could buy a distribution tape of Emacs from them (for about $150). As I recall, we, in fact, did so. Not because, we were particularly enamoured with giving the FSF money, but because we wanted a reliable copy, and we were no more enamoured with giving someone else the money. There was at least the hope that the money we gave to the FSF would be plowed back into supporting further development of Emacs. As to the pricing model, we intend to sell the open source version for about a quarter what we sell our flagship closed source version for, which is also the price we sell upgrades to our best customers for. Matching the upgrade price is the key reason we picked that price point--the open source version will help support customers who do not want more current versions, but want more freedom in modifying the software and supporting themselves. We have a fairly extensive client base who would like to self-support and are using older versions that they do not wish to upgrade, but do need sources for to handle incompatibilities in the underlying OS that have crept in over the years (e.g. we have Windows 3.x users that need an XP version, of the same old copy of our software, and we want to make their life easier). Note, the price point we have selected is about half the price of comparable competing closed source products. As to the development model, we intend to accept contributions (provide that the authors are willing to assign copyright owernship for us, so we can dual license and incorporate into our closed source versions) and will offer such enahncement authors some form of compensation for their contibutions (advance copies of the next free release are one likely candidate and attribution credit if desired). Is it possible that some authors will fork a competing version and sell or give that away, yes? However, we expect to mitigate that threat by providing only a subset of the flagship products functionality--a substantial subset, so that the open source version is not a toy or demo version, but in fact a valuable product in itself (just not quite as good as our flagship product)--with the further promise that other features from our flagship product will get incorporated into the open source version over time. That means any fork will either have to track our open source releases or will become less functional. Note, no where in our plans are attempts to keep others from selling the same open source software (nor from giving it away). In fact, we hope that some distributions do in fact give the open source version away, as loss leaders for our closed source version. At the same time, we do expect to sell the open source version, just not as the primary revenue stream. As far as I can tell, precluding others from selling or giving away your open source software, violates what most people mean by open source. At time same time, just because we allow others to give it away, does not mean that we have to give it away--that's a separate decision. It is possible to segment the market and still sell open source software. Hope this helps, -Chris * Chris ClarkInternet : [EMAIL PROTECTED] Compiler Resources, Inc. Web Site : http://world.std.com/~compres 23 Bailey Rd voice : (508) 435-5016 Berlin, MA 01503 USA fax: (978) 838-0263 (24 hours) -- -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
free Re: Dual licensing
What part of OSD#6 prevents someone for charging to license the software to one group and give the software away for free to another as long as the same open source license is made available to both? Actually, as long as the license is OSI compatible--meaning effectively that some recipient could give the software to the party to which one does not wish to sell, is there any reason that a developer could not sell open source software only to a select group of people? For example, consider the following possible strawmen: Strawman 1: 1) Developer A creates software. 2a) Developer A creates a web site and offers the software for gratis distribution to non-commercial users via a web site. 2b) Said developer offers for sale (but not gratis) direct distribution to commercial users. 3) Developer A ships the software to said users under the GPL. 4) Non-commercial user B gets a copy of said software and gives (or sells) it to commercial enity B (under the terms of the GPL) 5a) Can developer A, say that they have complied with the OSI definition? 5b) What if they indicate that such circumvention is legal--but discouraged at the web site? Strawman 2, same as one, but substitute for 2a/b 2a) Developer A creates a web site and offers the software for sale to non-commercial users via a web site. 2b) Said developer refuses to sell (directly, i.e. themselves) to commercial users. -Chris -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Question regarding modules/pluggins license?
Larry Masters asked: I currently work on an open source project that uses the GPL for a license. The project is written in PHP and uses modules/pluggins. The project has an API that other developers can use to create these modules/pluggins so they work within the framework of the project. If you (the author of such a project) clearly intend for the modules/pluggins to be not constrained by your license, then you should use a license that specifically allows it (or otherwise indicate that the intent is to specifically allow that case). (Of course, if you are one of several authors, as a group you will have to come to a consensus on this topic). The Lesser GPL is a license that attempts to make such things clear (and still be as closes as possible to the GPL). It may also be possible to express your intentions in additional clauses in either the source code or documentation. The standard C++ libraries shipped with g++ appear to do this in comments in their header files. Somewhere it is expressed that simply using the Linux API does not cause programs running on Linux to be GPL even though many parts of Linux are GPL (and I presume the whole thing is). In any case, being explicit is a good thing. So, is being careful. The worst case I can imagine (for me as a potential end user) is that someone develops some code licenses it under the GPL (and intends for that to be viral to all software which links to it), that code gets integrated (by a third party) into some package that I wish to use which purportedly allows linking (of modules/pluggins) without viral license attachment (thus potentially contravening the original authors copyright) and I as a user link the software with code (a module or pluggin) I cannot ship under the GPL and ship the resulting package (making the contravention real). The original author now sues someone (probably me) for doing something I thought I was permitted to do. No one is happy! Best regards, -Chris -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Question regarding modules/pluggins license?
Ian wrote: In other words, even if we assume that such a suit could succeed, the only people who have the standing to file it have stated publically that they will not do so. I would be similarly curious if a suit against Linus Torvalds (sp?) could succeed. Parts of Linux are clearly GPL and I suspect some is contributed by authors who wish the GPL to be applied virally making Linux in its entirety GPL, by necessity. Thus, in theory, one of those authors would seem to have rights to sue someone (either an end user or Linus) for linking against Linux and distributing the result--thus transitively against such an authors code and violating that authors copyright. Linus is certainly guilty of contributing to such an infringement. However, Ian's basic point is worth emphasizing. The GPL is only as constraining as the software's authors desire to enforce it. The only question the small point above brought up is in a collective work, is it not likely that some of the authors' desires are getting trampled on? -Chris -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Licenses and subterfuge
I know this question is a little off-topic for this list, but this list seems like the best place to get an answer to this question. I hope this question is at least tangentially relevant to this list as it concerns when open-source license come into play and certain forms of possible subterfuge one might use to avoid them. I also want to point out that I'm looking for opinions on this matter and not specific legal advice--informed legal opinion is, of course, welcome. Background: certain companies require that their suppliers ship them non-virally(*) licensed code--e.g. BSD and MIT licenses are ok, GPL and Sun licenses are not. A group I work with is attempting to comply with both the letter and spirit of the above rule and the licenses in question. That is we want to ship code that does not infringe on any open source license. We also want to ship our client a version which runs on a typical open source platform (e.g. Linux), but again without causing our client to open source their code. In particular, the client might wish to take sections of our code and include them in a non-open source project, and we don't want our actions to make that impossible (even when we are shipping our code under an open source license). More importantly, we want to keep the spirit also, and not take actions which although technically legal violate the intent or give the appearance of doing so. (* I don't mean viral in any pejorative sense. I would use some synonym such as accretive (a license which grows the open source software base), except that it is longer to type and viral is the most commonly used term for such licenses.) In most of the examples, I will refer to the open source license as the GPL (as that is the specific license in question in most cases). However, the same question would apply to any license (and I would presume that any prospective license writer should consider these questions reletive to their own license). Example 1: readline This is a typical subroutine that is distributed under the GPL (and is apparently used by the FSF as an example of things that one might incorporate that would cause ones software to become GPL). I will take as a starting point that if one writes an application that uses readline, using the GPL licensed header file, and links the GPL licensed readline library into ones application, then ones application is subject to the GPL. I will also posit that if one writes ones own function called readline that happens to implement the same interface, but which may or may not be (completely) functionally equivalent, and one does it in an appropriate clean-room fashion, so that no GPL code is referenced, that function can be incoporated into ones code without making the code GPL. Gray area that needs clarification: Since readline on Linux is shipped as a dynamic library, what if the application links to the implementation of readline dynamically. In particular, what if the application goes out of its way and uses its own prototype for readline (e.g. matching the version the application author has written and which ships with the application) and invokes the dynamic linker explicitly (e.g. using dlopen). Questions: If one has provided a version of readline that is not GPL, can one argue that the intent of the linkage is to access ones own verion of readline, and thus argue that the application should not be subject to the GPL? Is that subterfuge (an attempt to evade the license)? What if someone shipped with the application instructions on how to cause the dynamic linking to link the GPL version of readline? Does that make it subterfuge? Particularly, consider the case where the GPL version provides more functionality than the authors version and is arguably preferable. What if the application failed if no version of readline were supplied? That is that some version of readline was necessary to application or some portion of the application. What if someone neglected to ship the non-GPL version of readline? What if that deficiency were later corrected? Consider these question in terms of our intent to ship a non-viral version of our software that provides some basic functionality, but where the functionality can be improved by the user linking our software with GPL libraries. The last questions cover cases where we weren't entirely scrupulous in the process. If omitting certain steps is going to be problematic, I want to inform them so that they don't take shortcuts. Example 2: C++ functions in string Recent versions of the C++ standard header files (and presumably the underlying implementations) have also come under the GPL. However, the header files have an specific exemption listed in their source that allows the header to be included without making the application GPL. Would one have to verify the the implementation is distributed under the LGPL (or some other not-as-viral license)? What about the fact that non-GPL versions of the same header
Re: Silly question: are usage restrictions covered by the OSD?
Quoting Chris F Clark ([EMAIL PROTECTED]): me Perhaps a clause of the OSD should read that the license should not me discriminate against (or prohibit) any form of usage which is not me already proscribed by copyright law. That would be a very strong me bound on what open source licenses can regulate. Rick Moen replied: A possibly silly question of my own: If a particular form of usage is already proscribed by copyright law, then wouldn't it be pretty much pointless for a licence to discriminate against or prohibit it? 1) By usage I ment something more general. In particular, I was thinking of the 5, 6, or so specific rights reserved to a copyright holder in US law. I was not aware that EU law also reserved the right of executing a progam to the copyright owner also, which is certainly a relevant and important consideration. My intent by proposing the clause was to make certain that a license acted only as a grant type license. 2) I think because a license might be used in locations other than the author's own, some authors might want to specifically restrict that right in their license, despite the fact that such a clause would be unnecessary in their home jurisdiction. For example, the GPL specifically restricts ones right of redistribution, in the US that restriction acts more as a grant, because in the US one cannot normally redistribute works that are not ones own. However, if we went to some other location, we might find a jurisdiction that did not make redistribution a priviledged right reserved to the author and the GPL would then act solely as a restriction, not a grant. I'm not sure I can clarify what I meant without making my idea US-law-centric. In particular, I think a license ought to grant the recipients right to use the work in the manner that such works are normally used. That is programs should grant the right to be run, documents should grant the right to be read, pictures whould grant the right to be viewed, recorded songs the right to be heard, printed songs the right to be sung, etc. -Chris -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Silly question: are usage restrictions covered by the OSD?
I'm sorry, but I feel slightly mis-quoted here, where Chuck Swiger wrote: In contrast to the type of usage restriction that Chris was proposing, the GPL makes no attempt to prevent a user of Emacs from using that editor to produce proprietary software, and I think that is as it should be, at least in general. I believe I did not propose a usage restriction, except as clarifying what another person (Arnoud Engelfriet) wrote. I don't believe usage restrictions except for those inherent in copyright law, are compatible with the OSD (at least not compatible with the spirit of the OSD). On the other hand, I did mention a license concept based upon the restriction of creating derived works. I hope that such a license could be OSD compatible, because it does not descriminate on use (at least as programmers think of use, that is running the program), but it does prevent certain forms of derived works--in the case I mentioned, trying to prohibit the creation of secret non-open-source derivatives. Perhaps a clause of the OSD should read that the license should not discriminate against (or prohibit) any form of usage which is not already proscribed by copyright law. That would be a very strong bound on what open source licenses can regulate. Hope this helps, -Chris * Chris ClarkInternet : [EMAIL PROTECTED] Compiler Resources, Inc. Web Site : http://world.std.com/~compres 19 Bronte Way #33M voice : (508) 435-5016 Marlboro, MA 01752 USA fax: (508) 251-2347 (24 hours) -- -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Silly question: are usage restrictions covered by the OSD?
On Wed, 15 Oct 2003, Arnoud Engelfriet wrote: This may be a silly question as I'm probably overlooking something, but as far as I can tell the Open Source Definition does not forbid any general restrictions on usage of software. The closest thing is No Discrimination Against Fields of Endeavor, but that only forbids exclusion of _some types_ of usage, not exclusions on usage by everyone. Would something like You may only use this editor if you release all works you create with it as open source software fail under OSD #6, and if not, why would it fail the OSD? I would argue that your clause (you may only use this editor if ...) fails OSD #6, because it prohibits the field of endeavor creating non-open source software. The question that this does not address is how your restriction differs from the restriction in the GPL, (you may only create a derived work from this software if ...). That would also seem to prohibit the same field of endevour. However, the chief distinction is that concept of derived work. There is no field of endeavor of creating derived works from software that you are not the author of unless the author grants you that right. (This is one of the authors reserved rights under most theories of IP.) That is, without permission to create a derived work, one cannot create derived works at all, and thus it cannot be a field of endeavor. However, in distinction, one can create non-open source software using ones own IP. Thus, that can be a field of endeavor. Moreover, one can use a different editor to create such software. Thus, a usage restriction on a particular editor, would prohibit its use in that field of endeavor (which would otherwise be legal and thus a valid field of endeavor). And to my mind that contrvenes OSD #6. However, IANAL. Moreover, there is no court that has ever ruled on this particular point to say whether the argument is valid or not. Still, I am interested in other peoples impressions of this argument. The reason being, I am considering drafting a license which makes approximately that distinction. It is a license that is viral like the GPL except that it defines its point of requiring open sourcing of the resulting works the point of derivation rather than the point of redistribution. That is, one must release an open source copy of the derived work when one creates such a derived work, not only when one distributes such a derived work. (There are many details to work out, which is why I have not submitted it for review.) I am hoping that such a restriction will not be considered contravening the OSD, and that the license will become approved. -Chris * Chris ClarkInternet : [EMAIL PROTECTED] Compiler Resources, Inc. Web Site : http://world.std.com/~compres 19 Bronte Way #33M voice : (508) 435-5016 Marlboro, MA 01752 USA fax: (508) 251-2347 (24 hours) -- -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Silly question: are usage restrictions covered by the OSD?
I have gotten a series of questions/replies similar to the following, which I selected for no other reason than it was the most recent one and it was addressed to the entire group. (By the way, I do thank those who have responded, many of the replies have had points that were worthy of consideration.) So when someone's editing a file each time they write out the file they have to send the result to other people? No, that's not the intent. Such a requirement would be onerous and pointless. That is one of details, that is still being resolved, and there are lots of little subtleties that need to be straightened out. We don't want to require every trivial change to cause a requirement for publishing. In fact, we don't want to force preemptive publishing at all, just a requirement that if a derivative version exists, that other people who wish to have access to that version have a way of getting the source code. The idea we are trying to prevent is secret versions, versions where someone modifies the software in a proprietary way and uses that software for unfair advantage. The following example should be illustrative. Cadence Design took a copy of Emacs and modified it to have hooks into their propietary design tool, Verilog-XL. That is a derivative work of Emacs. However, they chose not to distribute the modified verion to avoid having to release trade secrets. Because some of the GPL restictions apply only at the redistribution level, Cadence was able to leverage Emacs into an internal tool that gave them a competitive advantage. The goal of the license I was proposing was to disallow that as a vaild use of the copylefted sources. That is, once they created such a derivative work, other users would have the right to it also. In particular, the folks at Synopsys, one of Cadence's competitors, should have the right to view the modified source code in case it helps them come up with a better version of their own tools. In contrast, many users of emacs create a startup file that turns on various modes, the intent of the license is not to require each of them to put their version of emacs up on a publicly addressable web page and post notice that such a version exists by taking out a full page advertisement in the NY Times. However, if you customize your version of Emacs, and someone asks you, How did you do that?, you, as a derivative author, should be required to point them at a copy of the code for your customization which they can learn from. Hopefully, the above two examples also explain how we intend to enforce this particular feature of the license--by competitor pressure. If one makes a derivative version of the software under the license, and a competitor finds out, the competitor will have the right to require that a copy of the software be made available to them as open source (i.e. under the terms of the license), and if the derivative author refuses, the derivative author will not have rights to the derivative copy as they will be violating the terms of the license which allowed them to make that derivative copy. And here is one of the subtle points, perhaps we can only enforce that restriction as an author. That is to conform to the requirements of copyright law, we might have to state that the author has the right to request a copy of any derivative work be provided back under the terms of the original license. Then, if the competitor wanted to enforce the clause, they would have to request the support of the original author, and to have the author make the request to the infringing derivative author. However, since there is no such license submitted for approval that attempts to implement such a restriction, if y'all want to ignore the subtleties of how one might write such a license, that is fine by me. I'm sure most of you have more important things to do. Again, my thanks for your time. -Chris -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Updated license - please comment
Only if their fork is still a software library. Nobody can fork it to become an application. I'm not sure how your problem is actually a restriction. Suppose, I as a developer wish to distriibute at application the uses the library in question. To distribute my application, I simply distribute my code and the code for the library--thus, the library is still a library. Now, any user can take the two parts (of the binary nerve gas, which themselves are perfectly harmless, excuse me but the metaphor seems just too apt), merge them together and viola (sp?) a useful application (totally toxic). Hope this helps, -Chris * Chris ClarkInternet : [EMAIL PROTECTED] Compiler Resources, Inc. Web Site : http://world.std.com/~compres 19 Bronte Way #33M voice : (508) 435-5016 Marlboro, MA 01752 USA fax: (508) 251-2347 (24 hours) -- -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Must publish vs. must supply
Me: Obviously, item 2 must be under some restrictions, or there isn't any must in your 3. Abe: -- I do not agree. The main restriction is that you keep your modifications private. The base line is: either keep them private *or* distribute to the public. Nothing in between. I'm sorry I misunderstood you also, and I apologize if I hijacked your ideas and took them in a direction you didn't intend for them to go. Avoiding selective secrecy (keeping modifiers (creators of derived works) from publishing only to their customers, but not to the world) is a reasonable goal for one to attempt to achieve in a license. I hope that the OSI board finds your license conformant. It is still a step in the correct direction in my book. -Chris Clark -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Open Source Business Found Parasitic, and the ADCL
MAA: Yes. I want to sell to commercial users and give away to others. That is incompatible with clause 6 of the OSD. Mark Murphy: For example, if what you are looking to release is a mature technology with an identifiable user base, you may be in fine shape with a not-quite-open-source license, if that user base will value your new licensing terms over what they have today. Which is a wonderful idea. However, to my knowledge no generally accepted license exists for that today. Especially, if one wants: the *exact* same code base to be commercially licensed and simultaneously available in source form for the public. The closest approximation I'm aware of is sell the present, free the past. It's not a bad model. However, some of us would like to truly give our current code away in a truly open source form and still sell it. I myself am dealing with exactly that conundrum. section which is a side-detal that belongs here extracted to below Some of the options we have considered are giving away older versions (the is a nice version of my software ca. 1996 that represents a nice complete thought and which could be easily open sourced, except for the fact that there are bugs in that version that are fixed in the current version, and the bugs are mixed in with enhancements, and how much effort do we want to go to for something we are giving away and intend to make no profit on???) or giving away stripped down versions (if we take the effort to port the current fixes to the 96 version but leave out the features, it is a version that is essentially a stripped down copy of our current code). Many companies do something similar to this by publishing gratis versions for non-commercial use, but, then those versions aren't really open source. And one can't incorporate parts of those releases in open source software. None of these options are as satisfying as finding a way to give away our current version and still retaining our rights. It is probably not possible. However, from all the efforts of commercial/proprietary software businesses to do so, you can see that it is an ideal to strive for. And despite the apprehensions of some members of this list, assuming that the only reason to want to do so, is to hijack the open source concept for commercial gain, there are propretary software vendors out there who wish to make their software more open source, one small step at a time, not for any self-serving reason, but simply because it has the right feel. However, some of us truly believe in intellectual property (that software is the fruit of our own hard work) and that our right to receive just compensation is another ideal which cannot be sacrificed in the process. from above: In particular, I have clients to whom I have sold proprietary copies to. I would be perfectly happy if those clients could use that software to create open source works that they distribute (with no forther royalties--our current software requires no royalties for distributing derived works). However, I don't want some non-client coming along and benefiting from the technology we have created and creating a propietary work without compensating us--once we are compensated we don't care. It is just the point of creating the derived work where we want and expect compensation. And, to tie this to the previous thread, that is why I was interested in the license that Abe Kornalis (I hope I spelled it correctly this time, I delete past postings so I can't be certain). Our mental model of where software has value is at the ability to create dervied works. Distribution does not interest us. You want to make billions of copies and give them to every person on the earth, go ahead. However, if they use our mental effort to save them mental effort, we would like an appropriate fee. Once we have been paid our fee, we don't care whether you as client charge further downstream fees or not, nor whether you give away source or not. That's our point of view. However, in the real world our license doesn't work that way, and unfortunately we haven't found a way to make it work the way we would like. Our default license does not allow our clients to distribute our sources as the part of their application, because if we did then we would loose our legal protection. We have to make point-by-point exceptions for the redistribution to keep things tidy legally. That's a real nuisance. Better for us would be a license that was closer to open source (or better yet truly open source) that recognized that derived works were still a right that as the original copyright owners we retained. Such a license would allow us to allow our customers to bundle our sources with their products and give them away, because they would not have given away our rights in our sources. The recipients of those copies would then be free to use the software as they saw fit (except for making new derived works using our parts, as that is still our
Re: Must publish vs. must supply
On Wednesday 12 March 2003 01:34 pm, Abe Kornelis wrote (editted silight by me in []: I'll stress my point one last time (you're bored stiff already, I don't doubt) I would offer the recipients of my software three choices: 1) make no modifications. 2) make mods and keep them private [under what conditions?] 3) make mods and publish to the public, either by [3a.] publishing yourself or by [3b.] passing a copy of the modifications to me. Obviously, item 2 must be under some restrictions, or there isn't any must in your 3. My feeling is that a license that allows only 1, 3a, and 3b is still open source (since the choice of 3a/3b) keeps the must restriction on musy-supply/must-public from being too onerous (well, that actually depends on how 3a and 3b can be acceptably accomplished under the license). I know that some/many people might object to a license that allows only 1 3, and it would not be a free license. Still, I do think it matches a model of sharing. It simply puts the point of where you have violated the author's copyrights at a different point (and that point matches my mental model). Moreover, I have no qualms that it prevents Chinese dissidents (or Al Queda memebers or whomever) from making private derived works. That is the intent. (Not specifically to penalize them, but to prevent others who can currently legally make private derived works of open source software form doing so with my software.) If doing something is illegal (or otherwise problematic) for someone, I have no desire to enable them to do it, by using a license that allows them to do it in private (since that right of privacy can be abused by others who I do not wish to have it). I would be saddened to find out, that I was required to give them that right of privacy to consider the license open source (as I might not then be able to distribute my software as open source). -Chris Clark One personal aside: I have been greatly pleased that the participants in this debate have chosen to try to consider the merits of each point soberly and with a minimum of inflammatory rhetoric. I understand that many of these points are volatile and could easily produce more heat than light Thank you. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Must publish vs. must supply
David Johnson wrote: Since the FSF rejects the APSL as being non-free, for the reasons that it regulates how the software may be used internally via a must-publish clause, then I'm pretty sure that you've got your terms backwards. I stand corrected. I did not consider the additional license terms to be pragmatic, but instead philosophical (thou shall not horde your software) and thus seemingly more inline with free software, but as I said, I was obviously mistaken. Clearly the FSF has decided that hording of software by corporations (as long as they don't distribute it) should be one of their freedoms. I find that a curious point, since as I understand it, the original impetus for the movement was some code that one corporation provided to Richard Stallman in source could not be used with another corporation's machine. To me hording is hording and if one creates a derived work of open software (thus becoming an author), then one should be willing to share the results with others. If software wants to be free (as someone once said), then it seems philosophically wrong to me to allow software to be imprisoned by a select group of people, just because we have decided they are end users. However, I do not speak officially for anyone in this regard, just myself. p.s. As to where the official differences between the FSF/Debian and OSI are in regards to must-publish, I would say it depends heavily on the individual queried. I can find any number of pairs of opposite vocal viewpoints in both communities. Perhaps this is how I became mis-informed. In the future I will try to refrain from categorizing this point of view as more in line with the free softare or open source movement as I cannot speak for either. -Chris Clark -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Must publish vs. must supply
In reply to: Clearly the FSF has decided that hording of software by corporations (as long as they don't distribute it) should be one of their freedoms. John Cowan wrote: The same applies to individuals. Do you want to be required to publish every little dink you make to GPLed software? How often? With what granularity? After every change? After every CVS commit? The answer is yes. I think that if I am using a modified version of an open source program, then I should be compelled to make that version should available if someone else wants it too, even if it is a little dink. I continue to think the GPL's attitude sensible: if you distribute the program, you must distribute the source. Yes, it is a sensible attitude. However, it is not the only sensible one and it is not necessarily appropriate for all software (or all authors). That is why there are different licenses. In particular, as an author, I am more concerned with derived works than distribution and I want a license that makes that (creating a derived work) the point of triggering the enforcement clauses. And since that is one of a copyright authors reserved rights, it is within my rights to chose that as the point of enforcement--I'm just waiting for an open source (or free software) license which does so. I don't expect other authors necessarily to share that view. I'm not trying to convince anyone that it is a superiour point of view. It's just my view. And to my mind there is imprisonment, software has been created and it has not been made available to others (that software is imprisoned, and when that software is based upon software I have written, my software is imprisoned within it). That is my point of view and that is what I would like the license my software is released under to reflect. You do not have to share that point of view. You can release (or use) software that is licensed in ways more conformant to your own point of view. -Chris Clark Off topic personal request: please don't cc me on replies to my posts unless you have reason to believe that I have not gotten the copy posted to the list (as it seems everyone on this list is in the habit of doing). It simply clutters my mailbox. Of course, that's just my view of netiquette, which again may be on the fringe. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Printer Drivers
I stand corrected on the point about the origin of free software. I had distinctly remembered reading that Stallman had a correct version on one machine (say a Lisp Machines computer) and wanted it for another machine (say Symbolics) but couldn't get or use the correct version due to a Non-Disclosure Agreement. However, maybe that is just an urban myth or an error in my recall. Apologies to all for my misremembering, -Chris -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Must publish vs. must supply
David Johnson writes: The FSF makes a (wise) distinction between privacy and secrecy. The boundaries between the two are the boundaries between the private and public spheres. A reasonable distinction. This brings up the question of where the private and public spheres end. Personally, the boundaries of a corporation (or any group) do not create a privacy boundary. By acting as a group, the individuals have made their actions public. Individuals may have the right to assemble, but they do not have blanket rights as a group (and in particular, when acting in concert their rights are specifically restricted). Looking at this another way, the laws do not allow corporations to take certain actions that they do allow individuals to take. That's because a corporation necessarily operates in the public shpere and the actions of a corporation affect many individuals. The rights of one individual however are generally private, because the actions and rights of one individula must be carefully balanced against the rights of another. Note that we don't even allow certain forms of association, where the purpose of those associations is in violations of the rights of other individuals. Thus, the rights of groups is truly severly limited, because by actiong in groups invidiauls make their actions public, even if they would otherwise be private. So, we do not allow corporations to discriminate based on race, gender, ethnic background, etc. while an individual within limits can. I just wish to apply the same limits to corporate use of software. It is not privacy as the corporation is operating in the public sphere. It is secrecy. What is the difference between imprisoning software by end users, and imprisoning software by the dictates of authors? Why is controlling the software in someone's private possession wrong if done by the user but right if done by the author? First, there is no absolute distinction between who imprisons the software. There are only the distinctions we apply by deciding what is right and wrong. Someone has the right to say the software will or will not be redistributed. That person has specific rights to imprison that software. The only question is on what basis do we assign that right to which individuals. In this case, there is legal precedent for the author's right to imprison the software. The right to make derived works is a right that is reserved to the author. Thus, some people have decided that that is where the right of imprisonment for software lies (in terms of making derived works). Other rights of imprisonment do not belong to the software author, but instead belong to the person who owns the copy of the software. Again, these rights have been established through precedent (and laws) over the years. You and I may not agree with each other nor with the legal precedents, but the precedents do stand as a body of decisions over who has which rights to imprison software in which ways. You may wish to argue that we set aside that precedent for this case. I feel that we should uphold it. My only point in entering this debate was to point out that the license restrictions suggested by Abe Kornalis do reflect that legal precedent and also reflect the desires of other software authors. Restricting the rights of others to make secret (and perhaps even private) derived works is a right that copyright law has established is within the authors domain. Unless one can find specific reason why it violates the open source (or free software) definition, I think such a license should be considered open source (and/or free software). Now, perhaps the privacy concern is sufficient to make the license not free software. However, I don't think it violates the open source definition--just my opinion again. Sincerely, -Chris Clark Again, a personal request: Please do not send me personal copies of mail that are also sent to the list. Extra copies serve no purpose as I can read the response sent to the list server just fine. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Must publish vs. must supply
In replying to: Is a must-supply (to copyright holder, that is) clause preferable over a must-publish (to the public, that is) clause, or vice versa. Mark Rafn wrote: Neither qualify as acceptible in my book. I'd be interested to hear from OSI board members whether this is an area where free as commonly used by the FSF and Debian differs from open source as used by OSI. Actually, as I understand it a must-xxx clause is closer to the definition of free-software than to open source. It is the GPL which established the viral nature, if you include free software in your program, you must provide it to your customers. The point of must-xxx clauses is to close a loophole where downstream authors can use the software in such a way that the effect is that it becomes closed source (un-free). If I write a piece of software and give it away under an open source or free software license, it is disturbing and offensive to discover that the software is used internally by a corporation to proprietary advantage, while the clients of that corporation (who are not be recipients of the software, since the use was internal to the corporation) are deprived of access to that derived work. A previous discussion on this topic posited the case where the software was incorporated into a web-server. Now, the actual server is not shipped to clients, only the pages it serves. This means that web servers can be used to close/make un-free previously open source software. The developer of the web server does not need to share his enhancements of the software with anyone. A must-xxx clause levels the playing field by eliminating this loophole. The web server author must publish his enhancements just the same as a person delivering the software on cd. -Chris Clark -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
[kmself@ix.netcom.com: Re: We are looking for an open source license that...]
Thank you, Karsten for your thoughtful reply. on Sat, Nov 09, 2002, Chris F Clark ([EMAIL PROTECTED]) wrote: 1) requires users to return to us modifications made to the code for incoporation into a future version (whether they otherwise distribute those changes or not). Karsten: Why? [much snipped] The reason for 1 (quoted below) is not so much as to receive the modifications although that would be a side benefit, especially in terms of making our software more portable (it currently runs on a variety of *nix platforms and the Windows family). It is more to discourage commercial users from using the open source version. We make a certain profit by being the sole provider of this software and we cannot afford to have that revenue stream dry up completely. However, we do not wish to deprive open source developers the bounty of our labor and have no qualms their using our tool to build open source programs that they give away. We just don't want some corporation using the open source version for proprietary software and avoiding paying us our rightful license fees. Note, in particular, our product is a tool that is used to build other programs and as such, one does not generally incorporate our product into the resulting open source software, except for the run-time library, which we have always provided in source code. This is the strongest argument for us distributing a gratis version. We can then restrict distribution to individuals (and not corporations) and allow them free use of the library under any open source license. However, we can not then label the product as open source. Moreover, we have to control the distribution (to make certain that the distribution restrictions were met), which as you have noted would limit mind share. And yes, I agree that the GPL would be the license of choice, IF only it would consider distribution within a company as redistibution and had a stronger requirement for compelling releasing sources. Many of our customers use our product because it gives the a technical edge over similar products. They use the product for in-house tools that never see the light of external users eyes. We are very frightened of losing that revenue stream if these users can get a free version that offers the same advantages. The closest analogy I can think of to our situation is Rational Rose. It is a great tool and one that I would expect my employer to provide if I could show true need for it. However, one can often get by with hand-drawn pictures on whiteboards, word documents, and scattered comments in the source code to achieve a fraction of the same effect and do so with little expenditure. Therefore, it is difficult to justify, although I am certain that those companies that use the tool receive competitive benefits from doing so. If Rational gave away Rose as open source, how many $2k per seat licenses would they sell? Would the world be a better place if they did? (I think my life as a developer would improve.) The question is, is there a way to give away ones product and still sell it at a premium? BTW, our current model is done on a pre-signed license basis (i.e. we publish the license up front and require acceptance before we ship and bill for the product) and our software does come with a limited warantee, in particular that it is free of third party IP infringements, with the relief that if such an infringement is claimed we will provide a non-infringing version or refund the purchase price, as well as a standard 30 day no questions asked return policy. (We've had about a 1% return rate since 1990.) -Chris -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
We are looking for an open source license that...
1) requires users to return to us modifications made to the code for incoporation into a future version (whether they otherwise distribute those changes or not). 2) allows us to distribute code under other non-open source/non-free licenses (including the user contributions we have folded in). 3) prevents users from distributing our code in a non-open source manner (so we can compel those who wish to do so to buy the non-open source version). We would prefer a license that also prohibits for-profit (or commercial) use in a non-open source manner, but that looks like a non-achievable goal while still using an open source license, since such a license would discriminate. (Most of our customers use our software to develop in-house, not for resale software, so we will certainly leave some money on the table with this strategy, but that's okay. A license that considered redistribution within a company as distribution would also be a plus for the obvious reason.) Does such a license exist? I get the impression from reading this group that several license writers are close to having developed such a license. We are not interested in developing such a license ourselves and want to use someone elses. Our situation--we have a non-open source piece of software that we have been selling since 1990. Over that time, we have repeatedly considered releasing either an open source version of the software or a non-commercial gratis version or both. We will release an open source version at the beginning of the year, if we can find an acceptable license by then. 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) -- -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Approval Requested for AFL 1.2 and OSL 1.1
Perhaps it makes sense (say in a preamble) to mention that certain sections (and obviously which sections) use wording copied from the US copyright code, so that eveyone knows that the reasons the words sound strange is that they are legal jargon with precise meanings -Chris -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: warranties
However, I may be confused by the term "merchantibility". I take that term to mean that a commercial product is fit to be sold for the purpose under which it is advertised. I can see no possible reason for a commercial concern to sell products it deems unfit for use, so I can't understand why software companies routinely disclaim this. While I can't speak for all vendors of all software, I can tell you what our lawyer told us when we were drafting our license (as best I can recall it). If the company doesn't explicitly disclaim all (implicit) warantees including merchantability, one leaves oneself open to a particular class of otherwise frivolous lawsuits. If one disclaims the implicit warantees, one must provide some explicit warantee for the contract to be valid. (Thus, the common warantee that "the media will be readable for a period of ninety days".) Certain problems are better to cover in a warantee (and to provide specific (controlled) remedies for, because disclaiming them actually opens a larger hole for lawsuits. (Patent issues are one of these areas.) All of these are simply "legal" concerns and do not have any bearing on whether the company will accept returns or not. The disclaimers are simply to help protect against certain legal tactics. Anyone can sue, but with the right defenses, one minimizes the chances that those suits will result in an adverse effect. The company I develop software for does accept customer returns (no questions asked). It's just a matter of good business sense. An unhappy customer is a constant problem. A less unhappy non-customer is someone who may later become a happy customer. However, our license includes the above protections--so if one just reads the license it would seem that we have no faith that our software will do anything. That is obviously not the case. Still we need to protect ourselves from unscrupulous people who might be willing to try suing us if it looked liked we were vulnerable. It's a basic problem with the legal system. Any well meaning agreement can be distorted and used to extract unintended concessions or as they say, "what you say can and will be used against you in a court of law." The legal system is not about what is right and wrong, but about what precedents can be brought to bear to win the argument even if the argument is falacious. 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) --
A question about distributing software under GPL
I'm sorry to interrupt the ongoing discussion of IPL and AFPL, but I have a simple question that I have been wanting to ask for a while and I had lost the mailing lists address, so I had to wait for a discussion to come along before I could ask. If we have some software (a library) that we wish to distibute under the GPL, but that software supports an application (specifically an application generator) that is not distributed under the GPL and is not open source, can we distribute the library under the GPL, and more importantly can we distribute it (and permits others to do so) with the non-open source program, since their interoperability is more than mere aggregation? Relevant facts (as I percieve them): The software to be released under the GPL is not currently open source (and has not been derived from any open (or closed) source materials)--i.e. the group wishing to distribute the software is the author of the software in all senses of the word and it is theirs to distribute under any licenses they see fit. The library may (or may not) have much value without the application generator (and the authors do intend to allow the software to be redestributed with or without the application generator--although the generator is not being released as open source). In addition, we intend to allow the applications generated (they are generated in source code) to be distributed as open source. Thus, in that sense in the context of a generated application, the library sources do have value for being redistributed without the application generator (and we specifically intend to allow that by placing the library under the GPL). Still, the real question is can the author of software release it under the GPL and yet distribute it with non-GPL software when the (interoperability) bonding appears to be tighter than aggregation? Note that we cannot be compelled to release the application under the GPL (or any other license) as it does not currently contain any GPL (or otherwised licensed) components. Of course, after we have released the library, the question becomes more interesting as the library was used in creating the application generator (as the generator itself is an example of the type of application that it can generate). However, it seems that we should, as the authors, be able to have a non-GPL license to our own library (again since it has no previously GPL parts in it) and thus distribute it under any terms we wish. Further, I presume that if we can release our library under the GPL with the related application generator (not under the GPL), this will not produce a hole in the GPL, since the only reason we want to claim that we can do so is that we have a non-GPL copy of the library code we used in the generator. If we had used any GPL (or otherwise licensed) code in our program, then we would have had to abide by that license (and in the case of the GPL release a source copy of our generator under the GPL (or not release it at all)). On a related point, if we cannot distribute our non-open source application with a GPL copy of our library, how could anyone release a CD with a non-open source Linux application and a copy of Linux (since the application is not useful without Linux, of which some parts must be GPL)? Does this argument make any sense? Is there any reason to believe that we can (or cannot) distribute our library and generator together in this fashion? Is there some other (related) way that we could achieve the same goals--for example distributing the package under some license that is itself not open source but which allows the libraries to be "extracted" from the package, where such an extraction causes the libraries to be under the GPL? - For those of you are interested why we might do this, we are attempting to follow the lead of L. Peter Deutsch and release old copies of our software under more liberal (and more open source) licenses. We expect no return for this release--we are doing it simply so we can easily give our software away (for example to universities)--in the hopes that by giving it away someone might do something useful with it that they couldn't (or wouldn't) have done without it. Note, at the same time we will be releasing a copy of the application generator (of the same version as the library) for non-commercial use (and not in source form). In fact, the whole point of releasing the library as open source is to support the non-commercial use of the generator (and we recognize that by doing so, we may be opening the library up to uses we had never intended, but hey that's a fact of life when releasing something as open source). Now, while this may not be of much interest to the open source community, because we haven't released the whole system as open source. It does enable the possiblity that more open source software will be created, for anyone that uses the
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: Simple Public License, draft
I don't know if this will help, but the licenses I have seen with non-compete clauses say exactly what the user's aren't allowed to build. If your tool is an "interpreter that runs servlets", then say the users aren't allowed to build "interpreters that run servlets" using your sources. That should make it quite clear what competing software is. If you have several things you want to list, how about using an appendix, and say the sources cannot be used to build the items listed in the appendix. Of course, the one thing I find complicating about this, is that you allow modifications in a previous paragraph. It is not clear that the two paragraphs do not conflict. Whie I understand that legally there may be a way of resolving that, as a naive user who wanted to make modifications, I would not know how to resolve that conflict, unless the license was more explicit as to which paragraph had precedence. -Chris
Re: [alexb@ufl.edu: Re: support requirement]
I don't see any gotcha. I would probably not need Vendor X's documentation and/or output to reimplement the program. You might if they were sufficiently clever. I can think of several pieces of software where the vendor has managed to implement something in a non-obvious way that has significantly improved performance over the naive implementation and that there are no competitive free software clones of for that reason (at least none that I know of and I've looked in some cases). If you can't think of any non-free software for which there are no free alternatives, you are missing a lot of software (and perhaps you are lucky enough not to need it). The best example I can think of comes from the EDA industry. There are a handful of commmercial simulator vendors that dominate the market and charge big-bucks for their tools, and have done so for some time. As far as I can tell, there is no effective free software in that market--and that's despite the fact that there are standard documents describing the simulation languages, which should mean that someone could just "implement the spec" and come up with a free tool. I think part of the reason is that the obvious implementation performs too poorly (hours of simulation time versus minutes) and the vendors have carefully tied their customers hands with NDA's so that the customers can't go to a free software developer and say "we would like you to make a free version with the following optimization" since the knowledge of the optimization is covered by the NDA. -Chris
[alexb@ufl.edu: Re: support requirement]
In a perfect world I would get to work with all free software. I don't want to work with code unless it's free. If I need code and the only code out there is available under Vendor X's license and I have the time and ability to reimplement that code and place it under the GPL, I will do it. There is one gotcha in that. The current Vendor X license may prohibit you from using it (including its documentation and/or output) to implement a competing version. They could put such a stipulation in a closed-source license. It is a simple variation on an NDA. If Vendor X has something they consider unique enough, they may attempt to protect their "ip" that way. This does not appear to be this vendor's motivation, since it sounds like they are actively considering distributing their software in an open source form (and hoping that their software will become the default in its niche). -Chris * Chris ClarkInternet : [EMAIL PROTECTED] Compiler Resources, Inc. CompuServe : 74252,1375 3 Proctor Street voice : (508) 435-5016 Hopkinton, MA 01748 USA fax: (508) 435-4847 (24 hours) -- Web Site in Progress: Web Site : http://world.std.com/~compres --
