|
»
»
GNU Arch moves to GPL v3 or later
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
 |
|
|
|
GNU Arch moves to GPL v3 or later
by Stephen J. Turnbull
::
Rate this Message:
Andy Tai writes:
> Hi, I am thinking of putting future releases of GNU Arch under the GNU > GPL v3 or later versions of the GPL as published by the Free Software > Foundation. Er, why make Arch code license-incompatible with a lot of GPLv2 code that's out there, such as the Linux kernel and (for now) XEmacs? What's so wrong with GPLv2? _______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@... http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/ |
|
|
Re: GNU Arch moves to GPL v3 or later
by Thomas Lord
::
Rate this Message:
Andy Tai wrote:
> Hi, I am thinking of putting future releases of GNU Arch under the GNU > GPL v3 or later versions of the GPL as published by the Free Software > Foundation. I would like to see if there is anyone (GNU Arch users, > past contributors) who may have any issue with this. > > For any comments on this issue please reply to this mail list or to me > (atai@...) and cc Robert Collins (robert.collins@...). > > I am pretty sure that a substantial portion of the GPL code in the distribution is copyright by me, so I guess it might be helpful to reassure you: My intention for that code was "GPLv2 or (at your discretion) any later version as published by the FSF". So, no objections from over here. My word is good. > Thanks, > Andy > > And thank you for your continued support. -t _______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@... http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/ |
|
|
Re: GNU Arch moves to GPL v3 or later
by Thomas Lord
::
Rate this Message:
Stephen J. Turnbull wrote:
> Er, why make Arch code license-incompatible with a lot of GPLv2 code > that's out there, such as the Linux kernel and (for now) XEmacs? > > What's so wrong with GPLv2? > Ask Eben? or ask the DRM wonks at FSF? They, along with Microsoft's interesting behavior in response, have given me enough reason to stand in solidarity on this issue. v3 doesn't hurt anything and there are pretty good arguments in favor of it. I don't know about XEmacs but the Linux kernel doesn't have the legal degree of freedom to move to v3 even if Linus wanted to -- so it's kind of a moot point. I don't care *that* much about license compatibility with existing code. All but an a ridiculously tiny amount of the really good code I'll see in my lifetime has yet to be written. -t > > _______________________________________________ > Gnu-arch-users mailing list > Gnu-arch-users@... > http://lists.gnu.org/mailman/listinfo/gnu-arch-users > > GNU arch home page: > http://savannah.gnu.org/projects/gnu-arch/ > > _______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@... http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/ |
|
|
Re: GNU Arch moves to GPL v3 or later
by Andy Tai
::
Rate this Message:
Tom, thank you. Your code, the largest portion of Arch, has been
assigned to the FSF. Nonetheless, your agreement to this is always the most welcome! Andy On 9/7/07, Thomas Lord <lord@...> wrote: > I am pretty sure that a substantial portion of the GPL code > in the distribution is copyright by me, so I guess it might > be helpful to reassure you: > > My intention for that code was "GPLv2 or (at your discretion) > any later version as published by the FSF". So, no objections > from over here. My word is good. > > > > > Thanks, > > Andy > > > > > > > And thank you for your continued support. > > -t > _______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@... http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/ |
|
|
|
|
|
Re: GNU Arch moves to GPL v3 or later
by Thomas Lord
::
Rate this Message:
Andy Tai wrote:
Tom, thank you. Your code, the largest portion of Arch, has been assigned to the FSF. Arch code itself, yes. I think hackerlab is still mine. It makes for little nevermind either way, though. -t Nonetheless, your agreement to this is always the most welcome! Andy On 9/7/07, Thomas Lord lord@... wrote: _______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@... http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/ |
|
|
Re: GNU Arch moves to GPL v3 or later
by Andy Tai
::
Rate this Message:
Thanks for this information. This is important.
On 9/7/07, Thomas Lord <lord@...> wrote: > > Arch code itself, yes. I think hackerlab is still mine. It makes for > little nevermind either way, though. > > -t -- Andy Tai, atai@... _______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@... http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/ |
|
|
Re: GNU Arch moves to GPL v3 or later
by Stefan Monnier
::
Rate this Message:
> Er, why make Arch code license-incompatible with a lot of GPLv2 code
> that's out there, such as the Linux kernel and (for now) XEmacs? Last I looked XEmacs still was distributed under the GPL>=2, so it is perfectly compatible with GPLv3. Stefan _______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@... http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/ |
|
|
|
|
|
Re: GNU Arch moves to GPL v3 or later
by Stephen J. Turnbull
::
Rate this Message:
Stefan Monnier writes:
> > Er, why make Arch code license-incompatible with a lot of GPLv2 code > > that's out there, such as the Linux kernel and (for now) XEmacs? > > Last I looked XEmacs still was distributed under the GPL>=2, so it is > perfectly compatible with GPLv3. Sure, if somebody wants to incorporate XEmacs in a future version of tla, they're free to do so, and we'll applaud their taste. But free software is about cooperation, and respecting others' goals. If a project, for any reason, wishes to continue to use "GPLv2 or later", then a move by Arch to GPLv3 makes Arch code unavailable to that project.[1] I would think that any free software advocate would consider that in principle a bad thing, and thus want to balance it with specific advantages of the new license. Linux and XEmacs are simply examples of that kind of project and of the variety of reasons why people might wish to continue to use the same licensing. Footnotes: [1] Note that this argument is isomorphic to the logic that Richard Stallman uses for claiming that XEmacs's failure to collect assignments makes XEmacs code "unavailable" to Emacs, although the specific obstacle is different. _______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@... http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/ |
|
|
Re: GNU Arch moves to GPL v3 or later
by Thomas Lord
::
Rate this Message:
I think that that's a solid complaint in the abstract. A good rule of thumb would be to do a little extra work and keep "supporting" GPLv2 just because -- well, it can only help. But, not in this case, probably. It's the specifics of the case here that matter. I love a great deal of all that code but, you know, not *that* much. It just isn't *that* precious. If anyone were to aim for heavy duty re-use of some part, I'd almost certainly say "copy from that, kind of trace some of the ideas, but basically rewrite for a cleaner form". This isn't a code base I think needs to be overly protected for maximum possible copyleft re-use. If it does turn out that someone is really screwed because they need a v2 form, hopefully they can speak up and arrangements can be easily made. -t Stephen J. Turnbull wrote: > Stefan Monnier writes: > > > > Er, why make Arch code license-incompatible with a lot of GPLv2 code > > > that's out there, such as the Linux kernel and (for now) XEmacs? > > > > Last I looked XEmacs still was distributed under the GPL>=2, so it is > > perfectly compatible with GPLv3. > > Sure, if somebody wants to incorporate XEmacs in a future version of > tla, they're free to do so, and we'll applaud their taste. But free > software is about cooperation, and respecting others' goals. If a > project, for any reason, wishes to continue to use "GPLv2 or later", > then a move by Arch to GPLv3 makes Arch code unavailable to that > project.[1] I would think that any free software advocate would > consider that in principle a bad thing, and thus want to balance it > with specific advantages of the new license. > > Linux and XEmacs are simply examples of that kind of project and of > the variety of reasons why people might wish to continue to use the > same licensing. > > > Footnotes: > [1] Note that this argument is isomorphic to the logic that Richard > Stallman uses for claiming that XEmacs's failure to collect > assignments makes XEmacs code "unavailable" to Emacs, although the > specific obstacle is different. > > > > > _______________________________________________ > Gnu-arch-users mailing list > Gnu-arch-users@... > http://lists.gnu.org/mailman/listinfo/gnu-arch-users > > GNU arch home page: > http://savannah.gnu.org/projects/gnu-arch/ > > _______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@... http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/ |
|
|
Re: GNU Arch moves to GPL v3 or later
by Alfred M. Szmidt
::
Rate this Message:
> Hi, I am thinking of putting future releases of GNU Arch under
> the GNU GPL v3 or later versions of the GPL as published by the > Free Software Foundation. Er, why make Arch code license-incompatible with a lot of GPLv2 code that's out there, such as the Linux kernel and (for now) XEmacs? The question is infact the reverse, why was Linux made incompatible with future versions of the GPL? It has been a known fact that the GPLv3 will be released, it has been a concious decision on the Linux developers to not be compatible with it (not collecting copyright assignment, expliclty releasing the source code under GPLv2 only). As for XEmacs, it is licensed under the GPLv2 or later, so they can use the changes if they so choose. In either case, Arch is already incompatible with the licenseing terms of Linux. Linux is licensed under the GPLv2 only, while Arch is licensed under GPLv2 or later. What's so wrong with GPLv2? Tiviosiation, Novel/Microsoft type deals, not being international enough come to mind. _______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@... http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/ |
|
|
Re: GNU Arch moves to GPL v3 or later
by Alfred M. Szmidt
::
Rate this Message:
> > Er, why make Arch code license-incompatible with a lot of
> > GPLv2 code that's out there, such as the Linux kernel and (for > > now) XEmacs? > > Last I looked XEmacs still was distributed under the GPL>=2, so > it is perfectly compatible with GPLv3. Sure, if somebody wants to incorporate XEmacs in a future version of tla, they're free to do so, and we'll applaud their taste. But free software is about cooperation, and respecting others' goals. Free software is about freedom. If it was about cooperation, and respecting others' goals, then we would be using a all permissive license like the Modified BSD license. Footnotes: [1] Note that this argument is isomorphic to the logic that Richard Stallman uses for claiming that XEmacs's failure to collect assignments makes XEmacs code "unavailable" to Emacs, although the specific obstacle is different. You might want to revise your history lesson about what Richard thinks. http://www.stallman.org/articles/xemacs.origin Hint, it had nothing to do with copyright assignments. _______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@... http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/ |
|
|
Re: GNU Arch moves to GPL v3 or later
by Stephen J. Turnbull-2
::
Rate this Message:
Alfred M. Szmidt writes:
> Free software is about freedom. If it was about cooperation, and > respecting others' goals, then we would be using a all permissive > license like the Modified BSD license. Free software is pointless if it is not distributed and modified by others. I call that "cooperation". And respect != submit. > Hint, it had nothing to do with copyright assignments. I don't know what "it" you think you're talking about; what I'm talking about is the fact that Richard has repeatedly stated that the fact that XEmacs is free software licensed under the GPL is insufficient for including XEmacs code in Emacs. The necessary ingredient is legal papers (typically, but not always, an assignment) from the author of each piece of code large enough to fall under copyright. _______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@... http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/ |
|
|
Re: GNU Arch moves to GPL v3 or later
by Stephen J. Turnbull
::
Rate this Message:
Alfred M. Szmidt writes:
> In either case, Arch is already incompatible with the licenseing terms > of Linux. Linux is licensed under the GPLv2 only, while Arch is > licensed under GPLv2 or later. Wrong. At present, Arch can incorporate Linux code, and vice versa, under the condition that the combination is distributed under GPLv2. There is no incompatibility of license here, only an incompatibility of Linus's freedom to choose a license he likes with the FSF's desire to refine the instruments it uses to accomplish its social goals. > What's so wrong with GPLv2? > > Tiviosiation, Novel/Microsoft type deals, not being international > enough come to mind. Internationalization, I guess. How do the other two apply to GNU Arch? _______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@... http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/ |
|
|
Re: GNU Arch moves to GPL v3 or later
by Alfred M. Szmidt
::
Rate this Message:
> In either case, Arch is already incompatible with the licenseing terms
> of Linux. Linux is licensed under the GPLv2 only, while Arch is > licensed under GPLv2 or later. Wrong. At present, Arch can incorporate Linux code, and vice versa, No, not at all, the license conditions for arch are _or_later_, these are terms different than those for Linux, so you _CANNOT_ incoperate changes from Arch into Linux. The GPL states that the license terms must be the same, since they are not, the two licenses are not compatible. _______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@... http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/ |
|
|
Re: GNU Arch moves to GPL v3 or later
by Thomas Lord
::
Rate this Message:
Alfred M. Szmidt wrote:
> You might want to revise your history lesson about what Richard > thinks. http://www.stallman.org/articles/xemacs.origin > > Hint, it had nothing to do with copyright assignments. > It was a an early instance of a pattern that has proved reliable, since those days: A project (like Emacs) gets to a stage of development that I'll dub "Immanent Maturity of Big New Features". That means that the program gets to some stage where for just increments of additional coding you get back leaps of new value (like adding some graphical dodads to Emacs' X interface). Well, what is a software services open source company to do when that happens -- when an interesting program reaches the state of "Immanent Maturity..."? At that stage, service firms want to "own" the program in the sense that they would prefer to be the exclusive supplier of the incremental improvements that create super-linear new value. If demand for that new value is high, and if the service firm largely throttles which new increments are done when, then the service firm can find ways to sell that new value at a profit. So: firms fork, essentially hostilely. It happened to Emacs, GCC, GDB, libc, Guile, Arch, Debian, GTk, Gnome, .... probably others I'm forgetting. These hostile forks are usually not accompanied by a lot of strife (e.g., if a lead developer accepts a job then it is barely even noticed that a fork took place). In most cases, the corporate forks win. In the list above, Emacs and Guile are exceptions and the jury is out on Debian. This isn't obviously bad -- it just *is*. Software development projects in the public interest ought to learn by now that, when they get far enough along, the pressure for commercial forks will be high. The strategies and tactics of public projects have to learn to dance with that devil, so to speak. One way to go, in theory, is to close the "quality and capability gap" between typical public and typical commercial projects. Maybe better software engineering practices (e.g., better revision control) might lead to a point at which it is always cheaper for the end-customers to buy incremental improvements from the public project at labor-cost than it would be to buy the same work from a corporate fork at a premium. Another way to go, in theory, is to start positioning public projects upstream of The Inevitable Fork and basically to try to monetize the process of technology transfer. The Corporate Forkers (an appellation one must type very carefully) have already demonstrated, again and again, that they are happy to pay a premium for technology transfer. They prove this when they hire project leads, or entire project teams. They prove it when they contribute to NPOs around large projects. They even prove it indirectly with the demands they create for certain kinds of technical documentation (e.g., the influence of an O'Reilley title). The open question is how to structure public projects in such a way that they can directly lay claim to some of that premium payout rather than becoming the loser in a contest for loyalties. I haven't tried to define "public project" exactly and, when I start talking about public projects that make money it invites the question of what distinguishes corporate and public. I'm thinking of public projects as those whose technology is fully free software, whose technology is transparent (publicly accessible), whose primary business activity is creating new software to add to their offerings, whose operators are identified to and accessible to the public, and which make no non-trivial service level guarantees to their paying customers. That is, I am thinking about those projects which are the fountainheads of practical free software R&D. Something like Gnome doesn't quite qualify, for example. The technology may be largely transparent (or might not, we don't really know). The identity and accessibility of operators is a debatable point. But it is clear that most of the primary operators of the project have plenty of private contractual obligations that influence the direction of their work. It's a corporate rather than a public project because its direction is partly determined by private service contracts for private gain. Compare that to how the Emacs project runs.... So, how can a public project dance with the Corporate Forkers? It's an interesting question. For one thing, I think public projects need to go ".com," so to speak, so that they can have a budget, a payroll, and official customers..... It's the last item in that list ("customers") that advises against going ".org" (NPO). -t _______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@... http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/ |
|
|
Re: GNU Arch moves to GPL v3 or later
by Stephen J. Turnbull
::
Rate this Message:
Alfred M. Szmidt writes:
> Wrong. At present, Arch can incorporate Linux code, and vice versa, > > No, not at all, the license conditions for arch are _or_later_, these > are terms different than those for Linux, so you _CANNOT_ incoperate > changes from Arch into Linux. The GPL states that the license terms > must be the same, since they are not, the two licenses are not > compatible. You're confusing the permissions notice, which allows a disjunction of template licenses, with the template licenses themselves, each of which individually must remain unchanged. The "or later" phrasing is simply a compact way to express what legally is a multiple license, akin to the GPL+FDL licensing recommended by the FSF for code examples in documentation. _______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@... http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/ |
|
|
Re: GNU Arch moves to GPL v3 or later
by Stephen J. Turnbull
::
Rate this Message:
Thomas Lord writes:
> Alfred M. Szmidt wrote: > > You might want to revise your history lesson about what Richard > > thinks. http://www.stallman.org/articles/xemacs.origin > > > > Hint, it had nothing to do with copyright assignments. > > > > It was a an early instance of a pattern that has proved reliable, > since those days: > > A project (like Emacs) gets to a stage of development If you want to go there, I'd be happy to :-), but please note that I was not talking about the Great Fork of 1994, I was talking about the *present* state of affairs where XEmacs developers regularly merge code from Emacs with minimal effort or discussion, while Emacs developers generally do not consider using XEmacs code at all unless the author is easily available to sign an assignment. And some are afraid to even look at it (in discussions with Ben Wing, Ken Handa went to the length of removing the whiteboard markers from the room so that no code would be fixed in a medium -- I hope that was a joke!) Stefan will probably put it a bit differently, as I believe he personally has done some reverse synching, but I'm pretty sure he will confirm that the legal hurdles are much lower and the amount of code synching much higher in the Emacs -> XEmacs direction than the reverse. I doubt he will deny that the legal hurdles are a big factor in reducing the reverse sync flow to a trickle. _______________________________________________ Gnu-arch-users mailing list Gnu-arch-users@... http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/ |
| < Prev | 1 - 2 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
