Two approaches to tightening restrictions on loadable modules
When the static kernel image is linked, references to symbols (the names of functions and data structures) are resolved using the entire global namespace. Loading a module also involves a linking step, but modules do not have access to the full namespace; instead, they can only access symbols that have been explicitly exported to them. There are two sets of exported symbols: those that are available to any loadable module, and those that are only available to modules that declare a GPL-compatible license. Access to symbols is the primary means by which the capabilities of loadable modules are limited, so it is not surprising that both patch sets make changes to that mechanism.
Restricted namespaces
For most of the kernel's existence, there has been a single namespace to hold all of the symbols available to a loadable module; that namespace only contains the GPL-restricted symbols if the module is appropriately licensed. In 2018, the kernel gained a symbol namespacing capability that can segregate some symbols and restrict their availability to modules that explicitly import the relevant namespace. This feature was meant to (among other things) make abuses (modules accessing symbols that they should not) more evident, but it has no access-control capability; symbols can still be made available just by importing the namespace that contains them.
There has long been a wish, though, for the ability to export symbols for use by a specific module, but no others. This patch from Peter Zijlstra adds that feature. In current kernels, a symbol is exported into a specific namespace (call it foo) with a declaration like:
EXPORT_SYMBOL_NS_GPL(symbol_name, foo);
Any module that contains a line like:
MODULE_IMPORT_NS(foo);
can then access the symbols exported into that namespace. Zijlstra's patch adds a tweak to the export declaration. To export a symbol that is only available within the module called foo, the declaration would be:
EXPORT_SYMBOL_NS_GPL(symbol_name, MODULE_foo);
This creates a namespace with a couple of special properties. When a module named foo is loaded, this namespace will be implicitly imported; there is no need for a MODULE_IMPORT_NS() declaration. And, in fact, any attempt to import a namespace whose name starts with MODULE_ will be blocked. The end result is that the symbol is available to foo, but to no other module.
In the discussion, nobody argued against the addition of this capability. There were a few thoughts on the syntax. Luis Chamberlain, the module-loader maintainer, suggested that a separate EXPORT_SYMBOL_GPL_FOR() syntax might be preferable to the MODULE_ convention; he also said that it would be useful to be able to export symbols to more than one module.
Masahiro Yamada, the maintainer of the kernel's build system, said that it would be better for the namespace name to be a C string rather than a bare name. That would eliminate some ambiguities within the kernel code; it would also be possible for that string to be a comma-separated list of target modules. That would be a big change, as was demonstrated when Zijlstra took a stab at it: the resulting patch touched 847 files.
It seems likely that the quoted-string approach will be favored going
forward, though. Zijlstra has put together a
version of the patch that supports exporting to multiple modules using
that syntax. It "seems to work with very limited testing
", but has
not yet been reposted to the list. The posting can
be expected soon if all goes well, but chances are that this work is a
bit too late to make it into the 6.13 kernel release.
When "GPL" is not GPL
Meanwhile, a separate patch is taking a rather different approach to the problem of inappropriate access to symbols by loadable modules. The kernel is licensed under version 2 of the GNU General Public License, and no other. When the Free Software Foundation created version 3 of the GPL, it was made incompatible with version 2; the kernel community declined to switch to the new license, and so cannot accept code that is licensed under GPLv3. So one would not normally expect to see device drivers (or other kernel modules) released under that license.
It turns out, though, that Tuxedo Computers maintains a set of device drivers for its hardware, and those drivers are indeed licensed under GPLv3. In the MODULE_LICENSE() declaration within those modules, though, the license is claimed to be "GPL". As a result, these modules have access to GPL-only kernel exports, even though they do not have a license that is compatible with the kernel's.
This situation has been in the open for some time, but it was only brought
to the foreground after this
research from Thorsten Leemhuis pulled it all together. Neal Gompa pointed
it out in 2020 and asked for a relicensing to GPLv2. The discussion
has resurfaced a few times since then, but the company has refused to make
that change. Earlier this year, Tuxedo's Werner Sembach made
the company's position clear: "We do not plan to relicense the
tuxedo-drivers project directly as we want to keep control of the upstream
pacing
". In other words, the incompatible license is a deliberate
choice made by the company to keep its drivers out of the mainline until
a time of its own choosing.
The licensing decision may be a bit strange, but it is certainly within the company's rights. Declaring a compatible license to gain access to restricted symbols is not, though. In response, Uwe Kleine-König has posted a patch series that explicitly blocks the Tuxedo drivers from accessing GPL-only symbols. With this patch in place, those drivers will no longer load properly into the kernel and will stop working.
The response to the patch has been generally (if not exclusively)
positive. But Sembach, unsurprisingly, is
not a fan. According to him, the situation is the result of
understandable confusion: "We ended up in this situation as
MODULE_LICENSE("GPL") on its own does not hint at GPL v2, if one is not
aware of the license definition table in the documentation
". The
licensing situation is being worked on, he said, and will eventually be
resolved.
If the company truly intends to work things out in good faith, it would almost certainly make sense to hold off on explicitly blocking its modules while that work proceeds. Given how long this problem has been known, though, and given the company's deliberate use of license incompatibility to retain control over its code, convincing the development community of its good faith may be difficult. That hasn't kept Sembach from trying; he has relicensed some of the modules in question, and promises to change the rest as soon as possible.
That is a step in the right direction, but there is no fury that compares
to that of a kernel developer who feels lied to about module licensing.
Kleine-König has indicated
his intent to try to merge the patch during the 6.13 merge window. Then,
he said, if the licensing issue is fully resolved, "you have my support
to revert the patch under discussion
". Whether things will truly go
that far is unclear; if Tuxedo is working to resolve the problem quickly,
there will probably be little appetite for merging a patch punishing the
company in the meantime. It seems unlikely, though, that Tuxedo will
attempt this particular trick again, and any others considering it have reason
to think again.
| Index entries for this article | |
|---|---|
| Kernel | Copyright issues |
| Kernel | Development model/Loadable modules |
| Kernel | Modules/Exported symbols |
Posted Nov 15, 2024 19:54 UTC (Fri)
by Heretic_Blacksheep (subscriber, #169992)
[Link]
Posted Nov 15, 2024 21:02 UTC (Fri)
by dskoll (subscriber, #1630)
[Link] (4 responses)
In retrospect, it would have been better to explicitly declare everything
Posted Nov 16, 2024 9:29 UTC (Sat)
by matthias (subscriber, #94967)
[Link]
Posted Nov 18, 2024 20:32 UTC (Mon)
by andy_shev (subscriber, #75870)
[Link] (2 responses)
Posted Nov 18, 2024 23:23 UTC (Mon)
by rhbvkleef (subscriber, #154505)
[Link] (1 responses)
Posted Nov 19, 2024 0:41 UTC (Tue)
by Wol (subscriber, #4433)
[Link]
???
"2.0 or later" means the distributor can choose which licence to use. Which means they can distribute the kernel under 2.0, AND THEY CAN DISTRIBUTE THAT MODULE UNDER 2.0.
To be even more pedantic, they can NOT distribute that module under "2.0 or later" because that is not a licence!
> or be relicensed to GPL-2.0-only.
And no, that module can't (in all likelihood) be relicenced. Under normal circumstances (true of pretty much EVERY Free licence), the only person who can relicence code is the person who owns the copyright.
Copyright 101 - in order to copy and distribute code, you need a licence.
Cheers,
Posted Nov 15, 2024 22:56 UTC (Fri)
by SLi (subscriber, #53131)
[Link] (10 responses)
There's a nuance here that I feel people often miss. While companies are legally sort of atomic entities, in reality they consist of humans. In this case, it seems to me that there is genuine confusion on part of the developer who's been talking for them, and of course the original intent and views of others may again be very different.
I've seen some larger companies from inside, and I'd say it's almost always a mistake to attribute any coherent intent or agency on them (like "Google is evil"). At best they have a... tangent, a direction where they seem to be heading. Look at the big companies we know best. They cannot even prevent themselves from firing people doing good work and killing profitable products in a way that seems random at best.
Here I gather we have a smaller company. In this case, while it's deplorable that people look at Nvidia and assume doing the same is fine, I think that *is* an understandable mistake, and it should be forgivable if you are willing to be corrected and not keep doing Nvidia.
In this case, I think it may even have been the case that the GPLv3 licensing was done BOTH 1) to control upstreaming and 2) in the mistaken belief that it is legally and culturally/ethically acceptable—as ridiculous as that may sound to us who are too deep in these things.
Now I'm no fan of companies circumventing open source licenses—and never imagined defending one!—but I think we should stop pretending that anyone doing this is likely aware they are doing so (albeit I'd assume many transition from "not aware" to "too invested to change"). Mastering programming, open source culture and law is a high bar.
I do also find it a bit sad that we seem to normalize the (American?) culture where it is assumed that if you are a company and doing anything at all, lawyers, and other similarly unproductive layers of bureaucracy, should be involved, as was suggested on lkml. That's an unnecessarily high bar for open source involvement. I don't want open source collaboration to have a lawyer as a requirement. Realistically also probably in most countries it isn't. In this case, I think the company needs to talk to one if it wants to keep doing what it has been doing, but if it has understood there is a problem and is working to fix it, I'm just not sure hiring a lawyer is in any way fruitful.
It's probably also healthy to recognize that it's a big ask from a single developer that they not revert a patch that changes "GPL v3" back to GPL if that breaks things. I know, in beautiful theory (and if you have billion dollar judgments), you never do anything until you have figured out the licenses. In practice, a programmer just does not get to be the guy who merged the patch that broke the product and didn't revert, and probably this is also the route of least risk for companies in most countries where justice is focused on righting wrongs, not making examples and enriching lawyers. Although he should have tested the patch that changed it to GPL v3...
NOW, I would still consider this still quite separate from what the kernel community should do about this. I feel it's quite reasonable to apply some pressure, such as in the form of that patch. But I think the assumption of hostile intent should be reevaluated at times.
Posted Nov 16, 2024 0:29 UTC (Sat)
by npws (subscriber, #168248)
[Link] (8 responses)
Posted Nov 16, 2024 2:26 UTC (Sat)
by viro (subscriber, #7872)
[Link] (2 responses)
Pulling stunts in that area _without_ a good legal help... ouch. Darwin Award material, that.
I'm not talking about the guy who'd ended up buried under that mess and probably cursing any number of people and PHBs right now. Mess is not of his making, and it's entirely possible that he'd assumed that whoever made the decision back then must've checked what they were doing. Always a bad assumption, but... I can see how _not_ asking for details could've been very tempting.
I *do* wonder what the original rationale had been - if nothing else, it promises not a small amount of schadenfreude towards the "spirit of GPLv3" True Believers.
Posted Nov 16, 2024 14:23 UTC (Sat)
by kleptog (subscriber, #1183)
[Link] (1 responses)
I'd not expect that at all. My experience is that questions about open source licensing leads to lots of blank stares when you ask the legal department, assuming you even have one. They specialise in contract law, that's their daily job. Generally there's one or two employees who think open source licensing is important enough and eventually it lands on the desk of the owner/founder (it's a privately owned company after all) and they make a business decision based on the perceived risks.
Would any of this reasoning be documented? Unlikely, it eventually becomes lost in the mists of time. Does that mean mistakes happen? Of course. Running a business means making mistakes. Does that mean we should send the rampaging hordes at any company for any mistake? No, because sometimes it's just an honest mistake and in much of the world, honest mistakes are not overly punished as long as you take steps to correct them. Which from what I see they are doing.
Entrepreneurs are used to taking decisions based on incomplete information. Lawyers are expensive, so you don't want to engage them for small fry.
Posted Nov 25, 2024 10:49 UTC (Mon)
by LtWorf (subscriber, #124958)
[Link]
Posted Nov 16, 2024 19:01 UTC (Sat)
by NYKevin (subscriber, #129325)
[Link] (4 responses)
(Hypothetical and general discussion of law does not count - it's only legal advice when you apply the law to a specific factual scenario that actually exists, recommend some course of action in response to those facts, and do so in a way that the recipient of the advice would reasonably understand as applicable to them in particular. While "you should talk to a lawyer" might be construed as advice, it is very general and fact-independent, and more importantly, the whole point of licensing is to encourage people to get advice from lawyers instead of laypeople, so it is very much in the spirit of the restriction to tell them that explicitly.)
Posted Nov 16, 2024 20:45 UTC (Sat)
by SLi (subscriber, #53131)
[Link] (3 responses)
Posted Nov 16, 2024 22:24 UTC (Sat)
by randomguy3 (subscriber, #71063)
[Link] (2 responses)
Posted Nov 17, 2024 0:17 UTC (Sun)
by SLi (subscriber, #53131)
[Link] (1 responses)
I also think that in most of those jurisdictions the rule is more like you're not allowed to 1) present yourself as qualified in law; 2) provide legal opinions for compensation (albeit I'm actually not sure if this applies in all contexts; I think a company may be allowed to hire someone who it believes is familiar with an area of the law to work on that stuff); 3) represent others.
Posted Nov 17, 2024 12:16 UTC (Sun)
by Wol (subscriber, #4433)
[Link]
And rather importantly, what does that mean? In the UK people who are NOT lawyers - who have no formal qualifications IN LAW - are also required by law to present legal opinions. In particular to LARGE corporations!
Okay, they are required to be formally qualified, and that qualification will almost certainly include the law as a required minor, but they are neither qualified nor licenced to practice law.
In the UK at least, all associations are supposed to include, as part of their governing structure, a Secretary. Above a certain size, these people have to be formally qualified, be it as a Secretary, Accountant, Lawyer or whatever. And these people are the ones held liable for the lawful behaviour of the company! As a Company Secretary, you are the person legally liable for the misbehaviour of the company you represent, and you could go to jail for it! Highly unlikely, but it's in the Statutes.
Cheers,
Posted Nov 21, 2024 15:04 UTC (Thu)
by ukleinek (subscriber, #56625)
[Link]
Yes, initially I didn't consider 2). If I had, I would have approached the issue in a slower way.
In retrospect I'm happy that Werner now managed to completely relicense the Tuxedo driver package to GPLv2+ and my suggested patch won't need to be applied.
Uwe
Posted Nov 16, 2024 13:41 UTC (Sat)
by quotemstr (subscriber, #45331)
[Link] (38 responses)
Practically speaking, the virality across dynamic linking is illusory. Plenty of programs link to readline without themselves being GPL and nothing goes wrong. The MIT Julia REPL has linked against readline for a long time. ZFS gets loaded into Linux. Nobody is afraid of getting sued.
So why should anyone think there's anything legally or socially wrong with modules marking themselves as GPL for symbol resolution purposes while not being licensed under the GPL themselves? IMHO, interfaces should be exported or not and the whole concept of exporting interfaces only to software under specific licenses --- especially if the restriction isn't reified into actual license text --- is silly.
Posted Nov 16, 2024 16:42 UTC (Sat)
by Baughn (subscriber, #124425)
[Link] (2 responses)
Posted Nov 16, 2024 17:44 UTC (Sat)
by viro (subscriber, #7872)
[Link] (1 responses)
And exports are really, really not something one could describe as an API - it's a huge pile of random functions and variables some module had found convenient to call at one time or another. It's more than one order of magnitude past anything sane and it had been for decades. Ironically, the same crowd that comes a-whining about stable in-kernel ABIs is going to scream bloody murder if somebody tries to reduce that pile of shit to something that might be described as an interface. For that to be even remotely similar to relationship with a dynamically linked library we'd need to stop exposing the internals to such extent; it's far more than any sane library would and that stretches the comparison way past the breaking point.
Licensing or not, we really need to get the exports surface into a saner shape; namespaced exports are interesting precisely because they allow some moves in that direction.
Posted Nov 16, 2024 18:15 UTC (Sat)
by quotemstr (subscriber, #45331)
[Link]
One should design programming interfaces with an eye towards how the ecosystem will use them. Declaring that something isn't an interface or an API when it looks like an API, walks like an API, and quacks like an API just makes it harder to fix the warts in the API surface. Doing so denies problems instead of fixing them.
Blacklisting an out of tree module *by name* in the core kernel crosses the line between encouraging collaborative development and outright user hostility. Wanting to do so is a signal that some user have unmet needs. Going out of the way to make it harder to satisfy these needs isn't the way. If I were packaging a distro kernel, I'd patch out the blacklist.
Posted Nov 16, 2024 17:16 UTC (Sat)
by khim (subscriber, #9252)
[Link] (4 responses)
How is it different from using cracked MS Office or MS Windows? I know plenty of people who have been doing that for years. And many Chinese gadgets include stolen code, too – does it mean licenses no longer matter at all?
Posted Nov 16, 2024 19:12 UTC (Sat)
by NYKevin (subscriber, #129325)
[Link] (3 responses)
I don't believe a court has ever addressed this question. In the US, they would likely use some variation of the Abstraction-Filtration-Comparison test. I'm not going to go into the details here, but any search engine will reveal that that test is highly complex and somewhat difficult to understand. It strikes me as rather implausible, given this framework, that a court would issue a bright-line ruling about whether or not dynamic linking is copyright infringement in all scenarios. The far more plausible answer is a very complicated "it depends."
Posted Nov 16, 2024 19:22 UTC (Sat)
by khim (subscriber, #9252)
[Link] (1 responses)
I agree with your but that's very different argument from “People are doing something, nobody is afraid of getting sued, therefore something is legal”. Protecting copyrights if very different from trademarks. You have to fight for your trademark abuse, or you may risk losing it. But you can sit it your copyrights, watch how people are abusing them for years, even decades – then sue only when it becomes profitable for you. Heck, Microsoft was using this tactic very successfully to establish Windows as the desktop OS and only started aggressively suing large companies when it was sure it would be profitable. Why should it work with GPLv2 or GPLv3 any differently?
Posted Nov 16, 2024 21:06 UTC (Sat)
by NYKevin (subscriber, #129325)
[Link]
In the case of Readline, the only commonality between the binary and the library is a set of linker bindings, which is both machine-generated (from Readline's source) and highly functional (i.e. most if not all of these functions could not usefully have any other signature). It is not at all obvious that Readline's linker bindings can escape the merger doctrine and/or 17 USC 102(b), and if they do not, then they necessarily get removed in the filtration step of the AFC test and there can be no infringement. Furthermore, this argument is intuitively obvious enough that you don't really need all the legal jargon to make it (it is enough to just point out that the linker bindings are functional and non-expressive, and the rest is just the details of how a court would phrase the rest of the opinion). So when the original comment says the following:
> Plenty of programs link to readline without themselves being GPL and nothing goes wrong.
...they are not literally arguing that the lack of enforcement is by itself a guarantee of no future enforcement. They are instead arguing that there is nothing to enforce in the first place, that the FSF knows or should know that, and thus there will most likely be no future enforcement either.
ZFS is a far more complicated case and I don't pretend to understand all the nuance. I'm not going to sit here and argue that ZFS is definitely infringing or non-infringing, but I will say that the lack of enforcement has been going on for long enough to constitute a norm (especially after Canonical decided to start shipping Linux-with-ZFS and nothing happened other than a couple of conflicting blog posts from SFC and SFLC).
Norms are not laws, and the Linux developers could change their collective stance (or individual stances) on this at any time, but norms are an important part of the system if you don't want to go to court all the time. I have seen quite a few FOSS developers simultaneously insist that their copyrights should be respected, but also state they will not be suing anyone in relation to those copyrights. The only way that can possibly work is when respecting copyrights is a norm within the FOSS community.
The treatment of dynamic linking under the GPL is another norm. It has no legal precedent one way or the other, aside from the tangentially relevant Oracle v. Google (disclaimer: I work for Google), which has opened the door to arguments of the form "APIs are subject to weak or no copyright, the API is the only thing in common between the binary and the library, the binary uses the API for a purely functional purpose which further weakens any copyright that might apply, and therefore the binary probably does not infringe on the library." But since nobody wants to go to court and run that argument up the flagpole, all we've got to go on is the norm that dynamic linking is subject to GPL formalities. If that norm is not actually a norm anymore, then sooner or later, somebody (who has adequate lawyers and/or money) is going to decide that they don't have to comply with it, and then what happens?
Posted Nov 16, 2024 20:49 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
There's two other arguments here, which you're missing, and why a black-list in the kernel is not an acceptable enforcement mechanism ...
The nVidia argument is that their driver was written for a non-linux, therefore cannot be a derived work. The shim, written for linux, IS a derived work, therefore it is licenced as GPL.
The readline argument is that the package author linked against the BSD version, therefore once again their program is not a GPL-derivative, and if the end user dynamically links the program to the library, the GPL itself explicitly DISclaims its application ...
That's why I think the GPL is a rubbish licence (for me) - the *normal* state of affairs for my language-of-choice is - apart from ensuring my code can't get locked up - it's a waste of space. In practice very little difference between it and the MPL.
(In DataBASIC there is a one-to-one relationship between source and binary files, and they are loaded(linked) at runtime. Not a lot of difference to applying the GPL to shell scripts.)
Cheers,
Posted Nov 16, 2024 22:08 UTC (Sat)
by dvdeug (subscriber, #10998)
[Link] (28 responses)
I'm sure that NYKevin is right in saying
>It strikes me as rather implausible, given this framework, that a court would issue a bright-line ruling about whether or not dynamic linking is copyright infringement in all scenarios. The far more plausible answer is a very complicated "it depends."
Then what? Java is a bright line case, as it's a clear API for external use and Java puts the two parts as separate as possible. Many C and C++ libraries are going to embed part of themselves in the binary in the form of complex macros and templates. You can't distribute the binary without distributing part of the library.
It's frustrating that people want to tear down this ability of Free licenses. This is not a problem for commercially licensed software, in most cases. You'd have to find a library that's already going to be on a user's system and use it to distribute software linked to a commercial library. Even then, the commercial software owners usually have licenses you agreed to to install the library and dev files on the development machine. So it's the Free software people who don't want to force everyone to agree to a license, who give away the software for free, that people want to take advantage of.
> So why should anyone think there's anything legally or socially wrong with modules marking themselves as GPL for symbol resolution purposes while not being licensed under the GPL themselves?
I certainly think there's something socially wrong with taking someone's gift and ignoring the terms under which it was given. If you want a system where you can load any modules, use a BSD kernel (without any GPL modules, since there are a few of those). Certainly don't use MacOS, since Apple uses cryptographically secure measures to prevent random modules from being loaded in the kernel, and doesn't give that power to just everyone. (I think Windows is the same way, but I'm not sure.) If the creators of a GPL kernel label some items as an external API for anyone's use, and other items as GPL hooks for functionally internal code loaded externally, respect that.
Posted Nov 17, 2024 12:31 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (27 responses)
> t strikes me as rather implausible, given this framework, that a court would issue a bright-line ruling about whether or not dynamic linking is copyright infringement in all scenarios. The far more plausible answer is a very complicated "it depends."
Personally, I think a court *would* issue a bright-line ruling "dynamic linking is NOT copyright infringement". This is where the use of the correct words is extremely important!
"2. Basic Permissions.
All rights granted under this License are granted for the term of copyright on the Program, and are irrevocable provided the stated conditions are met. This License explicitly affirms your unlimited permission to run the unmodified Program. The output from running a covered work is covered by this License only if the output, given its content, constitutes a covered work. This License acknowledges your rights of fair use or other equivalent, as provided by copyright law."
Dynamic linking occurs when you run the program! The GPL gives you "unlimited permission" to run the program!
So the question becomes "does the BSD version of the readline headers infringe the copyright of the GPL readline headers". Nothing to do (legally) with dynamic linking, at all!
Which is, of course, why this example is so complicated :-) And also when the FSF wrote the (L)GPL, they recommended the use of LGPL in general for libraries, otherwise people would use the proprietary/permissively licenced libraries to write code, and end-users wouldn't bother swapping them for the GPL versions. Especially if, as very likely, the software authors would close bugs with "use the same library as us".
Cheers,
Posted Nov 17, 2024 20:15 UTC (Sun)
by dvdeug (subscriber, #10998)
[Link] (21 responses)
If you're being pedantic, a court would never issue that ruling, and would never be asked to rule on the question.
> So the question becomes "does the BSD version of the readline headers infringe the copyright of the GPL readline headers". Nothing to do (legally) with dynamic linking, at all!
No. This whole article is about the kernel, not readline. Use the correct words. One question is, is code that is written to function as part of a program that is dynamically linked to the program automatically not a derivative work? I'm sure the court would say no. Then we get all the discussion about external module APIs, where the lawyers might argue that an API marked GPL is not an external module API, because it's clearly marked as only be usable by internal modules.
Note that the deep issue here with "dynamic linking is NOT copyright infringement" is that a Free program can always be rewritten into the form of a dynamic library, or to accept the new code as a dynamic library. At that extreme, the GPL becomes virtually meaningless.
Posted Nov 17, 2024 20:30 UTC (Sun)
by quotemstr (subscriber, #45331)
[Link] (1 responses)
Posted Nov 19, 2024 1:32 UTC (Tue)
by dvdeug (subscriber, #10998)
[Link]
I think the the court would at least acknowledge that there was an API for everyone and certain symbols that were only designed to be accessible to modules that could be part of the kernel.
Posted Nov 17, 2024 20:43 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (18 responses)
But that linking is still done by the END USER, so as per the GPL it is NOT COPYRIGHT INFRINGEMENT.
As was debated in the Google/Oracle case, the issue is "Can you copyright an API?" In order to convert a program to a dynamic library you need to have an API, otherwise you cannot link it. If you modify a GPL program to *create* an API, then the argument is that the API is a derivative of the GPL program and therefore covered by the GPL. In the nVidia case the API was clearly created for other programs to call the driver, so the API is clearly not a derivative (that's why nVidia don't distribute the kernel and driver together - it avoids any possible argument).
In the Java case, it's estoppel and all sorts of wotnot - the API was explicitly intended to be freely used.
In the readline case, it's very likely that the API is not copyrightable.
But as far as dynamic linking goes, unless you can come up with a scenario where it is not the end user who actually links the program to the library (or loads the module into the kernel), then as per the GPL itself dynamic linking CANNOT be a GPL violation.
> At that extreme, the GPL becomes virtually meaningless.
As far as I'm concerned, it is. If I GPL my code, downstream cannot distribute it as object without binary, but if their code calls mine, they can use any licence they like ... BECAUSE it's the end user that does the act of linking!
Cheers,
Posted Nov 17, 2024 21:49 UTC (Sun)
by quotemstr (subscriber, #45331)
[Link] (11 responses)
So what if I statically link my proprietary program to a GPLed library? When I distribute the resulting binary, I'm independently distributing my own code (which I have the right to do) and distributing the GPLed library (which I have the right to do), and that the two are combined into a single ELF file is irrelevant. If I instead put my dynamically linked binary and a .so in a zip file and redistribute that instead of a statically linked binary, have I done something meaningfully different? At what point exactly does mere linking have legal significance?
Keep in mind that the normative text of the license is agnostic with respect to linking technology and that this whole distinction doesn't apply to languages like Java and Python that use entirely different linking methodologies. If I jarjar together a GPLed class file and a proprietary one, what would the result be?
Given all the open questions and contradictions, I have a hard time seeing how the FSF maximalist interpretation can be correct. I wouldn't feel particularly afraid linking, statically or not, a GPL incompatible program to readline.
Posted Nov 17, 2024 23:19 UTC (Sun)
by khim (subscriber, #9252)
[Link]
When you are distribution something which includes both GPL code and non-GPL code. I still couldn't understand why people are discussing ununteresing and entirely irrelevant case where non-GPL code is distribution without GPL code. It's your you code, it can be distributed on any terms that you may ever invent. As long as nVidia drivers are distributed as something that is not compiled and they are not distributed together with Linux kernel, itself – there are no issues. But when you distribute them together… it's different story Why does it even matter? Because copyright was originally developed for books. And if you plan to distribute two works from two different authors you need permissions from all three entities: Alice, Bob, and Carol (anthology compiler: yes, Carol gets separate copyright and can write separate license, too). Now, if Alice doesn't want to say something secret to Bob (as she usually does), but, surprisingly, doesn't even want to be publishing under the same cover as Bob (because they had huge fight and don't want to see each other ever again)… then Carol couldn't publish such book if licenses that Alice and Bob have given Carol are precisely such license that demands that they would be only ever published in separate books. And that is where linking (static or dynamic) becomes important: GPL is designed to disallow proprietary extensions and demands that if you want something then the whole work should be licensed on GPLv2 terms: 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. As you can see that question that Wol wants to be bright-lined… it's already answered by GPL itself: MIT Julia REPL module, proprietary nVidia module, ZFS with it's anything-by-GPL license… as long as they are distributed without GPL components… GPL gives them quite explicit right to use some other license. It would have, probably, been illegal for GPL to try to restrict such distribution – but it doesn't even try: if you are distributing something that can be used with GPLed component but doesn't include that GPLed component… it's all fair game and you can use anything you want. You only have the right to distribute GPL library if you provide source for “the whole work” on the GPL-compatible terms. Which, of course, immediately raises the question of what is “the whole work”. Stallman famously made Steve Jobs to do that with NEXT Objective C compiler. And there were other similar cases. Nothing ever reached the court, but I don't think anyone would say that these two pieces are not parts “of the whole work” is they are mixed together so tightly that it's essentially impossible to pry them apart. Static linking is explicitly a tool that creates one, single, “whole work” from independent components, you would have to argue that people that invented it were idiots, to claim that what you are distributing is not “the whole work”. These the questions, aren't they? At what point border between your program and dynamic library becomes thick enough for someone to credibly claim that no, these two things are no longer part of “the whole work”, these are two independent pieces, usable without each other? I would suspect that it would strongly depend on the type of API that your library uses. E.g. if you library is separate dinamic library, but it doesn't even expose any symbols, but instead you have tool that creates offsets of the interesting data structures and these are, then, used in C64-era PEEK/POKE interface that directly embeds knowledge about layout of your library into some proprietary program and where any minor change to the library would render said program usable… I don't think anyone would say that these are still separate works. But if your API is very simple and non-invasive (e.g. if you library just accepts text strings that it interprets and returns text strings as it's output and doesn't need to touch anything in your program) – then it would be separate work, definitely. It's not materially different from simple execution of external program. And that is where all these symbols, marks and everything start to become important: when you plan to distribute both GPLv2-licensed kernel and some modules simultaneously… IOW: precisely in a situation of Tuxedo Computers laptop!
Posted Nov 18, 2024 12:18 UTC (Mon)
by paulj (subscriber, #341)
[Link] (9 responses)
I think this statement is largely correct, but not for the reason you think it is.
I've heard different things from different lawyers, but the one thing I do not hear from them is any kind of reasoning that rests on the technical details of how two works are "linked". The opinions rest on legal details and interpretations. Approaching these questions like a programmer, where you think that some programmer meaningful boundary must of itself be meaningful to lawyers is... not at all safe. The lawyers do not care a jot.
> I have a hard time seeing how the FSF maximalist interpretation can be correct.
Here's another funny thing, the most "maximalist" interpretations I've heard from lawyers, are from corporate counsel at large tech companies - who aren't per se fans of the GPL, and do not really have an interest (as a corporate overall) to argue for the GPL being super strong. This is why the large corporates I'm familiar with generally have very strict rules on avoiding incorporating GPL code into their code-bases - and/or quite extensive review processes to get permission to use GPL code. You can see this in the behaviour in a number of large tech corporates, where they have rewritten functionality so as to be able to remove GPL code.
Conversely, some of the /least/ maximalist interpretations I have heard argued, have been from lawyers firmly in the Free Software world. Including very well-known ones.
Posted Nov 19, 2024 0:05 UTC (Tue)
by NYKevin (subscriber, #129325)
[Link] (8 responses)
While the corporation's overall interest may prefer a weak GPL, the interests of the corporate lawyers are much more straightforward: "don't get sued." This is also why big companies (such as my employer[1]) dislike the AGPL: They feel that the uncertainty around the license's boundaries is not worth any potential upside in terms of available software. While I have read and sympathize with Drew DeVault's response[2] to this, the reality is that lawyers are in the business of risk mitigation, not FOSS maximalism. If there is any reasonable likelihood that the license can be interpreted in a given way, the lawyers have to consider the possible consequences of that interpretation.
I also feel obligated to point out that, on a completely literal reading of AGPL 3.0 §13, you can violate the license just by writing code that the license disagrees with ("[...] if you modify the Program, your modified version must [...]"), even if that code is never compiled or executed. I find it difficult to imagine how a large tech company is supposed to comply with that extremely strict interpretation of the license, unless we're to presume the company exercises pervasive oversight over every single version of the code that is ever created for any purpose, including local debugging and experimentation. Drew would presumably argue that I'm being unfair and overly literal, but again this is a case of risk mitigation. The license does not *say* that there is an exception for local debugging and experimentation, nor an exception for code that is never exposed to external users, so as far as these lawyers are concerned, an unmentioned exception is no exception at all.
[1]: https://opensource.google/documentation/reference/using/a...
Posted Nov 19, 2024 21:31 UTC (Tue)
by nix (subscriber, #2304)
[Link] (7 responses)
I would guess an assumption that purely local stuff doesn't count as distribution or copying, and thus the license never kicks in anyway. This is, of course, not true in jurisdictions such as the UK, where *all* copies require licensing, even temporary copies in memory, and there is no concept of fair use -- but I think it safe to say that this sort of stuff is utter nonsense that is impossible to comply with, and can and must be ignored, given that questions have been asked in Parliament back in the 2000s to find out how many MPs had committed an act of copyright violation on account of such terms within the last week without realising it (I think at the time it was through using an iPod and/or mobile phone music playback?) and, yes, a great many of them had, including many members of the then cabinet. (Of course, nothing was done.)
Posted Nov 20, 2024 2:22 UTC (Wed)
by NYKevin (subscriber, #129325)
[Link] (4 responses)
Any sentence starting with "I would guess" will cause corporate lawyers to run screaming in the other direction. They don't want to guess. They want the license to make specific assurances.
As far as US law is concerned, there's nothing in the law that gives a blanket exemption for distribution or copying. But it's worse than that. 17 USC 117 contains a set of narrow exceptions for:
* Copying a binary into RAM in order to execute it.
If you need a specific exception in the law for activities as benign as all those, it is obvious that you also need an exception for any other purely local copying (which does not otherwise fall within the scope of an exception).
Posted Nov 20, 2024 12:20 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (2 responses)
I can't imagine an individual suing, but Trading Standards would certainly be interested ... selling software would pretty much certainly include an implied licence to be able to use it, no?
Cheers,
Posted Nov 20, 2024 12:26 UTC (Wed)
by nix (subscriber, #2304)
[Link] (1 responses)
Posted Nov 20, 2024 15:41 UTC (Wed)
by Wol (subscriber, #4433)
[Link]
I would have thought the reason everyone trying it in the UK settled before the case went anywhere, would be because the victim screamed "Scam!" and plaintiff decided discretion was the better part of valour.
As a private individual, I'd demand my money back under SOGA, and while that doesn't apply to businesses I can't imagine a judge looking favourably upon similar shenanigans against a business.
Cheers,
Posted Nov 20, 2024 12:24 UTC (Wed)
by nix (subscriber, #2304)
[Link]
*I* would guess because I'm not psychic nor a lawyer and I'm not writing for corporate lawyers (unless in fact this is a forum full of corporate lawyers and I never noticed).
Posted Nov 20, 2024 12:14 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (1 responses)
Note that the GPL explicitly covers this - that section 2 I quoted gives the *end user* a licence to do whatever they like. So the GPL at least, *does* kick in - it says "you can ignore me and do what you like". (Until you try to "convey propagate or distribute" ...)
Cheers,
Posted Nov 20, 2024 12:27 UTC (Wed)
by nix (subscriber, #2304)
[Link]
Posted Nov 19, 2024 1:25 UTC (Tue)
by dvdeug (subscriber, #10998)
[Link] (5 responses)
This is irrelevant. You can not distribute a sequel to someone else's book, because it's a derivative work. What makes code legally a derivative work of other code? There hasn't been a lot of case law about it, but I'd certainly argue that new code that intricately connects to data structures and functions in old code, in a way that's very distinctive, would be a derivative work.
> As far as I'm concerned, it is. If I GPL my code, downstream cannot distribute it as object without binary, but if their code calls mine, they can use any licence they like ... BECAUSE it's the end user that does the act of linking!
But that's your code. The idea that proprietary software does and can block any such thing, often going to the extents of having end users sign huge EULAs, but free software can't restrict itself being used as part of another non-free program.
Posted Nov 19, 2024 9:23 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (4 responses)
> This is irrelevant.
It's actually very relevant. It means dynamic linking *itself* CANNOT be a copyright infringement.
> You can not distribute a sequel to someone else's book, because it's a derivative work. What makes code legally a derivative work of other code? There hasn't been a lot of case law about it, but I'd certainly argue that new code that intricately connects to data structures and functions in old code, in a way that's very distinctive, would be a derivative work.
And THIS is the point. Is your work a derivative of the other work! Nothing to do with dynamic linking at all!
Or are we both arguing the same thing without realising it?
Cheers,
Posted Nov 19, 2024 21:35 UTC (Tue)
by nix (subscriber, #2304)
[Link] (3 responses)
It's defined by the law, and more generally defined by courts when cases go to court: a license only says what happens if something *has been decided to be* a derivative work of something covered by that license. (In the UK it is almost entirely defined by reference to precedent: Parliament hasn't ruled on this stuff much. In the US I believe things are quite different: US law is much more about fiddly nailing-down-of-tiny-details, where UK law goes in for broad swaths and letting courts decide the fine details in ways that make sense at the time, and then letting precedent force consistency in future.)
Posted Nov 19, 2024 22:21 UTC (Tue)
by Wol (subscriber, #4433)
[Link]
Where did I say (or even imply) that? What is a derivative work is, as you say, a matter of (vague) law.
Go back to what I *did* say - that "dynamic linking can NOT be a GPL copyright violation, because the GPL *explicitly* permits it" (unless someone can come up with a scenario where the linking does not happen on the end user's machine - I can't!).
Distributing a program that abuses a GPL API can be a copyright violation, but that's not down to the end user, and that's not dynamic linking, and it's not a violation if the "abuser" does it on their own machine ...
Cheers,
Posted Nov 20, 2024 2:15 UTC (Wed)
by NYKevin (subscriber, #129325)
[Link] (1 responses)
You're thinking of European law. US (statutory) law absolutely does not nail down the fiddly little details of derivative works, it just gives a one-paragraph definition and lets the courts work it out:
> 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”.
(17 USC 101)
Posted Nov 20, 2024 12:28 UTC (Wed)
by nix (subscriber, #2304)
[Link]
Posted Nov 18, 2024 12:34 UTC (Mon)
by paulj (subscriber, #341)
[Link] (4 responses)
If I write a work of fiction, which builds on a universe you created in a work of fiction you wrote, such that to properly understand my work of fiction the reader really needs to have read your work of fiction so as to understand the characters, may I distribute my work of fiction without any regard for your copyright in your work of fiction? (I never distribute your work, and the "combination" of my work with yours only ever happens "dynamically" at "readtime" in the readers head).
If I write a programme, that builds on a body of code you created, such that to understand the function of my programme, the programmer needs to understand the basic, visible function of the code underlying whatever APIs it exposes; and such that the computer in order to be able to interpret my code and make my code function needs to also have your code present, may I distribute my work without any refgard for your copyright in your work? (I never distributed your work, and the combination of my work with yours only ever happens dynamically at runtime - ignoring entirely the matter of compilation and whether copyright vests in API definitions).
?
Posted Nov 18, 2024 12:39 UTC (Mon)
by pizza (subscriber, #46)
[Link]
Unfortunately, in the US, "API definitions" are copyrightable. Use of them _may_ be considered fair use though.
(Thanks, Oracle...)
Posted Nov 18, 2024 16:43 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (1 responses)
That's often called FanFic, and/or "Classic Literature".
As a fan of pTerry, he often did that a lot. To truly understand Maskerade, you need to know Phantom of the Opera. To truly understand Wytches Abroad, you need to know Hamlet. As far as other authors / composers go, West Side Story may be a nice musical, but would you get the deeper meaning without knowing Romeo and Juliet? I love Miss Saigon, but much more is understood when you know Madame Butterfly. Etc etc.
The problem is, the answer is always "it depends". And it always helps to show that the work you depend on, itself depends on even deeper works. Both Hogwarts and Unseen University have a heavy dependence on works like the "Billy Bunter" books, and Greyfriars, and stuff like that. And as Ecclesiastes says, "there is nothing new under the sun", it shouldn't be that hard quite often to come up with evidence that copyright in stories isn't as obvious as people like to pretend ...
So why should programming be any different?
Cheers,
Posted Dec 6, 2024 1:33 UTC (Fri)
by jjs (guest, #10315)
[Link]
I'm also aware that Phantom of the Opera, Hamlet, Romeo and Juliet, and Madam Butterfly are out of copyright. You can find legal copies of them on Project Gutenberg. So Pratchet's fine works are NOT violations of copyright for, among other reasons, the fact there's no copyright to violate. It also means the examples don't really throw any light on whether or not his writings would have been copyright violations IF those works were still under copyright. Courts (at least in the US) tend to go with the simplest conclusion to reach, and (traditionally) purposefully did NOT speculate on other reasoning that were irrelevant (i.e. in this case, whether or not it would have been a violation IF the preceding work were copyrighted), in order to avoid setting precedent.
> That's often called FanFic, and/or "Classic Literature".
And fanfic can certainly be violation of copyright. Try writing a Star Wars novel and publishing it without getting Disney (previously LucasFilms) license. Desilu was very tolerant of fanfic for Star Trek (not certain about current owners).
The dividing line between "copyright violation" and "no copyright violation" in derived works (and what constitutes a derived work), from my understanding, is something that's decided on a case by case basis by the courts in the US.
Note: IANAL
Posted Nov 19, 2024 0:43 UTC (Tue)
by NYKevin (subscriber, #129325)
[Link]
This has been a serious point of controversy for at least as long as the internet has existed. You can find threads on early Usenet filled with professional and amateur authors debating this very topic. Much like the case of dynamic linking, there has as of yet been no case law. Unlike the dynamic linking case:
* There have been a few close calls, with the closest probably being The Wind Done Gone by Alice Randall. In the case regarding that book, the Eleventh Circuit found that the publisher of Gone With the Wind was not entitled to a preliminary injunction because a fair use defense likely applied, and the parties then settled out of court.
Posted Nov 18, 2024 12:26 UTC (Mon)
by paulj (subscriber, #341)
[Link]
The most comprehensible "rule of thumb" I have heard, from corporate lawyers advising engineering on how to approach things and use to know whether there was some legal issue that could cause problems, was if one work depended /specifically/ on another for its function or meaning. If that was the case, and there was any grey area / question at all on the licence compatibility, then it was definitely a problem for legal.
How well that rule of thumb is in actually deciding, I don't know. As per another comment, I've heard different things from different lawyers about linking proprietary works to GPL libraries. There doesn't seem to be a clear consensus amongst lawyers. Which suggests there is a lack of case law.
Posted Dec 5, 2024 9:57 UTC (Thu)
by callegar (guest, #16148)
[Link] (1 responses)
Restricted namespaces looks like a GPL2 library that exposes an API yet explicitly introducing a restriction for other GPL2 code to use it, namely the other code must have a certain name. What strikes is that it seems unusual to make it artificially difficult to combine different pieces of free software carrying the same licence. Are there other established examples?
In fact, the restriction, seems to be something to differentiate the GPL API for "in tree" modules wrt "out of tree modules", because the restricted namespace seem only manageable for the modules that are developed in strict coordination with the rest of the kernel. In fact, even small actions like renaming a module, or making a similar module for a slightly different case requires changing the module-names to which the kernel API is exported from the kernel side.
Where exactly does the need for this restriction come from? Is it because without it is practically impossible to enforce that out of tree modules only use the GPL API? Is it to prevent external modules from using the whole of the GPL API, since the kernel developers need freedom to change some parts of it? Wouldn't a 2-class distinction in between an in-tree GPL API and an out-of-tree one (which could be also intended as an "unstable" and "stable" one) suffice for this while being simpler? Couldn't the proposed solution be an encouragement for out-of-tree modules to "steal" the names of internal ones? Namely, in some out-of-tree module you want to use an API piece that is only exported for module "foo". You make a module named "foo" that provides the original functionality of "foo" plus yours and you arrange your installer so that it overwrites the original module...
Posted Dec 5, 2024 14:56 UTC (Thu)
by corbet (editor, #1)
[Link]
Even within the monolithic kernel, different subsystems hide much of their data internally; that's just basic good development practice. Exporting a symbol is the opposite of that — it makes the symbol to everybody who is able to link to it. That is not great when the symbol is really only being exported for one special consumer (KVM, say) that needs access to it. Strict namespaces allow that sort of targeted export without making a symbol globally available.
And yes, this is a feature for in-tree modules. The kernel does not add features for out-of-tree modules; any export has to have an in-tree user. A single-user export for an out-of-tree user is not going to happen.
Save us from...
Hindsight...
GPLv2 rather than GPL. I suppose this could be changed in the kernel, but there would be a huge disruptive flag day.
Hindsight...
GPL-2.0-or-later ?
GPL-2.0-or-later ?
GPL-2.0-or-later ?
The "or later" wording is NOT a licence, it gives you permission to choose which licence YOU want to use.
When you distribute code from multiple owners in a "combined work", they must have given you compatible licences.
"GPL2 or later" gives you a GPL2 licence should you wish to use that licence.
GPL2 is compatible with GPL2, therefore you can distribute "GPL2 or later" code with GPL2 code, because YOU are using (legally) the same licence to distribute both codebases.
Wol
Companies are made of humans
Companies are made of humans
Companies are made of humans
Companies are made of humans
Companies are made of humans
Companies are made of humans
Companies are made of humans
Companies are made of humans
Companies are made of humans
Companies are made of humans
Wol
Companies are made of humans
> licensing was done BOTH 1) to control upstreaming and 2) in the
> mistaken belief that it is legally and culturally/ethically acceptable—as
> ridiculous as that may sound to us who are too deep in these things.
Is the GPL actually viral across dynamic linking?
Is the GPL actually viral across dynamic linking?
Is the GPL actually viral across dynamic linking?
Is the GPL actually viral across dynamic linking?
> Practically speaking, the virality across dynamic linking is illusory. Plenty of programs link to readline without themselves being GPL and nothing goes wrong. The MIT Julia REPL has linked against readline for a long time. ZFS gets loaded into Linux. Nobody is afraid of getting sued.
Is the GPL actually viral across dynamic linking?
Is the GPL actually viral across dynamic linking?
Is the GPL actually viral across dynamic linking?
Is the GPL actually viral across dynamic linking?
Is the GPL actually viral across dynamic linking?
Wol
Is the GPL actually viral across dynamic linking?
Is the GPL actually viral across dynamic linking?
Wol
Is the GPL actually viral across dynamic linking?
Is the GPL actually viral across dynamic linking?
Is the GPL actually viral across dynamic linking?
Is the GPL actually viral across dynamic linking?
Wol
Is the GPL actually viral across dynamic linking?
> At what point exactly does mere linking have legal significance?
Is the GPL actually viral across dynamic linking?
TURBO.EXE and TURBO.OVL are not two different works, they are definitely part of the same thing!Is the GPL actually viral across dynamic linking?
Is the GPL actually viral across dynamic linking?
[2]: https://drewdevault.com/2020/07/27/Anti-AGPL-propaganda.html
Is the GPL actually viral across dynamic linking?
Is the GPL actually viral across dynamic linking?
* Making backup copies of software for archival purposes.
* Making copies of software "for purposes only of maintenance or repair [of the computer]." The statute does give somewhat vague definitions for those terms, and by my reading, they probably cover things like restoring from backup, reinstalling broken software, defragmenting your hard drive, etc.
Is the GPL actually viral across dynamic linking?
Wol
Is the GPL actually viral across dynamic linking?
Is the GPL actually viral across dynamic linking?
Wol
Is the GPL actually viral across dynamic linking?
Is the GPL actually viral across dynamic linking?
Wol
Is the GPL actually viral across dynamic linking?
Is the GPL actually viral across dynamic linking?
Is the GPL actually viral across dynamic linking?
Wol
Is the GPL actually viral across dynamic linking?
Is the GPL actually viral across dynamic linking?
Wol
Is the GPL actually viral across dynamic linking?
Is the GPL actually viral across dynamic linking?
Is the GPL actually viral across dynamic linking?
Is the GPL actually viral across dynamic linking?
Is the GPL actually viral across dynamic linking?
Wol
What is copyright in derived works?
Is the GPL actually viral across dynamic linking?
* A non-profit, The Organization for Transformative Works, exists, hosts a significant amount of fan fiction on the internet, retains lawyers, and is prepared to defend themselves in court if anyone ever sues them.
* In practice, nobody wants to sue the OTW because litigation is expensive, it might establish a precedent in favor of fan fiction, and it would generate a lot of negative press in the short term. Also, really egregious cases (where fair use is unlikely to work, such as when large amounts of text are copied verbatim) can be handled much more efficiently through the usual DMCA process instead of a lawsuit.
Is the GPL actually viral across dynamic linking?
A few questions
So I am not the author of that feature and cannot speak for sure about the motivations behind it. But I don't think it really has anything to do with licensing; it's basic information hiding.
A few questions