Re: IPL as a burden
G'day all. On Wed, Jan 17, 2001 at 11:34:49AM +, SamBC wrote: > The OSD requires that licenses do not discriminate against a group of > people - it may be pushing it, but this license discriminates against > those unable (or at an even greater push, unwilling) to pay a license > fee. That _is_ pushing it. The GPL discriminates against those unable or unwilling to comply with the GPL. Cheers, Andrew Bromage
Re: IPL as a burden
G'day all. On Wed, Jan 17, 2001 at 06:48:44PM -0800, Frank LaMonica wrote: > Please clarify or expand on that statement. The issue under discussion was what incentive would hackers have for contributing to a product released under a Source Included Software scheme that was not Open Source such as, for example, software released under the IPL as it currently exists. Someone from intraDAT (I think it was Manfred) said earlier that the company would offer money to people who sent improvements to their software back to them if they included it in the product. No details have come out about how this would be done or what guarantees there would be (and nor should they; this is an OSS licence discussion list, not a forum for discussing business practices of non-OSS companies), however I think this addresses the point. Rather than building an external group of unfunded developers under the bazaar-based OSS model, build an external group of partially-funded developers. I don't pretend to have any insight as to whether or not such a business model would succeed in the real world. Cheers, Andrew Bromage
Re: IPL as a burden
G'day all. On Wed, Jan 17, 2001 at 10:17:41AM -0800, Frank LaMonica wrote: > I like the terminology you used: "source included software (SIS)". SIS would > be much better than a closed source, proprietary alternative, but I don't see > any incentive for open source programmers to contribute to such a program. As I understand it, interDAT will be offering them money. Cheers, Andrew Bromage
Re: Free Software Licensing Strategy -- Some guidelines
G'day all. Karsten, you've done an excellent job with this. There is one point that I'd like to make which might be worth adding, as it's a common misconception. On Tue, Jan 16, 2001 at 02:11:24AM -0800, [EMAIL PROTECTED] wrote: > The Artistic License is notable for its use with the Perl programming > language, however, it's a somewhat eclectic and ambiguous document. The author of Perl and the Artistic License, Larry Wall, has publically stated several times that it was specifically designed to be used as part of a dual licensing scheme only. For example: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-08/msg01317.html When choosing the Artistic License, if you ignore Larry's advice and do not dual license with some other open source licence, you do so at your own legal risk. Cheers, Andrew Bromage
Re: IPL as a burden
G'day all. On Mon, Jan 15, 2001 at 04:51:27PM -0800, Lawrence E. Rosen wrote: > Economic arguments in support of open source should be > carefully reasoned. I'm not an economist, I don't pretend to be an economist and I am not qualified to make economic arguments. I'm merely stating some of the things that I as a consumer take into account when making purchasing decisions. Cheers, Andrew Bromage
Re: IPL as a burden
G'day all. On Mon, Jan 15, 2001 at 07:55:22PM -0800, Frank LaMonica wrote: > If you read the > rest of my posting, you would see that I continued on by saying the people on > this list are exceptions - they do care about the source code. Unfortunately, > we are the extreme minority. I did read that and agree that this is the current situation. I do not believe that it need be so. > BTW, your analogy about a car is no longer valid. Almost all new cars are > controlled by proprietary programs running in embedded processors that can only > be accessed by very expensive equipment that is tightly controlled by the car > company. The days of tuning your own car without a computer are over, we've > lost the automobile war :( I've never bought a new car, so I wouldn't know. :-) In fact, I think this makes my argument all the stronger. I _can_ run my 15-year-old car if I want to. For example, if it was designed to run on leaded petrol, I can modify it so that it accepts unleaded, LPG or unleaded with non- lead additives when leaded petrol is no longer sold, as it will be in a few years' time. OTOH, try running fifteen-year-old software written for a platform that is no longer sold if you don't have the source code. Just so that nobody misunderstands me, I'm making no statements about economics or law (whether that be the law is it is or as it should be). I'm merely stating as a consumer what I want to be able to do with the things that I have paid for. That's one reason that I use a lot of open source software. However, like most people, it's not a "show stopper". I would never go so far as to refuse to buy from a company just because they don't let me tinker with their products. And it's one reason why I don't use open source software exclusively. My point is: the question of whether or not I have the right to hire any appropriately qualified person to repair or modify a product, the right to resell it or give it away when I've finished with it and the right to do any of the above without the permission of the person I bought it from _does_ affect my purchasing decisions, whether or not I am personally qualified to do it. People already think this way about their cars, their PCs, their homes and any number of other items they have paid money for. Imagine if you had to hire the original builder back if you wanted an extension to your house! I'm not even close to being a master builder, but I, like most people who think about it, value the ability to hire who I like to do said modifications. I happen to be in the same mindset about my software, the only difference being that in the case of software, I can do a lot of the modifications myself. Cheers, Andrew Bromage
Re: IPL as a burden
G'day all. On Mon, Jan 15, 2001 at 04:36:38PM -0800, Frank LaMonica wrote: > Most users of software don't consider the availability of source code in > their purchasing decisions. Why? Because they are not in the business of > writing software, they are simply using an application as a tool. I think they might take the availability of source into account if they understood it better. When I buy a car, I don't care about tinkering with its innards because I am not a mechanic, and have no aptitude or desire to become one. However, I do insist that my car be servicable by any appropriately qualified mechanic that I nominate. That way, I'm not locked into paying the company I bought the car from every time it needs maintenance. With a car, that means many things including good engineering such as low coupling between independent systems (if I change the colour of the upholstery, that shouldn't make the headlights stop working) transparency (i.e. that the insides of the car are not hidden) and openness (anyone can produce service manuals, spare parts or even a clone of the whole car if they want to). And in the end, I should be able to modify the car to my hearts' content (maybe put in a different sound system, maybe put in a cargo barrier, maybe convert it to run on unleaded petrol or LPG) and sell it to someone else when I don't want it any more, and not have to get permission of the original car manufacturer to do any of these things. Naturally I would wait until the warranty expired (assuming the car came with a warranty) before doing anything not approved by the vendor, but it wouldn't be because the vendor forced me to. Would you buy a car that didn't let you do any of this whether you're a mechanic or otherwise? If I were not a programmer, I'd reason the same way about software. If my purchased software needs maintenance, I don't want to be at the mercy of the company I bought it from. I want to be able to hire any appropriately qualified programmer that I wish, or even do it myself if I think I know what I'm doing; after all, I'm not a mechanic but I can change a tyre with the best of them. I should be able to freely give details of my fixes/enhancements to others, and I should be able to resell the software when I'm finished with it. I should not have to get the original vendor's permission to do it. Would you buy software that didn't let you do any of this, whether you're a programmer or otherwise? This is not the full set of rights provided by Open Source, but if I were not a programmer, it's what I'd be looking for. Cheers, Andrew Bromage
Re: Misunderstanding of the basics?
G'day all. On Mon, Jan 15, 2001 at 06:42:28PM +, Dave J Woolley wrote: > In any case, the GPL is only requiring that you record the removal > of the code, whereas you are forbidding its removal, in this clause, [...] One of the things I notice is that the requirement of the GPL not to remove certain documentation and the IPL requirement not to remove certain lines of code are in some sense equivalent. In a very abstract sense they are, but there is a key difference. The GPL requirement is there to enforce what in Europe is referred to as "moral rights", specifically the moral right to be identified as the author of a copyrightable work. In some countries, this right cannot even be waived! The GPL documentation restriction (i.e. you must state what changes were made and who did it) as merely codifies this "moral right". I would even argue that the OSD perhaps should contain a clause that an OSD-compliant licence may contain requirements a list of modifications be maintained and preserved. Restricting what derivative works can and cannot contain is very different from preserving the software's audit trail. The former is a business decision which is in conflict with the OSD, and the latter is good engineering practice. :-) Cheers, Andrew Bromage
Re: AFPL vs. GPL-like licenses?
G'day all. Robert Feldt wrote: > What are the implications of using AFPL versus using GPL? As another said, the key is to determine what your goals are, however I suspect that you already knew that. You appear to have implied that the good will of the community is a possible determining factor, so you should factor that into your list of goals, and be prepared to bend, because the community's goals and your goals may be in conflict. Whatever happens, remember that you always have the option of combining more than one licence. For example, if you can't choose between two licences, you could release under both and give the licensee the choice. Perhaps the combination of AFPL+QPL, giving your software both liberal non-commercial distribution terms plus the option of more stringent but provably Open Source(tm) terms. Or you could do what Aladdin did and release new versions under the AFPL and older versions under an Open Source licence. Any of these options might carry more favour with the community than using something which is not OSD compliant. Then again, you may wish to look at your software and decide who its intended audience is and what that intended audience would be prepared to accept. It's IMO usually perfectly acceptible to ignore those who would never have used or been affected by your software anyway. :-) Cheers, Andrew Bromage
Re: Qt/Embedded
G'day all. On Saturday 18 November 2000 04:32 am, [EMAIL PROTECTED] wrote: > > You're aquainted with how a linker works? [...] On Sat, Nov 18, 2000 at 10:49:11AM -0800, David Johnson wrote: > For a few linkers, maybe. For others no. [...] If I may ask a meta-question here... This question has come up before when talking about referencing libraries from source code. Some languages do not textually include any source code from the library when linking it in, using some kind of automatically generated "interface file" instead. Some (e.g. C, assuming the programmer plays by a standard coding convention) textually include only that information which is necessary to access resources in the library. Some (e.g. C++) may textually include actual code. Would a real court actually rule on this? It seems so... uhm... outside the scope, if you know what I mean. It could mean that a given generic licence (e.g. GPL) could be enforcable on one platform but not on another, or in one language but not in another, depending on how the platform or language developer chose to implement some standard feature, and while I don't claim to know the minds of US judges, this does seem to be an area that they'd rather not get into. I would think they'd rather rule on the principle of linking, or the principle of library use, as opposed to ruling on specific techniques to implement those features. Or is this just wishful thinking? :-) Cheers, Andrew Bromage
Re: Do programs compiled with a GNU compiler have to be open source?
G'day all. On Sat, Oct 28, 2000 at 11:24:30AM -0400, [EMAIL PROTECTED] wrote: > Do programs compiled with a GNU compiler have to be open > source? The short answer is "not usually". The longer answer: I would think that it would be exceedingly hard to argue that the output of a compiler is a derivative work of (or "work based on") the compiler or any standard libraries that must be provided as part of a conforming language implementation, especially if the language has at least one other sufficiently conforming implementation. IANAL, but I know that I wouldn't like my chances defending that position in court. A possible exception might be if the compiled output is mostly boilerplate (e.g. as is the case with the output of yacc/bison or lex/flex). You will almost always find, though, that compiler writers that use a GNU licence _their_ work protected by it, not yours. The Free Software Foundation is particularly nice about this. You will invariably see in the documentation a disclaimer that using this GPL'd compiler does not in and of itself make your programs covered by the GPL. You should naturally check your own compiler's documentation for details. Cheers, Andrew Bromage
Re: Apache v. GPL
G'day all. W. Yip writes: > > Then again, how does an advertisement clause such as the above amount to > > incompatibility with GPL? On Tue, Apr 11, 2000 at 09:13:21AM -0700, Seth David Schoen wrote: > The GPL requires people relying on its permissions to grant the same > permissions to others in order to distribute code. Of course the copyright holder does not rely on any permissions in order to distribute their own code. If I create GPL'd code which I attempt to combine with pre-existing Apache-licensed code, I am not bound by the GPL on my own code. That suggests that for me the two licenses are "compatible", doesn't it? I may have effectively stopped others from redistributing my code, of course, but that's my fault for choosing an "incompatible" licence. Cheers, Andrew Bromage
Re: Licensing and public performance
G'day all. On Mon, Apr 03, 2000 at 05:53:20PM -0700, Seth David Schoen wrote: > There have been some rumors that version 3 of the GNU GPL may require > disclosure of source code in some cases of public performance. I have also heard these rumours. I believe that this is intended to deal with server-based applications. > I am not sure whether or not the situation you describe counts as > public performance. Nor am I. I suspect that it would depend on how much the software is used in the work, and what role it plays. For example, if you produce a recording of some synthesised music on recorded onto a writable CD, I would guess that the final work may count as a public performance of the synthesis software but most likely not of the CD recording software. > The OSD has no particular comment on this, although many people have > felt that it is inappropriate to use a license to violate the privacy > of the users of some software package. There may be media-creation software "out there" whose licences require that works created using the software include a credit. Could anyone who uses such software please take a look at their licences to see if they do? Mind you, that might be based on shrinkwrap agreements rather than appealing to "public performance". As for the OSD's comment, I was worried that it might be discriminatory against fields of endeavour: those producing media for distribution with this software have to redistribute the software, but others do not. That looks too much like "commercial users must redistribute the source but non-commercial users don't have to". Cheers, Andrew Bromage
Licensing and public performance
G'day all. I'm co-writing some software that is only really useful in a certain media industry which doesn't have a history of being very "open" with their source. If it is used within the industry, it will very likely be internally modified by media producers and used to produce works, and the modified versions will almost certainly not be distributed. I'd like to prevent this, but also, obviously, I'd prefer not to trample on fair use. I suspect that the answer lies in restricting "public performance". So let me ask the lawyers and non-lawyers: Could I license a program so that if you distribute a work which was created using a modified version of the software (which could be considered as "public performance" of the software), you must redistribute the modifications that you made? And would it violate the OSD? Cheers, Andrew Bromage
Re: Wired Article on the GPL
G'day all. On Thu, Mar 30, 2000 at 12:11:20AM +0100, W. Yip wrote: > Fellas, this seems to be the type of dispute we have been waiting for. Is it too late to grab a copy of cphack now? Will I or won't I be able to join the inevitable class action for breach of contract against M if they _do_ revoke the GPL on cphack if I've obtained my copy after the lawsuit was filed? And are my chances better or worse living in a country where we don't have a UCITA? Cheers, Andrew Bromage
Re: How To Break The GPL
G'day all. On Fri, Mar 03, 2000 at 10:45:47AM -0500, John Cowan wrote: > This is offered in the spirit of "How To Make Atomic Bombs", and does > *not* mean that the author approves of the conduct described herein. [deletia] > Now who has violated Trent's copyright? Not Alice: she did not modify or > distribute Trent's work. Alice wrote and distributed what is, in the opinion of RMS, a derived work of Trent's work and thus her work is covered by the GPL. In the discussion which follows, I'll restrict myself to the case of a non-GPL'd work usig a GPL'd library. This is probably the most legally controversial part of the GPL. It's difficult to say whether or not a program which uses a library is a derived work of that library. If I were a judge (and IANAL so this is unlikely to say the least), I would probably decide on a case-by-case basis. If, for example, there exist non-GPL'd implementations with an identical interface and equivalent functionality, I would have to rule that it is _not_ in the spirit of "derived work" to class the program as a derived work. Let's make it a little more specific and ask yourself "is Alice's program a derived work of Trent's code"? Alice writes a graphics program (perhaps a game, for example) which is developed using Trent's GPL'd implementation of OpenGL. In this case, there are many proprietary implementations of OpenGL available. When Alice sends her sh/make/English instructions to incorporate Trent's code include an instruction _not_ to download Trent's code if there is already an implementation on Bob's machine. Cheers, Andrew Bromage
Re: License Approval Process
G'day all. On Tue, Feb 15, 2000 at 08:07:07PM -0800, David Johnson wrote: > Actually, my dictionary has 17 definitions. Yes. That's why I said "at least three". I think those three definitions are the ones most likely to be confused by the term "free software". It could mean "free" as opposed to "costly" (freeware), "free" as opposed to "encumbered" (MIT/new BSD) or "free" as opposed to "enslaved" (GPL). > Using Richard's definitions, "Free Software" is as unrelated to "Free Speech" > as it is to "Free Beer". "Free speech" is closest to what he is trying to achieve. At the risk of looking like wanting to have the last word, I hereby mention Hitler and thereby close this thread before the inevitable flamefest from my little soapbox speech gets out of control. Back to the OSI certification process discussion... Cheers, Andrew Bromage
Re: License Approval Process
G'day all. On Tue, 15 Feb 2000, Michael Stutz wrote: > > Is it *possible* for a license to be compatible with another? Offhand > > I can think of just two possibilities for the GPL: the LGPL, and code > > that has no license and is in the public domain. On Tue, Feb 15, 2000 at 07:35:57PM -0500, [EMAIL PROTECTED] wrote: > It's certainly possible. The GPL is particularly restrictive in this > sense. Contrary to popular belief, "free speech" (as RMS describes it) is not the same as "free time". "Free time" has no strings attached, whereas "free speech" has implied responsibilities. Unfortunately, the FSF have never AFAIK noted that English has at least _three_ definitions of the word "free", which makes the term "free software" that much more confusing. > What I would like to see as a variation of the GPL is one which allows > modifications to be placed under any certified Open Source license (this > is assuming a good certification process, which is being called into > question). I think this would make a good license to allow your code to > be used with the maximum amount of open source software, but still > disallow closed source software. (This would be a middle ground between > the GPL and the LGPL.) This sounds like inserting another condition into the MIT licence would do the trick. I'm not good at legal wording, but how about this? Any distributed or published work which is, in whole or in part, derived from the Software shall be licensed as a whole under an OSI Certified Open Source licence. Cheers, Andrew Bromage
Re: MIT license vs Dynamic Linking
G'day all. On Tue, Nov 16, 1999 at 12:00:34AM -0800, Bruce Perens wrote: > Regarding whether or not a GPL copyright owner can make a claim on a derived > work, sure he can - copyright law provides for that. On a dynamic-link work? > That depends. Probably if your executable uses headers that are part of the > work, as they are copied into the executable. This, of course, only applies to the C/C++ world, where module use is achieved by textual inclusion of source files (i.e. headers). In Java, use of a module is achieved by inspecting the compiled version of the module. In other languages, such as Modula-3, when the module to be used is compiled, the compiler often produces a special interface or import file which is later inspected by users of the module when they are compiled. One could argue that the interface/import file is a derived work of the original source, but it'd be hard to argue that a special interface or import file is "copied into the executable" in such languages. Taking the example to absurd extremes, as is the custom at this point in any such example, does what consitiutes a "derived work" now depend on how the compiler performs its job? Could it vary from compiler to compiler for source written in the same language, depending on whether or not your compiler uses textual inclusion to implement module importing? > RMS' law school instructor argues that dynamic linking is a device to > deliberately circumvent copyright law, and thus should be considered the > same as static linking. That interpretation could win in court, or not. Strange, I thought it was a device to control use of system resources. :-) I guess that interpretation might work if you could prove intent. Cheers, Andrew Bromage
Re: Can Java code EVER be GPLd, at all?
G"day all. On Sat, Nov 13, 1999 at 08:37:49PM +, Dj wrote: > The problem you face is simple. The viral nature of the GPL means that to > run a GPL java program means always binding with non-GPL code such as > the class libraries. With the possible exceptions of using certain kinds of distributed operating system or distributing core files, nobody ever distributes running Java programs, so the GPL doesn't say anything about what should happen in the situation. Cheers, Andrew Bromage
Re: Standard interfaces
G'day all. On Tue, Nov 09, 1999 at 05:41:42PM -0500, Alex Nicolaou wrote: > I think you missed my point. I'm not saying standards are good or bad, > or that de facto standards are right or wrong. I'm saying that the fact > that people defend standards generated by competition in the market > place is evidence that some people accept the idea of de facto standards > and reject official standards. If you don't mind the comment, there's quite a difference between the way that the US looks at things and Europe looks at things here. Look, for example, at digital mobile phone systems. When the US wanted to implement digital mobiles, basically every company got to design and implement their own. The result is that every digital mobile in the US has to be an AMPS analogue phone too, otherwise you can't roam across the country, into cells owned by a phone company which didn't implement your standard. (Well, that was the situation about five years ago. It may have changed a bit now.) Europe, on the other hand, got all the manufacturers around a table and got them to work out a standard together. They came out with GSM, which is what was almost universally adopted in the world outside North America, including all of Europe and Australia and most of Africa and Asia. Now there are fairly sound economic reasons why the USA didn't adopt GSM (it would have meant effectively scrapping the AMPS system and starting over again, as happened in Australia, which in the USA would not have been economically feasable). But it still highlights a big difference in culture: On the whole, Europe prefers official standards, and the USA prefers de facto standards. It may have something to do with Europe being a loose federation, and not wanting to promote one country's standard at the expense of some other country. (The rest of the world, of course, waits for Europe and the USA to come out with their standards and picks whichever looks best. ) > The bottom line is that standards are an obstacle to freedom. I could easily argue that standards promote freedom, too. You forcing me to use a certain standard certainly does stomp on my freedom, but picking the wrong standard reduces the freedom of my customer base. If, for example, I write software which uses only the Win32 API, I reduce my customers to those who have Win32. Those who only have POSIX (which, when Win2K comes out, will be pretty much everyone) I cover more people. Therefore I should use POSIX because it gives more people the freedom to use my software. Now if I were to come up with my own interface to my own you-beaut operating system, I'm in an even worse position. > I think that there are many > examples in the GNU software world where the software has been > "improved" rather than conforming to the standard. To this day I hate > operating "info" and curse the person who decided that man pages were > not good enough; but there you have it: a better way was chosen over the > standard way, because standards are an obstacle to progress. Well, I can understand why info was used in preference to man pages. Have you ever tried to find anything in the gcc man page? % zcat /usr/share/man/man1/gcc.1.gz | wc -l 4191 Ouch. However, if the GNU project had picked (and extended if appropriate) an existing standard (SGML comes to mind) rather than come up with their own, imagine how much better off we'd all be now... That, IMO, is one of the reasons for the adoption of the World Wide Web standards as they were originally formulated: they were based on EXISTING standards, such as SGML and MIME, and they would interoperate with other standards like ftp and gopher if you wanted them to. It's also one of the reasons for the popularity of C++, despite it being a programming language theorist's worst nightmare: The new features behaves just like you would expect C to behave under the same circumstances. Cheers, Andrew Bromage
Re: Standard interfaces
G'day all. On Tue, Nov 09, 1999 at 12:18:29 -0500, John Cowan wrote: [no modification allowed in the context of language bindings in standards] > > Is Java code that binds such standard interfaces inherently unfree? On Tue, Nov 09, 1999 at 06:12:45PM +0100, J.H.M. Dassen (Ray) wrote: > Such a license is not OSD-compliant. > > Does it violate the OSD, specifically clauses 3 and 4? > Yes. Clause 4 hints at a mechanism that can be used to make the interface > free in this case: require that modified versions are clearly marked as such > (in the context of standards: explicitly mention they don't conform to the > standard). In the case of Java, it might work to add the requirement that the class(es) must be placed under a different package name. I think that might give the desired effect, of discouraging modification while still allowing it if someone downstream thought the cost was worth the hassle. Cheers, Andrew Bromage
Re: OpenDesk.com License Proposal
G'day all. On Sun, Nov 07, 1999 at 02:17:47AM +0100, Philipp Gühring wrote: > 2) Commercial Use for Private Installations (e.g. installing OpenDesk on an > Intranet) > a) Modifications to Covered Code must be released under this license. > > The GPL does that. No it doesn't. If you install a modified version of a GPL'd product as a server product on an intranet, you are not obliged to release modifications, since you are not actually distributing anything, neither binaries nor source. The situation with OpenDesk (or, indeed, any server app system) is different, since you don't have to distribute anything in order to let people use it. The GPL doesn't help, since it only covers distribution of source, object code and binaries. ObGPLbait: The GPL is a great licence, but it does read like it comes from a former era, when you could really only run a program by executing its binary on your own machine, and everyone understood what you meant when you used words like "compiling" and "linking". Modern techniques of application serving and programming language implementation mean that it doesn't really help preserve either the openness or freedom (take your pick) of many modern applications. Cheers, Andrew Bromage
Re: Accusations, accusations, always accusations
G'day all. Quoting Andrew J Bromage ([EMAIL PROTECTED]): > > Even though I find this debate rather off-topic and would love to get > > back to licence discussion, I'd be interested in seeing a true line > > count of the source for some standard Linux system (say, Debian with > > only the compulsory packages installed) to see what proportion of code > > is in fact GNU software. On Sat, Oct 23, 1999 at 11:42:37PM -0700, Rick Moen wrote: > Runs the risk of accidentally assuming that each line of code is equally > significant. That's true. Some lines of code are run more than others, and some are I suspect that gethostbyaddr() is much much harder to write than printf(), for example, so printf() should probably be given fewer significance points. However an assembler, while being straightforward (in principle) to write, may deserve significance points because it's so fundamental to programming. Plus there's the problem of what programs are more important than others. (Personally, every time I've installed Debian, to pick but one, the first thing I did was deleted emacs, but others might consider that piece of software essential. Every time I've installed FreeBSD, the first thing I did was installed bash, so there. ) Oh, and it also runs the risk of being a total waste of time, just like this discussion. :-) Cheers, Andrew Bromage
Re: Accusations, accusations, always accusations
G'day all. On Sun, Oct 24, 1999 at 12:26:36AM -0400, delirium4U wrote: > I was under the impression that GIMP itself was part of the GNU project, Whoops, so it is. I didn't see GTK on the list of FSF software, so I jumped to conclusions. I stand corrected. Even though I find this debate rather off-topic and would love to get back to licence discussion, I'd be interested in seeing a true line count of the source for some standard Linux system (say, Debian with only the compulsory packages installed) to see what proportion of code is in fact GNU software. It's a non-trivial task precisely because of the problem of determining the provenance of each sub-component of a given package. For example, glibc is a combination of GNU project code plus other stuff bundled from BSD, LinuxThreads, a lot of Sun code and recently some Mach code too. Cheers, Andrew Bromage
Re: Accusations, accusations, always accusations
G'day all. Disclaimer: I'm not on anyone's side in this debate. I just noticed quite a few factual errors in this post. I'm also not a Linux worshipper, and definitely think the Hurd has more promise as far as operating systems go. Now read on... On Sat, Oct 23, 1999 at 01:38:35PM -0500, Alejandro Forero Cuervo wrote: > When any program calls printf, fopen, pthread_create, malloc, inet_addr > and many other functions, the program is, more than likely, using code > coming from the GNU project. The Linux pthread_create is not from the GNU project, but rather is the LinuxThreads package imported. All the inet stuff is BSD code (and hence BSD licenced). Malloc is a GNU adaption of Doug Lea's implementation (the GNU project added the multithreading support). So of the five that you mention, two could be considered "code coming from the GNU project". > How far do you think the Linux kernel would > get with no implementation of printf? How many programs do you think > would run? Any program written for a system with no console, written not to use a console or written not to use stdio, I should think. This would include any embedded system, anything written exclusively for a GUI, any daemon, anything which can use sfio (e.g. Perl), anything written in a language other than C... Oh, and the kernel comes with its own implementation (customise for use in a kernel) anyway. See /usr/src/linux/lib/vsprintf.c for details. > How many programs would build with no make, shell, textutils (ie cat), > shell utiles (ie cd, sleep, echo), sed or C/C++ compiler? Most computers which exist in the world have never been used to build software. Who was it who said that Unix was a nice OS for software development and that's about all? :-) In particular, the ucLinux project isn't interested in distributing any of these tools since they're not important to have on your Palm Pilot. > Are things such as GNOME not part of the guts of the system (in those > workstations where XWindows is considered a standard part of the system > and programs depend of calls to, say, GTK)? Is GTK part of the GNU project? I thought it was part of the GIMP project. GNOME is part of the GNU project, but more Linux distributions (particularly those with commercial support) are pushing KDE than are pushing GNOME. Oh, and of course the XWindow implementation that you tend to find on Linux systems is of course not part of the GNU project. > I'd think it is clear that the guts of the system were written by the > GNU project over anyone else. You may be right, but I think you picked bad examples. Cheers, Andrew Bromage
Re: Does a GPL API infect its apps?
G'day all. On Wed, Oct 20, 1999 at 02:08:20PM -0400, Raymond Luk wrote: > Web have a Web application framework which is open source > (www.smartworker.org). It is currently using a BSD-style license but we want > to change to GPL. It is essentially a set of mod_perl classes. If you're using mod_perl, it might be worth considering releasing under the same terms as Perl (i.e. either GPL or Artistic, at the licencee's discretion). The reason I suggest this is that it's not clear what constitutes "linking" under the GPL in the context of interpreted or partially compiled languages (or even of client/server systems such as CORBA, but that's another story). The GPL was clearly written with C in mind, not Perl. The Artistic License, on the other hand, makes it explicit: 6. The scripts and library files supplied as input to or produced as output from the programs of this Package do not automatically fall under the copyright of this Package, but belong to whomever generated them, and may be sold commercially, and may be aggregated with this Package. 7. C or perl subroutines supplied by you and linked into this Package shall not be considered part of this Package. Cheers, Andrew Bromage
Re: GNU License for Hardware
G'day all. On Thu, Oct 14, 1999 at 12:46:16PM -0400, Matthew C. Weigel wrote: > Whereas Linux (the kernel) *is* free, and is considered part of > the GNU system. I like the acronym expansion of GNU/Linux: GNU's Not Unix/Linux Since Linux is in fact a re-implementation of Unix, it's recursive and contradictory all at once. Hofstadter would be proud. Cheers, Andrew Bromage
Re: [openip] Re: GNU License for Hardware
G'day all. On Mon, Oct 11, 1999 at 03:39:21PM -0700, Reto Stamm wrote: > Any suggestions for names? FWIW, the Esperanto community uses "libera programaro" to mean "free software". I guess the hardware equivalent would be "libera ferajxo". (Note for the unaware: The "jx" combination is \^\j in LaTeX, '\xBC' in iso8859-3 or '\u0135' in unicode.) Cheers, Andrew Bromage
Re: How about license-review@opensource.org?
G'day all. On Tue, Sep 21, 1999 at 03:24:42AM +, [EMAIL PROTECTED] wrote: > Nobody would have objected to that message. I didn't think so. My point is that had this mailing list been called "license-review", I probably wouldn't have posted it here, because it wasn't a licence which needed review. :-) All this discussion over the name and charter. Why does this remind me of a Usenet RFD? Cheers, Andrew Bromage
Re: How about license-review@opensource.org?
G'day all. On Mon, Sep 20, 1999 at 07:24:10PM -0700, Derek J. Balling wrote: > I would vote for creating a new list, license-review, which is clear on > what it is for, and leave the discussions here, where they seem to match > the list name. As a matter of interest, was my question (i.e. "here are my constraints, what licence would suit my purpose") on topic on license-discuss? I probably wouldn't have asked here had the list been named license-review since I didn't have a licence to review... Cheers, Andrew Bromage
LPF email address
G'day all. I thought I'd ask the LPF about the copyright API problem, but the email address appears not to work (after a week of retrying). Someone on this list may have an email address which works, since there must be some overlap between the two interest groups. :-) The address that I have is: [EMAIL PROTECTED] Thanks all. Cheers, Andrew Bromage
Implementing an encumbered API (was that AT&T licence thing)
G'day all. On Fri, Sep 10, 1999 at 05:31:08AM +, [EMAIL PROTECTED] wrote: > Is there any published documentation on it? There is one book which has been out for almost ten years. The book is copyrighted by the company and this notice appears at the front of the book: [Company] owns the copyrights in the [API], including the list of procedures which constitute the interface, and the [API] specification and manuals. These may not be copied without [Company]'s permission. [Company] will enforce its copyrights and trademark rights. However, [Company] does not intend to exclude anyone from creating [programs] that call the [API] procedures. Also, [Company] does not intend to exclude anyone from creating [implementations of the API calls], provided a separate written agreement is entered into with [Company]. [Company] gives permission for you to copy the [API] procedure calls for writing [programs] that use the [API]. Any program that incorporates any of the [API] procedure calls must include the proper copyright notice on each program copy, as given in the [spec], available from [Company]. A no-charge license is available from [Company] for anyone who wishes to write [an implementation] that uses the [API] procedure calls. This license must be in writing. [Guff about use of the trademark follows.] The copyright message is: The [API] Interface Procedures and [associated protocol] are: Copyright 1988, 1989, [Company]. All rights reserved. [Trademark] is a registered trademark of [Company]. Interestingly enough, this was in the published version but I can't find it in the version of the spec that is on the company's web site. There is another book to be published soon, also written by employees of the company, which will be on using the API effectively. (Those who have an interest in the field have probably worked out exactly which API I'm talking about now.) > If I can go into a bookstore > and get a book and learn about the API that way, it's going to be very > difficult to enforce a copyright on the API that would prevent its > re-implementation. One would have thought so. It looks like they've gone to a lot of trouble to prevent someone doing that, though. Cheers, Andrew Bromage
Re: ATT SOURCE CODE AGREEMENT Version 1.2C
G'day all. On Thu, Sep 09, 1999 at 08:50:01PM -0700, Bruce Perens wrote: > OK. The OpenGL _trademark_ can not be used unless you have a license. > However, you can program to the API without that license. The Open Source > Definition says nothing about how you license your trademarks. As long as > the _code_ can be used by someone who does not wish to use your trademark > and calls it something else, it's still Open Source. If you want to attach > a mandiatory certification program and a license to the trademark, that's > fine. So what you're saying is that assuming it's not illegal to implement this particular API without the licence (which I still have to check[1]) I could distribute it under any licence I want with a disclaimer saying that if you want to create something based on this which claims API compliance (i.e. uses the trademark) or redistribute it using the name of the API, you should obtain a licence yourself. Excellent. Sounds good to me. Thanks. Cheers, Andrew Bromage [1]Someone who works for the company in question but is not a lawyer said simply "the API is copyrighted", but I'm not entirely sure what that means. How can you copyright a collection of typedefs and function prototypes?
Re: ATT SOURCE CODE AGREEMENT Version 1.2C
G'day all. I wrote: > ! This brings up a question that I was planning to ask anyway. > ! > ! Is there an open source licence which allows the possibility of > ! encumbered code? On Fri, Sep 10, 1999 at 03:25:48AM +, [EMAIL PROTECTED] wrote: > I don't understand the question. Please re-state. Here's the Reader's Digest version: I am writing an implementation of an API which is encumbered (just like the OpenGL API is encumbered). To distribute an implementation, you must obtain a free (i.e. no money) licence from a certain company who holds the copyright. If I want to be able to claim that my code conforms to the API, I will have to obtain such a licence. The trouble is, if I release open source, and someone else wants to fork the tree, they will have to obtain one too. What open source licences, if any, allow this? Or is it impossible to reconcile this requirement with the OSD? The rest was commentary. Cheers, Andrew Bromage
Re: ATT SOURCE CODE AGREEMENT Version 1.2C
G'day all. On Thu, Sep 09, 1999 at 10:21:32PM +, [EMAIL PROTECTED] quoted: > SOURCE CODE AGREEMENT > > Version 1.2C This brings up a question that I was planning to ask anyway. Is there an open source licence which allows the possibility of encumbered code? I'm currently implementing a certain encumbered API, which requires a free (as in "free beer") licence, even for commercial use. I'm not sure of the exact wording of the licence (I haven't obtained one yet), but I understand that all it says is that the implementor will not infringe any of that company's intellectual property, with the strong implication that you should find a way to implement it which doesn't use techniques covered by that company's patents. (This is a straightforward thing to do.) One way to go would be the same way that Mesa got around the OpenGL licence: by not claiming compliance and releasing under the GPL. That's a neat solution which I could probably get away with, but if I ever wanted to sell the software commercially, it would be better to be able to claim compliance. Probably a licence which only allows distributions of modifications via patches (QPL-style) would fit the bill, but that doesn't fit nicely with a bazaar development model, which I may choose to adopt. Another possibility is to split the software. I could implement the meat of the code using my own API and release it LGPL, then implement the "real" API using a very thin layer of code as an adapter and release that as proprietary or QPL. It's kinda ugly to use such a mix of licences, but it would work. (Of course the bridge between the adapter and the meat of the code could be implemented in many ways, if I didn't want to use the LGPL. A CORBA bridge, for example, might be a nice solution.) Anyway, this AT&T licence works if the originating author is the same as the patent holder, but it doesn't help me very much. What I really want is a licence which is copyleft (i.e. affords the same protections and allows the same freedoms as the GPL) with the proviso that if you want to fork the tree, you have to ensure that you obtain the relevant free licences, which would be declared somewhere in the licence. If you modify the code sufficiently as to remove the encumberance, then you could have the option of releasing under the GPL. If you add more encumberance, you must declare it, and the encumberance must be of a form such that it at least allows free distrubution and use for non-commercial purposes. Or something like it. Does anyone have any thoughts or suggestions? I don't want to have to write a new licence. I hate legalese and want to avoid confusion if I can. Of course in a perfect world we wouldn't have encumbered APIs or algorithms. Indeed, here in Australia we don't have software patents, so I could probably get away with ignoring the whole mess, so long as I didn't allow the US to use it. :-) Thanks in advance, etc. Cheers, Andrew Bromage
Re: Draft 1 of the OpenDesk.com Public Source License
G'day all. On Thu, Nov 18, 1999 at 08:24:49PM -0800, Bruce Perens wrote: > I surmise that > the proportionally lower interest in BSD, Mozilla, and other non-GPL > projects might be due in part to this sentiment. Hmmm... I suspect that there are more "external" people working on, say, Mozilla than there are working on, say, GCC. That's just a guess, mind you. Plus, there seems to be more development interest in XFree86 than there is in Emacs. I don't think the licence has as much to do with it as you think, compared with how sexy the project is and how badly the community wants the software/changes. Cheers, Andrew Bromage
