Re: Alternatives to Creative Commons
On Thu, Sep 18, 2008 at 9:38 AM, Jamie Jones [EMAIL PROTECTED]wrote: Multiple tar.gz files could probably fix that - or requiring users to checkout from the revision control system. GPLv3 section 5c (note bold text): c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, *regardless of how they are packaged*. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it. Clearly you cannot escape the terms of the GPL by splitting the work into different packages, otherwise everyone would do this. I know I'd laugh at anyone that said that to me about my data The GPL does not distinguish between code and content, both of which are data aka software. With the attitude you've presented, and given that your work is almost certainly building on the GPL licensed work owned by others, I can see legal trouble in your future.
Re: Alternatives to Creative Commons
IANAL and am not presenting a legal opinion. What I am speaking about here is based on numerous conversations I've had with lawyers in the IP (sic) field. On Thu, Sep 18, 2008 at 1:13 PM, Jamie Jones [EMAIL PROTECTED]wrote: How do you define an entire work? I've been told repeatedly that one game == one work. Others have said that it was unclear and I'd have to research legal precident (case law) on the issue. Nobody has said that it's a matter determined by the author or that they are more than one work. In the end it comes down to a judge's decision on a specific case, but overwhelmingly judges favor the author(s) who's work is being extended/modified in copyright infringement cases, and because this is known it almost never gets to court. The issue of code and content is no different than the issue of patches or libraries. Labeling one part code and another part content changes nothing, both are software and both are part of the same work - the game you're releasing. Consider even on a technical level how arbitrary the code vs content labeling is; code is rarely (if ever anymore) direct machine code, it's compiled or interpreted instructions which are processed by other software and instruct that other software what to do. Content, lets take a graphic for example, is processed by other software and instruct that other software what to do. Game engines, and more specifically game code, are not game browsers - at least I've not seen a modern one that is (ScummVM is not modern). The pieces of your content are usually labeled and have parameters specific to the game code you're running, ie FighterIcon1. Of course you can swap out FighterIcon1 for another FighterIcon1 with the same requirements met and have it run, but you could also replace one of the program's FighterDamage function with a replacement that has the same arguments and return types in order to change that software's behavior. As the copyright holder, it would be my prerogative to license either how I see fit, and I see nothing in that license that states I must license my other works under it, just because I choose to distribute them together. You are correct, if you were the sole copyright holder there would be no issue. The GPL does not restrict a sole copyright holder in any way because the copyright holder needs no special permission (a license) to do anything with their own work. However, this is almost never the case. GPL licensed work often extends work held by several, sometimes even hundreds, of different copyright holders. Any or all of them can challenge your right to use their work on the basis of license violation and thus copyright infringement. Work is not licensed under the GPL in the spirit of allowing 3rd parties to make derived work effectively proprietary. I can tell you that if someone tried to pull something like this with our engine they would receive a notice of AGPL violation with a 30 day window to rectify the problem.
Re: Alternatives to Creative Commons
On Thu, Sep 18, 2008 at 6:05 PM, Ken Arromdee [EMAIL PROTECTED] wrote: In order to release it under the GPL (at least if you want people to be able to distribute it), you have to release the uncompressed audio or video Says who? You have to distribute the it in a form that's ready for editing. Even DV (digital video) is compressed, people use it all the time even professionally for editing and it's extremely lossy (miniDV is 4:1:1, beside the intraframe compression applied). Most digital tape mediums don't even support lossless video. Neither the GPLv2 or GPLv3 say anything about lossless. If you're editing the audio/video in some weird format that you don't have a free tool for, this may be a problem. If the content is generated, then yes you do, and yes it's a problem for people using proprietary toolchains to generate free content. This in my mind is an argument against using proprietary toolchains. You do not, however, need to release tools already available under a GPL compatible license unless modifications are needed to generate the object code (your generated content).
Re: Alternatives to Creative Commons
On Thu, Sep 18, 2008 at 9:56 PM, Ben Finney [EMAIL PROTECTED][EMAIL PROTECTED] wrote: Arc Riley [EMAIL PROTECTED] writes: IANAL and am not presenting a legal opinion. What I am speaking about here is based on numerous conversations I've had with lawyers in the IP (sic) field. Such a field doesn't really exist. I think the only relevant field for this discussion is copyright law. and that would be why I put quotes around IP and followed it with (sic). I agree entirely that all bitstreams are software, and it makes little sense from a copyright perspective to try labelling them with different copyright status based on how they happen to be interpreted at a given point in time [0]. Especially when they inter-link. What you're describing is more like writing a game program using the programming language of the game engine. None of the copyright work actually makes its way, even in derived form, into your work. That is like saying that writing a set of replacement functions with the same names, arguments, and return types does not constitute a derived work when it's purpose is to replace specific source files in a GPL licensed work. Under copyright law, at least in the US, you can write software that provides the same function as a copyrighted piece of software and it's not a derived work. You can even provide the same external API, reference Wine given that Wine is a complete implementation. You cannot however release patches and claim they are not a derived work because they don't contain any of the original work in them. This comes back to what I was saying before, it apparently doesn't matter how the pieces fit together, it matters what the whole is. It's a matter of common sense human judgement. Obviously you're creating a derived work by putting together a set of content software, regardless of whether that content includes instruction code or media, which is crafted in such a way to replace or supplement an existing piece of work. Consider this from the other side of the fence. You put together a supplemental content set that expands Blizzard's World of Warcraft (I don't know if this is technically feasable but lets assume it is), they take you to court for violating their copyright in creating a derived work, and the judge looks at the situation in it's whole. Your content is meaningless pieces without the game code behind it, it is not intended to be presented on it's own and needs Blizzard's copyrighted work to run, extending or expanding it's functionality. This is the context that it was explained to me, though I may not be explaining it correctly.
Re: Alternatives to Creative Commons
On Thu, Sep 18, 2008 at 9:04 PM, Jamie Jones [EMAIL PROTECTED]wrote: That is your belief. I could release content (textures and level geometry) that I have been creating for my game right now, and it could be used by at least 6 other game engines, and a variety of utility programs. They could be refactored to work with other games, yes, just as code can be (and is) refactored for other works. In general, for game content to be meaningful, it must be designed/packaged to certain specifications which make it clearly intended to expand or extend the existing GPL-licensed work. Your engine is special. I've looked at it, and your engine isn't AGPLv3, it's AGPLv3 + additional clauses. Quoting from your license -- start quote -- Did you check the source code to see if any additional clauses were added to the AGPLv3 before making this claim? Apparently not, and neither did Francesco Poli a little over a year ago when he made similar accusations based on text on the same URL: http://www.mail-archive.com/debian-legal@lists.debian.org/msg37427.html Again, a reaction to content on a wiki page without bothering to read that no extra clauses were ever applied and have never appeared in the svn trunk nor any release. As I recall, the License page wasn't even linked to from anywhere on the site at that point and represented internal discussion only until it was posted to this list and I had to mark the page as readonly to stop the barrage of wiki edit flames coming from readers of this list. To put that discussion in context, we had already resolved with a lawyer that no extra clauses were required to achive the desired effect and would thus be redundant, but nobody here bothered to ping us about this even to verify that the content of a wiki page was actually edited by one of us. Yes, I am upset this is the second time someone has made unfounded and unresearched claims on this list regarding extra clauses being applied to our software, and a good example why I'd prefer if Debian not have anything to do with our project.
Re: Alternatives to Creative Commons
There is absolutely no issue licensing game data under the (L/A)GPL. In fact, this is required for at least the GPLv3 in that the license applies to the whole of the work, and all it's parts, regardless of how they are packaged. Thus if the game code or any dependencies (ie, the engine) are licensed under the GPL, the data must be licensed under a GPL compatible license (which the CC licenses are not). After numerous conversations with copyright lawyers on the specific subject of games, the entire game is one copyrighted work.
Re: Alternatives to Creative Commons
On Wed, Sep 17, 2008 at 3:21 PM, Miriam Ruiz [EMAIL PROTECTED] wrote: This might be really relevant for us, the Games Team, as there seem to be quite a lot of games that have a different license for the engine and the game data, and the combination of GPL and CC-by-sa seems to be getting more and more popular. And that is fine, so long as the game data is /also/ available under the GPL. Note that it is not just games that have this problem, nor is this a problem specific to content vs code. Many projects have incompatible licenses applied to different components or dependencies. Copyright holders often just need to be made aware of this legally makes the work undistributable as it cannot be distributed while in compliance with both licenses. On the other hand, for some games (and theoretically for most of them), the same game engine can be used with different data, and some times vice-versa. If this is the case, the situation might be similar to a media player and media data, or to a word processor and the document. The case where the same game content can be used in a different engine+code verbatim is exceedingly rare. As I understand the situation, what makes the game one copyrighted work is that the content is not generic, application-agnostic software as an image in the GIMP or a text document in a word processor. While the technical process that these are loaded may be very similar, this is an issue of legal judgement, not technical process. That the code and content is both software and is utilized as a single work is what makes them one work. One could likely argue that if the game content were in a standard format and displayed/interacted with much like a web browser displays HTML/CSS/Javascript that the content would be considered a separate copyrightable work. An example of this may be ScrummVM. I'm not aware of any modern system like this, however. Note that the conflict that's arisen with incompatible licensing is due to poor education on the GPL. Many people are under the false impression that the GPL only applies to executable code or that there is some problem with licensing content under the GPL. In truth, those looking for their work to be under the strong copyleft effect of the GPL are best not separating their work's copyright artificially as it may open a loophole for 3rd parties to release proprietary replacement game content.
Re: Alternatives to Creative Commons
On Wed, Sep 17, 2008 at 7:56 PM, Karl Goetz [EMAIL PROTECTED] wrote: I'm pretty sure at Linux.conf.au this year in the games miniconf, someone from CC Australia was recomending the use of CC (-SA i think) for game data, and said it didnt conflict with the GPL. I too have heard people from CC claim that CC licensed work was GPL-compatible. This disagrees with the FSF's position: http://www.fsf.org/licensing/licenses/ IANAL, but I believe in the FSF's legal accuracy in this given that I've heard (possibly innocent) lies about the GPL spoken by CC people, such as the perpetuation of the linking clause myth and in great detail how the GPL doesn't cover non-instruction software such as icons and fonts. Again, it's always possible to dual license the content. The (A)GPLv3 is stronger copyleft than the CC-BY-3.0 and CC-BY-SA-3.0 licenses, and more specifically addresses software matters (refering to any information stored on a computer, not just instruction code), so if a work is already being made available either under the CC-BY-3.0 or CC-BY-SA-3.0 there are no additional permissions granted by also offering it under the (A)GPLv3 while clearing up any questions about the legal distributability of their software.
Re: Is AGPLv3 DFSG-free?
On Mon, Sep 15, 2008 at 2:49 PM, Davi Leal [EMAIL PROTECTED] wrote: Is it so hard for you understand, that not being able to distribute only the binary of a modified Linux kernel (without distributing its source code) is a rectriction? I think at this point we're all clear on the terms of the license. If there are remaining questions, they should be asked. We've come to a point where our varying beliefs across a spectrum from anti-copyleft to strong copyleft are being voiced. This is what I have written earlier in this thread in degrading into personal opinions rather than arguing DFSG-freeness. The issue of whether the AGPLv3 should be used is moot here. It is being used, it's popularity is growing, and Debian users are choosing to use AGPLv3 software regardless of whether it's packaged or how it's labeled. The only issue at hand is whether the Debian project is going to behave in a combative manner against these projects in labeling them as non-free or accept them as part of the body of free software.
Re: Is AGPLv3 DFSG-free?
On Thu, Sep 11, 2008 at 12:19 AM, Jordi Gutiérrez Hermoso [EMAIL PROTECTED] wrote: there are other ways you can satisfy clause 13, namely, the usual channels of distribution that the GPL provides, plus a trivial network server to indicate those other ways. The license does not require you to provide your own network server to indicate anything. All you need is to include is a pointer to *a* network server hosting the code. That is, if you're hosting a modified version of a game server, you're required to prominently offer players the URL of a location on a network server which hosts a diff of your minor changes, a tarball of files you've replaced, a VCS branch with your changes applied on top of the version you forked from, or a full copy of the version you're running. This can be Savannah, shifting the hosting cost to the FSF/GNU if you feel it's too much. They'll gladly host your modified code for free, as will a number of different groups. In the case of PySoy, we'll gladly host PySoy-based games, branch of our engine, or branch of any dependency. I see this as a convience to us and our users.
Re: Is AGPLv3 DFSG-free?
On Thu, Sep 11, 2008 at 4:08 AM, MJ Ray [EMAIL PROTECTED] wrote: Jordi Gutiérrez Hermoso [EMAIL PROTECTED] wrote: One's modification and distribution over a network of that software, let's be explicit. And I argue that this extra cost is no greater than the cost of providing the network interface that's triggering this clause in the first place. I don't know about others, but I am charged for data transfer. It has already been made clear that you're not required to distribute the modified source on the same network connection as the remote interaction. That those debating against the AGPLv3 on this thread have such a weak case that they must argue that the cost to upload the source is burdomsome, given the existing cost associated with hosting that software for remote interaction and the cost of hardware to host it on, demonstrates to me that this debate is over. Yes, it's absurd to ensure cooperation! The first point of the first principle of cooperation is voluntary. http://www.ica.coop/coop/principles.html Nobody is being forced to use the software, just as nobody is forced to become a member of a cooperative. Participation remains is voluntary. How would that satisfy section 13? A CD isn't a network server. It doesn't, (s)he was mistaken. Section 13 clearly reads that it must be hosted on a network server. Don't forget hosting-users. Tomorrow you might be paying for uploads. Gladly, and I believe I already made a statement to the effect that we will be paying for uploads for others modified versions. The hosting cost is negligible. What we care about is having the source code available and that all users are made aware of it's availability.
Re: Is AGPLv3 DFSG-free?
On Thu, Sep 11, 2008 at 9:34 AM, Karl Goetz [EMAIL PROTECTED] wrote: Suppose the following scenario: Someone gives you a CD with debian, and you install the weblog tool, which happens to be agpl. Your internet connection is two way satalite, 500mb/month, data both directions costs, and it could be up to 25cents/mb over your quota. Now imagine because the package you got from debian wasnt finished (perhaps a typo leaves a path broken), you have to make a change to the packages source. This is a potential case, yes. You just changed it. You now have to make it available (with its dependancies? i'm not sure). No. It is neither standard nor customary to re-release an entire package for a small bugfix. You could just upload a patch to the project's mailing list and refer to the URL of that patch in the list's archive. The cost to upload that patch is small compared to the cost of web browsing. What worries me is that the people in this situation *dont realise* what they got themselves into (its on my debian cd, so i can use it for personal use however ... right?). It's not personal use when you have remote users, it's public use. Private use is software on my own computer that nobody ever interacts with or uses. I'm not worried about people who 'opt in' to agpl software, i'm worried about people who *dont realise* what agpl means to them, and wind up in a tricky legal corner. What's tricky about it? Upload your changes somewhere. That's all. You miss the license, someone emails you about it, you upload. No big deal. The only way anyone is going to see a courtroom over this is if they intentionally fail to comply with the license terms.
Re: Is AGPLv3 DFSG-free?
I agree, which is why we chose the AGPLv3 for our project. I've gotten the impression, though, that many people on this list are arguing against the AGPL on the basis that they want to retain people's freedom to exploit the ASP loophole. On Sun, Sep 7, 2008 at 1:57 PM, Joachim Breitner [EMAIL PROTECTED] wrote: ... then, in the spirit of Free Software, I'll be thankful that due to the AGPL I, as a user, can get the source from it. Therefore, not by word-by-word interpretation, but by respecting the spirit of the DFSG in the light of new developments, I consider AGPL licensed works as acceptable for Debian. (This is, in a sense, a political statement.)
Re: Is AGPLv3 DFSG-free?
On Wed, Sep 3, 2008 at 2:23 AM, Don Armstrong [EMAIL PROTECTED] wrote: We only distribute source at the instant we distribute the binary. We (generally[1]) don't distribute the source after we've stopped distributing the binary. The AGPL requires distribution of source at any time that the application is used. The GPL does not. The AGPLv3 only requires the distribution of /modified/ source. If Debian distributes their packaged version, and that version is served by a 3rd party for other users unmodified, that 3rd party is not bound by the distribution terms of section 13. Note the phrase if you modify the Program. If Debian no longer distributes the binaries and source for that version, the requirements of that 3rd party are unchanged. Debian is hardly an agent making modifications on the behalf of the 3rd party. If the 3rd party modifies the source, they're required to host their modified version regardless. In this way, unless Debian is hosting modified applications for remote users to interact with, the AGPLv3 is identical to the GPLv3 in the manner and requirements for Debian. Further, I do not read in the license that distribution of source *must* happen when the application is used. You have to make it available on a remote server, that is all. That server goes down, yes it's a problem you need to solve, but it's not like the lawyers come out. Someone tries to download it, finds the link broken, sends you an email, you fix it, no big deal. If some copyright holder was insane enough to start with involving lawyers the situation could surely be solved long before the issue ended up in court.
Re: Is AGPLv3 DFSG-free?
On Tue, Sep 2, 2008 at 4:46 AM, Gervase Markham [EMAIL PROTECTED] wrote: If it were just running on your server, there would be no distribution requirement. But it is running on your server and sending and receiving data from the user, which is different. This is the core of the issue. If you are a local user of the software, the AGPLv3 is identical to the GPLv3. It's only when you're running the software on your machine for other people to use (whether that be an IRC bot, a webapp, or a game server) does the AGPLv3 specific clauses take effect. In these cases, all it's doing is ensuring that the users of the software are granted the four software freedoms. We do not view this as a use restriction, as the user of the software has no restrictions added to her remote usage nor local usage should they download it, but rather ensuring that she has the same abilities and rights we have with locally-run free software. If it's a small embedded system, the source code is likely also to be small. An excellent point. And if you can't afford the costs of the bandwidth for the small embedded system, you can't run the service at all! Free as in freedom does not necessarily mean free as in cost to you. .. and even if hosting the source code over your own Internet connection, it should also be noted that in almost any case remote users downloading the modified source should represent an extremely small part of your bandwidth.
Re: Is AGPLv3 DFSG-free?
On Tue, Sep 2, 2008 at 6:29 AM, Bernhard R. Link [EMAIL PROTECTED] wrote: * Arc Riley [EMAIL PROTECTED] [080902 11:23]: In these cases, all it's doing is ensuring that the users of the software are granted the four software freedoms. It's not the users of the software, it's the users of services run by the software. This is a trivial distinction. Take for example a typical use example of our engine; the actual game code (in Python) runs on a server, likely at an affordable high-bandwidth co-hosting facility such as ServerBeach. The users, people playing that game, using a Firefox plugin and a version of our engine that runs just the rendering and physics threads. That game is identical for them as if they had downloaded the Python source and were running it locally without the hassle of having to install anything first. In most cases this is for previewing new games on the web. They are remote users interacting with the software. Under the GPL 2 or 3 their software freedoms may not be afforded because, while their use and interaction with that software is nearly identical to running it locally, they need not be sent the game code itself. We foresaw many groups using our engine under the GPLv3 to host proprietary games in this manner. Under the AGPLv3, however, users must be given the opportunity to download the game and thus run it on their own hardware, modify it, etc. Under the AGPLv3 we're developing these new features knowing that our user's freedoms will be protected regardless of what physical machine they use the software from. Of course it has other positive effects as well, such as mitigating secret server code business models (ie, shifting a good deal of the game logic to undistributed server software). We want to promote ethical business models for copyleft games, we view part of that is deterring unethical practices with our software.
Re: Is AGPLv3 DFSG-free?
On Mon, Sep 1, 2008 at 6:03 AM, Miriam Ruiz [EMAIL PROTECTED] wrote: Some of the problems might be important anyway. I'll sum up my personal concerns. Say I want to create a 3D virtual world based on the IRC network, using PySoy as the base framework for that, PySoy being AGPLv3 will force me to: 1) Either not being able to modify the source code or 2) Spam everyone I interact with, saying the client I'm using and how to get the full source code. The license does not say you must advertise, only that you must prominently offer. In your example of an IRC network, providing a source URL with CTCP VERSION requests more than sufficiently fufills this requirement. 3) Be able to notify servers in the network on how to be able to get that source code too. It's common on IRC for servers to grab CTCP VERSION requests as well. Most network protocols have a mechanism similar to this, including XMPP. Since, to activate the AGPLv3 section 13, the remote user must already be interacting with your software, a query/response pair is more than reasonable. 4c) Through a public server, having to identify myself (thus, I wouldn't be able to remain anonymous) Current free VCS solutions do not require you to identify yourself with your legal identity, many people publish code under an alias/monkier, and the license requires nothing to the contrary. Of course I've said this already. 5) Have legal problems in countries in which my program might not be legal, by providing having to provide it to people there, as I might be interacting with people in that country. Example: My 3D irc has support for encrypted connections, I might be chatting with people from other countries in which encryption might be forbidden. License is forcing me to commit a crime in that country. This is no different from with the GPL. You just can't work on the cryptographic parts of the code, and are thus not in a requirement to distribute those parts. Note that the Corresponding Source is every dependency your software uses, the GPL doesn't require you to distribute every dependency, only the parts you've modified. The AGPLv3 is no different. Replying to you seems to be moot, however, since it doesn't appear that you're reading replies, only continuing to repeat your beliefs untainted by dialog/debate. We've been over all of this in this thread.
Re: Is AGPLv3 DFSG-free?
On Mon, Sep 1, 2008 at 10:03 AM, Miriam Ruiz [EMAIL PROTECTED] wrote: Of course, but they'll have your IP, which is (at least in my country) personal information. In any case it is enough for someone to be able to find you, so you won't be really anonymous. Think about China, for example. Tor. GNUnet. This is a problem answerable by technical means. Maybe I haven't explained myself properly. In my country, cryptographic code is legal. Lets say for example that in France it isn't. I can choose not to distribute my code in France, but I cannot make my program not interact with French people until I have already interacted with them. I see quite an important difference here. As an American, I cannot export cryptographic software. As a result, I don't work on it. That doesn't prevent me from building or modifying software that utilizes those components, as those components are imported. Of course you can choose not to interact with them based on IP address. This is done all the time.
Re: Is AGPLv3 DFSG-free?
On Sat, Aug 30, 2008 at 11:49 AM, Miriam Ruiz [EMAIL PROTECTED] wrote: 2008/8/30 [EMAIL PROTECTED]: Just host the source code at Savannah or any other similar service. How does that scale when a lot of users modify or customize the code? These are technical challenges, not legal problems, and will be solved by the community as the need arises. I'd say in the next year or two free VCS services will allow people to register new branches to existing projects. Many people have presented problem situations based around current technical shortfalls, but also problems that don't exist now such as extremely large projects (gigs of modified source, really?) or popular free VCS services that go down often and long enough to become a license compliance issue. It is not important that these problems be solved now, only that they are solvable and will be solved because that's how we - the free software community - handle problems. Especially when said technical challenges regard the distribution and management of source code. And, how can one do that and at the same time keep being anonymous (dissident test)? As I've already answered that question at least twice, you are not required to use your name or other truthful information when signing up for VCS services. A person needing to remain anonymous due to government problems can easily do so. I've certainly posted code under enough aliases to show this is not only possible, but is ready done today.
Re: Is AGPLv3 DFSG-free?
This thread has slipped into absurdity. These fringe cases with the viewpoint that free software copyright holders are just biting at the bit to take people to court retroactively for short-term lack of compliance at no fault of the software modifier. The GPL could be abused by a copyright holder as well, it's just not done. In every GPL violations case I know of, compliance was sought, and compliance was obtained, it's rare for such cases to even be seen by a judge. If such a situation arose where a copyright holder did start engaging in vengence litigation, debian-legal could certainly discuss whether to continue including the contentious software in free regardless of the license.
Re: Is AGPLv3 DFSG-free?
On Fri, Aug 29, 2008 at 5:00 PM, Francesco Poli [EMAIL PROTECTED]wrote: The problem is: what happens if the VCS goes off-line for one afternoon (or for one night, for a couple of days, for a week, ..., forever)? Am I failing to comply with the AfferoGPLv3, unless I immediately shut the network application down (until the VCS is back on-line) or I immediately provide an alternative means to get the Corresponding Source? No such clause exists in the license. If you feel otherwise, please paste where the license reads anything similar to that. If you're hosting a GPL licensed binary on one server, and the source on another, you're not required to take the binary down when the source goes down so long as you get the source server up (or replace it) in a reasonable amount of time. If your free VCS service goes down for an extended period of time, just re-upload to another, and you've continually complied with your requirement to provide the modified coorespondance source. If you're really worried about this, upload it to two different free VCS services.
Re: Is AGPLv3 DFSG-free?
On Fri, Aug 29, 2008 at 5:56 PM, Francesco Poli [EMAIL PROTECTED]wrote: It says that I must offer an opportunity to receive the Corresponding Source of [my] version by providing access to the Corresponding Source from a network server at no charge. There's no indication that I can delay this opportunity at will, as in yes, to get source click here, but maybe you have to come back tomorrow. If you setup a system which required a delay, that would be questionable. For example, there are commercial download services which permit free downloads after a delay (say, 5 minutes) to encourage paid membership for instant downloads. Whether this is ok with the (A)GPL can be debated. However, if the source is temporarily unavailable not by your intention or fault, then so long as you make a reasonable attempt to make it available (ie, somebody emails you to let you know the source server has been down, it doesn't come right back up, and you upload it to another server) you're still in compliance. The word continuously at no point appears. 99.999% uptime is not demanded by the license. It is expected that things fail on the Internet. It seems I am obligated to ensure the Corresponding Source is available as long as I offer access to Object Code... As long as represents duration of offer, not continuous/simultaneous. As long as you're still offering the binaries, you must still offer the source code. This does not mean if the server hosting the source code goes down, you must also take down the server hosting the object code, so long as you get the source code server back up in a reasonable amount of time. Shit happens, it's expected, and the (A)GPL has no teeth to bite anyone in the ass just because a server fails. Heck, if you mistakenly fail to comply with the GPL's source offering requirement, and someone informs you of it, you have 30 days to correct the problem while you're still able to distribute the object code in full compliance with the GPLv3.
Re: Is AGPLv3 DFSG-free?
On Fri, Aug 29, 2008 at 7:21 PM, David Martínez Martí [EMAIL PROTECTED] wrote: Then, if I download it, and I made some modifications at the source code, the AGPL (under certain conditions) will bind me to publish the source code. Note that the (under certain conditions) is offering remote use of the software you've modified, and you must only offer it to those who are using your software. I see two major errors on the AGPL. One, that binds the occasional developer to make their modified work public. Only when and to those using your software remotely. Likewise, with the GPL, an occasional developer must also make her/his modified source available to those they send their object code to. And two, that forbids the possibility of selling it, because you are forced to share it for free. You can sell access to the software, and give the source to those who've already paid for this service. The only time the AGPLv3 section 13 requires you to make your modifications public is when your modified version is public. For example, say that I have a company, and we downloaded the meneame.net source code and we've improved it. Then I'll sell to Joe for 200 Euro. Joe now has a CD-ROM with the modified source and wants to try it at home with his IRC friends. But Joe doesn't have a Internet connection, It only has a GPRS modem. His internet provider will bill for each Megabyte. Should Joe upload that source code? and, what If Joe doesn't want to make that code public? This is akin to saying, Joe only has a GPRS modem, and gives someone a modified binary, the source code is a lot bigger, thus it's a financial burden to Joe to comply with the GPL. If license compliance is a financial problem for Joe, he better consider that before he buys modified source from someone who isn't willing to include hosting the source code online as part o the sale.
Re: Is AGPLv3 DFSG-free?
On Thu, Aug 28, 2008 at 4:16 AM, Josselin Mouette [EMAIL PROTECTED] wrote: The problem with the AGPLv3 is that you can argue the distribution requirement is onerous. It may be a bit more onerous for a dissident Since anyone can get a free, anonymous account at any number of free VCS solutions, and since a dissident only need share source with those they're already permitting remote access over a network to, I do not see any situation where this would cause a problem. but frankly we are talking about ridiculous costs here Really? Let's look at some options; BerliOS - free. Gna! - free. Launchpad - free. Savannah - free. Sourceforge - free (with advertising) All of these services are extremely stable, I believe all have been in operation for more than 3 years, and these are only the most popular. This is 2008, not 1998, nobody needs to pay to host free software anymore. http://developer.berlios.de/ As often stated on this list, you cannot always state the DFSG-freeness of a license, you need to apply the rules to a *work*. If the sources are several gigabytes large, then the price of distributing them becomes unacceptable and the work may not be DFSG-free. I'll point out, again, the phrase standard or customary means of facilitating copying of software in section 13; it is neither standard nor customary for a modified version of code which is several gigs in size to be distributed in full. We upload a patch or create a VCS branch for our modifications and the license is fufilled.
Re: Is AGPLv3 DFSG-free?
On Thu, Aug 28, 2008 at 5:46 AM, MJ Ray [EMAIL PROTECTED] wrote: So the PySol project wants to use the AGPLv3 and the forced distribution of source code is a desirable effect, but it's distributed on the non-free most-source-unavailable Launchpad webapp? PySoy. We are distributed via SVN and Trac on our own server. We're going to be using Launchpad for the PPA (personal package archive) for Ubuntu packaging, and it does not appear that this need be exclusively for Ubuntu. While it'd be nice to have Launchpad already released under the AGPLv3 (they're apparently working toward this) we're not going to refrain from working with the Ubuntu project over it. Our use of the AGPLv3 is to prevent people from circumventing the copyleft licensing by hosting games using our engine only over the web, and to remove the fear of this as a barrier to adding the features which permit server-hosted games (where the game code runs only on the server). It's not based on some ideological viewpoint that proprietary webapps are unethical and should be boycotted.
Re: Is AGPLv3 DFSG-free?
To be honest, I just don't want our project to be in the middle of this given the situation; - we're in 1.0-beta* phase right now receiving community input on the API as we build toward 1.0 - our last beta release was January 1st 2008, licensed under the GPLv3, so it can't be used to test the AGPLv3 here - 1.0-beta2 is completely obsolete now with many API changes/additions, making support difficult, and feedback from beta2 is no longer constructive - svn trunk (licensed under AGPLv3) is currently unstable due to known threading issues on multicore systems, and thus should not be packaged - 1.0-beta3 is /at least/ 6 weeks off I've been told that other AGPLv3 licensed projects in a greater state of stability are in the pipeline toward ftpmasters, which will set precidence. If they approve them, we'll get back in that pipeline ourselves. I believe we'll be able to offer Debian packages via our Launchpad PPA (where the Ubuntu packages will be distributed from at least until intrepid+1), so it's not like Debian users are going to be excluded. Most Debian users I've known have non-free disabled by default in any case, and maintaining our packages via PPA is less work not to mention sans being put in the proprietary software repository. On Wed, Aug 27, 2008 at 4:55 PM, Ian Jackson [EMAIL PROTECTED]wrote: Miriam Ruiz writes (Re: Is AGPLv3 DFSG-free?): 2008/8/25 Arc Riley [EMAIL PROTECTED]: I respectfully request that PySoy not be packaged in Debian if the AGPLv3 is confirmed as non-free in the eyes of your project, as this would be considered by our project as false advertising in grouping us along side blatently proprietary apps. I closed my ITP ( http://bugs.debian.org/495172 ). That doesn't mean that someone else might in the future not want to maintain a package for it in Debian anyway. I think this is a shame.
Re: Is AGPLv3 DFSG-free?
It would seem as consensus has been reached. Once confirmed, someone should update http://en.wikipedia.org/wiki/Affero_General_Public_License I respectfully request that PySoy not be packaged in Debian if the AGPLv3 is confirmed as non-free in the eyes of your project, as this would be considered by our project as false advertising in grouping us along side blatently proprietary apps.
Re: Is AGPLv3 DFSG-free?
On Sun, Aug 24, 2008 at 6:28 AM, Bernhard R. Link [EMAIL PROTECTED] wrote: No, there is an very important difference. The GPL ensures that everyone is allowed all the things they would be if there was no license at all. That is not true. There are countless public domain works which the source code is not available, thus the GPL ensures *more* than if there was no license at all. From reading your email, it sounds like you would also believe that requiring the distribution of source code when object code is distributed is limiting how the software is distributed, which would fail DFSG #1. Others would argue that the GPL ensures that DFSG #2 will continue to be met by future package contributors and forks. What AGPL does, is trying to limit how a program is allowed to run. That is an very important difference. The AGPLv3 does not limit how a program is allowed to run, it only requires that modified source code is made available to those you're allowing to use that software over a network. DFSG #2, in making source code available, seems to cover this, and there does not seem to be a DFSG against requiring it's distribution to remote users vs only those the software is distributed to. If you feel otherwise then please point out the DFSG line item which discriminates against this license. All you've included in your emails is your own personal opinions over the freeness of the AGPLv3. With all due respect, this thread is regarding whether the AGPLv3 complies with the DFSG, not a straw poll on people's personal feelings about it. Given that we're talking about an official FSF license, written and supported by SFLC lawyers, explicitally GPLv3 compatible, drafted and approved through a lengthy public process that included input from the Debian project, and adopted by many free software projects, I think the AGPLv3 warrants a bit more involved debate than continually repeating personal opinions.
Re: Is AGPLv3 DFSG-free?
On Sun, Aug 24, 2008 at 7:38 PM, Ben Finney [EMAIL PROTECTED][EMAIL PROTECTED] wrote: This is an appeal to authority: who drafted the license terms, and who has okayed them, doesn't have any impact on the facts about the effects of the license terms on a work. We're trying to determine the effect of the license terms when applied to a work, regardless of who wrote the license. It was not intended an appeal to authority, rather pointing out the severity of this discussion. This group's earlier declairation that the GNU FDL is non-free caused a rift in the community. Further declaring the AGPLv3 DSFG non-free would widen that rift and, as this is a software license, will alienate an even larger segment of the free software community from the Debian project. This divide is troubling and the only reason why I resubscribed.
Re: Is AGPLv3 DFSG-free?
On Sat, Aug 23, 2008 at 6:43 AM, Bernhard R. Link [EMAIL PROTECTED] wrote: This is not the case. You are not required by the AGPLv3 section 13 to ensure the code is made available to anyone unless you have modified the code *and* you're allowing remote users to use that modified version over a network. Your own private use of the software, modified or not, does not activate AGPLv3 section 13. So you say that the and/or in above statement is only an and. I don't see how that reduces the non-freeness. What was proposed was that every single user of the software would be required to host, on their own server and at their own expense, or even over the same net access through which remote access to the software is provided, a copy of the source code for every piece of AGPLv3 licensed software they wanted to use. What I am continually having to re-iterate in this thread is that this only applies to those who are running modified copies of code which is not already available online, that a free VCS solution is suitable, and it you're only required to share the source code with people you've already opted to allow remote access to your modified version. If you believe this is non-free, then please present a definitive situation or set of conditions in which you believe the AGPLv3 license violates DFSG. Please stop this new wave FUD. How many people had their own computer when the GPL was made? How many people back then only used software on other people systems without owning a copy of it? Where is there anything new here except the attempt to limit people's right to run their software for any purpose they see fit? The ability to use software for any purpose is not restricted by the AGPLv3, any use restriction would fail software freedom #0. The only additional requirement beyond the GPLv3 is that you allow remote users of your software the ability to obtain a copy of the source code. If you disagree, please expand on your statement. In regard to FUD, I am not here to convince any other project that they should use this license. We are using the AGPLv3, I have only stated some of our reasons for making that choice. Debian represents such a small, shrinking percentage of our target audience that DFSG'ness is not going to influence that decision. I honestly see no purpose in packaging PySoy for Debian given that we'll be maintaining a separate package for Ubuntu regardless of the outcome of this discussion. PySoy (and many web apps, etc) represents such a small, unimportant niche to the Debian project that our choice of license is not going to influence the DFSG. In evidence to this, it's been almost a year since the AGPLv3 was released with many projects upgrading to it, yet apparently to date none have been packaged for Debian. The only matters at hand is correcting misunderstandings of the license and debating whether the license qualifies as DFSG, something that has not been resolved yet. If your project is going to judge a FSF license as DFSG-nonfree it should not be based on misunderstanding. You should almost certainly have a lawyer in this discussion and have someone more knowledgable than myself (IANAL) on the AGPLv3 engaged in this debate.
Re: Is AGPLv3 DFSG-free?
On Sat, Aug 23, 2008 at 2:04 PM, Miriam Ruiz [EMAIL PROTECTED] wrote: A new question has come to my mind: What would happen if you run an AGPLv3 program that was modified by someone else. I asked an identical question a few months ago. I'll try to explain it as it was explained to me; Cast: Bob is the maintainer of the original software package licensed under the AGPLv3 Alice made a private modification in which no remote usage was given Joe is a user of Alice's version, used to serve a app on his public site Since Alice did not provide interactive access to a remote user, AGPLv3 section 13 never came into effect. Since Joe did not modify the software as he received it from Alice, under normal circumstances AGPLv3 would not seem to apply to him either. If Alice distributed her modifications exclusively to Joe, such as a contracted work, she also need not comply with the GPLv3 terms under section 2: You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force. You may convey covered works to others for the sole purpose of having them make modifications exclusively for you, or provide you with facilities for running those works, provided that you comply with the terms of this License in conveying all material for which you do not control copyright. Those thus making or running the covered works for you must do so exclusively on your behalf, under your direction and control, on terms that prohibit them from making any copies of your copyrighted material outside their relationship with you. Note, however, that in doing Joe is the one making the modifications via their exclusive arrangement, and thus AGPLv3 section 13 applies to him. Bob can ensure this as copyright holder. If Alice and Joe had no exclusive arrangement, Alice would have distributed her modified copy to other people, in which case her work (in most cases) would already be available. In either case, Bob's goal of ensuring the availability of modified versions of his software should be met. It's of course impossible to cover every potential scenario. The FSF has said that they expect more frequent license releases as the need arises.
Re: Is AGPLv3 DFSG-free?
On Wed, Aug 20, 2008 at 4:25 PM, David Martínez Martí [EMAIL PROTECTED] wrote: The problem with this license is, that anyone that tries to use and/or modify it must distribute it to third parties. I don't think that can be free. This is not the case. You are not required by the AGPLv3 section 13 to ensure the code is made available to anyone unless you have modified the code *and* you're allowing remote users to use that modified version over a network. Your own private use of the software, modified or not, does not activate AGPLv3 section 13. The purpose of the AGPLv3 is the GPL (v2 or v3) is not sufficient to guarentee the freedoms we value in software given the new wave of network-based software where the user would never receive a copy in most cases. But, ok, suposse that's not a problem. The next problem is that this license was written with a scenario in mind (Internet + VCS + money for hosting) . It doesn't was desinged to cover all posible cases. Only one is covered. There's a more than sufficient number of free VCS services available that money is not required for code hosting. The web-based GUIs of those services are simple enough that anyone who's clueful enough to modify the software is going to be competent enough to create a free Gna!, Savannah, or even a Google account. In many cases pushing it as a branch on the software project's own VCS, as any project using the AGPLv3 likely wants to make merging changes as simple as possible. On Thu, Aug 21, 2008 at 3:21 AM, Christofer C. Bell [EMAIL PROTECTED] wrote: On Tue, Aug 19, 2008 at 7:28 AM, Miriam Ruiz [EMAIL PROTECTED] wrote: 3) The user cannot remain anonymous. In the case of point #3 that you're making here, are you saying that the AGPLv3 fails the dissident test? I've already replied to Miriam's concern about anonymous posting of code. To reiterate: - you are only required to distribute modified code to those you're permitting remote access to use your version, - you are not required to permit anyone remote access, thus able to keep your usage of the software hidden, and - you have no further requirement to identify yourself as aa contributor/editor than you do with the GPLv3 Thus, I pose if the AGPLv3 fails the dissonant test, so does the GPLv3. If you disagree, please propose a situation in which it may not and specify the license text which causes this to be so.
Re: Is AGPLv3 DFSG-free?
On Wed, Aug 20, 2008 at 5:14 AM, Francesco Poli [EMAIL PROTECTED]wrote: The situation is different with AfferoGPLv3 section 13, where just using a modified version of the work forces you to convey the Corresponding Source, from the same server (which could just be from impractical to impossible, think of a network application running on a resource-limited embedded system) or from a different server (with all the already discussed reliability issues, which cause possibly significant costs). At the risk of repeating myself, I don't believe this technical challenge of reliably hosting code poses a serious hurdle to compliance with this license. We have distributed VCS systems available and in widespread use, for example. A GIT/Mercurial/Bazaar/etc setup which is mirrored to multiple servers run by multiple groups would ensure that the source is always available, if the current VCS services pose a problem for AGPLv3 compliance. I also don't believe the current VCS services have reliability issues to the extent that section 13 compliance is an issue. If a service does go down, it's really not a big hassle to upload the source to another host. In accordance with the AGPLv3 section 8, you have 30 days to do so after being notified of the problem. Does anyone here believe that free VCS services are so fly-by-night that it's reasonable to expect this to happen more than once? Certainly if they become so, a more reliable free VCS solution could be setup by the community to mitigate future problems.
Re: Is AGPLv3 DFSG-free?
You're taking quite a few steps forward on logic here, let's rewind a bit. I'm not sure that that's the case, but that seems like a pretty clear contamination of unrelated software, which would break DFSG 9. It does not change the license of that software in other uses, it only applies the terms of AGPLv3 section 13 to the whole of the work. The GPL has always applied to the whole of the work, including libraries distributed under a different license. Consider the GPLv3's definition (which is also used in the AGPLv3): The Corresponding Source for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work. If you write a library, and then link that library with an existing GPL licensed package, to satisfy the terms of the GPL in that modification you must provide your library either under the GPL or under a license which is GPL-compatible (that is, allows the terms of the GPL to be applied to it, even if normally distributed in a more permissive manner). We're not changing/contaminating the license of dependencies any more than the GPL has always done. If anything, Google the organisation is the server-side user. Whether Google the corporation or an employee of Google is the user is moot. It's also moot to try to draw a line between client and server on a network basis. Consider that the license text at no point specifies the Internet or which OSI layer that interaction takes place on. Two users of an XMPP network able to interact with the other's software thus enact AGPLv3 section 13. At this point of consideration the only difference is who the software in question is willing to interact with, based on it's settings and protocol. Google employee Bob may need special access to run a script that requests the software version of every user that connects to their XMPP servers, but as far as this license is concerned, all that matters is that the AGPLv3 licensed software interacts with Bob's script by replying. Again, there is no requirement that your software interact with all users. Free (as in cost) code hosting services do not offer guarantees of availability or longevity, so the user must still host their own copy too, else the C.Source may not be available when it is requested. There's no guarentees on any server, but a popular free VCS service is undoubtedly more reliable than what most people could provide with their own servers. I can't see a copyright holder bringing an infringement case against a modder because gna.org had server trouble one night making their modified code unavailable for a few hours. These things happen, we deal. Why? Don't all users of the modified version also have to keep a copy to be able to satisfy section 6, as outlined above? They can share the cost by using 6e, but they don't reliably avoid it. Section 6 is Conveying Non-Source Forms, and specifically uses the word convey. Note section 0's definition of this word: To convey a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying. Section 13 requires the distribution (conveying) of the Corresponding Source, not the object code, and thus section 5 (not 6) applies to the act of network distribution required by section 13. If you were to additionally offer the object code on a network server, such as a .deb non-source package, then section 6 comes into effect, but no more so than it would with the GPLv3. Most of your points are based on section 6 terms, so we should resolve this understanding first.
Re: Is AGPLv3 DFSG-free?
To cut down on number of emails, I'm replying to both Miriam and Francesco below: On Tue, Aug 19, 2008 at 8:53 AM, Francesco Poli [EMAIL PROTECTED]wrote: But there's a significant difference in reliability when the Corresponding Source is hosted on the *same* server where the AfferoGPLv3'ed program is running on: if that server is down, no Source distribution will be performed, but no remote interaction with the program will happen either... This is absolutely true, in a best case scenario you would host the code yourself from the same computer and network connection as the remote user is connecting to you by. However, even GPLv3 section 6d does not require this and that section is far more picky on how the Corresponding Source is provided. On Tue, Aug 19, 2008 at 8:28 AM, Miriam Ruiz [EMAIL PROTECTED] wrote: It seems that the logic under AGPL is to consider a network connection (which doesn't have to be the Internet, it can be, lets say, bluetooth) almost at the same level as code linkage then. Not quite, from my understanding. It's first important to note that the term linking does not appear anywhere in either the GPLv2 or GPLv3, this is a common misunderstanding of the licenses that I had too before spending some time talking to various lawyers about it. Copyright law can only extend the copyleft terms so far that works are combined into one work. That is much broader than linking. Consider what the GPLv3 says about this in 5c: c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it. The whole of the work, and all its parts is not even limited to executable code. A game, for example, includes the software media components which a reasonable person (ie, a Judge) would say is part of the game. This is confusing to us programmers because the software mechanism for loading said media components is little different from how Firefox loads webpages or Xine loads movies, and yes it does create some fuzzy areas where the copyright holder may need to specify her/his intentions. It also doesn't matter how they're packaged or how they interact. The copyright holder can say if the parts communicate over a Unix pipe, they're separate works, or the copyright holder can say if you're extending my original work in any manner the GPLv3 applies to all parts. In the end, if a serious conflict ever arose it'd be up to a judge to decide, and only to determine if the components are two separate works or one whole work. This term, however, is very different from AGPLv3 section 13, which does not combine works over a network into a single work. This section merely gives the same GPLv3 rights to users of a software who access that software over a network, rather than having a copy of the software on their own machine in order to run it. I'm not exactly sure how it would be technically possible to prominently offer all users interacting with it remotely through a computer network [...] an opportunity to receive the Corresponding Source... in certain kind of programs that do not have a textual interaction with people. Note that it doesn't specify *how* you offer the source code or through which mechanism. Using your example of a network time server, no the protocol really doesn't offer this easily. In this case, you'd just show that you're making a reasonable effort to comply with the terms of this section in posting a link to the source code where you advertise the network time server's address. Even in that case, the license probably requires you to have the source code available some period of time afterwards (three years) The AGPLv3 section 13 terms do not specify this, and thus, no such requirement exists. All that's required is that it's made available through a networked server. I believe the language in this section is intentionally broad in order to legally allow the flexibility needed to reasonably comply. The only place in the (A)GPLv3 that specifies a duration of time the Corresponding Source must be made available is when the object code is distributed on a physical product, such as a router or mobile phone, when the Corresponding Source is not physically distributed with the same product. 3) The user cannot remain anonymous. What stops me from getting an anonymous account at Gna! (or any other free VCS services) and posting my modified version there? The license certainly doesn't require that I identify myself beyond the terms of section 5a does (which is identical to the GPLv3). I'm also quite bothered regarding to which extent does the AGPL applies to
Re: Is AGPLv3 DFSG-free?
Sorry for any etiquette foobars I may have made, I wrote that email in a bit of a hurry this morning. So I still don't understand the original claim that connecting a 3d IM client to an AGPLv3'd GTalk server would allow Google to obtain the source of the client. Anyone? When the client permits the server to interact with it. For example, if Google ran a script asking every client which connected to their servers for their version. If the client was licensed under the AGPLv3 and replied, thus supporting interaction and allowing Google to use said client software over a network, AGPLv3 section 13 it seems to be to apply to that interaction. For us, PySoy-based game clients will almost always provide a fairly rich level of interaction to remote users, to the extent of P2P (player to player) distribution of game content and even server-less game modes. The terms of AGPLv3 section 13 applying to all networked instances of PySoy games is a desirable effect of the license for many reasons. If we accept that interact means act on each other (Collins Eng Dict), then the AGPLv3 software acts on Bob's script's output, but Bob's script doesn't seem to act on the AGPLv3 software's output in the above case, so they do not interact. If Bob's script sent the request in response to a connection/authentication from the client, then this is complete. I would say, further, that any query/response pair represents interaction over a network. I'm obviously taking the most broad interpretation possible here. I'm not sure if this is related to the DFSG status of the license, however. Well, there are guarantees available on servers, but they cost, which would break DFSG 1. Co-hosting the application and C.Source avoids the application being used in breach of licence when the C.Source is unavailable. AGPLv3 makes anyone who can't co-host the application and C.Source into second-class users who should take their app offline whenever the C.Source's home looks unavailable, breaking DFSG 5, or DFSG 1 if checking has a significant cost. Maybe I'm just making light of this scenario, I as a copyright holder would never expect people to temporarily stop using software just because the server that hosts it's source code is temporarily down. But if that's a real concern, the code could be uploaded/mirrored easily enough to guarentee uptime. I think we should examine reasonably obvious lawyerbombs *before* they explode in our face. It might not be a few hours - it might be forever. Free hosting services have vanished in the past. You are correct, they have, and for the most part projects which were hosted on them moved to another free VCS service. Sorry, satisfy was a bad word. Let me try to explain the relevance of section 6's list: section 5 is section 4 plus notices and general public licensing of modifications. Section 4 requires distribution as you receive it, in any medium [...] any price or no price which is not troublesome (and so the GPLv3 is fine on this) but section 13 limits that to from a network server at no charge, through some standard or customary means. I suggest that we don't have standard means to download the C.Source for a network application yet and section 6 gives examples of some customary means. Also, I suggest that a user cannot rely on the C.Source being available at no charge by any means without liability for the hosting and download costs. Ah, I can see where you drew this conclusion now, even if I disagree. The license does not specify that the distribution must be in any specific form. If section 6 distribution terms were desired for section 13, it would have specified so in section 13. Legal documents are very specific about this, they need to be to avoid confusion. Section 13 only requires it be distributed through a standard or customary means. The way I read this means a manner in which source code is generally distributed by the community. As a tarball over HTTP, as a distributed VCS branch, etc. The language is open-ended enough such that future means of distributing source code are available as they become standard or customary.
Re: Is AGPLv3 DFSG-free?
Greets. It's been awhile since I unsubscribed to this list, so a quick introduction is that I'm the maintainer of the PySoy project, the game engine being discussed here. There are two issues being discussed, one is what the AGPLv3 means, and another on how it applies to PySoy. I'll only address the license in this email. Given the thread thus far to paste AGPL section 13, the only section which differs from the GPLv3 beyond name changes: 13. Remote Network Interaction; Use with the GNU General Public License. Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph. Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the work with which it is combined will remain governed by version 3 of the GNU General Public License. I'm going to break this down into pieces, as I understand it from numerous conversations with people at the FSF, SFLC, etc: *your modified version must prominently offer all users interacting with it remotely through a computer network* The terms of client/server/peer do not appear in the license text. A user is thus any person operating software which interacts with the software you're running, regardless of the network role your software is running in. If you're running a 3d IM client connected to GTalk, and that client has modified code, you're thus required to allow Google sysadmins to receive a copy of your changes. Also note that the first paragraph of section 13 only applies when you're able to connect to the Internet, thus, the license passes the desert island test just the same as the GPLv3 does. *an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source** from a network server at no charge, through some standard or customary means of facilitating copying of software.* Note that this does *not* read that the user of the software must, themselves and through their local Internet connection, send a copy of the modified software. It also does not specify that the user must host it on their own server. It is standard and customary that software patches be made available through a VCS. Many VCS's allow numerous options in how this can be done. There are numerous free code hosting services available to anybody with a network connection. In many cases only the modifications to the Corresponding Source on which it's based (ie, VCS patches) need be uploaded, and only once, by the modifier themselves. Thus, the source sending requirement does not violate DFSG's guidelines 3 or 5, as nobody who is able to run software on the network is burdened (financially or otherwise) with offering their changes to the people operating software that their modified software is interacting with. *but the work with which it is combined will remain governed by version 3 of the GNU General Public License.* While paragraph 1 requires all modified Corresponding Source be included, including dependencies, this does not mean that dependencies are now subject to AGPLv3 outside the context of this specific software. Including the whole of the Corresponding Source closes a loophole where essential functionality is added to a dependency (ie, new functions added to a library) but only the modifications to the AGPLv3 covered work which utilize those functions are provided on request. Thus, the AGPLv3 does not contaminate other software as in DFSG guideline 9. The only potentially tricky spot I see is the dissident test. I believe the AGPLv3 could pass as it does not require that the software, when on a network, interact with anybody. That is to say, if avoiding an evil government's prying eyes was desired, the software could only interact with trusted agents, and thus keep even it's presence secret.
Panda3d Public License?
Has anyone looked at Disney's Panda3d Public License Version 2.0? http://www.panda3d.org/license.php Clause 4 seems worrysome (requires sending signifigant changes to Disney). Other parts seem redundant with copyright law. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: x264 for Debian
On Thu, Mar 02, 2006 at 01:26:56PM -0800, David Liontooth wrote: Are there objections to including the new H.264 encoder in Debian? For details, see bug 354667 (request for packaging). Debian maintainer Christian Marillat currently maintains an unofficial package, and we would like your advice on whether this GPL'd codec meets the DFSG. Theres a difference between the code and the codec. The codec has dozens of different corporations holding patents over it, who will try to extract royalties for it in countries where those patents are upheld (ie, USA), and giving it this is free because it's GPL hurts truely patent-clear codecs such as VP3.2/Theora from being recognised as such. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: x264 for Debian
On Thu, Mar 02, 2006 at 10:45:12PM +, M?ns Rullg?rd wrote: The codec has dozens of different corporations holding patents over it, who will try to extract royalties for it in countries where those patents are upheld (ie, USA), and giving it this is free because it's GPL hurts truely patent-clear codecs such as VP3.2/Theora from being recognised as such. VP3/Theora is all but free of patents. On2 has granted unlimited free use of the patents they hold relevant to VP3. There are almost certainly other patents that could be construed to cover VP3 as well. It is a good gesture nonetheless. I didn't say patent-free, I said patent-clear. On2 has put a license on it which allows it to be used for any purpose and disclaims any right to restrict it's use or charge royalties. This is the patent version of the BSD license. The dozens of corporations holding patents over H.264/MPEG-4 have not made such a release, and are activly seeking royalties. We don't even know yet what those royalties will be since those corporations are still fighting amoung each other over how to divy up the bounty from the combined patent portfolio. Regardless of the result, it is not patent-clear, will not be patent-clear, and will suffer worse bashlash as the free MP3 encoders did. The GPL specifically forbids redistribution when the liberties granted by the GPL are limited or restricted by patents/etc. To distribute this software on any US-based server is, thus, in violation of the GPL. That said, VP3/Theora can hardly compare with H.264 in terms of coding efficiency. There really is no viable alternative in some situations. Microsoft's WMV9/VC1 comes close but I'm sure it has every bit as non-free licensing terms. This argument has nothing to do with the freeness of it, or it's compliance to the DFSG, but instead seems to be arguing that it's patent status should be ignored because it's superiority over free codecs makes it OK to ignore the ethical concerns over it. This is the same argument used to promote the nvidia binary drivers. Something being useful is not a valid argument to ignore it's proprietary nature. This is what non-free exists for. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: x264 for Debian
On Fri, Mar 03, 2006 at 12:09:39AM +, M?ns Rullg?rd wrote: Sure, On2 has allowed free use of *its* patents relating to VP3. That doesn't mean that some obscure company will pop up out of nowhere with a bunch of patents they claim *also* apply to VP3, and that On2 has been infringing all along. Something like that happened with JPEG not too long ago. This argument has been made. It's response from lawyers is that, unlike On2's VP3.2, JPEG was believed to be patent-FREE. This opens the way for someone to claim that their generic patent applies. On2's VP3.2 patents have held undisputed for many years now. The base methods have clear prior use (huffman tables, MDCT, etc), nobody has disputed them, and since On2's more recent codecs (VP5, VP6, etc) are based on VP3.2 it would serve someone well to dispute it if they thought they could. There's a big difference, also, between someone could dispute it and many people have patents covering it specifically and are seeking royalties. Someone could argue that the compression method used by bzip2 is patented and try to seek royalties, but this could doesn't trigger the problem in the GPL, that clause is only triggered when someone is activly legally persuing royalties or other restrictions on use or distribution. Nobody has, or is, persuing royalties on On2's VP3.2. All known patents which apply have been disclaimed. It is, thus, patent-clear and DFSG-free. The patent situation is unfortunate. Nevertheless, the H.264 codec is being adopted by broadcasters throughout the world. For good or bad, the codec is here to stay for a while. I'm not arguing that. Broadcasters are implementing any number of proprietary methods. They are a direct threat to software freedom and need to be boycotted by the free software community. To do otherwise is to put ourselves in a legally disadventagous position while further supporting those who seek to promote proprietary software. I'm not saying the patent issue should be ignored. It just strikes me as silly to even start comparing Theora with H.264. Certain graphic artists would say the same of GIMP vs Photoshop, or compare their favorite music application with the numerous GNU/Linux offerings, or even 3d Studio Max/Bryce/Poser/etc vs Blender. There are free alternatives. They may or may not be considered acceptable for specific applications, but this doesn't change that proprietary software is proprietary and is, thus, not DFSG-free. This is all off-topic for debian-legal, so I won't pursue the argument further (unless someone says something really silly). Not really. Wether something is acceptable for inclusion in the debian free package pool for license and patent reasons is exactly what this list is for. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dual licensing (was: Re: [no subject])
On Sat, Nov 05, 2005 at 06:47:03AM +1100, Andrew Donnellan wrote: So if you want, you can use it under the terms of the MIT license. And, if you prefer, you can use it under the terms of the GPL license. I mean the *developer* must comply with both licenses, eg if you d/l under the GPL and MIT, then the developer must still put the written offer for source code and meet all the distribution requirements of the GPL, but anyone else can choose between the GPL and the MIT license. This is true for any developer who releases under both licenses, but any developer may release under just one license and then only comply with that one. In the effort for expanding understanding, here's why that is, by looking at the way the GPL works... The GPL has it's legal enforceability from copyright law. GPL'ed software is copyrighted, which restricts all but the most fringe fair uses to the software. No user has the right to use or redistribute the software in most ways under this state of non-license. The GPL, being a license, also serves as a sort of unsigned contract between the two parties. The author, by releasing per software under the GPL, offers in writting to provide certain things to 3rd parties, including source code, which is what prevents deceptive authors from releasing under the GPL but not complying with it themselves. Then the copyright holder provides a license which permits non-exclusive, royalty-free access to the software under certain conditions. We're all probobally very familiar with what the GPL provides, so I'll leave it there. Now, with dual licensing, the copyright holder offers two different licenses. The purpose of any license is to permit activity which the copyright, by itself, will not. It cannot legally restrict beyond what copyright already does. Nothing in the MIT license, using this as an example (there's a number of proprietary licenses used too, see MySQL or ReiserFS for good examples), says you must also comply with the GPL license. Nothing in the GPL license says that you must also comply with the MIT license. Therefore, you have a choice, since both of these licenses independently grant you access to the code. If you, as a developer, user, reseller, etc choose to only use one license, that is your right, as granted by the original copyright holder. When you slap your copyright on your contributions, assuming you're adding or changing it, you may choose to only license your changes under the GPL, or under the MIT, as both permit changes to be added and redistributed. Now, most dual licensed software requires that, in order for your changes to make it back into the main distro, you must license under both licenses. Some also require that you give the copyright of your changes to the original author. See reiserfsprogs/README for an example of this, where you're allowed not only to keep your copyright but, if you dual license for commercial/proprietary sale (ie, company wants to use reiserfs in non-free software) he may cut you a check for non-trivial contributions. None of this is required. You can, in the above example of GPL+MIT, release a fork of the code under the GPL exclusivly (or MIT exclusivly) if the author won't accept your contribution unless it's also dual licensed. That is, if you write a really great new optimized search routine for MySQL but you don't want your additions to be anything but GPL, MySQL won't accept it, but that doesn't mean you can't offer a fork or patchset for others to use. Now, having a single software package where two or more different licenses cover different parts of the code is a different issue, one that was hinted to earlier on the thread. In this case, those licenses apply only to the parts of the package which they cover, and this may or may not be in violation of the GPL depending on how those pieces fit together. If they're ment to be compiled into a single binary, or linked against each other, and the licenses aren't compatable, the maintainer for that package needs to be schooled. It's perfectly fine, however, for a library to be released under a BSD license with an example mini-app which uses the library licensed under the GPL and documentation licensed under the FDL (or CC Attrib-AsIs or any other combo). A GPL'ed application can link against BSD-licensed library and the docs, which are entirely seperate, can be licensed however the author chooses. A similar situation can arise from patent licenses, which are similar but of an animal all their own. If the patent license (a license which grants access to some patented method or procedure) is GPL-incompatable the author must be very careful that whatever software implements it not be linked directly against either the GPL or LGPL, as section 7 of the GPL and section 11 of the LGPL would render such software illegal for 3rd parties to distribute, as enforced by the copyright
