Re: MPEG-4 patent license issues - libfaad* and libx264* andother codecs.
> OTOH, it looks like these packages currently in Debian do have upstreams, > against whom the patents have not been enforced, correct? Do we know of > *anyone* who's been C&D'ed specifically for distributing a *subset* of the > code in these packages? If not, it sounds like the lack of enforcement is > pretty clear to me, do you disagree? I can't find any instances of MPEG-4 patent enforcement against mplayer, xine, vlc, or ffmpeg. The instance of patent enforcement against FAAD/FAAC remains however, and this is the only Free implementation of the AAC codec. Note that the AVC and AAC patent collections seem to be under different licensing authorities. With that caveat, I would agree with the lack of patent enforcement. MWSBell -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#346354: Is distribution of the maxdb-doc package a GPL violation?
On Thu, 04 May 2006 21:47:47 +0200 Sven Mueller wrote: > Hi. > > I've read the whole bug log and though I'm not a regular on > debian-legal, I still would like to add a note to it: > > I don't know what the current upstream does, That's what should be found out! ;-) > but I wonder about one > thing: The header about the SAP Html Export indicates that the export > happened on 19.10.2004, about 1.5 years ago. If upstream really makes > changes in some other format but the HTML (which might still be > possible), why wasn't the file re-exported after that date? Maybe because no further modification was made after that date, I don't know. > I for one have seen quite a number of documents that were once > generated or exported from some source format A into some other easily > modifiable format B. And ever since, they have been kept up to date by > editing the exported format B files, while the (once original source) > files in format A lay rotting and are removed at some point > (sometimes, but not always directly after export). And I know a few > such documents which still have comments on them indicating that they > were once exported by some random tool. Such cases are clear situations where the source code changed form at some point. This is really possible and the definition of source found in the GNU GPL shows such a flexibility. > > So, who can say wether the exported HTML isn't now really the prefered > point of modification by upstream? Upstream should state that, whenever it's not clear enough from some other evidence. > Did the file change over time, > though the comment still indicated the same date&time of export? > Though it's no prerequisit, it would be a hint that upstream is indeed > directly modifying the HTML files instead of modifying some other > source and then re-exporting the files. That would indeed be a useful hint. > > Regards, > Sven > > PS: I've subscribed to the bug, so no need to CC me on replies. OK. I am instead a debian-legal subscriber, so no need to Cc: me on replies as long as debian-legal is a recipient. -- :-( 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 pgpUA0cIgvZOm.pgp Description: PGP signature
Re: Free Art License
On Thu, 04 May 2006 09:08:24 +0200 Frank Küster wrote: > Nathanael Nerode <[EMAIL PROTECTED]> wrote: > > > It *does* mean you would be forever required to keep updated > > information on where recipients can access the original artwork. > > > > (For the Mona Lisa, the answer would be The Louvre.) > > > > The freeness of this is arguable. I think it's supposed to be > > primarily a form of attribution or credit, and it doesn't seem > > unreasonable to me. However, it may be overbroad. Convince me. > > Perhaps keeping track of the movements of the Mona Lisa as it's > > sold to different museums *is* unreasonable. > > Especially since it could be stolen. Indeed. Am I required to catch the thieves before I can distribute copies again?!? :-| > On the other hand, it is > important for a free piece of physical artwork that it be publically > accessible; the one who has power over the license (the Louvre, I > guess) would also have to make sure that, when it is sold, it will not > end up in a private house. The licensor is not bound by the license. The licensee is. If the original ends up in a private house, I, as a licensee, am not anymore able to specify where the recipient will be able to access the original, since he/she could be unable to access it... Another problem. -- :-( 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 pgpzIG2NcbGxI.pgp Description: PGP signature
Re: Free Art License
On Thu, 4 May 2006 02:09:51 -0400 Nathanael Nerode wrote: > Francesco Poli wrote: > > On Mon, 1 May 2006 15:18:32 -0400 Nathanael Nerode wrote: > > > On Thu, 27 Apr 2006 17:54:53 +1000 Andrew Donnellan wrote: > > > > There is a license called the Free Art license, I don't know if > > > > that is DFSG-free. > > > > > > I believe that it is. > > > > If you do, could you please reply to my analysis with an actual > > rebuttal? > OK. > > This license *has* to be read in the context of physical artwork. For > an all-digital artwork, it has lots of redundant, unnecessary > clauses. Maybe, but I don't think it's clearly stated... At least, the FSF does not mention this caveat in its license list: http://www.gnu.org/licenses/license-list.html#OtherLicenses Anyway, let's assume it's for physical works of authorship only (if this is true, we are quickly going off-topic here, since Debian users cannot aptitude install physical objects...). > > Suppose the Mona Lisa were licensed under this license; I will give > examples using it as I go through your comments. Oh my goodness... We are lucky that copyright did not exist when Leonardo Da Vinci was alive! ;-) > > You wrote earlier: > > > > - specify to the recipient where he will be able to access the > > > originals (original and subsequent). > > > > I'm a little concerned that this could mean that, in order to > > distribute a work under this license, I forever required to keep > > updated information on where recipients can access every previous > > version. > Not quite. Remember what "originals" means in the context of this > license: it means a single copy, normally of a physical artwork. > > It *does* mean you would be forever required to keep updated > information on where recipients can access the original artwork. > > (For the Mona Lisa, the answer would be The Louvre.) For a less famous work it would be harder to tell! > > The freeness of this is arguable. I think it's supposed to be > primarily a form of attribution or credit, and it doesn't seem > unreasonable to me. It would be if it stated something along the lines of: | - specify to the recipient where *you were* able to access the | originals (original and subsequent). It instead forces me to track down any movement of the original work. > However, it may be overbroad. Convince me. > Perhaps keeping track of the movements of the Mona Lisa as it's sold > to different museums *is* unreasonable. That is exactly what I'm concerned of: since it says "specify to the recipient where *he will be* able to access the originals", it's the future it's talking about. It could even be unsatisfiable, strictly speaking, because I cannot specify *today* where the recipient will be able to access the originals *in the future*. But even ignoring that, it seems that I'm at least required to update this datum everytime I distribute, interpret or represent the work... I'm not a detective, how can I be forced to keep track of where every original work I want to distribute (a copy of) goes? > > > What if the original changes, say, URL? Have I to keep track of > > where it goes? > This is literally impossible. The original is a single copy, not a > work. If it changes URL, you are most likely looking at a different > copy. :-) OK, forget about the URL: s/URL/museum/ > > > What if the original vanishes? > Now, *this* is a problem. Since the original is a single copy, the > vanishing of that copy is a big issue. I believe, however, that "The > original has been destroyed; nobody at all can access it anywhere" > should be sufficient to satisfy this clause. This should be drafted > better to clarify this issue. This is a freeness issue indeed, if > such a clause is not sufficient. I'm not sure that such a statement would be considered enough to go away with the destroyed original case... So, indeed, I think this is another problem. > > This is, again, clearly intended for physical artwork. I'm not > entirely sure *how* to apply it to artwork which originated in > digital form. > > I believe the only logical interpretation of the license is that an > all-digital work might have *no* "original" at all in the sense of the > license. Recall the definition of "The Original": > > > - The Original (the work's source or resource) : > > A dated example of the work, of its definition, of its partition or > > of its program which the originator provides as the reference for > > all future updatings, interpretations, copies or reproductions. I think it can make sense for non-material works too. > (Incidentally, I have no idea what "of its partition" means here. > "Its program" seems designed to refer to dance or theatre works.) I think it's talking about a musical score (in italian: "partitura"; probably similar in french, I don't know). [...] > > Have I to keep a copy of the original and > > make it available, in order to be able to distribute a subsequent > > work? > Stop thi
Re: clarification of doc licensing for db3/db4.2
Hi, sorry for not responding earlier. * Mike Olson ([EMAIL PROTECTED]) [060410 03:51]: > This is going to be some work for me. Oracle's legal department has been > very helpful on our open source requests so far, but it's a large team and > is not familiar with this issue yet. I'll need to find, then brief, then > extract approval from, the right people here. > > Before I do that, can I get some kind of authoritative statement from > Debian that the effort is necessary, and that it will satisfy the concerns > that have raised this issue for the second time? I want to be helpful, > but I want to be sure we are solving the problem here. Hm, there is some good and bad news on it. First of all, the current statement in db3/db4.2 doesn't match how we expect documentation to be. However, beginning from db4.3, this is already fixed, so we don't have really large problems for future development. For db3 and db4.2, there are two ways to fix the issue: * We could stop providing the package for etch (and tell people to use db4.3/db4.4 instead). * Oracle could change the license, e.g. to the one used in db4.3/db4.4. >From the release team's point of view, it definitly makes sense to reduce the number of libdb-versions as much as possible. :) We currently have: db3 |db3 | 3.2.9-25 | unstable | source db4.2 | db4.2 | 4.2.52-24 | unstable | source db4.3 | db4.3 | 4.3.29-5 | unstable | source db4.4 | db4.4 | 4.4.20-4 | unstable | source However, given both history and that db4.2 was quite much used in sarge (and db3 was still in major use), I doubt a bit that we can manage that in time for etch. Do you think it is possible without too much effort to adopt the documentation license from db4.3/db4.4, which reads as: | This product and publication is protected by copyright and | distributed under licenses restricting its use, copying and | distribution. See the LICENSE file in the distribution for further | information. also to the db3/db4.2-packages, where this section reads as: | This product and publication is protected by copyright and distributed | under licenses restricting its use, copying and distribution. Permission | to use this publication or portions of this publication is granted by | Sleepycat Software provided that the above copyright notice appears in | all copies and that use of such publications is for non-commercial use | only and no modifications of the publication is made. If not, we should consider how to get to the goal with minimum effort on all sides. Thanks for your support. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#346354: Is distribution of the maxdb-doc package a GPL violation?
Hi. I've read the whole bug log and though I'm not a regular on debian-legal, I still would like to add a note to it: I don't know what the current upstream does, but I wonder about one thing: The header about the SAP Html Export indicates that the export happened on 19.10.2004, about 1.5 years ago. If upstream really makes changes in some other format but the HTML (which might still be possible), why wasn't the file re-exported after that date? I for one have seen quite a number of documents that were once generated or exported from some source format A into some other easily modifiable format B. And ever since, they have been kept up to date by editing the exported format B files, while the (once original source) files in format A lay rotting and are removed at some point (sometimes, but not always directly after export). And I know a few such documents which still have comments on them indicating that they were once exported by some random tool. So, who can say wether the exported HTML isn't now really the prefered point of modification by upstream? Did the file change over time, though the comment still indicated the same date&time of export? Though it's no prerequisit, it would be a hint that upstream is indeed directly modifying the HTML files instead of modifying some other source and then re-exporting the files. Regards, Sven PS: I've subscribed to the bug, so no need to CC me on replies. signature.asc Description: OpenPGP digital signature
Re: Bacula documentation
This one time, at band camp, John Goerzen said: > > Is this free? (I'm thinking not...) No. Banning (or only allowing with different conditions) commercial use is a fairly straight forward marker of failing the DFSG. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Bacula documentation
Is this free? (I'm thinking not...) This manual may be included without modification in a packaged release for use with Bacula, or it may be copied for your own or company use, and it may be cited in small parts for presentation purposes. It may not be published for sale in any form, other than small citations, without express written permission from the author. http://www.bacula.org/rel-manual/index.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: Re: MPEG-4 patent license issues - libfaad* and libx264* andother codecs.
On Wed, May 03, 2006 at 05:11:38PM +0100, Matthew William Solloway Bell wrote: > I mean with respect to looking in packages to find out if they have a > coder or a decoder. > So, we have a document that supports a reasonable belief that the > patents that cover parts of the MPEG-4 standard are invalidated by prior > art. > But, we have a history of patent enforcement that certainly covers the > AAC encoding process and may cover the decoding process. As well as code > that implements the decoding process for both AVC and AAC, we have > libx264 that encodes AVC in main. > Should we continue regarding the MPEG-4 patents invalid, for either or > both of encoding and decoding, or should we remove code? Well, basically what we have is that a collection of patents were collectively enforced against a work that included both an encoder and a decoder. We don't know which patents it's claimed were infringed by the work; we don't know which part of the work it's claimed infringed the patents. This makes it difficult to draw too many parallels with the current packages. OTOH, it looks like these packages currently in Debian do have upstreams, against whom the patents have not been enforced, correct? Do we know of *anyone* who's been C&D'ed specifically for distributing a *subset* of the code in these packages? If not, it sounds like the lack of enforcement is pretty clear to me, do you disagree? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Free Art License
Nathanael Nerode <[EMAIL PROTECTED]> wrote: > It *does* mean you would be forever required to keep updated information on > where recipients can access the original artwork. > > (For the Mona Lisa, the answer would be The Louvre.) > > The freeness of this is arguable. I think it's supposed to be primarily a > form of attribution or credit, and it doesn't seem unreasonable to me. > However, it may be overbroad. Convince me. Perhaps keeping track of the > movements of the Mona Lisa as it's sold to different museums *is* > unreasonable. Especially since it could be stolen. On the other hand, it is important for a free piece of physical artwork that it be publically accessible; the one who has power over the license (the Louvre, I guess) would also have to make sure that, when it is sold, it will not end up in a private house. >> - The Original (the work's source or resource) : >> A dated example of the work, of its definition, of its partition or of >> its program which the originator provides as the reference for all >> future updatings, interpretations, copies or reproductions. > (Incidentally, I have no idea what "of its partition" means here. "Its > program" seems designed to refer to dance or theatre works.) I've seen "partition" used in a cover text of a music CD, it seems to refer to the score of music for the orchestra. It might be a false-friend like translation, in german a music score for many instruments is called "partitur". Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
