|
|
Subscribe / Log in / New account

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Mar 22, 2016 5:23 UTC (Tue) by mcatanzaro (subscriber, #93033)
In reply to: Rust's Redox OS could show Linux a few new tricks (InfoWorld) by gnu
Parent article: Rust's Redox OS could show Linux a few new tricks (InfoWorld)

"The GPL is good for forcing people who make changes to the source to contribute back. This would be okay if you were developing a program, but never ideal for libraries or operating systems, because the GPL forces any code that even remotely uses or links to the GPL'd source, to become GPL'd."

This is where I closed the browser tab. It looks like they don't know about the system library exception?


to post comments

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Mar 22, 2016 5:29 UTC (Tue) by mcatanzaro (subscriber, #93033) [Link] (3 responses)

Ah, disregard, I got that completely backwards.

Still, a really strange interpretation of the license; as if they think all Linux programs are GPLed, just because they use Linux system calls.

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Mar 22, 2016 8:32 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

All Linux kernel modules are GPL, though. And they are building a microkernel, so the separation between the core OS kernel and regular user mode code is much less clear.

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Mar 22, 2016 9:50 UTC (Tue) by xav (guest, #18536) [Link]

Ahem *NVIDIA* ?

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Mar 22, 2016 14:11 UTC (Tue) by edomaur (subscriber, #14520) [Link]

Uh ?

No, that's not the case. Otherwise they would be no proprietary drivers ever loaded in the kernel.

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Mar 22, 2016 19:14 UTC (Tue) by remicardona (guest, #99141) [Link] (42 responses)

+1, I fell off my chair when I read this. It reminds me of Microsoft FUD from the early 2000's ("GPL is a cancer" et cetera ad nauseam). I can't believe anyone would write this in 2016, with all of the success Linux and countless other GPL software (e.g. all major browsers contain at least LGPL code, Google is switching Android to the GPL-licensed OpenJDK) are enjoying.

I'm usually not a very paranoid guy, but I'm tempted to think all of this (the licensing, the everything-is-a-URL plan, etc) is just an elaborate and very well laid-out troll. Some BSD folks have similar views on licensing (hi Theo), but at least he's churning out code. Redux is nothing more than an empty book at this point.

Really, there's not much to see, we should collectively move on.

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Mar 23, 2016 1:05 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (41 responses)

> +1, I fell off my chair when I read this. It reminds me of Microsoft FUD from the early 2000's ("GPL is a cancer" et cetera ad nauseam).
Well, guess what - MS was right. See: GPLv3.

> I can't believe anyone would write this in 2016, with all of the success Linux and countless other GPL software (e.g. all major browsers contain at least LGPL code, Google is switching Android to the GPL-licensed OpenJDK) are enjoying.
GPL's popularity (which is rapidly declining) does not invalidate its infective nature.

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Mar 23, 2016 10:16 UTC (Wed) by aggelos (subscriber, #41752) [Link] (40 responses)

+1, I fell off my chair when I read this. It reminds me of Microsoft FUD from the early 2000's ("GPL is a cancer" et cetera ad nauseam).
Well, guess what - MS was right. See: GPLv3.
Godwin's la... wait, too soon.
I can't believe anyone would write this in 2016, with all of the success Linux and countless other GPL software (e.g. all major browsers contain at least LGPL code, Google is switching Android to the GPL-licensed OpenJDK) are enjoying.
GPL's popularity (which is rapidly declining) does not invalidate its infective nature.
"Infective" or "viral" are clear propaganda terms. I've heard people use "hereditary" which, while not a perfect analogy, seems to be a fair bit more accurate, in that (a) if you're creating a derivative you're either doing it on purpose or you're well aware that what you're doing might easily create a derivative (b) it does not come loaded with judgement on the desirability of the derivative (turns out that most people create derivatives on purpose, with a partner code base of their choosing).

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Mar 24, 2016 8:36 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (39 responses)

Have I compared GPL with Hitler?

And no, GPL is infective, not hereditary. It can propagate to unrelated code merely by the virtue of it being liinked and distributed with GPL. A true hereditary license is LGPLv2 with static linking exception. Or MPL, for that matter.

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Mar 25, 2016 2:06 UTC (Fri) by aggelos (subscriber, #41752) [Link] (26 responses)

Have I compared GPL with Hitler?

Nope, you've compared the GPL with cancer. The point I was making stands: do we /really/ need to wait for the Hitler comparison?

And no, GPL is infective, not hereditary. It can propagate to unrelated code merely by the virtue of it being liinked and distributed with GPL. A true hereditary license is LGPLv2 with static linking exception. Or MPL, for that matter.

Yah, pointing out the unspoken assumptions in such narratives remains fun and is never a drag.

Obviously the GPL does not propagate to code. A different, some would say fairer, way of looking at this is that the authors of the GPL'd code do not want you to integrate _their_ code in a proprietary program. By extension, they can't allow you to permissive-wash it for a 3rd party either.

"Unrelated code" and "Merely by the virtue of being linked" are hardly convincing turns of phrase. After all, the authors of this code explicitly called out to an external component to do something for them. So, you know, "merely" integrated the functionality of N function symbols (probably some data structure definitions too, but let's keep this charitably minimal) in the operation of their program. Does this automatically create a derivative? Well, no, there are cases where it doesn't. But of course, if they have good arguments that they're not creating a derivative, the GPL does not apply, nor is it even trying to. In any case, given what linking to code is about (making use of it), if what they're doing is declared derivative work, well, they can't really be surprised about it (though wishful thinking is something we all engage in occasionally). Hence, hereditary seems appropriate.

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Mar 25, 2016 2:14 UTC (Fri) by aggelos (subscriber, #41752) [Link]

s/what they're doing/what they're distributing/

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Mar 26, 2016 5:23 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (24 responses)

> Nope, you've compared the GPL with cancer. The point I was making stands: do we /really/ need to wait for the Hitler comparison?
Awww... Ok, just to make you happy: "GPL is Hitler".

> Obviously the GPL does not propagate to code. A different, some would say fairer, way of looking at this is that the authors of the GPL'd code do not want you to integrate _their_ code in a proprietary program.
That's another way to say "GPL propagates to everything it touches if it's allowed to". Just like an infectious disease or cancer.

You certainly can isolate GPL or simply avoid it altogether - just like you can avoid or quarantine an infectious disease.

> "Unrelated code" and "Merely by the virtue of being linked" are hardly convincing turns of phrase. After all, the authors of this code explicitly called out to an external component to do something for them.
Nope. It will propagate up to the process boundaries.

For example, if I distribute a closed-source math software package that uses libreadline for a couple of interactive dialogs then ALL the source code would have to be opened (with all of its patents). Even the code that was written without any thought of reliance on libreadline.

Some people are now making an assertion that it's OK to do that with unrelated code (see: ZFS on Ubuntu) but it hasn't been tested legally and is contrary to the opinion of the FSF.

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Mar 31, 2016 13:53 UTC (Thu) by aggelos (subscriber, #41752) [Link] (15 responses)

Hmm.

- "This cancer thing is such intense posturing that seems tantamount to triggering Godwin's law"

- <ad-hominem patronization>

This seems like an accurate summary of the exchange in the previous posts, from my PoV.

That's another way to say "GPL propagates to everything it touches if it's allowed to". Just like an infectious disease or cancer. You certainly can isolate GPL or simply avoid it altogether - just like you can avoid or quarantine an infectious disease.

Well, I've yet to see code or a copyright license that reaches out and forces people to type in specific function names, while providing arguments of the specific number and types required and making use of the result. So I find that your use of the word "propagates" mixes up who has agency here and is making decisions. It's the people, not the code or the license.

For example, if I distribute a closed-source math software package that uses libreadline for a couple of interactive dialogs then ALL the source code would have to be opened (with all of its patents). Even the code that was written without any thought of reliance on libreadline.

This is mere repetition of the same narrative, without addressing the (potential, from your PoV) logical flaws pointed out in it. Now this same narrative is told in terms of an innocent proprietary project whose authors "only" decided to link against libreadline.

AFAICT, there's two arguments being made here, one implicit and one explicit. The implicit one is that libreadline is trivial and that it would be unfair for the authors of the proprietary code, which is decidedly nontrivial (a fact which I guess is intended to be reinforced by the presence of patents?), to "lose" "everything".

It seems to me the setup doesn't quite work. First, given that software is distributed under the GPL precisely with the intent that it should not be incorporated in proprietary programs, I'm finding it hard to sympathize with the authors of the made up proprietary math package. Would one expect sympathy if they somehow incorporated a competitor's proprietary code in their own proprietary project? The two hypothetical scenarios are similar in one specific respect, namely that the people whose code you're making a derivative of, explicitly do not want you to do that (and, I think most reasonable people would agree, are under no obligation to help you).

Also, there's an obvious double standard in this narrative. It's inviting the reader to sympathize with the authors of the proprietary code, but not with the authors of the GPL code whose work would end up in a proprietary product if the copyleft terms were somehow lifted.

The triviality argument works both ways. Since libreadline is that trivial, I'm sure the authors would have no problem dropping the dependency. Perhaps by switching to libeditline, which is a BSDL'd replacement for readline, and having a new version out in a matter of days (allowing for extensive testing). Needless to say, nobody ever got sued for past inappropriate usage of readline, yet at worst one would end up paying damages for the copyright infringement. In no case would one be legally forced to GPL their code (AFAIK, that's not even legally possible).

Now, if the authors of the proprietary software had integrated some more significant strong copyleft software, perhaps they'd find themselves dependent on it, but then it's pretty clear that their stuff is derivative, no?

The second, explicit, argument is that code would have to be opened up which is not dependent on the GPL parts. Again, as above, no code "has" to be opened up and the triviality argument does not hold much water by itself. If, however, one decided to make use of a GPL component they do so with the full knowledge that their derivative needs to comply with the GPL and the GPL tries to incentivize people to produce more free software (surprise, surprise).

Having cleared the copyright considerations, we're left with nomenclature. IIUC, your argument, phrased in a non-propagandory fashion, is that 'hereditary' should apply to the weakest form of copyleft only (i.e. MPL or LGPLv2 with a static linking exception) whereas strong copyleft should be deemed 'viral'. IMHO, the 'viral' part has been thoroughly taken down:

(a) if you're creating a derivative you're either doing it on purpose or you're well aware that what you're doing might easily create a derivative (b) it does not come loaded with judgement on the desirability of the derivative (turns out that most people create derivatives on purpose, with a partner code base of their choosing).

What matters for the purposes of deciding between analogies is the agency; licenses do not 'propagate', it is people who knowingly create derivatives. The word 'viral', when it comes to agency is so wrong that it seems clear to me that it's use is motivated by political views rather than any desire for accuracy.

Even when it comes to the aspect of "what are the bounds of a derivative with respect to copyright" (which is off-topic for this discussion, as it does not concern copyright license terms, but copyright law itself, a larger discussion), 'viral' seems pretty flawed. When you create a derivative of a proprietary program P, your whole program is a derivative of P. Do you call the proprietary license of P viral too because _the whole_ of your program infringes on it? Of course not, this is not an apt analogy. What happens is that your program, as an entity, derives from P. 'Hereditary' may not be a perfect analogy, so far it's the best one I've heard.

I could consider your 'viral' for copyright terms that (a) were forcibly applied and (b) applied for programs that communicated by both implementing a standard protocol or something equally ridiculous. Legal fiction aside, none of these are even possible in any copyright system I'm aware of.

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Mar 31, 2016 15:35 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (14 responses)

> AFAICT, there's two arguments being made here, one implicit and one explicit. The implicit one is that libreadline is trivial and that it would be unfair for the authors of the proprietary code, which is decidedly nontrivial (a fact which I guess is intended to be reinforced by the presence of patents?), to "lose" "everything".
Libreadline is not exactly trivial but neither is it very complicated. It's not _fair_ that it should infect the whole code base.

Note, that it's entirely within the libreadline's authors right to impose such restrictions. I'm just saying that they are not even close to fair and the rational choice for libreadline users is to walk away.

If you add GPLv3 to the mix then it becomes not only unfair, but also political and deceptive.

> Would one expect sympathy if they somehow incorporated a competitor's proprietary code in their own proprietary project?
This is again a wrong analogy. The correct analogy would be a commercial library that prohibits its users from competing with library author's products.

> Having cleared the copyright considerations, we're left with nomenclature. IIUC, your argument, phrased in a non-propagandory fashion, is that 'hereditary' should apply to the weakest form of copyleft only (i.e. MPL or LGPLv2 with a static linking exception)
Correct. These licenses do not propagate outside of their "genetic line".

> whereas strong copyleft should be deemed 'viral'. IMHO, the 'viral' part has been thoroughly taken down
Incorrect. GPL _is_ viral. You might not like the connotations of it, but it IS viral.

And OF COURSE it's political. Everything is, even including the GPL itself. Should I quote the section 0 of it?

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Mar 31, 2016 22:16 UTC (Thu) by raven667 (subscriber, #5198) [Link]

> It's not _fair_ that it should infect the whole code base.

As you point out, you have no rights to use the code whatsoever except for what the author grants to you, the fact that you think it unfair that the author doesn't allow you to help yourself to any code you find in any way you want is a fundamental disagreement that probably can't be resolved by furthering the discussion.

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Mar 31, 2016 22:56 UTC (Thu) by anselm (subscriber, #2796) [Link] (6 responses)

GPL _is_ viral. You might not like the connotations of it, but it IS viral.

Real-life viruses don't require premeditated positive action on the part of their hosts in order to become active. While it is perfectly possible for you to catch a cold simply by being in the wrong place at the wrong time, your code can't be “infected” with the GPL unless you deliberately add GPL'ed stuff to it and then deliberately decide to distribute the result, which is a huge difference. Even then the GPL only applies to the combination of your work with the GPL'ed stuff – your stuff on its own can be licensed differently as long as the terms of its license don't restrict the rights that recipients of the combined result enjoy through the GPL. That is not how actual viruses work.

Calling the GPL “viral” is essentially propaganda.

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Apr 1, 2016 0:33 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

> Real-life viruses don't require premeditated positive action on the part of their hosts in order to become active.
Yes, and?

> Even then the GPL only applies to the combination of your work with the GPL'ed stuff – your stuff on its own can be _licensed_ _differently_ as long as the terms of its license don't restrict the rights that recipients of the combined result enjoy through the GPL.
No, it can't be in any meaningful way. GPL requires redistribution under GPL. Full stop.

It's just that some other open source licenses can be transparently and automatically upgraded to GPL.

> Calling the GPL “viral” is essentially propaganda.
So is "free software" which isn't actually free in any sense.

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Apr 1, 2016 10:36 UTC (Fri) by anselm (subscriber, #2796) [Link] (3 responses)

No, it can't be in any meaningful way. GPL requires redistribution under GPL. Full stop.

Non-GPL doesn't require redistribution under GPL simply because it might conceivably be brought together with GPL.

Suppose I write a program with a command-line interface and license the source code under the MIT licence. Both the source code and any resulting binaries can therefore be distributed under the terms of the MIT licence. If I add the build-system machinery required to optionally let people, if they so desire, link my program with a copy of GNU Readline (which is distributed under the GPL) that they supply themselves, that means a binary resulting from that operation must be distributed under the GPL if and only if these people deliberately decide to distribute it at all. That, however, in no way prevents me – or anyone else – from distributing the original source (or binaries that don't include GNU Readline) under the MIT licence. Even people who receive source for both my program and GNU Readline under the GPL applying to the combination binary would be free to distribute the source for my program, or binaries of my program that aren't linked to GNU Readline, under its original MIT licence. Hence the GPL on GNU Readline can't “infect” my original program against my wishes or the wishes of any recipient.

Of course if somebody intentionally decides to base a program on GPL'ed code where the GPL code isn't optional, that means the program can only be distributed in accordance with the GPL. But that is no different in principle from basing a program on code under some proprietary licence where the proprietary licence makes stipulations as to if and how the resulting program can be distributed. That's not “being viral”, it's just how copyright works. Generally if software authors don't like the way stuff they wish to use is licenced (GPL or otherwise), they're free to find alternatives with licences that are more acceptable to them. People who are “infected” with a “virus” usually have no such choice.

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Apr 1, 2016 10:51 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

> Suppose I write a program with a command-line interface and license the source code under the MIT licence. Both the source code and any resulting binaries can therefore be distributed under the terms of the MIT licence.
AND THAT'S WHAT I CALL FREAKINGLY DECEPTIVE. Please, stop doing this. It's about as honest as Trump's statements that he's the greatest supported of women's rights.

"Yes, sure. GPL totally doesn't require you to distribute code under GPL. You are also free to put it into the public domain or use MIT/BSD! Oh, and if you don't want to do THAT you're also free to settle for up to $150k per violation with each copyright holder. Have fun."

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Apr 1, 2016 11:13 UTC (Fri) by anselm (subscriber, #2796) [Link]

It's about as honest as Trump's statements that he's the greatest supported of women's rights.

If you have anything to add except ad-hominem, let's hear it.

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Apr 1, 2016 18:51 UTC (Fri) by flussence (guest, #85566) [Link]

>"Yes, sure. GPL totally doesn't require you to distribute code under GPL. You are also free to put it into the public domain or use MIT/BSD! Oh, and if you don't want to do THAT you're also free to settle for up to $150k per violation with each copyright holder. Have fun."

Or more tersely: “If you want to screw over your users, foot the bill for development yourself.”

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Apr 1, 2016 15:04 UTC (Fri) by aggelos (subscriber, #41752) [Link]

Real-life viruses don't require premeditated positive action on the part of their hosts in order to become active.
Yes, and?

And the 'virus' analogy is conclusively nonsense. Why keep pretending this is not the case? Honestly, your tireless repetition of the same narrative, without addressing the gross logical fallacies pointed out in it, feels like an attempt to shout people down. Even keeping up with all the implicit arguments and half-formed points is taxing. Could you at least put some effort into expressing yourself in a way that enables, rather than hindering, the discussion?

Calling the GPL “viral” is essentially propaganda.
So is "free software" which isn't actually free in any sense.

More like 4 senses. Freedom to run for any purpose, freedom to examine the source, freedom to distribute copies, freedom to collaborate on and distribute modified copies at least. This rhetoric remains as unconvincing as it is tiring :/ Is there any point in asking for intellectually respectful discussion any more?

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Apr 1, 2016 9:11 UTC (Fri) by paulj (subscriber, #341) [Link] (4 responses)

If you don't like readline's licence, don't use it. If you find that it's "not fair" that you can't use readline on your own terms, well then I could equally think it's "not fair" that you're allowed to distribute your software as closed-source. In short, stop whinging that other people have the same rights to their code as you do over your own.

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Apr 1, 2016 9:34 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

Sure. And it would be nice if GPL fans stopped calling BSD/Apache-licensed projects "unfree" or "closeable source".

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Apr 1, 2016 10:33 UTC (Fri) by paulj (subscriber, #341) [Link] (2 responses)

"free" has a specific meaning in the realm of Free Software licensing. Deliberately chosen to play on other meanings no doubt, but within that context "free" and the mirror "unfree" are correct descriptions of BSD/Apache.

"closeable source" on the other hand is just a generally descriptive term. BSD/Apache licence are explicitly designed to allow further mods to be kept closed!

I'm always amused by the more dogmatic BSD/Apache proponents who try to cast the GPL's attempt to keep code under that licence open as some restrictive of freedom, but who will get huffy if take their BSD/Apache code and - exactly as the licence allows and their espoused view of "freedom" seems to be in favour of - close it off.

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Apr 1, 2016 11:04 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> "free" has a specific meaning in the realm of Free Software licensing. Deliberately chosen to play on other meanings no doubt, but within that context "free" and the mirror "unfree" are correct descriptions of BSD/Apache.
Then so is 'viral' for GPL. Why do you object to it? It has an entirely specific and accepted meaning in the realm of Free Software Licensing.

See: https://en.wikipedia.org/wiki/GNU_General_Public_License for references.

> I'm always amused by the more dogmatic BSD/Apache proponents who try to cast the GPL's attempt to keep code under that licence open as some restrictive of freedom
Yes, it is a clear limitation of freedom. FSF tries to justify it by their political goals, but it's still a restriction.

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Apr 1, 2016 11:28 UTC (Fri) by paulj (subscriber, #341) [Link]

The issue with "viral" is that it is just incorrect.

"free", I can totally agree that some might value open-preserving freedom more, while some might prefer closed-preserving freedom. There's an inherent trade-off there between the freedom for recipients to do whatever they want with the code, and the freedom of the code itself. You can not preserve both the freedom of the code and the freedom of recipients to do what they want. That's fine. In the context of FSF and copyleft, "free" means placing the freedom of the code above the freedom of people to close it. In the context of BSD/Apache, etc., it means preserving the freedom of recipients of the code, over the freedom of the code. Completely fine, they both make sense, they both have their place.

"viral" as an analogy to describe the GPL is not very good. All analogies fail at some point, but a good analogy at least holds for a while. However, GPL as a "virus" falls apart almost immediately. One does not have a choice, typically, in whether a virus will try infect you. Incorporating GPL code is however a choice.

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Apr 1, 2016 14:55 UTC (Fri) by aggelos (subscriber, #41752) [Link]

AFAICT, there's two arguments being made here, one implicit and one explicit. The implicit one is that libreadline is trivial and that it would be unfair for the authors of the proprietary code, which is decidedly nontrivial (a fact which I guess is intended to be reinforced by the presence of patents?), to "lose" "everything".
Libreadline is not exactly trivial but neither is it very complicated. It's not _fair_ that it should infect the whole code base.

(Your comments persist on simply repeating terms that have been pointed out as knowingly (and grossly) misrepresentative ('infect'). To me, this seems like a propaganda campaign and definitely not an attempt at having an intellectually honest discussion.)

AIUI, the 'not fair' comment quoted above concerns the concept of 'derivative' in copyright law. IIUC, you think that it should be 'fair use' to call out to or embed a library and should not be subject to copyright limitations.

(meta: If you think the above is a misrepresentation of your thesis, please consider that it's hard to make out an argument among slogans that are clearly /not/ concerned with making a logical argument, rather with repeating a narrative. This is tiring work. I suspect that's not lost on you, but pointing it out all the same. Personally, I'm thinking that if LWN had some cap on the number or rate of comments per article by any single commenter, that might help with having a more concise discussion and make it easier for more people to be heard. Well, for well-intentioned people at least.)

If this is your point, then is not your frustration misdirected? Of course people who (a) do not want to help companies/individuals produce proprietary software and (b) want to incentivize people to knowingly participate in the production of free software will prevent appropriation of their code to the extent allowed by law.

Not that one can easily sympathize with your PoV -- AFAIUI, your argument is mostly concerned with enabling people to produce proprietary software. Which, it seems to me, is easy enough already (not to go into the larger discussion on whether free work for vendors of proprietary software is 'fair' or indeed whether further skewing the legal framework in favor of the production of proprietary software is socially useful). I mean, it's not like the set of laws concerning copyright and, especially, patents WRT software has been lobbied into existence by software freedom activists. Some might even say the current system started out and has largely evolved to cater to the needs and wants of proprietary software production (though, of course, different classes of proprietary software vendors have different requirements).

Note, that it's entirely within the libreadline's authors right to impose such restrictions. I'm just saying that they are not even close to fair and the rational choice for libreadline users is to walk away.

If you add GPLv3 to the mix then it becomes not only unfair, but also political and deceptive.

'political' isn't a slur. Everything we do has political connotations. When 'political' is used pejoratively, that seems like a way of telling people that they should not be thinking about politics, which seems hypocritical given the, I'm sure you'll agree, very much political narrative your comments have been reproducing. Also, given what we've read so far ('cancer', 'viral', 'infect', 'propagates'), I take issue with your calling anything deceptive. However, if you have an argument to that effect re: the GPLv3, please share it in a clear manner so that we can all consider its merits.

Your wording "libreadline users" seems ambiguous in this context

/Users/ of software using libreadline are probably happily reaping the benefits of using software that they can read the source of and, importantly, collaborate on, receive and distribute modified versions of.

/Developers/ who want to integrate readline in their product seem to be well aware what the licensing conditions are. People who want to develop proprietary software know that this code is not for them. People who want to develop free software may use this code, but they cannot permissively relicense or they would enable others to create proprietary derivatives. If they have reasons to require that their derivative be permissively licensed, they can consider their options and decide appropriately. I honestly fail to see where the (I hope you agree that's accurate) intense hatred of the GPL in your posts here stems from, other than the fact that it may disqualify some code from inclusion in proprietary programs.

Oh, and if you're going to talk about 'community splitting' again, we've already had that discussion here.

Would one expect sympathy if they somehow incorporated a competitor's proprietary code in their own proprietary project?
This is again a wrong analogy. The correct analogy would be a commercial library that prohibits its users from competing with library author's products.

That took quite a few re-reads to (maybe) figure out what you're talking about. IIUC, you're conflating code and people and making the argument that _code_ is a user of that library and hence the analogy should be with _people_ who are bound by an overreaching EULA? Again, IIUC (and your phrasing is really not helping), this seems quite confused. (a) As has been pointed out repeatedly, code does not have agency, its authors do (b) AFAIK, an EULA is /not/ a copyright license, but a contract. If there's an argument to be made here, kindly unpack it cause I, at least, cannot make sense of the above, and I tried to.

Having cleared the copyright considerations, we're left with nomenclature. IIUC, your argument, phrased in a non-propagandory fashion, is that 'hereditary' should apply to the weakest form of copyleft only (i.e. MPL or LGPLv2 with a static linking exception)
Correct. These licenses do not propagate outside of their "genetic line".
whereas strong copyleft should be deemed 'viral'. IMHO, the 'viral' part has been thoroughly taken down
Incorrect. GPL _is_ viral. You might not like the connotations of it, but it IS viral.

Umm, no-one can argue with 'incorrect' :-) Whatever arguments you've presented though...

And OF COURSE it's political. Everything is, even including the GPL itself. Should I quote the section 0 of it?

I think you misunderstood there. As explained above, 'political' is not a slur. However:

The word 'viral', when it comes to agency is so wrong that it seems clear to me that it's use is motivated by political views rather than any desire for accuracy.

i.e. your comments lead me to question your willingness to conduct a discussion (which might result in disagreement, sure) instead of engaging in posturing and staying on message re: cancer, viral, infectiousness and so on.

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Apr 1, 2016 9:09 UTC (Fri) by paulj (subscriber, #341) [Link] (7 responses)

"For example, if I distribute a closed-source math software package that uses libreadline for a couple of interactive dialogs then ALL the source code would have to be opened (with all of its patents). Even the code that was written without any thought of reliance on libreadline."

Other's have pointed out the flaws in this with regard to it being your choice, but note the last the part is just completely untrue. Even if you *did* violate the GPL on libreadline by having some parts of your code rely on it, that does _not_ mean you have to distribute all the source code to rectify the mistake. Indeed, you need not even have to distribute _any_ of "your" source code ("your", because if it depends heavily on someone's else code for key functionality then copyright law says it no longer is completely "yours" - the "someone else" gets rights to it too). So that's just totally bogus.

There are a number of ways such a mistake might be rectified to the mutual satisfaction of all relevant parties. Just stopping with distributing this package linking to readline potentially. More egregious cases might involve you paying damages. In no way is it _required_ that the issue be solved by you distributing _all_ the source code under the GPL (or compatible). Now, it could be that that happens to end up the best option for you in the end - but to characterise it as the only possibility is flat out wrong.

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Apr 1, 2016 9:27 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

> Other's have pointed out the flaws in this with regard to it being your choice
Only in the choice of my wording, not in substance.

> There are a number of ways such a mistake might be rectified to the mutual satisfaction of all relevant parties. Just stopping with distributing this package linking to readline potentially.
Nope. There is exactly one way to cure copyright violation in the GPL (Section 8) - complying with the license terms. Every other way will require settling with each copyright holder.

If you refuse to do that, the library author is thus entirely within their rights to sue for the max damage ($150k per copy, remember) even if you cease distribution of infringing package immediately. Well, OK. Technically paying up to $150k per copy _IS_ another way to comply with the license.

What I hate in GPL fanboys is their deceptive and misleading statements. Like "GPL doesn't force you to distribute code under GPL". It's technically true, but it's unlikely to matter for a proprietary software developer.

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Apr 1, 2016 10:26 UTC (Fri) by paulj (subscriber, #341) [Link] (5 responses)

You can comply with the licence simply by ceasing to distribute the infringing work. Which you can do by not distributing the combined, deriving work at all; or else by dropping the dependency on other people's code for whatever functionality either by removing the functionality or implementing it yourself. Your choice.

Note that that need _not_ affect the damage done to the copyright holder of that other code while you were infringing their rights, and they could still try recover those damages from you regardless of you having ceased to infringe their rights.

In no case are you ever forced to release your source code. However, can you still be held to account for infringing other people's rights? Yes, potentially.

Every software developer past their teens surely knows there are consequences to relying on other people's code, rather than writing it themselves?

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Apr 1, 2016 10:26 UTC (Fri) by paulj (subscriber, #341) [Link]

Oh, and there being consequences have nothing to do with free software particularly.

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Apr 1, 2016 10:36 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

> Note that that need _not_ affect the damage done to the copyright holder of that other code while you were infringing their rights, and they could still try recover those damages from you regardless of you having ceased to infringe their rights.
> In no case are you ever forced to release your source code.
Again, I wish people would top making deceptive statements.

Yes, nobody forces the source code release at gunpoint. The worst that could happen is a lawsuit for damages in ranges of tens of millions - that's certainly not "forcing" or anything. You are absolutely free to pay the settlement to each and every copyright holder of the affected library.

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Apr 1, 2016 10:40 UTC (Fri) by paulj (subscriber, #341) [Link] (2 responses)

If you use someone's else code, there are consequences.

You're like a child complaining there are consequences to stealing sweats from a shop, that you might be "forced" at "gunpoint" to hand them back. The injustice of it!

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Apr 1, 2016 10:57 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Did I say anywhere that I'm not aware about the license limitations or that complying with the license should not be mandatory? Please, do provide my quote.

> You're like a child complaining there are consequences to stealing sweats from a shop, that you might be "forced" at "gunpoint" to hand them back. The injustice of it!
Hmm.. Let me try to run my insult generator.

Ok, here it goes: 'These GPL hippies talk all the time about GPL because they want to have their code written by large companies, while paying nothing for it. They can't care less about actual users or the advancement of industry, all while sanctimoniously proselytizing about "freedom"'

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Apr 1, 2016 11:18 UTC (Fri) by paulj (subscriber, #341) [Link]

In an earlier comment you said that it was "not fair" that using the functionality of someone else's GPLed library should mean you have to comply with the licence of that library:

"It's not _fair_ that it should infect the whole code base."

--- Cyberax in http://lwn.net/Articles/681977/

That definitely sounds like you're complaining about having to comply with other people's copyright licences.

Pray tell, if I got hold of your closed-source code somehow and did whatever I wanted with it - sell it commercially (maybe with further code of my own), or GPL it - would you be fine with that?

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Mar 25, 2016 2:28 UTC (Fri) by aggelos (subscriber, #41752) [Link] (11 responses)

Oh, another unspoken (and false) assumption in "It [the GPL] can propagate" is that one would be legally bound to license whatever code they have distributed in a program which also constitutes a derivative of GPL code, under the GPL. In fact, they would just be prohibited from distributing their derivative of GPL'd code under terms which are not those the authors of the GPL part intended. Is that in some way unfair?

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Mar 26, 2016 7:35 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (10 responses)

> Oh, another unspoken (and false) assumption
No, it's a true assumption if a little bit simplified. If you distribute GPL-ed code then you also must distribute your source code.

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Apr 4, 2016 21:39 UTC (Mon) by Wol (subscriber, #4433) [Link] (9 responses)

Not at all. If you distribute GPL-d *BINARIES* then you must also distribute any of your source code that those binaries depend on.

Please, Cyberax, I've said before, PEDANTRY IS IMPORTANT. If I distribute GPL-d (source) code, I am under no obligation WHATSOEVER with regard to any of my own code.

Cheers,
Wol

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Apr 4, 2016 22:14 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

That is incorrect. Section 3 of the GPLv2 explicitly refers to section 2 which specifies:

> These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

Just distributing the source code doesn't let you get out of GPL's obligations.

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Apr 4, 2016 23:27 UTC (Mon) by pizza (subscriber, #46) [Link] (3 responses)

Since you're quoting the GPLv2 section 3, let's continue to its last paragraph:

"However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable."

I don't think it would be terribly controversial to consider anything in the iOS SDK a "system library" for purposes of the GPLv2. There's no inherent incompatibility with the GPLv2 and iOS any more than Windows or AIX or whatever is inherently incompatible.

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Apr 4, 2016 23:34 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Yes, correct. However, please re-read the message I've been answering to.

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Apr 5, 2016 1:44 UTC (Tue) by Wol (subscriber, #4433) [Link] (1 responses)

Yes, do please re-read it.

It's only if you distribute BINARIES that you are forced to distribute your own code.

If I distribute GPL'd *SOURCE* code (any code, mine, yours, Jo Bloggs's), I am under NO OBLIGATION WHATSOEVER to distribute my source code. Obviously, from the first sentence of this paragraph I may have *chosen* to distribute my code but that is a *choice*, not a *requirement*.

Hence I don't understand why you quoted section *3* of the GPLv2, which is explicitly about distributing binaries, which is why I was explicit about the fact I was distributing source. If I don't provide a binary, section 3 doesn't apply - it's totally irrelevant.

In fact, if I want to mix proprietary and GPL'd source code, and distribute the resulting program, the simplest way to avoid the GPL (provided I have the necessary licence to the proprietary code) is to distribute the whole lot as a source-only build system. That way, it falls under the "mere aggregation" state, and it's left to the end user to build the derivative work, which is perfectly legit.

Cheers,
Wol

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Apr 6, 2016 7:05 UTC (Wed) by hummassa (subscriber, #307) [Link]

well, actually, that would depend on your patches really NOT being a derivative work on the GPL'd parts in the legal sense of "derivative works" (as per 17 USC 101, for example, if the jurisdiction in casu was the USofA: <<A “derivative work” is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a “derivative work”.>>)

In my jurisdiction, the definition of a derivative work is even more nuanced (if your work uses the "mis en scene" of preexisting one it can be construed as a derivative work.) OTOH, my jurisdiction has additional "fair use" protections applicable to software (it renders, among other things, the "no virtual machines" clauses of EULAs null and void).

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Apr 4, 2016 23:45 UTC (Mon) by anselm (subscriber, #2796) [Link]

Just distributing the source code doesn't let you get out of GPL's obligations.

Yes, but whoever receives the combined source code under the GPL is free to take the not-derived, reasonably-considered-independent-and-separate bits and distribute just them under whatever licence is attached to them, without passing along the GPLed bits or subjecting the receipients to the GPL. For that matter they could replace the GPLed bits by independently-developed code under some other licence and distribute the result under whatever terms derive from that licence and the one of the non-GPL bits, without any obligations under the GPL at all.

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Apr 5, 2016 8:12 UTC (Tue) by paulj (subscriber, #341) [Link] (2 responses)

Wol,

I don't think you're correct. The GPL applies to _all_ the GPL source (and derivatives) whether you distribute a GPL work or source or binary form. If you distribute in binary form, there is just additional text around how to discharge your responsibilities re the source.

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Apr 5, 2016 9:27 UTC (Tue) by Wol (subscriber, #4433) [Link] (1 responses)

iirc (I haven't gone back to check) I think my responsibilities are limited to ensuring the recipient can tell the difference between my code and someone else's?

Beyond that, if I distribute *as source*, I can pretty much ignore what the GPL says because the act of handing over the source fulfils my obligations, no?

(So I'm not saying the GPL doesn't apply :-) I'm saying the requirements are so trivial that it would be hard work NOT to comply :-) I believe some companies have succeeded, though, with either that or the MIT licence!)

Cheers,
Wol

Rust's Redox OS could show Linux a few new tricks (InfoWorld)

Posted Apr 5, 2016 9:44 UTC (Tue) by paulj (subscriber, #341) [Link]

So, the scenario you have in mind isn't 100% clear, but from:

http://lwn.net/Articles/682463/

it seems possible you think that as long as you distribute the source of the GPL code that you use in your programme under the GPL, that you can then do what you like with your "own" code (i.e. that code typed directly by you), as long as you don't distribute binaries of the whole thing. E.g., I assume that therefore you think you could distribute your own source code under what ever licence you wish, because your own source code could never derive from that other GPL source code.

My understanding from lawyers is that that need not be correct. Source code you have typed yourself can still derive from other source code. So your "own" source code could derive from the GPL source code, and so if you distributed that "own" code you'd have to honour the GPL licence of the other source code it derives from - even if distributed in source form.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds