On Wed, 2009-06-17 at 16:25 -0700, Saravanan Shanmugham (sarvi) wrote: > This is not FUD and did not mean it that way either. This is what I have > heard from some licensing lawyers relating to usage of GPLv3 software > while working on my own startup. And I have heard this same concern from > friends in other companies as well. > The problem is that there's a lot of anti-GPLv3 sentiment out there from people who haven't actually read it. As a Linux distributor who works in the mobile and embedded space, we've encountered a lot of it from companies who fear that it prevents them from using Linux.
When we've gone through their problems, we've nearly always found that there's no text in the GPLv3 even close to what they believe. Sometimes the misunderstanding comes from earlier GPLv3 drafts, and is with regard to text or clauses that never made it to the final licence. > The specific concern I have heard as quoted to me is relating to > language in GPLv3 relating to 'intimate data communication' with GPLv3 > communication. > The section you are referring to is the most basic one, the definition of "Source Code": 1. Source Code. The "source code" for a work means the preferred form of the work for making modifications to it. "Object code" means any non-source form of a work. A "Standard Interface" means an interface that either is an official standard defined by a recognized standards body, or, in the case of interfaces specified for a particular programming language, one that is widely used among developers working in that language. The "System Libraries" of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A "Major Component", in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it. 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. The Corresponding Source need not include anything that users can regenerate automatically from other parts of the Corresponding Source. The Corresponding Source for a work in source code form is that same work. > If you had standalone tools/command or utility programs that don't talk > to each other, I suspect it would have been ok. > > Upstart is one of those applications that everyone in the system needs > to communicate via D-Bus messaging where the Message API is defined by a > GPLv3 application in this case Upstart. > The Upstart D-Bus interface is very much intended to be a public interface that any software may use without licence contamination. The D-Bus protocol is an official freedesktop.org standard, and the Upstart interface is published and documented over that protocol according to the standard. This is a long way from "intimate" (the old IPC interface 0.3 uses could be described as intimate, and one of the reasons it was dropped was to avoid this issue). If this needs specific addressing, I could add a comment to the dbus/*.xml (which define the interfaces) explicitly stating that software may freely use these interfaces. Also, don't forget that Upstart, as the system init daemon, is covered by the "Major Component" definition. Also my reading of that licence text suggests that the "Corresponding Source" part refers only to the Corresponding Source of Upstart ("the work"). This means that Upstart's Corresponding Source includes the source code for shared libraries and dynamically linked subprograms that Upstart is specifically designed to require. > BTW, when I said people might go off and do their own > replacement/branch-off it would be still be Open source since its > started from the Upstart pedigree. So I don't see how that would be free > riding, since GPLv2 would still require them to publish their changes as > well. Just because some one does not like GPLv3 does not make them free > riders. :-)) > Such a "licence fork" would still not be perceived well in the Linux community, especially since the only change has been in the version of the GPL rather than a sudden switch to a new and radical licence. I'd rather we figured out what the specific issues with the GPLv3 were. That being said, the licence fork would assumedly be based off the 0.3.x branch or 0.5.0/1 which are both "GPL version 2 or later". So the fork would be in the strange position where it could not take any code from bzr, or from later Upstart releases (since they are GPLv3 only) while Upstart trunk itself could happily merge the code of the fork (because it is permitted to increase the licence version). Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist?
signature.asc
Description: This is a digitally signed message part
-- upstart-devel mailing list upstart-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel