Re: Microsoft Bing or Windows Spotlight daily picture as wallpaper?
El 9/10/22 a les 13:08, Patrice Coni ha escrit: Dear debian-legal people, I develop a software that downloads the daily picture from Bing or Windows Spotlight and set it as wallpaper on a X11 desktop environment. Bing or Windows Spotlight are features of Microsoft. The daily picture is obtained from www.bing.com or from arc.msn.com. Each image appears to be copyrighted by its owner. The software (DailyDesktopWallpaperPlus) not only downloads the picture, but the copyright and description of each image is stored in a local database. The images are saved and can be reused later. Is this legal? What do I have to consider? My goal is that the software to be included by Debian. Link: https://github.com/pgc062020/DailyDesktopWallpaperPlus Thanks in advance. Best regards Patrice Coni There could be two possible scenarios: either the images are free for use even for commercial purposes (so Microsoft can use them without asking for further permission) or Microsoft did seek and got explicit permission from the picture copyright owner to display them on their feature. In the first scenario, Debian probably could use them as well; in the second, probably not. Note the "probably" on both cases. Also, this check should be done for each and every picture going to be displayed, present and future. If Microsoft is using today a picture for which needs not an explicit grant, we have no warranty at all that tomorrow it will be the same. IANAL neither DD but I would be very uncomfortable with this software even as an end user where I would end having copyrighted images locally stored for which I could be held personally liable.
Re: anti-tarball clause and GPL
El 24/7/19 a les 22:28, Florian Weimer ha escrit: > * Adam Borowski: > >> In the light of the currently discussed GR proposal, I wonder if the >> following license clause would be considered DFSG-free and GPL-compatible: >> >> ## >> I do not consider a flat tarball to be a preferred form for modification. >> Thus, like any non-source form, it must be accompanied by a way to obtain >> the actual form for modification. There are many such ways -- unless you >> distribute the software in highly unusual circumstances, a link to a >> network server suffices; see the text of the GPL for further details. >> ## >> >> I believe such a statement would be GPL-compatible; rationale: >> * by the 2011 Red Hat kernel sources outcry, it is obvious such a tarball >> is long obsolete >> * a flat tarball deprives the recipient of features of modern VCSes >> * comments giving rationale for a change tend to be written as VCS commit >> messages >> * future forms are not banned: it is conceivable that next week someone >> invents a revolutionary new form that wins over git >> >> Thoughts? > The GPL version 2 already requires that you maintain something like a > ChangeLog: > > | 2. You may modify your copy or copies of the Program or any portion > | of it, thus forming a work based on the Program, and copy and > | distribute such modifications or work under the terms of Section 1 > | above, provided that you also meet all of these conditions: > | > | a) You must cause the modified files to carry prominent notices > | stating that you changed the files and the date of any change. > > On the other hand, not allowing source distribution as a “flat > tarball” sounds like an additional restriction, which would be > incompatible with the GPL. (Just like parts of glibc used to require > distribution on tapes, only less inconvenient.) Actually, the GPL only mandates stating *who* made changes and *when*, but not *what* changed. As I see, just adding something like "Modified by John Doe on 2019.07.25" on the comment header where the GPL copyright notice lies would suffice. OTOH, some CVS systems may misattribute authorship if the person pushing the code to the exportable tree version is not the same who actually originally wrote the code on a private trunk tree: although Git makes a difference between author and commiter, Subversion does not.
Re: FRR package in Debian violates the GPL licence
El 21/3/19 a les 11:17, Giacomo Tesio ha escrit: > So why do you think that this is a "toxic precedent"? No free software could run under Windows without proper Microsoft licensing: Firefox, Libreoffice... No free software could use or implement compatible Windows services, either server or client, without proper Microsoft licensing: Samba, rdesktop... That would make Linux and Windows ecosystems fully disjoint. This would force me to use Windows to do the work I'm paid for and for which I've been using Debian for 10 years. OTOH, that would make the software patent problem fully irrelevant because copyright would cover what currently is being enfonced by patent licensing.
Patent discussion on debian-legal (Was: Hacking License)
El 12/12/18 a les 16:06, Ian Jackson ha escrit: > As for the first link, it says only > | Copyright, licensing and patent issues > | Discussions about legality issues such as copyrights, patents etc. > > which IMO accurately describes the scope of the list within Debian. IIRC there was a discussion some time ago strongly discouraging patent discussion on debian-legal, for fears about these could be used against the project itself on the grounds of prior knowledge. Should be removed the patent discussion mention on the list description?
Re: Hacking License
El 11/12/18 a les 23:46, Paul Jakma ha escrit: > On Tue, 11 Dec 2018, Eloi Notario wrote: > >> Furthermore, these patches will be protected by the GPLv3 and even if >> publicly available Sencha will be unable to sell them, > > Probably you know this, and you meant "sell them exclusively or > somesuch", but just to note: > > Nothing in the GPL prevents one from selling GPL source code. > > ;) > > regards, Yes, this misunderstanding is the result of an attempt to reword this paragraph and not proof-reading again ;-) That was really meant to say that the actor could not *relicense* the third-party patches under another, non-GPL license. I am very well aware of the GPL-selling capabilities, actually my paycheck comes in part from that very point :-)
Re: Hacking License
El 11/12/18 a les 22:33, Giacomo ha escrit: > On December 11, 2018 7:54:16 PM UTC, Eloi Notario wrote: >> El 11/12/18 a les 9:53, Giacomo Tesio ha escrit: >>> [...] >>> 2. If ExtJs was a Derived Work of a software release under the >> Hacking >>> License, Sencha would have no right to keep any version proprietary. >> Being Sencha the copyright owner (noting for clarity as I cut that from >> the quote), I am quite skeptical this argument will hold at least under >> Spanish law and probably under all those jurisdictions where the >> "Public Domain" concept is not acknowledged because no author rights can be >> waived. This includes the right to decide how -and if- a work is to be >> distributed. > As should be clear in the text you quoted, I was talking about an > hypothetical ExtJS that was > > - a Derived Work > - of a software under the Hacking License Maybe I cut too much text from the original quote. Let me pick a previous paragraph: > 2. Sencha releases as GPLv3 only the first major version and the first > minor version of a new release, and only release as proprietary the > code the successive minor versions (that can largerly extend the > widget available). This is, as you stated, what could happen if the original work was licensed under the GPLv3. However, if we're talking about a derived work, then the proprietary selling of this extended package is already a violation of the GPL. The fact that, with your license, this would too end in a violation is moot: your "new" protection already exists. > This, just like with the GPL, would bind them to distribute their Derived > Work under the same License that they received it. > > Also, in no way the Hacking License put the covered work under public domain > (and if you read it this way, I would really appreciate if you can explain > your interpretation so that I can clarify the text). I did not say so. Even more, where I live any "public domain" license is actually void and as such may mean the same as full protection, that's why the Creative Commons came with a CC-0 license that says "if where you live is public domain legally acknowledged then that's what you have, if not then your rights are essentially "do as you please" with this work as long as you don't claim ownership". What I said is where "public domain" is not a valid status for a work is because some author rights cannot be waived. One of them, the transfer of authorship. > The non-exclusive copyright assignment doesn't waive any right, just shares > the transferable ones with upstream copyright holders "to the extent > permitted by law" and under the license conditions (if the upstream copyright > holders violate such conditions they lose such rights). And what makes your license different from the GPL in that point? If you make modifications subject to copyright law, you retain the full copyright while also having your changes subject to the GPL. From the modifier's point of view, the GPL protects you against downstream picking up your changes and privately licensing them (so both upstream *and* you can sue) while copyright law protects you against upstream doing the same (because *you* are the copyright holder of your modifications). This was just pinpointing a detail. However, on the broader issue I understand that Debian is not only obliged, by manifesto, to have only free software on main, but also to make sure that the resulting combined work is also distributable: just think about the infamous "OpenSSL exception". That fact that your license may be considered free software is a requirement, but by itself is not enough: OpenSSL is free software, a program which uses OpenSSL may be free software by itself, but the combined work may not without the exception clause.
Re: Hacking License
El 11/12/18 a les 9:53, Giacomo Tesio ha escrit: > [...] > 2. If ExtJs was a Derived Work of a software release under the Hacking > License, Sencha would have no right to keep any version proprietary. Being Sencha the copyright owner (noting for clarity as I cut that from the quote), I am quite skeptical this argument will hold at least under Spanish law and probably under all those jurisdictions where the "Public Domain" concept is not acknowledged because no author rights can be waived. This includes the right to decide how -and if- a work is to be distributed. However, for that to work requires Sencha being the sole author (and you pointed he refuses patches for this very reason), but nothing forbids other contributors to fork and then patch Sencha's work. Furthermore, these patches will be protected by the GPLv3 and even if publicly available Sencha will be unable to sell them, forcing him to either reimplement in his own way or not to use them at all if he wishes to distribute privately.
Re: Github TOS effecting change to copylefts?
El 08/03/17 a les 08:24, Mike Hommey ha escrit: > On Wed, Mar 08, 2017 at 07:46:29AM +0100, Ulrich Mueller wrote: >>> On Tue, 7 Mar 2017, Gunnar Wolf wrote: >>> The best analysis of this situation I have read so far is the one in >>> Noodles' blog: >>> https://www.earth.li/~noodles/blog/2017/03/github-tos-change.html >> IMHO that analysis misses one point. Namely, in section D.4 "License >> Grant to Us" the Github ToS have: >> >> "That means you're giving us the right to do things like reproduce >> your content [...]; modify it [...]" >> >> Which requires that any file uploaded to Github must come with the >> permission to modify it. Not a problem for free software, one would >> think. However, if your package is GPL licensed then you cannot >> include the COPYING file itself, because it would be in conflict with >> above terms. >> >> "Everyone is permitted to copy and distribute verbatim copies of this >> license document, but changing it is not allowed." > You're subtly omitting what the "modify it" applies to, though... the > text reads: "modify it (so our server can do things like parse it into a > search index)". As I see it, that annotation between parenthesis is not a restriction on the scope of modifications allowed by Github but just an example of what such modifications might be. There is a paragraph about limiting the scope of such modification rights which forbids them selling and distribution outside of Github's own service, but that says nothing about changes. > Now, let's go back in time a few weeks, before that ToS existed. What do > you think github was doing with all the files there are in github > repositories, to have the search function working? Has anything changed > about that in the past 2 weeks? No. > > Now, the question is: 2 weeks ago, was github legally allowed to do it? > Whoever wrote that ToS thinks that was a rather gray area that needed > clarification. If we're questioning Github's search engine on these grounds, we'd rather question all search engines in all scenarios, most of them dealing with non-free content. If that's the case, all of them are violating copyrights of thousands, if not millions, of individuals. Let me put a real life example: in Spain several years ago there was a legislative change requiring all websites citing or indexing content from media registered in a Spanish association (AEDE) to pay a tax. This was made similar to the infamous SGAE (RIAA's spanish brother) tax payable on any device capable of playing music and/or video, including all digital media like hard disks or smartphones (not joking). This law was commonly called the "Google tax" as it clearly targeted them but affected hundreds of other services, from other search engines to personal blogs citing news articles. What did Google do? They chose not to pay this tax and simply closed Google News in Spain. Remember, this was in response for a specifically legal change. However, if merely indexing would rather infringe copyright law, Google would be actually drowned in legal actions. Okay, Google might not be a good example of "good guys", but they surely have an army of lawyers who know what can and can't do, or how near the lie they can get without crossing it. And they obviously thought that Google News Spain crossed the newly-drawn line. Here we're also talking about a redrawn line, even if it was only moved a mere inch.
Re: Legal issues with haskell-unix-time
El 24/05/16 a les 12:36, Dmitry Bogatov ha escrit: > There is 'cbits/conv.c' in 'haskell-unix-time' source package, which > is probably is of same copyright, as haskell code (BSD-3-clause), > but there is part of it, that is explicitly marked as all-rights-reserved. > No email is provided. This troublesome part is only for portability on > Solaris, and is not used on GNU/Linux systems. > > What is the best way to deal with situation? I know, there is Files-Excludes: > clause in debian/copyright, but what to do with part of file? > > For your convenience, offending file is attached, but you probably > interested in whole package. > Just a side question: Are these funcions even copyrightable? The is_leap function is quite trivial, and the typical exercise for a programming student; the timegm is a conversion from a tm struct to an unix time which could even be reimplemented with no great effort.
