Re: [Debtags-devel] Re: Creating a Debtags 'license' facet
Hi, after (barely) catching up by just word-scanning some mails (I don't have the time to read all my mail - I might not have net access for the next two weeks again, travelling around in an RV through national parks), just a few ideas by me: How about making the tags titled: Contains files with 'attribution' requirements Contains files with 'share-alike' requirements and maybe Is fully public domain Basically, we should be able to map typical restrictions - and GPL does have restrictions, as anyone here should know - to tags. It should be made clear, that this doesn't remove the need to check the actual licences, though... Using this contains files with restriction X approach, having packages with different licences used in them should be possible. As should users be able to filter out certain things they do not accept. The must not modify licence thing of course is a special issue... just my $.02 best regards, Erich Schubert -- erich@(mucl.de|debian.org) -- GPG Key ID: 4B3A135C(o_ To understand recursion you first need to understand recursion. //\ Wo befreundete Wege zusammenlaufen, da sieht die ganze Welt für V_/_ eine Stunde wie eine Heimat aus. --- Herrmann Hesse
Re: New 'Public Domain' Licence
On Thursday 09 June 2005 11:10 pm, Anthony DeRobertis wrote: Andrew Suffield wrote: The primary threat is not from the heirs (although that is a threat, and you don't have control over all your heirs - your parents and cousins can qualify), If you're worried about your heirs revoking your copyright licences, I suggest talking to the FSF or someone like them; you could make the FSF the heir to your copyrights. No, your parents and cousins CANNOT qualify, blood relation is not enough under the statute. The right of termination flows from you, to your spouse, then to your children, and final to your estate's executor. You can transfer the copyright to others beyond that chain, but the termination right remains with the others. So, if I will my copyright to Frank, my 3rd cousin, who then licenses it to MGM, either my spouse or children can still exercise their termination right over that license (but not the transfer to Frank... since transferring the copyright by will is not susceptible to termination). -Sean -- Sean Kellogg 2nd Year - University of Washington School of Law GPSS Senator - Student Bar Association Editor-at-Large - National ACS Blog [http://www.acsblog.org] w: http://probonogeek.blogspot.com So, let go ...Jump in ...Oh well, what you waiting for? ...it's all right ...'Cause there's beauty in the breakdown
Re: New 'Public Domain' Licence
On Thursday 09 June 2005 06:36 pm, Michael K. Edwards wrote: I wrote: So I think it turns out I was right in the first place: continued verbatim copying and distribution counts as utilization, and the only scope for argument is about how much bug-fixing you can do after termination without being sued for preparing a new derivative work. Sean commented previously that Congress's use of the otherwise undefined word utilize in 17 USC 203 is confusing, and I agree. However, the Mills Music case clears things up considerably; and as Congress hasn't seen the need to override Mills by modifying 203 and 304 in any of the various revisions to the Act over the subsequent 20 years, I think we can take it as good law. Although I haven't Shepardized it yet, I've used FindLaw to search for subsequent Supreme Court decisions that reference Mills, and it doesn't appear to have been repudiated by later courts. In fact, see Stewart v. Abend 1990, which references Mills when comparing the 304(c)(6)(A) exception to the author's termination rights against the lack of such an exception in the provisions for the renewal term of a pre-1978 copyright. The opinion states: For example, if petitioners held a valid copyright in the story throughout the original and renewal terms, and the renewal term in 'Rear Window' were about to expire, petitioners could continue to distribute the motion picture even if respondent terminated the grant of rights, but could not create a new motion picture version of the story. Thus Mills was still good precedent in 1990, and was used in the course of distinguishing between relicensing at the commencement of the renewal term and post-renewal-term termination with respect to pre-1978 works. Note also that the Supreme Court affirmed the decision of the Ninth Circuit in Stewart v. Abend and largely rejected the reasoning in the 1977 Rohauer v. Killiam Shows decision of the Second Circuit (the previous authority, given that certioriari was denied at that time). It is interesting to note that Nimmer's commentary on Rohauer seems to have strongly influenced the justices who joined in the Stewart decision. You could be right... but I think that Mills is distinguishable on the law (if not also the facts...). The renewal right under (s)304 and the termination right under (s)203 are really quite different. For example, the renewal right is transferable, where the termination right is not. Additionally, if utilization is read the way you suggest, it really strikes at the heart of the policy objective of the termination right. The objective, as explained by my Copyrights Prof., is to provide authors a second chance to negotiate licenses that may have been poorly made when the work was first released. If termination only prohibits the creation of new derivative works, leaving copying and distribution of preexisting derivatives, then what's really left to renegotiate? As an added complication, the utilization term is only applicable in the case of derivative works based on the licensed work, but not pure copies. So if I have a license to copy and distribute a Beatles's song without any alterations from the original, when the license is terminated I'm left with nothing... I can't even keep the original copy around! Does making a derivative really earn you so many rights that you not only get to keep the copy, but also made new copies and distribute?! ... something doesn't smell right. -Sean -- Sean Kellogg 2nd Year - University of Washington School of Law GPSS Senator - Student Bar Association Editor-at-Large - National ACS Blog [http://www.acsblog.org] w: http://probonogeek.blogspot.com So, let go ...Jump in ...Oh well, what you waiting for? ...it's all right ...'Cause there's beauty in the breakdown
Re: New 'Public Domain' Licence
On 6/10/05, Sean Kellogg [EMAIL PROTECTED] wrote: You could be right... but I think that Mills is distinguishable on the law (if not also the facts...). The renewal right under (s)304 and the termination right under (s)203 are really quite different. For example, the renewal right is transferable, where the termination right is not. Additionally, if utilization is read the way you suggest, it really strikes at the heart of the policy objective of the termination right. 304(c)(6)(A) is exactly the same text as 203(b)(1), and applies only to termination during the extension term (the 19 years after 28+28) of a pre-1978 copyright. No relation to the renewal term, as discussed in Stewart v. Abend. The objective, as explained by my Copyrights Prof., is to provide authors a second chance to negotiate licenses that may have been poorly made when the work was first released. If termination only prohibits the creation of new derivative works, leaving copying and distribution of preexisting derivatives, then what's really left to renegotiate? Largely, terms on reproduction of the original work. And as the most important applications of the derivative work business are sound recordings and film/television rights, and sound recordings are exceptions to the Exception (per Woods v. Bourne), Congress probably figured that it was stupid for a film to be withdrawn from circulation because its producer's license to some song was terminated (as had happened upon copyright renewal under the 1909 law). Authors don't generally grant their publishers blanket licenses to create derivative works of their books, and by the time they're authorizing a screenplay they ought to know this is their one shot at negotiating big royalty payments. So about the only people getting burned by the derivative works exception to termination are open source authors who grant blanket authorizations to modify and reuse; and that's fine, because it would be just as silly to let them pull the plug on users of a derivative of their work as it would be to let songwriters hold already prepared films for ransom. As an added complication, the utilization term is only applicable in the case of derivative works based on the licensed work, but not pure copies. So if I have a license to copy and distribute a Beatles's song without any alterations from the original, when the license is terminated I'm left with nothing... I can't even keep the original copy around! Does making a derivative really earn you so many rights that you not only get to keep the copy, but also made new copies and distribute?! You're misreading utilize; it's the publisher's right to utilize the copyright license by copying and initial distribution that's being terminated, not any right of use and subsequent transfer inherent in an individual copy after first sale. All that preparing a derivative work (under explicit license to do so) gets a publisher is the right to continue the terms of the existing agreement with respect to that derivative work. Read Woods v. Bourne for an idea of which royalty agreements get renegotiated and which don't. Cheers, - Michael
Re: New 'Public Domain' Licence
On 6/10/05, Michael K. Edwards [EMAIL PROTECTED] wrote: 304(c)(6)(A) is exactly the same text as 203(b)(1), and applies only to termination during the extension term (the 19 years after 28+28) of a pre-1978 copyright. ... 39 instead of 19 now, of course, courtesy of the Sonny Bono Act. Regrets, - Michael
Re: MPlayer revisited
Diego Biurrun [EMAIL PROTECTED] wrote: On Wed, Jun 08, 2005 at 05:34:02PM +, MJ Ray wrote: Bugs in some package already in debian doesn't let another package with those bugs in as a right, though. It just means we have bugs to deal with. Yes. Still Debian's position needs to be consistent and credible as well. If MPlayer has problem X and therefore cannot enter Debian, then the other multimedia players sharing problem X would have to be removed, wouldn't they? The other multimedia players should have a bug of the appropriate severity reported to them. I'd expect anything serious enough to keep MPlayer out would cause them to be removed from a release, or maybe even the archive entirely. [...] or maybe nothing mplayer team will be good enough and we need to get a lawyerly opinion. Sorry, I don't understand this sentence, could you please clarify? Sorry, I seem to have missed words. Should read maybe nothing the mplayer team can say will be good enough. [...] MPlayer includes both libdvdcss and libdvdread in the libmpdvdkit2 directory. IIRC Andrea removed it and decided to link to the Debian libdvdread dynamically. I think my summary is accurate but unclear. I'll improve it later. Thanks, -- 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: New 'Public Domain' Licence
Anthony does an excellent job of making the arguments in favor of the Linux kernel as a joint work and/or a collective work containing multiple components under separate authorship; but I simply don't agree. The collective work theory doesn't hold water at all (except with regard to firmware blobs, which indeed are not part of the kernel). The kernel, drivers and all, is a single work of authorship subject to periodic systematic overhaul when internal APIs change. Any piece of the code could get refactored or replicated anywhere else in the kernel at any time without the involvement or approval of its contributor. Nor is anyone else a joint author; Linus doesn't exercise a heavy hand when he doesn't have to; but he alone has the power to approve contributions to the active development branch, and exerts a degree of creative control that no one else can claim. A lot of authority is delegated to maintenance series editors, but that's not where the action is, and they serve at his pleasure and their individual decisions are subject to his veto. You might say that Aalmuhammed was Spike Lee's Alan Cox or David Miller, by analogy with the facts of the case: quote [4] Aalmuhammed joined Washington on the movie set. The movie was filmed in the New York metropolitan area and Egypt. Aalmuhammed presented evidence that his involvement in making the movie was very extensive. He reviewed the shooting script for Spike Lee and Denzel Washington and suggested extensive script revisions. Some of his script revisions were included in the released version of the film; others were filmed but not included in the released version. Most of the revisions Aalmuhammed made were to ensure the religious and historical accuracy and authenticity of scenes depicting Malcolm X's religious conversion and pilgrimage to Mecca. [5] Aalmuhammed submitted evidence that he directed Denzel Washington and other actors while on the set, created at least two entire scenes with new characters, translated Arabic into English for subtitles, supplied his own voice for voice-overs, selected the proper prayers and religious practices for the characters, and edited parts of the movie during post production. Washington testified in his deposition that Aalmuhammed's contribution to the movie was great because he helped to rewrite, to make more authentic. Once production ended, Aalmuhammed met with numerous Islamic organizations to persuade them that the movie was an accurate depiction of Malcolm X's life. /quote But Aalmuhammed still lost the portion of his case that depended on a claim of co-authorship: quote [24] Aalmuhammed did not at any time have superintendence of the work. Warner Brothers and Spike Lee controlled it. Aalmuhammed was not the person who has actually formed the picture by putting the persons in position, and arranging the place. . . . Spike Lee was, so far as we can tell from the record. Aalmuhammed, like Larson's dramaturg, could make extremely helpful recommendations, but Spike Lee was not bound to accept any of them, and the work would not benefit in the slightest unless Spike Lee chose to accept them. Aalmuhammed lacked control over the work, and absence of control is strong evidence of the absence of co-authorship. ... [27] The Constitution establishes the social policy that our construction of the statutory term authors carries out. The Founding Fathers gave Congress the power to give authors copyrights in order [t]o promote the progress of Science and useful arts. Progress would be retarded rather than promoted, if an author could not consult with others and adopt their useful suggestions without sacrificing sole ownership of the work. Too open a definition of author would compel authors to insulate themselves and maintain ignorance of the contributions others might make. Spike Lee could not consult a scholarly Muslim to make a movie about a religious conversion to Islam, and the arts would be the poorer for that. /quote Notwithstanding the various degrees of autonomy that driver writers and subsystem maintainers possess, I think that the Linux kernel is neither a joint work nor a collective work, and irrespective of acknowledgments and copyright notices no one other than Linus can claim authorship under US law of any portion of the mainstream kernel. Not, that is, unless and until he burns out and hands the reins to a new benevolent dictator. Cheers, - Michael (IANAL, TINLA)
Re: New 'Public Domain' Licence
Michael K. Edwards wrote (with spacing fixed): 2) the 50% rule applies to _authorship_, which connotes (per Aalmuhammed v. Lee) a degree of creative control so high that, e. g.,there is no candidate for authorship of the Linux kernel other than Linus Torvalds; I've read the cited case, and it does not seem to apply well to the Linux kernel. The first problem is that not all versions of Linux have Linus as having sole control over the work; Linux 2.0, 2.2., and 2.4 are all controlled by people other than him. The same applies to all the various branches (-ac, -mm, etc.). The second problem is that Linus allows a large amount of effective control over the kernel to his section maintainers; while he can of course say no to their changes, he generally delegates that decision to them. The third is that large parts of the kernel are written by diverse people and are not actually part of an inseperable whole at all; examples include drivers. Some of these, for example, are used on xBSD as well. The fourth is that the cited case involves things certainly not relevant to Linux, such as a work for hire agreement being signed. In short, Aalmuhammed was hired to offer advice, not to create parts of the movie. He had no control over the movie. This is not at all how large contributions to the kernel work. As a typical example, let's say I have a Foo Corp video card, which is not supported by Linux. I reverse-engineer the hardware interface, and write a driver. After a good deal of testing, I submit it to linux-kernel (the kernel mailing list). I have had full control over this work; I am its author. Several people on linux-kernel provide suggestions; by the standards in Aalmuhammed v. Lee, they are not co-authors. After I make those minor changes, the person in charge of video drivers accepts my driver, and forwards it to Linus, who includes it in the kernel tarball. What has happened here is that Linus (and possible some others) have created a collection, which is probably in itself copyrightable. He/they are indeed the author of that collection; however, I am still the author of my part of that collection. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: MPlayer revisited
On Fri, Jun 10, 2005 at 08:34:39AM +, MJ Ray wrote: Diego Biurrun [EMAIL PROTECTED] wrote: On Wed, Jun 08, 2005 at 05:34:02PM +, MJ Ray wrote: Bugs in some package already in debian doesn't let another package with those bugs in as a right, though. It just means we have bugs to deal with. Yes. Still Debian's position needs to be consistent and credible as well. If MPlayer has problem X and therefore cannot enter Debian, then the other multimedia players sharing problem X would have to be removed, wouldn't they? The other multimedia players should have a bug of the appropriate severity reported to them. I'd expect anything serious enough to keep MPlayer out would cause them to be removed from a release, or maybe even the archive entirely. OK. or maybe nothing mplayer team will be good enough and we need to get a lawyerly opinion. Sorry, I don't understand this sentence, could you please clarify? Sorry, I seem to have missed words. Should read maybe nothing the mplayer team can say will be good enough. I surely hope we're not at the point where constructive dialog has become impossible. I ask all of you to judge my words on their merit and not past statements made by other people. MPlayer includes both libdvdcss and libdvdread in the libmpdvdkit2 directory. IIRC Andrea removed it and decided to link to the Debian libdvdread dynamically. I think my summary is accurate but unclear. I'll improve it later. I beg to differ. The sentence DeCSS code: removed and mplayer-debian uses libdvdread3 instead has two problems: 1) It implies that MPlayer contains DeCSS, which it does not. MPlayer contains libdvdcss. DeCSS and libdvdcss are not the same. DeCSS is based on a key that was leaked to the internet, while libdvdcss basically bruteforces the weak CSS encryption. DeCSS has been the subject of several lawsuits (which were all won by the forces of light), while libdvdcss has never had any legal troubles. 2) It suggests that libdvdread is a replacement for libdvdcss, which it is not. libdvdread provides access to the different types of information stored throughout a DVD, it's essential for any kind of DVD playback. libdvdcss decrypts CSS, it's only necessary for playing encrypted DVDs. Sorry, I really do not want to sound argumentative. It's just that I encounter these misconceptions all the time when I talk to people about the situation of Debian and MPlayer. I have to clarify these two points constantly, that's why I am insisting here. Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openssl vs. GPL question
Michael K. Edwards wrote: You might also observe the comments at http://bugs.mysql.com/bug.php?id=6924 and http://bugs.mysql.com/bug.php?id=8508 regarding MySQL's retreat, first from providing OpenSSL-enabled binaries, and then from referencing OpenSSL in the server source code. Any bets on whether there was a quid pro quo involved when Eben Moglen submitted an affidavit in Progress Software v. MySQL? If you wish to allege underhanded dealings, please bring some evidence. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openssl vs. GPL question
On 6/10/05, Anthony DeRobertis [EMAIL PROTECTED] wrote: Michael K. Edwards wrote: You might also observe the comments at http://bugs.mysql.com/bug.php?id=6924 and http://bugs.mysql.com/bug.php?id=8508 regarding MySQL's retreat, first from providing OpenSSL-enabled binaries, and then from referencing OpenSSL in the server source code. Any bets on whether there was a quid pro quo involved when Eben Moglen submitted an affidavit in Progress Software v. MySQL? If you wish to allege underhanded dealings, please bring some evidence. Perhaps it would be more accurate to say that MySQL's executives appear to have been availing themselves of the services of the GPL Compliance Lab, and have probably received a few letters on Columbia University letterhead. I think the FSF's entire handling of OpenSSL is underhanded. For them to make the false claim that API usage makes for a derivative work when it suits them, and then to accept the copying of the OpenSSL API into the GPL'ed yaSSL and the GPL'ed shim to GNU TLS, and then recommend these alternatives over OpenSSL to all GPL licensors, is beyond hypocritical. As regards MySQL, here are some comments by one Tim Smith on bug 6924: quote We would like to be able to release binaries with SSL support, and are investigating different options for that. I'm told that building with yassl is possible right now, so this may be an option for you, depending on how you're using MySQL, etc. ... It's due to unclear license issues. Basically, we'd be OK distributing OpenSSL-enabled binaries, but anyone who redistributed them would probably be violating the license. Our licence doesn't have a clear exclusion that handles OpenSSL. I'm doing a bit of parroting here, since I'm not directly involved with making these decisions. I can tell you for sure that it's due to legal, not technical, reasons. /quote Who do you suppose would be telling MySQL that they don't have the ability to alter the license on their own software to accommodate their own decision to use OpenSSL? - Michael
Re: openssl vs. GPL question
Michael K. Edwards wrote: P. S. If you think that an FSF vendetta against OpenSSL would be an anomaly, or that RMS is purist about copyright law when it comes to his own conduct, you might be interested in Theo de Raadt's comments at http://www.monkey.org/openbsd/archive/tech/0002/msg00171.html . That URL says From: Brett Glass [EMAIL PROTECTED] who is, AFAIK, not Theo de Raadt. The only two Theo de Raadt postings in that thread are essentially go away. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openssl vs. GPL question
Michael K. Edwards wrote: On 6/6/05, Michael K. Edwards [EMAIL PROTECTED] wrote: Whoops, I misattributed that message. It's Brett Glass who wrote that, NOT Theo de Raadt. :-( And after Googling Brett Glass briefly, I doubt he has much concrete evidence to back up his claim that RMS plagiarized Symbolics code. [...] Sorry about my last message; I managed to reply before seeing these corrections. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: MPlayer revisited
MJ Ray wrote: I'm not quite sure what sort of statement about patents will convince ftpmasters. Maybe knowing what patents held by who are definitely infringed by mplayer is good, especially if none of them are actively enforced, or maybe it is bad. ObligatoryIAmNotALawyerDisclosure / This seems like a potentially bad idea, actually. I certainly can't cite specific laws, but I seem to recall from similar discussions that if a patent holder can prove a patent was violated in full knowledge of the violation, he is entitled to triple damages. In the course of researching patents possibly violated by MPlayer, one would surely uncover the presence of the same patents in code already in Debian -- the already-mentioned Xine, Avifile, etc. regards, -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Debtags-devel] Re: Creating a Debtags 'license' facet
On Thu, Jun 09, 2005 at 12:17:42PM +0200, Enrico Zini wrote: On Fri, Jun 03, 2005 at 10:06:48PM +0100, Andrew Suffield wrote: On Fri, Jun 03, 2005 at 04:20:05PM +0200, Enrico Zini wrote: You've got a problem with this one, because licenses can be combined conjunctively and disjunctively. So a package might be both entirely under foo and entirely under bar (foo || bar), or it might be partially under foo and partially under bar (foo bar). If that is the only problem, a package can be tagged with more than one tag even from the same facet, which would be good enough to categorise your two examples. Imagine a package that can be distributed if you meet the terms of: - the GPL - both the MIT license and the 4-clause BSD license, simultaneously - both the MIT license and the Artistic license, simultaneously How would you tag this, so as to capture all this information? -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: New 'Public Domain' Licence
On Fri, Jun 10, 2005 at 12:50:03AM -0700, Sean Kellogg wrote: On Thursday 09 June 2005 11:10 pm, Anthony DeRobertis wrote: Andrew Suffield wrote: The primary threat is not from the heirs (although that is a threat, and you don't have control over all your heirs - your parents and cousins can qualify), If you're worried about your heirs revoking your copyright licences, I suggest talking to the FSF or someone like them; you could make the FSF the heir to your copyrights. No, your parents and cousins CANNOT qualify, blood relation is not enough under the statute. The right of termination flows from you, to your spouse, then to your children, and final to your estate's executor. Sounds like a US perversion to me. I doubt many places have weird laws that override normal inheritance law. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: [Debtags-devel] Re: Creating a Debtags 'license' facet
On Fri, Jun 10, 2005 at 07:22:59PM +0100, Andrew Suffield wrote: On Thu, Jun 09, 2005 at 12:17:42PM +0200, Enrico Zini wrote: On Fri, Jun 03, 2005 at 10:06:48PM +0100, Andrew Suffield wrote: On Fri, Jun 03, 2005 at 04:20:05PM +0200, Enrico Zini wrote: You've got a problem with this one, because licenses can be combined conjunctively and disjunctively. So a package might be both entirely under foo and entirely under bar (foo || bar), or it might be partially under foo and partially under bar (foo bar). If that is the only problem, a package can be tagged with more than one tag even from the same facet, which would be good enough to categorise your two examples. Imagine a package that can be distributed if you meet the terms of: Uhh, unclear, this should be read as: EITHER - the GPL OR - both the MIT license and the 4-clause BSD license, simultaneously OR - both the MIT license and the Artistic license, simultaneously -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: New 'Public Domain' Licence
On Friday 10 June 2005 11:24 am, Andrew Suffield wrote: No, your parents and cousins CANNOT qualify, blood relation is not enough under the statute. The right of termination flows from you, to your spouse, then to your children, and final to your estate's executor. Sounds like a US perversion to me. I doubt many places have weird laws that override normal inheritance law. Normal inheritance law?! That's the understatement of the day. After taking Wills, Trusts, and Estates I am of the complete opinion that there is no such thing as normal inheritance law. The issues lies with competing policy objectives: 1) keeping with the intent of the dead, 2) providing for the dead's dependents. If the dead gives all of their money to someone other than their dependents, then someone else has got to provide for those dependents... and that someone often becomes the State. Since inheritance is not a natural property right, but a legal construction of the State itself, it is well within the State's right to dictate that certain portions of your estate MUST transfer to your dependants. To hold otherwise would allow the deceased to abandon their dependents and make the rest of society pay, all to the benefit of their non-dependent beneficiary. I'll tell ya, they teach Copyrights in a 3 credit course and its probably too many credits... they teach Wills, Trusts, and Estates in a 5 credit course and its not nearly enough time to cover everything. -Sean -- Sean Kellogg 2nd Year - University of Washington School of Law GPSS Senator - Student Bar Association Editor-at-Large - National ACS Blog [http://www.acsblog.org] w: http://probonogeek.blogspot.com So, let go ...Jump in ...Oh well, what you waiting for? ...it's all right ...'Cause there's beauty in the breakdown
Re: Re: openssl vs. GPL question
Hi everyone, On 6/4/05, Dafydd Harries [EMAIL PROTECTED] wrote: I have a package Alexandria, written in Ruby, which will depend on a new library in the next version. This library, ruby-zoom, is an LGPL Ruby binding of libyaz. libyaz links to OpenSSL and is, as far as I can tell, under a 2-clause BSD licence. Everything fine so far. But it seems to me that it will be impossible for Alexandria, which is under the GPL, to use ruby-zoom legally as, by doing so, it will be linking against OpenSSL, which is under a GPL-incompatible licence. Am I right in thinking so? It is Debian's historical practice, and the FSF's stance, not to permit this kind of dependency (direct or indirect). I believe strongly, and have adduced plenty of case law to demonstrate, that the FSF's GPL FAQ is in error on this point. I would not say, however, that my opinion represents a debian-legal consensus. See recent debian-legal threads about Quagga, which is in a similar position. My understanding of this issue is based on reading this thread: http://lists.debian.org/debian-legal/2002/10/msg00113.html If there is indeed a licence problem here, I can see two main solutions: - Try to get libyaz in Debian to link against GnuTLS instead of OpenSSL. - Get the maintainer of Alexandria to make an exception for linking against OpenSSL. The latter is probably a better choice (at least in the short term), since the OpenSSL shim for GNU TLS was added to the GPL (not LGPL) libgnutls-extra. (It's possible that it has since been moved into the LGPL portion, but I don't think so.) While I don't believe in the FSF's theories about linking causing GPL violation (especially in the indirect scenario), it's the Debian way to request a clarification from upstream. I notice that the Tellico package, which is GPL, already links against libyaz. Is this a licence violation? No; but there again, it would probably be best to check with upstream about whether they would mind adding an explicit OpenSSL exemption. Wishlist bug? Sorry to arrive late, I am not on -legal, amd only noticed this thread during one of my usual checking of what's happening around here. I appear to be the maintainer of tellico, so I would like to have a good advice on what to do for this problem. I have CC'ed Robby Stephenson, who is the upstream author of Tellico, so he can know and make a decision about it if he thinks he should. Regards, Regis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Creating a Debtags 'license' facet
On Fri, Jun 10, 2005 at 03:32:14PM -0300, Humberto Massa Guimar?es wrote: * Andrew Suffield :: On Thu, Jun 09, 2005 at 12:17:42PM +0200, Enrico Zini wrote: On Fri, Jun 03, 2005 at 10:06:48PM +0100, Andrew Suffield wrote: On Fri, Jun 03, 2005 at 04:20:05PM +0200, Enrico Zini wrote: You've got a problem with this one, because licenses can be combined conjunctively and disjunctively. So a package might be both entirely under foo and entirely under bar (foo || bar), or it might be partially under foo and partially under bar (foo bar). If that is the only problem, a package can be tagged with more than one tag even from the same facet, which would be good enough to categorise your two examples. Imagine a package that can be distributed if you meet the terms of: - the GPL - both the MIT license and the 4-clause BSD license, simultaneously - both the MIT license and the Artistic license, simultaneously How would you tag this, so as to capture all this information? ( GPL ) || ( MIT 4BSD ) || ( MIT Artistic ) ?? :-) this is the easy one, what if some files are provided under each of those licenses? GPL + (MIT 4BSD) + (MIT Artistic)? Although it is not precise, it might help to have a multiple-license tag. Probably everything more fine-grained has to be manually reviewed, anyway. Just tag each package with every license which is somehow related to the license of that package, and hope that there aren't a bajillion libraries (which are probably the easiest use of this type of tagging: What libraries are compatible with the program I already have or want to have) which do a given thing which also match a semi-complicated license condition (like, !BSD !GPL). Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
