Re: Against DRM 2.0
On 5/21/06, Max Brown [EMAIL PROTECTED] wrote: Max p.s. Software is not music. Software is not visual art. Software is a code, a literary work (and Berna Convention consider software as a literary work). So software patents are unlogicall. There are two prevaling views of software which I have seen. The view that software is the opposite of hardware, anything which is in binary format and the view that software is executable code. The former view is the most inclusive and the one (in my understanding) held by DD's. The latter is the one held by you. To better understand the former view I recommend you read this article: http://emoglen.law.columbia.edu/my_pubs/anarchism.html Please know that I am not a Debian developer and do not represent the views of the Debian project. -David Mattli
Re: Bug#365408: [POLICY-PROPOSAL] Drop java*-runtime/compiler, create classpath-jre/jdk and java-jre/jdk
Arnaud Vandyck [EMAIL PROTECTED] MJ Ray a Âcrit : [...] A virtual package name is a functional label, not a product name. Java is the name of an island and a natural language too. I'm surprised if Sun can prevent use of a word in this way. A function that is used to call a runtime, compiler, etc of the Java(tm) language! A package name does not call the language. Java is the name of an island. -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
Martijn van Oosterhout [EMAIL PROTECTED] writes: Well, IANAL, but as far as I can see, as long as Sun has a valid reason to change their mind and is willing to compensate any losses caused by them changing their mind, they can do whatever they like. Well, but *that* I don't think is a worry. Sun changes their mind, we take the software out of non-free again, oh well. Just like if they change the license down the road. The worry is over whether we get sued. If they might just make us take the software out of the archive again, oh well. Like Steve says, I think that's a risk for quite a lot of stuff in non-free, and is one of the (many) reasons why the amount of support Debian offers for non-free is extremely limited. *Because* this is non-free, I think the situation is very, very different than it would be for main, and in more ways than just what criteria are applied to judging the license. For example, I personally don't think that Debian makes as strong of an ongoing committment to support something by including it in non-free; simply removing it in the case of problems is more of a viable option. (This may be an opinion that's idiosyncratic to me, though.) A few possible problems are: - The promise was made without consideration (no symbolic one cent payment) - The promise was not formally notarised. A press notice may not count. - It wouldn't damage Debian or anybody much to revoke the statement. They may not be able to recover damges for the period you relied on their statement, but nothing prevents them from stating the contrary. that's assume the promise is considered valid ofcourse. One of the reasons why I'm curious about analoguous laws in other legal systems is that, as I understand it, the no consideration bits aren't as relevant to estoppel. That's a factor in validity of contracts, but estoppel is a separate principle. Estoppel basically says that you can't trap people by lying about your intentions and then suing them when they rely on your promises. A comparison of estoppel between English, American and German. It refers to contracts however, we we don't have in this case: http://tldb.uni-koeln.de/php/pub_show_document.php?pubdocid=114700 Yeah, that page is about promissory estoppel, and what I'm talking about is equitable estoppel. http://legal-dictionary.thefreedictionary.com/equitable+estoppel equitable estoppel n. where a court will not grant a judgment or other legal relief to a party who has not acted fairly; for example, by having made false representations or concealing material facts from the other party. This illustrates the legal maxim: he who seeks equity, must do equity. Example: Larry Landlord rents space to Dora Dressmaker in his shopping center but falsely tells her a Sears store will be a tenant and will draw customers to the project. He does not tell her a new freeway is going to divert traffic from the center. When she failed to pay her rent due to lack of business, Landlord sues her for breach of lease. Dressmaker may claim he is equitably estopped. Thie simplest solution in this case would be if Sun simply attached the FAQ as an addendum to the licence rather than stating it's not legally binding. Yeah. Not disagreeing there. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Distributor License for Java: External Commentary
On Tue, May 23, 2006 at 03:15:32PM +1200, Adam Warner wrote: Hi all, Commentary by Dalibor Topic: The license is, frankly, still pretty bad, and contains various nasty clauses: from the overly broad indemnification(i) part, which has nothing to do with Sun's JDK software, to the subsettig restrictions not being limited to Sun's software. That's from a cursory glance, I think you'll get to see more comments once people take it apart, and the JavaOne buzz is gone Thanks for bringing my comments up, I guess. :) I believe there are some provisions where the FAQ and the license text talk about a different scope of right/obligations. One of them is indemnification, where the obligations under 2.f.i seem to go too far (any use of the os, or any part, which is a wider net than Sun's code alone). As far as I can see, Sun could do a better job at making the license clearly say what the FAQ says that it should say. :) As for the subsetting restrictions, those things have really fascinating side effects. I've talked with tmarble about one weird corner case after the announcement, and I hoped it would not occur in practice. Since it seems that it is about to occur in a package (JacORB apparently requires overriding bootclasspath according to a recent mail to debian-java), I guess I can explain it here: One of the ideas behind Sun's restrictions on subsetting/supersetting/messing around with their classes is that they certify a specific binary as a whole. Now, funny enough, Sun's JVM, and most other runtimes, provide a convenient way to mess around with the classes anyway, using the -Xbootclasspath* options at runtime to replace core classes by other implementations. That used to be the 'standard' way to deal with bugs in Sun's XML implementation, for example, until Sun introduced the official extension mechanism. Of course, messing around in one's own privacy is a different thing from deploying applications in public that replace chunks of Sun's implementation before they run. So the manual page for the java binary contains a note saying Note: Applications that use this option for the purpose of overriding a class in rt.jar should not be deployed as doing so would contravene the Java 2 Runtime Environment binary code license.. See http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/java.html for a reference. This is where the fun begins. What is the effect of contravening the DLJ? Judging by the section on termination, automatical termination without notice would be the worst case, but I doubt that's in the interest of the respective parties. More seriously: What would the effect of Debian distributing a JacORB package, which replaces parts of the bootclasspath, potentially configured to run with Sun's JVM, be on Debian's license to redistribute Sun's JVM? Less seriously: Should a developer packaging free software have to care about the restrictions of some piece of non-free software he may be potentially violating? :) Since Sun has announced their desire to open up their last bastion of proprietary software at JavaOne, though, I don't think the DLJ matters much, seen over the next years. I don't particularly care if Sun's implementation ends up in non-free, or doesn't for the next two years, as long as it joins Kaffe gcj IKVM cacao jamvm ... in main eventually. cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sharpmusique in Debian
Is there any legal reason why sharpmusique is not in Debian, given that multiple .deb packages already exist? If you're going to ask about a license (which is what I assume you are doing), please include the license in question (unless it is in /usr/share/common-licenses). In this case, the license in question is the GNU General Public License, version 2. I see no legal reason why this is not in Debian. I do see a technical reason: no one wants to make packages, apparently, since the RFP in question is still open (345903). I realize that the license works, and I apologize for not mentioning that. I just wondered if there were any DMCA-related issues, not knowing what implication those have on Debian, inasmuch as the package was created by reverse-engineering a proprietary protocol. thanks, Charles -- Soldier Sailor And marine Now get a shave That's quick and clean Burma-Shave http://burma-shave.org/jingles/1941/soldier signature.asc Description: Digital signature
Re: Against DRM 2.0
2006/5/23, David Mattli wrote: There are two prevaling views of software which I have seen. The view that software is the opposite of hardware, anything which is in binary format and the view that software is executable code. The former view is the most inclusive and the one (in my understanding) held by DD's. The latter is the one held by you. To better understand the former view I recommend you read this article: http://emoglen.law.columbia.edu/my_pubs/anarchism.html I know that article (by Stallman's lawyer). But the question is very easy: any lawyer knows there is a big difference between corpus mysthicum (the artwork/the code) and corpus mechanicum (the carrier/the file). The copyrightable work is only the artwork/the code! Only if *the code* is the same, there is a violation of copyright: you can obtain the same functions with two different languages. Only patents forbid this, because patents forbid to copy an idea. It seems that Debian considers music and images as software: *components* of a software. This is a great error: for example, a free software can use CC no-derivative images with any problem, because the code (the software) is under a license and images are under another license. There isn't incompatibility between the licenses because an image is not a software, *it is not a component of the code* (you can write a book under verbatim copying with images under a free license: there isn't any incompatibility). So I don't understand why songs, images. etc. must follow a software definition. I think that any lawyer will belie me. Max
Re: sharpmusique in Debian
Charles Fry [EMAIL PROTECTED] wrote: /usr/share/common-licenses). In this case, the license in question is the GNU General Public License, version 2. I see no legal reason why this is not in Debian. I do see a technical reason: no one wants to make packages, apparently, since the RFP in question is still open (345903). I realize that the license works, and I apologize for not mentioning that. I just wondered if there were any DMCA-related issues, not knowing what implication those have on Debian, inasmuch as the package was created by reverse-engineering a proprietary protocol. The xml files in the glade subdirectory, as well as the images don't have a license statement (at least not in their svn repository). Shipping a copy of the GPL in the distribution does not mean that every file is licensed under it. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Against DRM 2.0
Max Brown [EMAIL PROTECTED] But the question is very easy: any lawyer knows there is a big difference between corpus mysthicum (the artwork/the code) and corpus mechanicum (the carrier/the file). The copyrightable work is only the artwork/the code! So, in your language, we require the same freedoms to use, study, adapt and share the corpus mysthicum for everything in our corpus mechanicum. Sorry if that's butchery of a foreign language, but this list is usually in English. This is a great error: for example, a free software can use CC no-derivative images with any problem, because the code (the software) is under a license and images are under another license. A free software compiler can call a no-derivatives linker, but that doesn't let the linker into main. This is about freedom, not licence compatibility. Hope that explains -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
On Mon, 22 May 2006 19:13:47 -0700 Russ Allbery wrote: Martijn van Oosterhout [EMAIL PROTECTED] writes: [...] Thie simplest solution in this case would be if Sun simply attached the FAQ as an addendum to the licence rather than stating it's not legally binding. Yeah. Not disagreeing there. Mmmh, we would end up with a contradictory license if Sun did this, because the FAQ seems to be inconsistent with the current license. Hence, no, I don't think attaching the FAQ to the license would be a good solution. The license itself should be rephrased in order to actually say what Sun meant. -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpYlkNDd6xXX.pgp Description: PGP signature
Re: Against DRM 2.0
2006/5/23, MJ Ray [EMAIL PROTECTED]: Sorry if that's butchery of a foreign language, but this list is usually in English. Ah ah! This is in english too (there are many universal juridical latin terms!): In copyright law this led to the distinction between the corpus mysticum (the work) and the corpus mechanicum (the carrier), the one capable of copyright, the other of ownership. http://www2.law.uu.nl/priv/cier/nl/onderzoek/AHRB%20nieuw.doc The problem is that there isn't a lawyer here: this is the problem! So the right is an optional element here. :-) Max
Re: Sun Java available from non-free
On Sun, May 21, 2006 at 06:14:51PM +0200, Michael Meskes wrote: On Sat, May 20, 2006 at 04:18:44PM -0500, Anthony Towns wrote: Anyway, the background is that James Troup, Jeroen van Wolffelaar and myself examined the license before accepting it into non-free (which is three times the usual examination, and was done given the inability to examine the license in public), and both James and Jeroen had extensive contact with Sun to ensure that the tricky clauses were actually okay. You won't expect Sun to say they are not, would you? :-) The questions asked weren't Is this okay for non-free? it's Did you mean or when you wrote ?. The answers to those latter questions are, ttbomk, all included in the FAQ, which is why ignoring it just wastes everyone's time. most important, is that should any of these problems actually happen, we can fairly simply just drop Sun Java from non-free if we can't come to a better conclusion. Do you mean we can drop it if problems arise? Or do you mean we can drop it if we cannot conlcude it's okay to distribute it? I doubt you mean the first case, as it would be too late then. No, that's not the case -- if we are informed that there is a problem with what we're distributing, we can drop it 90 days after we're so informed, and not have any problems. Right, but again, why bringing the package with a bad license into the archive first? Because non-free is for bad licenses in the sense that they don't meet the DFSG, and because the Sun license is not bad in the sense that it causes any problems that we cannot deal with. DPL, I wonder Why the Sun-Java package is not handled the same as any other package. What makes it so special that it deserves special treatment? Java is one of the most important packages for which we don't have an effective non-free replacement at present. The only one that I can think of that would be more important would be flash. Cheers, aj signature.asc Description: Digital signature
