Re: OpenLDAP license
From: "David Johnson" <[EMAIL PROTECTED]> > > If the OSI decides to focus on licenses, I suggest that it will find the > > BSD does not encapsulate enough of the OSD to guarantee the rights the OSD > > seeks to enumerate. > > ??? But the BSD license *does* encapsulate all of these rights. Let's take the OSD from the top. #1: BSD complies #2: BSD is mute. It does not encapsulate any portion of #2. #3: BSD complies, but is weak because it does not use a copyleft mechanism to require that the right to make derived works to be carried forward to each recipient. In other words, I can take a work using the BSD, add a modification, but restrict the right to make further modifications of my modification. The BSD does not require me to license my modifications using the BSD. [ as a side note, I think this is one of the places where the OSD itself is flawed. The language of #2 should say, in my opinion: "The license must allow modifications and derived works, and must REQUIRE them to be distributed under the same terms as the license of the original software." ] #4: BSD complies #5: BSD complies #6: BSD complies #7: BSD does not comply. (BSD code could be distributed in binary-only form with completely different and more restrictive licensing terms than the BSD). #8: BSD complies #9: BSD complies > So would a license that said in effect "zero restrictions, period". Such a license would have some of the same problems the BSD has. > Licenses by themselves are absolutely meaningless, in the same way > that deeds to property are meaningless without the property. The rights enumerated by the OSD can be secured for the public only by using a copyright license, because the default status of a work fixed in a tangible form in countries signatory to the Berne convention is "restricted by copyright". Because that is the legal default, the >license< must encapsulate the OSD. Otherwise, the fallback position is into a rights-limited strict copyright hostile to the ethical framework of the OSD. > The term "Open Source", applied as an attribute of software, means that the > software generally follows the criteria set forth in the OSD. Unfortunately, it does not. The definition of the term is subjective, not definitive. That's why "OSI Certified" is important. > And since I use the BSD license myself, I will have to object to any scheme > that removes that license from OSI Certification. Why? OSI Certification doesn't determine if your individual distribution is "open source" or not. Only the recipients of your work can make that determination. If you think it's important to the recipients of your work that the OSI certifies your release, then you should use a license which encapsulates the OSD. If the BSD is found not to sufficiently encapsulate the OSD (and in my opinion it does not), then the OSI should not certify it. Otherwise, in my opinion, the certification is essentially meaningless. OSI Certification should mean "the rights granted to you WILL comply with the OSD." Not "MAY" comply with the OSD. Ryan
Re: OpenLDAP license
I thought I was going insane there for a few days. The most recent list traffic has done much to clarify the points I was trying (and failing) to make. So here's my root question: What specific rights >should< an OSI Certified License enumerate? Some of the OSD? None of the OSD? All of the OSD? Coming at this from an outside perspective, I certainly believed that the OSD was supposed to describe the framework of an "open source" license, not the general "distribution" of a project. It is littered with terms which refer to the license, or to things the license must or must not allow or prohibit. I think that the terms "the license" and "the policies of the distributors of the code" are used as synonyms within the OSD, and they should not be. The concept of "conforming license + commonly available sourcecode == OSI Compliant" makes sense to me, but I think that it opens a lot of questions/holes in people's use or abuse of the "OSI Compliant" term, as evidenced by the recent series of examples. I think that one reason people are struggling so much with drafting "Open Source" licenses is that they don't have a roadmap. I also think that the OSI should concern itself with license terms only, and not with the other general policies of those who distribute the software. If they ensure that the OSD is encapsulated in the licenses they approve, then as long as the users follow the license terms, OSI Certified releases will ipso facto follow the OSD. If the OSI wishes to continue to concern itself with distributions rather than just licenses, then the OSD should be re-written to get rid of the references to licenses. If the OSI decides to focus on licenses, I suggest that it will find the BSD does not encapsulate enough of the OSD to guarantee the rights the OSD seeks to enumerate. And if the OSI decides that the BSD license shouldn't be considered "OSI Certified", what would be the real harm? OSI Certified doesn't mean "Open Source", since that term was held to be un-trademarkable. "OSI Certified" and "Open Source" aren't synonyms: "OSI Certified" is a subset of all potential Open Source strategies. Saying that BSD-style licenses aren't "OSI Certified" wouldn't mean that BSD-style licenses weren't Open Source, it would just mean that the license itself wasn't strong enough to ensure that the provisions of the OSD would be protected and respected. Ryan
Re: OpenLDAP license
From: "David Johnson" <[EMAIL PROTECTED]> > > "Accordingly, an open-source license >MUST< guarantee that the source is > > readily available..." > > But it does not say that the source must be made available for every > distribution. It says the license >MUST< guarantee that the source is readily available. Thus, the license >MUST< have a term which describes this guarantee. Because if the license does not have such a term, then the license does not guarantee anything. Ryan
Re: OpenLDAP license
> You are describing copyleft. Not all Open Source software (nor Free Software) > is copyleft. A copyleft is a legal mechanism of using a copyright license to require that anyone who distributes a covered work must grant a license to the recipient of that work with the same terms as the original license. It has nothing to do with source code. I have authored a copyright license which uses a copyleft to enable the distribution and modification of roleplaying game rules without any reference to software of any kind. Copyleft is a way of perpetuating copyright license terms forward to all future recipients of the covered work. Combined with a clause restricting modification of the copyright license, it creates an unchanging standard set of rights that one inherits when one receives a copy of the covered work. A "strong" copyleft forbids combining work licensed using the strong copyleft with work that does not to create a derivative work. Using a "strong" copyleft, one is given the choice of either making the whole work compatible with the strong copyleft license, or forgoing the use of those parts which cannot use the strong copyleft license. The GPL is a "strong" copyleft because it has this requirement, not because it requires the free distribution of sourcecode. > the entire Free Software Movement (they spell is capitalized) > agree that unrestricted licenses like MIT, BSD and Apache > are indeed 100% Free Software licenses. "free software" is software that is licensed to you using terms that prohibit you from imposing a requirement of the payment of a fee on the right of recipients of the software to make copies or redistribute the software. The FSF argues that the BSD license is "free software" (free as in beer). It also points out that the license does nothing to guarantee that it is "Free Software" (free as in speach). It is very careful to say that the BSD license is compatible with the GPL (because the BSD license really doesn't do much at all) - which is not the same as saying that the BSD license is >interchangeable< with the GPL. You cannot take something licensed using the GPL, toss the GPL, and distribute it using just the BSD. It is "compatible" with the GPL because it does not affect any of the rights the GPL seeks to secure. It is a "free software license" because it does not require the payment of a fee for the right to make and distribute copies of the software. The FSF argues that using a non-strong copyleft license is less than optimal because doing so removes the pressure (in the form of the strong-copyleft) on future developers to make their code Free as well. It admits that using software licensed to you as free software, essentially regardless of the terms, is ethical within the framework of the Free Software Foundation because your Freedom has not been abridged - and if you change the terms of the license or release a binary-only version to other people, then you are the problem, not the original license terms. Ryan
Re: OpenLDAP license
From: "Ian Lance Taylor" <[EMAIL PROTECTED]> >> My opinion is that the OSD reflects the ethical position put forward >> by the champions of Free Software, and that it represents their >> intent as to what should and should not be considered "Open Source". > You probably didn't mean it as such, but that is actually a somewhat > politicized statement in the insular politics of the free software and > open source communities. You are correct, and I apologize. I did not mean to make a political (or impolitic) statement. Quoting from the OSD page itself, this is what I meant to say: "We think the Open Source Definition captures what the great majority of the software community originally meant, and still mean, by the term "Open Source"." To me, this is the credo of the OSD. If we are to support the OSD, then the OSD should capture what the great majority of the software community means by the term "Open Source", and I suggest that for the great majority of the software community (in addition to many other things) "Open Source" means "binary-only distributions are unacceptable." > The two relevant statements are ``The > program must include source code'' and ``binary-only redistribution is > acceptable.'' Here is what I see. I see a requirement in the OSD that source code >MUST< be provided with binaries. Then I see a specific exception provided that requires the distributor of the code, if a binary-only distribution is made, to make the source available in a "well publicized manner". If the OSI wants to keep to this concept that licenses which allow binary-only distributions meet the OSD, then I think the OSD should be changed. First, the first sentence of #2 has got to go. Either you must include source, or its optional. If its optional, say so. If it's not optional and the OSI really means you must include the source, then take out the verbiage about not including source and don't certify licenses which permit binary-only distribution. Worst case, change the word "must" to "should". Second, I think that the OSD should require specific language in a certified license that explains what "well publicized means of obtaining the source code" is. I note that many of the current OSI certified licenses (especially the BSD varients) are completely moot on this topic. How can a license that does not discuss how to get the source comply with a requirement that the license ensure that the source be available in a "well publicized" manner? Specifically, I call your attention to the italicized comment in #4: "Accordingly, an open-source license >MUST< guarantee that the source is readily available..." Care to explain what part of the BSD license guarantees that the source will be readily available? > As such, the OSD was written to define what was and was not open > source software. I'm not comfortable describing the OSD as an > ethical position. I have tremendous respect for you sir, and have found your postings on this list to be uniformly excellent in logic and content. However, I cannot read the italicized comments between the sections of the OSD, which contain phrases like "users have a right to know who is responsible for the software they use", and "Distributors of open-source software have the right to make their own choices about their own software." without drawing the conclusion that the OSD codifies a set of ethical principles. Discussions of rights are inextricably linked to discussions of ethics. I must therefore disagree with your interpretation of the content of the OSD. It is as much an ethical framework as the Declaration of Independence is. And like the Declaration which heavily influenced the contents of the Constitution which resulted from it, the OSD has to acknowledge that the ethical framework it espouses will be encapsulated in the licenses it inspires. Ryan
Re: OpenLDAP license
> This is the case of the Berkeley license, for example. The Berkeley > license is OSD-compliant. However, anybody who receives a legal copy > of code under the Berkeley license may redistribute it themselves > under different terms. In particular, the Berkeley license permits > binary-only redistribution. So my question remains: Is the OSD as written too specific regarding its requirement that the source code be commonly and easily available to recipients of the software? My opinion is that the OSD reflects the ethical position put forward by the champions of Free Software, and that it represents their intent as to what should and should not be considered "Open Source". I hate to sound like a nag, but I just can't reconcile "The program must include source code" with "a binary-only distribution is acceptable." What is the point of Open Source then? Is Microsoft Windows open source? If you're one of Microsoft's 1,000 biggest customers, they'll give you the source code to Windows. Sure, 60 million people don't have the source, but some people do, and that seems sufficient to comply with this interpretation of OSD #2. Ryan
Re: OpenLDAP license
From: "David Johnson" <[EMAIL PROTECTED]> > Since this license appears on the very same site where I can download the > source code, it counts. It seems axiomatic to me that any license seeking to comply with the OSD must have explicit instructions detailing the responsibility of each party to the license (meaning anyone who distributes the software) to make the source available when they redistribute the code. The proposed license could remedy this by adding a sentence to Section 2 stating that the source code must accompany any binary distribution, or instructions must be provided to each recipient of a binary-only distribution on how to request the source code or locate it on the internet. The fact that numerous OSI approved licenses do not address this issue seems to me to be a fundamental failing on the part of the OSI certification process and indicates that a top-down review of the process and the standards of certification should be undertaken. The OSD specifically calls for a "well publicized means of obtaining the source code", and I believe that in order to qualify as an OSI certified license, the license should explicitly state a mechanism for obtaining the source code. Anything else is external to the license and thus beyond the control of the law, and thus beyond the intent of the OSD. Therefore, my opinion is that the OSI certified licenses which do not comply with that need should be de-certified until such time as they do. Either that, or the OSD should be modified by deleting Item #2 in its entirety. It seems to me to be a binary choice: Either #2 is enforced in the certification process, or it is removed from the definition. Having it in the OSD, but not requiring OSI certified licenses to implement it's terms seems hypocritical. Note that the OSD does not concern itself with matters "understood" by others, or "common knowledge". It specifically concerns itself with "The distribution terms of open-source software". Thus, each and every item on the OSD list should be encapsulated by the licenses which seek to implement it, and should be a requirement for OSI certification. To me, this is the single most important aspect of the whole OSI effort. If we are not to champion free and easily accessible source code as a primary mandate of the organization, then we should shut the organization down and go back to explaining the difference between free speech and free beer along with every copy of the software we distribute. Without source, there is no Open Source. >> And if "due credit" means "money", it violates #1 as well. > It's pretty clear that "due credit" in this context refers to attribution. I couldn't tell if you were kidding or not about this item. Clearly, "due credit" is an unacceptably vague term to use in an Open Source software license, which will be subjected (if tested) to the most critical of dissections should the issue ever be litigated. "Due credit" is a vague term that is essentially undefined - meaning that someone downstream could claim that it means whatever the heck they want it to mean. Including "you must pay me $100 dollars per copy for redistributing my code." If the drafter of the license means "All redistributions of the code must include a public acknowledgement that the work is based on materials derived from code created by the OpenLDAP Foundation" then that is what the license should say. Otherwise, the term is at best irrelevant, and at worst a potential OSD #1 conflict. Part of the point of submitting licenses to this list is to get feedback about them and help to improve them based on the shared community experience in dealing with the concept of Open Source and Free Software. I'm frankly surprised at the seemingly hostile tone of the responses I received to my feedback. Ryan
Re: OpenLDAP license
OSD #2: "The program must include source code, and must allow distribution in source code as well as compiled form. " And if "due credit" means "money", it violates #1 as well. Ryan
Re: OpenLDAP license
What does clause #6 mean? What is "due credit"? I could argue that "due credit" is a crisp US$100 bill, mailed to my home address. There's nothing in the license that says the code and derivative works therefrom must be governed exclusively by the license. (All you have to do is provide a copy of the license. You don't necessarily have to follow the license.) The license does not require that the source code be distributed with binaries. (That means it doesn't comply with OSD #2.) Ryan
Re: licenses for RPGs
Do you have the right to make a game which is mechanically compatible with another game? Yes, it appears that you probably do, unless there is a patent or trademark right involved. Do you have the right to make a product which contains the unique copyrighted content of D&D, or derivative works therefrom? No, in my opinion, you do not. And in-between lies a big grey area where only a court can decide, on a case by case basis, if a particular work is an infringing derivative work. The OGL (like the GPL) is just a framework for getting rid of the threat of lawsuits and the grey area. Sure, you could black-box and clean-room Linux, but you're far more likely to use Linux with the GPL, because you can do so at essentially no cost, and in a framework which provides for little risk of litigation. The OGL framework, when applied to the System Reference Document, provides a way to make D&D compatible content that is far, far more extensive than the basic rights you might have as they relate to the public domain status of the game rules of D&D. And there's no grey area. Both conditions which make it possible to bring to market a commercial product without having to provide for a substantial threat of litigation. And it's furthermore quite silly to point at the former TSR (now Wizards of the Coast) business and say that the climate of litigation is fostered by one company. Every commerical hobby game publisher has taken the exact same position for 25 years - that the mere game rule content in an RPG is the least part of the copyrighted work of an RPG, and that derivative works based on such a product are infringing. The OGL and the d20 concept are a step away from the parochial view of RPGs as isolated creative endeavors and towards a view of clearly deliniated rights - and to my mind, that's a positive step forward. Ryan
Re: What is Copyleft?
From: "Dave J Woolley" <[EMAIL PROTECTED]> > or you link it against the dynamic version to create a dynamically > *linked* executable, which can load the full text of the library > and run time. > There are three possibilities here: > > - unlinked (LGPL gives a dispensation on the headers used); In my opinion, not a derivative work. LGPL neither grants nor restricts rights to this situation, except as relates to the distribution of the source code of the LGPL'd material, and in that sense, the code might as well be GPL'd. The function prototypes in header files almost certainly cannot be copyrighted, thus there's no point in licensing their use. In fact, you can almost always call an exported function by ordinal number, thus I wouldn't even have to include the actual function names in my non-licensed code; I could just call the functions by ordinal rather than by name. > - statically linked; In my opinion, a derivative work of all the sources of the object code, because they're all combined into one work when the compilation is complete. With the GPL, all of that code would also have to be GPL'd. With the LGPL, nothing but the LGPL'd library code needs to be covered by the LGPL. This, I think, is the most valuable use of the LGPL for programmers working in a mixed free/non-free environment. It allows a free-software library to be used with non-free code. From the standpoint of the FSF, this is a very suboptimal situation (because it tends to allow non-free code to proliferate by leveraging free code). If a court found that the first and third results Mr. Woolley enumerated were not derivative works (and thus could ignore the terms of the LGPL or the GPL for non-free code), I suspect that a case could be made to the FSF for abandoning the use of the LGPL. I suspect that the "statically linked" scenario is permitted because allowing unlinked and dynamically linked code essentially means that not allowing it would just be frustrating, requiring a program to dynamically link at program start, essentially achieving the same result. > - dynamically linked. In my opinion, not a derivative work, because the parts are never combined into one work. In my opinion, from the standpoint of making a work a derivative work, the law does not understand or care about the concept of a thread of execution, no more than the law cares about the order you read pages in a collection of books. Furthermore, I would argue that the GPL doesn't cover this situation, because the GPL explicitly disclaims any authority over what the program does once it starts to execute. "The act of running the program is not restricted." The only part of the free code that is actually combined with the non-free code are the function prototypes, which I maintain cannot be copyrighted, and thus are not governed by the terms of either the LGPL or the GPL. Ryan
Re: Fw: What is Copyleft?
From: "David Johnson" <[EMAIL PROTECTED]> > > Making a function call > > is not the same thing as actually incorporating the code of that function > > into the body of the calling code. > > Though I'm on your "side", there is a big difference between data transfer > and code execution. Transferring data between two processes by way of IPC or > a network protocol is in a completely different realm than a single thread of > execution weaving its way in and out between an application and a library. As a practical matter, I agree. As a programmer, I understand the concept of a "thread of execution". Does the copyright statute? In other words, does the law see a series of instructions executed in a certain order as a derivative work, regardless of how those instructions came to be excecuted in that order? Imagine I have two novels. On page 100 of Novel A, there is an instruction: Open up Novel B, turn to Chapter 7. When finished, come back to this point and continue reading. As the reader, (the processor in this analogy) I follow these instructions. My "thread of execution" takes me from Page 100 in Novel A, to Chapter 7 of Novel B, and back to page 100 of Novel A again. Are Novel A and B now a derivative work? Ryan
Fw: What is Copyleft?
Inadvertantly sent just to Mr. Dixon - my apologies to him for the double post. From: "Rod Dixon, J.D., LL.M." <[EMAIL PROTECTED]> [ I said, in reference to various library linking examples:] >> How can that create a derivative work? >> > Well, the question is why wouldn't it? Because you're not modifying the original work. You're not adding anything to it. The two parts (the Program and the Library) aren't ever combined into one work. If you would argue that they are combined because they're both loaded into memory together, than you'd have to say that >everything< in the computer's memory formed a derivative work, so you could >never< use a GPL'd program unless every byte of information in the computer's memory was also GPL'd. >> If I use a GPL'd program to output a CSV data file, and import that into >> a database, is a derivative work created that combines my code and the >> database? >> >Try a better hypo or simply state what you are driving at. My above example is flawed. It should have read "a database management program". I'm suggesting that the definition of a derivative work can't include data being passed between two independent pieces of code, via file, via a network, or via an internal process communication. Making a function call is not the same thing as actually incorporating the code of that function into the body of the calling code. When you make a function call in compile-time linked code, you are creating a derivative work, because the function code itself will be compiled into the Program and inextricably combined with your code. When the two are separated by a run-time linking, there can be no derivative work. Imagine this example: I write a program which runs interactively. It takes an input of the name of a DLL. The program loads the DLL, which will cause some of the code in that DLL to excecute automatically when the library is loaded, even if the calling program does nothing. If the hypothosis that run-time linking created derivative works is true, the above program could never be covered by the GPL. This is not such a far-fetched example. This is how printer and video drivers work in Windows, for example; and many are not distributed with the OS. It would be impossible to write a GPL'd program that used the standard device-driver model for printing using Windows if this run-time linking hypothesis were valid. > There is, however, one disadvantage; > the copyright holder of the library might create problems if they are or > become an opponent of open source. I think that's a danger of calling functions in non-free libraries. I think it's a potential design flaw. I don't think it's a copyright violation, thus I don't think the GPL governs the situation. Ryan
Re: What is Copyleft?
From: "John Cowan" <[EMAIL PROTECTED]> > Dynamic linking with unfree libraries *not* distributed with the OS is a > gray area in the GPL. When it was written, dynamic linking was a > marginal concept. The FSF believes that linking with unfree dynamic > libraries, except as mentioned above, is not allowed. Section 0: "a work "based on the Program" means either the program or any derivative work under copyright law..." Is the argument that a run-time link to external code creates a derivative work (in the sense that the copyright statutes define a derivative work) of the Program and the external code? Under this theory, you couldn't use GPL'd code with RPC or HTML or SMPT or any other inter-process communication system unless the whole system was GPL'd! If I understand the internals of the situation correctly (which I may not), a program that binds to a DLL at runtime does so through the mediation of the OS. Data is packaged, handed to the OS, the OS moves it from the process making the call to the target process, where the data is unpacked and loaded into the target's address space. There's never a time where the free software is even in the same address space as the (potentially) non-free library code. How can that create a derivative work? Is a web page with external URLs a "derivative work" of the base page and all the pages the links (and those page's links, ad nauseum) refer to? If I use a GPL'd program to output a CSV data file, and import that into a database, is a derivative work created that combines my code and the database? Also from Section 0: "The act of running the Program is not restricted." That would seem to exclude anything the code does once it starts to execute from being covered by the terms of the GPL, would it not? Ryan PS: I completely understand how the utility of a program could be crippled if it relied on non-free code in an external library. However, I don't think you can say that the copyright statute's definition of a "derivative work" extends the license's conditions to the external libraries. I think you would have to add a section to the GPL that explicitly required the source code of any library bound at run-time to be covered by the terms of the license; a term that would be particularly tricky to draft since the program could be written in such a way that the library that would actually be bound at run-time was indeterminate when the software was written (such as selecting from a number of different printer drivers or video drivers, some of which may antedate the release of the program itself...)
What is Copyleft?
Here's a question I thought I'd never have to ask. What is a Copyleft? The reason I ask this question relates to RMS's recent pronouncements about Apple's psuedo-open license terms. He says, in part, that one of the flaws of the license is that: "It is not a true copyleft, because it allows linking with other files which may be entirely proprietary." I the working definition of "copyleft" I have been using is: "A way of using contract law (through a copyright license) to ensure that everyone has the freedom to copy, modify and distribute a given work. It takes the copyright law and turns it inside-out. Instead of being used to limit what you can do with a copyright work, a copyleft ensures that your freedom can't be abridged." Now, let me say that for the purposes to which RMS developed the GPL in the first place, his indication of a "flaw" with the Apple license is completely consistent. However, I would say that the ability to link with non-free code, while an incompatibility with the GPL, isn't a copyleft problem. If the license allowed a user to link to non-free code, and distribute the combination in object-form only, then I would say that it was a copyleft problem, because free code would be rendered non-free (the gestalt work would have two copyright interests; the Free part, and the non-Free part, and thus the work as a whole couldn't be distributed without additional permissions). If I write a copyleft free program for Windows, I should be able to load and link at runtime to any DLL in the system, regardless of whether or not that DLL is free code or not, shouldn't I? How else could a Windows program ever be written using the GPL? (I don't know enough about Linux to have an opinion about Linux code). The copyleft concept is supposed to ensure that any material I use or modify which is based on copylefted content has to obey the same terms as the original copyleft license, correct? The concept of "copyleft" itself shouldn't be so specific as to include material related to the linking model of computer software, should it? Ryan
Re: Converting/Splitting Code - Open to Closed
From: "Ralph Bloemers" <[EMAIL PROTECTED]> Can the OWNER of the copyright in software code that has been released under a GPL (http://www.gnu.org/copyleft/gpl.html) change its mind and take the software *private* (any future versions would be proprietary and released only under typical object code only licenses)? == Someone could attempt to secure a patent on the code after it was released using the GPL. Assuming a patent was granted, the patent holder could then stop the distribution of the code by requiring the payment of a royalty for distribution, thus making it impossible to distribute the code and conform to both the GPL's terms and the patent licensing agreement. This is one of the dangers of basing Linux (or any other large, multicontributor project) on the GPL; the threat that something embedded deeply in the code could eventually have an external patent applied, necessitating a rewrite of the affected portions of the software; and possibly "breaking" dependencies. The GPL is a copyright license, so it isn't going to be much help in defending against a hostile patent suit. Ryan
Re: Open Source *Game* Programming License
From: "Henningsen" <[EMAIL PROTECTED]> > The game programming community has another big problem with the GPL: > Cheating is much easier when you have the code. Of course, there's another faction in the community who believes that by having the code, work can continuously be done to thwart/foil the hackers; most of whom are able to use the same debugging/profiling tools the developers have and can get at the internals of object-code only releases anyway. Openness is good for gaming just like it is good for cyrptography. Ryan
Re: Open Source *Game* Programming?
From: "Henningsen" <[EMAIL PROTECTED]> > Is there any open source certified license that meets these criteria? No, because a requirement to pay a fee is a restriction against free redistribution of the software. This issue is addressed directly by the OSD FAQ. > And a more philosophical question: If it is against the spirit of open > source to require commercial users to buy a license, why is that? Because the intellectual heritage of the free software movement assumes a moral right for >everyone<, not just non-commercial users, to have unrestricted access to the source code running on their computers, and the right to make changes and modifications as they see fit. The people whom the OSD addresses are the end users of the software, not the publishers. The free software vision is that the kid who buys a game using your engine should have an unencumbered right to tinker with it, and release those modifications to the public so long as the same rights are conveyed forward to the next recipient. > Remember, the > modifications a publisher might make to my code are worth nothing. The > graphics is what is valuable. That's a very narrow, and impractical view of the business of selling game software. If anything, it's easier to get good artists than it is to get good programmers. While the sunk costs may be heavily tilted towards the art vs. the code, the technical challenge of bringing the product to market is clearly with the code, not the art. Publishers spend tremendous amounts of money developing, testing and supporting the code base for computer games. The question you have to ask yourself is this: Is it more important to me that my work get wide distribution even if someone else gets wealthy as a result, or is it more important that I know that nobody is making money off my work unless I do too? Ryan S. Dancey Learn about Open Gaming: www.opengamingfoundation.org
NVIDIA GPL violation
Reading /. today about NVIDIA using some GPL'd code in their XFree86 driver raised some questions for me. >From the description given, it seems that NVIDIA used at most a handful of lines of code from the middle of someone else's program; that program being covered by the GPL. The author of that code contacted the company and informed them that they were violating the GPL and that they needed to remedy their breach of contract. I'm assuming that it is the stance of the community that the use of >any< GPL'd code is sufficient to create a "derivative work" and thus trigger the terms of the license itself. I'm wondering if that is in fact an accurate interpretation of how a court might rule on the matter. Since the GPL is a copyright license, and copyright covers the expression of ideas, not the ideas itself, the small part of GPL'd code used by NVIDIA might not cross that line from "expression" from "idea". Is there any standard test the courts have used to determine when a software program is derivative of another? Is the test "any code re-use at all" or is there some test of the ratio of new to recycled code? Ryan
