Re: Is this better for tomsrtbt?
Tom Oehser [EMAIL PROTECTED] What I don't like is other people just copying the *actual binary* without giving any credit or acknoledgement that *they* don't want to bother to compile it *themselves*. As long as they mention where they got it, I'm fine with it. So, in the case above, am I required not to add the 'give credit and mention where you got it' clause to the binary object, even if I make the source code available without any such restriction? Yes. That would be in violation of Section 2b of the GPL. The GPL doesn't really clarify this, it is, after all, aiming at the source code, and there is probably no consideration that anyone would *care* about a particular binary compile output. Compiling a program into object code is certainly forming a derivative work, and thus it falls under Section 2. The GPL does not need to enumerate every different way to form derivative works in order for it to apply to them. Also, if you look at the language in the first line of Section 3, it is clear that the GPL considers object code to fall under Section 2. Now, I can *definitely* apply this restriction to all the scripts and Luas that I wrote from scratch, *maybe* apply it to the agglomeration and the arrangement (such as using a very small gzipped root and bzip2ed /usr, is that copyrightable?) The idea of compressing filesystems? No, as copyright applies to expressions and not ideas. The actual filesystems of course are copyrightable, but then they are derivative of the works they contain, and you will have to follow the GPL. and *maybe* apply it to my versions of the documents and man pages. It is *possible* that I can apply it to binary objects where I am making the program *in source* available *without* restriction, but I dunno from reading the licenses. Are you talking about the GPL? The GPL states very explicitly in Section 2b that derived works must be distributed under the terms of the GPL. There is no provision for extra restrictions. But I can *ABSOLUTELY* make it clear that this is my desire, want, and expectation, to the fullest extent legally available to me. Which, under the GPL, is nil, unless you can find a law requiring attribution. Don't pretend that this "desire, want, and expectation" is part of the license, though. IANAL. That is what I'm getting at, in my license- "as far as legally possible, if you reuse ANY of this, you must give credit to the source". --
RE: namespace protection compatible with the OSD?
"Lawrence E. Rosen" [EMAIL PROTECTED] I was trying to point out that you CAN'T ALLOW someone to use your name -- e.g., ALL uses, even friendly ones, are misuses -- because it is YOUR trademark and not theirs. If you allow a third party who creates a derivative work to market that derivative work under your trademark, without exercising control over the quality of his derivative works, you will lose your trademark. It is okay for a third party to say his derivative work is "compatible with" Apache, or "equivalent in functionality to" Apache, or "meets the specifications of" Apache, or even that it is "better than" Apache, but it is NOT okay for him to market his derivative work "as" Apache. Apache should not allow anyone else to adopt its trademark for their software! (The word "should" in that last sentence is as close as I'm going to come to giving unsolicited legal advice to Apache.) "OSI Certified" is a certification mark, a kind of trademark. Yet open source software authors can claim their software to be "OSI Certified", not just "equivalent to OSI Certified". This doesn't constitute abandonment of the trademark -- does it? --
Re: namespace protection compatible with the OSD?
Brian Behlendorf [EMAIL PROTECTED] I'm saying two things: if you create a derivative work from my code, then the license says if you change the behavior of the functions or macros, etc., defined in my .h, that you must call it something else. However, if you keep the same interface (keep the .h consistant, but change the .c, though it's more accurate to say "API" and "implementation") then you may continue to call it "mylibrary.h". I'm having trouble with the interface/implementation distinction here. Is "behavior" the same thing as "interface"? Secondarily, I'm saying even if you didn't implement my code, but followed the published document that describes the spec (which I also put under this license), you'd have to follow the same rules. This cannot be accomplished with an open source copyright license. This sounds like a job for trademarks. Perhaps a better way to think about this whole issue is something like this: "Permission is hereby granted to use the trademark 'mylibrary' in connection with a computer program, provided the following conditions are met: 1. The program include a file named 'mylibrary.h' which is syntactically equivalent to the file 'mylibrary.h' of the reference implementation available from somewhere"... (be more specific about the meaning of "syntactically", mention standards, etc.) I'm not sure what "incompatible" means here? What if my new improved version was intended as a replacement, but which added new features in a way that necessitated a degree of incompatibility? If you make a change that introduces any degree of incompatibility, even if it's "fixing a bug", then it would have to be renamed. Hopefully I'm reasonable enough to change my API should I be notified of bugs in it, but if I'm not, fork. All changes potentially introduce incompatibility, even bug-fixes, because old code can rely on the buggy behavior. Is your intent to prevent people from adding new features and calling it the same? I don't know. In some cases I could see (if I have understood you correctly), the restriction could be a way of preventing a fork of the code. IMO, the ability to fork is a necessary part of an open source license. It doesn't limit the right to fork at all, but it does somewhat carve out an API namespace; the example of MS using something like this to prevent Win32 reimplementation is probably a good example, where they'd put a license like this on their Win32 spec. This doesn't seem to be at all the same thing. Nobody has to execute a license of Microsoft's in order to implement the same API's as Windows, unless doing so involved creating a derivative work of some copyrighted material. What you're proposing sounds like it could be accomplished using trademark, and avoiding that whole sticky copyright-of-API's issue altogether. I'd be surprised if they don't already have some sort of anti-reimplementation or anti-reverse-engineering clauses in their click-through or shrink-wrap licenses, though. They can have all kinds of clauses; that doesn't mean anything if nobody executes the licenses. You can get people to execute the license by granting them a right that they would not otherwise have: an exclusive right under copyright, or the right to use a trademark. Because your objectives seem to be aligned with the intentions of trademark law (preventing consumer confusion from dilution of the name), it seems that trademark would be a better fit. --
Re: Subscription/Service Fees - OSD Intent
Ian Lance Taylor [EMAIL PROTECTED]: ) It may certainly be possible to have a [requirement that derivative works ) be licensed under the GPL] for Open Source software. I am not denying ) that. However, until such a time as the [requirement that derivative ) works be licensed under the GPL] is [met], the software cannot be ) considered Open Source. If a [requirement that derivative works be ) licensed under the GPL] were allowed in an Open Source license, then ) if Andy has [met the requirement by distributing his derivative work ) under the GPL], then gives the software to Bob, Bob does not have to ) [meet the requirement to distribute derivative works under the GPL], ) since all the rights attached to the Andy's copy of the software ) transfer to Bob (#7). Plainly, this is not what #7 means. Argument by analogy is always tricky. In this case, I don't think your analogy is correct. Your analogy presumes a scenario in which Andy has a legally obtained copy of the source but is not under the requirement that derivative works be licensed under the GPL. That is implied by your statement that Bob has all the rights which Andy has but does not have the requirement of distributing under the GPL. There is no such implication. A "not" has slipped in there! I am considering the case where Andy is licensed under some condition (whether it is a requirement that any derivative works be distributed under the GPL, or perhaps a requirement to pay a fee.) My statement that Bob has all the rights which Andy has but does not have the requirement of distributing under the GPL is derived from David Johnson's argument about OSD #7 -- namely, that a recipient of Open Source software gains all of the rights that the distributor had with regard to the software, _without_ having to meet any of the requirements that the distributor did. Here is my interpretation of David Johnson's point. If Andy has a copy of a program under an open source license which requires paying a license fee, and Andy pays that license fee, and Andy distributes the program to Bob, then by OSD #7 Bob has all the rights that Andy has. If Andy has the right to run the program, then Bob also has the right to run the program. That's how I understood it also. But no Open Source licenses (that I can think of) actually work that way. If Andy gives Bob a copy of the software, that does not mean that Bob should automatically be granted Andy's rights, _without_ meeting the conditions under which Andy obtained them. If we apply your analogy to this, you are quite correct that if Andy has a copy of a program under an open source license which does not require redistribution under the GPL, and Andy distributes the program to Bob, then Bob is not require to redistribute under the GPL. But that argument proves nothing interesting. That is not my analogy. I will be more explicit. Scenario 1 - Andy obtains a copy of a software program. - Andy reads the license. The license states, in part, that it will grant him rights to copy, modify, distribute and prepare derivative works, under certain conditions. The conditions include a requirement to pay a fee. - Andy accepts the license. Andy is now granted those rights. Andy has also now incurred an obligation to pay the fee. - Andy gives a copy of the program to Bob. (Legally, as Andy has been granted that right.) - Bob reads the license. The license states, in part, that if he has received his copy from somebody who was granted rights under this license, Bob is also granted those rights. - Bob accepts (or doesn't accept) the license. In case he accepts, he does not have to pay a fee to copy, modify, distribute, or prepare derivative works. Scenario 2 - Andy obtains a copy of a software program. - Andy reads the license. The license states, in part, that it will grant him rights to copy, modify, distribute and prepare derivative works, under certain conditions. The conditions include a requirement that any derivative works of the software that Andy creates must be licensed under the GPL. - Andy accepts the license. Andy is now granted those rights. Andy has also now incurred an obligation that any derivative work of the software he should create must be licensed under the GPL. - Andy gives a copy of the program to Bob. (Legally, as Andy has been granted that right.) - Bob reads the license. The license states, in part, that if he has received his copy from somebody who was granted rights under this license, Bob is also granted those rights. [Note: This license is not the GNU GPL, obviously.] - Bob accepts (or doesn't accept) the license. In case he accepts, he may prepare derivative works and license them under any license he chooses. A way to work around this is to provide a license which is an open source license but which says that every time
Re: Subscription/Service Fees
"Karsten M. Self" [EMAIL PROTECTED]: I wasn't thinking of any form of copying restriction, only having it clearly stated in the license that if you continue to use the software you are required to pay $x to xyz inc. Nope. Violates #7: "The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties". http://www.opensource.org/docs/definition.html How is there an additional license required? A requirement to pay somebody something does not imply that an additional license is required. I believe the original poster is envisioning it simply as a clause in the (sole) license. You can charge for subscriptions to updates (Cf: Red Hat). You can't charge for ongoing execution rights. Of course not. "Execution rights" are not among the exclusive rights listed in 17 USC 106 (assuming we are talking about a copyright license in the US), so it makes no sense to talk about granting them. A shareware style requirement to pay for use is not a matter of granting (or not granting) specific rights, but of imposing obligations in return for the rights which are granted. Clearly, #7 does not apply. --
Re: What is Copyleft?
"Ryan S. Dancey" [EMAIL PROTECTED] 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. Actually, this has nothing to do with the issue of compile-time vs. run-time linking. Here's an example: Suppose I take an ordinary, simple, statically linked program that is licensed under the GPL. I want to add some code to it and keep it secret, so I do something like obfuscate the C source or hide the source altogether and distribute object files only. This obviously goes against the "preferred form" clause of the GPL. However, it would not be a violation under your logic, as the proprietary modifications can easily be "extricated" using diff or a similar utility. (Suppose that I am not distributing the final binary, but the tarball containing the original source and proprietary files.) What differentiates this scenario from the "mere aggregation" that the GPL specifically disclaims? The way in which the original files and the proprietary files interact -- their function call prototypes, their linker symbols, the "data being passed between two independent pieces of code." It is not insignificant. --
Re: Converting/Splitting Code - Open to Closed
Brian DeSpain [EMAIL PROTECTED] Yes - but the previous versions licensed under the GPL remain GPLd and development can continue on the code. Can you explain why this is the case? In reality, the code would most likely *fork,* leaving one strand open and the other proprietary. That's exactly what would happen and that's why the GPL is there in the first place. The copyright owner retains copyright, therefore can make changes. You cannot retroactively change licenses under the GPL. People retain their original rights under the GPL. How can licensees retain their rights against the copyright owner's will? Is there something in the GPL that requires this? --
Re: IPL as a burden
[EMAIL PROTECTED]: I believe OSD section 7 may cover that: 7. Distribution of License. The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties. =2E..in which case, the requirement for an additional runtime license by the initial licensee would be incompatible with 7. In other words: all rights associate with copying, modification, distribution, *or use* of the program must be granted in the OSD-conformant license. Still, it's interesting that this is an imputed, not an explicit, property of the OSD. Possible loophole? It could be. I think you mentioned the answer in a different post: The short explanation: The GNU GPL (as with most free software licenses) grants rights to _non authors_ (or copyrightholders) of a work _which they wouldn't have, independently of the license_. My question is: Is there any good reason that an Open Source license should not consist solely of these kinds of rights? Is there a reason why an Open Source license should prohibit or conditionalize something that I already have the right to do (such as execute code, given that I have obtained a copy of the code)? Running the program is not a right that an Open Source license need grant; it's a right that everyone already has. And while section 7 of the OSD specifies that the rights granted be universal without the need for an additional license, it says nothing about the rights taken away. I'm wondering if we could eliminate these kinds of loopholes by outlawing licenses that take rights away altogether. --
RE: AFPL vs. GPL-like licenses?
"Lionello Lunesu" [EMAIL PROTECTED]: It reminds of something I did in my childhood (I must have been 12 years old or so). Somebody gave me a collection of comics that he knew I liked. I read most but when I got tired of them I try to sell them in a yard sale. Then my brother pointed out to me that I shouldn't sell anything that I got as a present. I understood the mistake I made and waived from selling them. Now that I have my own 'present' to give to 'the software society', I'm afraid that some people might _willingly_ make the same 'mistake' I made. They are allowed to do so under the GPL. It seems to me that designing a license like the AFPL means spending a lot of time and frustration trying to exclude something that doesn't impact your software's freedom in any sense. For instance, one of the major reasons I signed up with my ISP is to download high-quality free software. That's a commercial interest. I just checked the AFPL, and sure enough, because a commercial ISP is not an "information storage and retrieval system" nor a "removable computer-readable" medium, it would appear to prohibit downloading AFPL'd software. Adding special exceptions for these "harmless" cases of commercial interest adds needless complexity to an open source license. --
Re: Qt/Embedded
On Fri, 17 Nov 2000, David Johnson wrote: On Friday 17 November 2000 01:20 am, [EMAIL PROTECTED] wrote: The idea is that, if a program is a work, and if (as the courts have held, in Mai v. Peak) a program in memory meets the fixed and tangible requirements of copyright law, and is therefore a copy under copyright law, then a program linked to a library at runtime is a derivative work. I don't see how this follows. I've heard this before, but I've always dismissed it as hearsay. I will have to look up Mai v Peak. The implications of this are mind-boggling! Does Stephen King have rights to my brain because I've read his books and they're now in my memory? If that is what the license requires, then yes. Mai v Peak establishes that because a computer program has to be copied to memory to be used, one can be guilty of copyright infringement merely by using the work. The court did not seem to cover Section 117 of Title 17 very thoroughly and it seems to me that similar cases could argue under 117(a)(1) especially. Even under the conclusion of Mai v Peak, the effect on the GPL would be to require users to proliferate "written offers" (or copies of the source code) and "prominent notices" of modifications (if the program is modified) throughout their computer's RAM and other temporary storage locations as they are operating a GPL'd program. Whether "a program linked to a library at runtime is a derivative work" is a different question. IANAL.
