LWN: Comments on "WordPress, themes, and derivative works"

WordPress, themes, and derivative works

dlang — Fri, 06 Aug 2010 08:42:38 +0000

in all cases you may be distributing the library, so it's not a matter of if you are distributing it, but rather if your program becomes a derivative work if you use one method of linking, but not if you use a different one.

since linking is not a creative task, I don't see how it could create anything that's protectable by copyright.

WordPress, themes, and derivative works

rqosa — Thu, 05 Aug 2010 10:07:02 +0000

> what's even worse is trying to say that using the API in one way (static linking) makes a derivative work, but in another way (dynamic linking) does not. Given that there is no difference in the creative work involved (writing the new program), only in the mechanical step of creating the binary.

But there is a difference: the statically-linked binary includes (parts of) the library. If you distribute the binary, you're also distributing (parts of) the library. It's less clear whether the dynamically-linked binary contains any parts of the library; if there are things like inline functions or template functions in the .h files, it probably does, but otherwise…

(However, PHP code is distributed in source form, and it seems pretty clear that source code that merely contains a call to "require_once()" isn't necessarily a derived work.)

WordPress, themes, and derivative works

dlang — Tue, 03 Aug 2010 01:25:05 +0000

if using the API makes it a derivative work, then glibc is a derivative work of libc because they both implement the same API

all iphone apps are derivative works of the iphone OS as it created the API (This is something that Apple would love to have be the case, that way they could use copyright and the DMCA to ban anything from running on the iphone without their approval)

what's even worse is trying to say that using the API in one way (static linking) makes a derivative work, but in another way (dynamic linking) does not. Given that there is no difference in the creative work involved (writing the new program), only in the mechanical step of creating the binary.

The example of apple above is why I say that winning the definition war would be dangerous. It could get even worse than that example. Microsoft has now licensed the ARM core, so they may an ARM device that has a custom chip (in the ARM world you have the core and a bunch of things that can be combined together and manufactured as one chip), and then set the license for the chip API to exclude GPL code. They could even do it in an 'accidental' fashion like the Sun CDDL does.

some free software advocates are so eager to get legal tools in their hands to beat on proprietary software vendors that they don't stop to think how those same tools could be used against free software.

WordPress, themes, and derivative works

marcH — Mon, 02 Aug 2010 23:37:59 +0000

> but people are claiming that software A must be a derivitive of library B due to the fact that there is no other library that it works with, if there was another library then it may not be a derivitive of software B.

"Is there an alternative implementation?" is indeed not a rigorous way to express this "test". The real question is: "Is the API of library B an original, copyrighted creation of B?" (assuming that a copyright on just an API can be legal - but please let's not start over).

> this is what isn't logical, and as others point out, is a very dangerous precedence to set.

"Logical", "legal" and "dangerous" are different things. Please avoid mixing them in the very same sentence, otherwise it looks like your reasoning is not sheer but tainted by your agenda.

> it would make all free software that was written for windows derived from windows

Yes. But since Microsoft licenses are absolutely not using the concept of "derived work" like the GPL does, this would be a very different story. (about this difference see other posts above)

> (because that's the only OS it was written for)

Not really, but rather because: win32 and other MS APIs are original, copyrighted creations of Microsoft.

WordPress, themes, and derivative works

pbonzini — Mon, 02 Aug 2010 21:54:55 +0000

> The general purpose of an "include" file is to serve as reference material > so that a compiler, etc. can be compatible with provided technical interfaces.

That's in C. But in PHP an include file contains the interface _and_ their implementations. A PHP include file is more akin to a shared object than to a .h file.

WordPress, themes, and derivative works

dlang — Sun, 01 Aug 2010 21:22:57 +0000

it would make sense that the status of software A didn't change, but people are claiming that software A must be a derivitive of library B due to the fact that there is no other library that it works with, if there was another library then it may not be a derivitive of software B.

this is what isn't logical, and as others point out, is a very dangerous precedence to set.

it would make all free software that was written for windows derived from windows (because that's the only OS it was written for), it would make linux derived from Intel's 386 chip (because that's what it was designed to run on), it would give apple exactly the control that they want over all software written for the iphone, etc

such results would be nonsense, but the same logic that you are claiming for the situation where there is no code copied from a library into an applications source code would lead to these conclusions as well.

I may have missed something, but I haven't seen any court cases that implied or stated that this is valid logic to follow, and there are court cases (like the recent 'jailbreaking a phone is ok' case) that point the other way.

as i said before, besides being a dangerous precedence to set, I don't think it's needed, in part because I haven't see anyone try to use it (in anything other than public threats)

WordPress, themes, and derivative works

marcH — Sun, 01 Aug 2010 11:51:28 +0000

> he's not saying that the GPL has a poor legal basis, just that the FSF definition of a derivitive work hoes beyond where it has a good legal basis.

Yes, sorry. In this context I was abusively using "GPL" instead of: "the GPL difference compared to the LGPL".

> the idea that software A could be considered derived from library B one day (because it only works with library B), and then the next day someone releases library C with the same interface as library B changing the status of Software A to no longer be considered a derivative work of library B (because it now works with both library B and library C) seems like nonsense to me.

Yes it would be nonsense.

What makes perfect sense however (whether it is legally correct or not) is that the status of software A in your example does not actually change. Because everything in your example is derived from library B, including library C since it is cloning B. I am not saying this is legally correct (I am not a lawyer). But it is simple, logical, consistent and makes sense.

(Note: this originated in http://lwn.net/Articles/394889/)

WordPress, themes, and derivative works

butlerm — Sun, 01 Aug 2010 06:32:32 +0000

"arguing that dynamic linking is Ok, but static linking makes something a derived work smacks of [...] silliness"

There is probably a pretty good argument that both static and dynamic linking create derivative works, either on disk or in memory. The difference is in part to avoid the silliness you describe with regard to copying software in memory, Congress has explicitly exempted the creation of adaptations and copies by end users that are necessary for them to use software on a machine, provided they do not transfer the adaptations to others, of course. See 17 USC 117.

The thing that irritates me the most about the specious idea that a plugin etc is a derivative work merely based on considerations such as utility and compatibility is if that were to become the case, the outcome would be _far_ worse than what little advantage it might gain in some circumstances.

Every Win32 program could require permission from Microsoft to be distributed for example. Or every program that reads files saved in a proprietary format, or supports proprietary network protocol extensions, and so on.

WordPress, themes, and derivative works

butlerm — Sun, 01 Aug 2010 06:16:10 +0000

"You meant: unfortunately *for the GPL*?"

No, I mean unfortunately for the persons who find themselves in the situation of making an argument before a court that (1) runs contrary to dozens of precedents, (2) against the whole tenor of copyright law for at least a century, and (3) without at least a theory of why the law requires such a conclusion.

The GPL is just fine. The only issue is about where and when the difference between the GPL and the LGPL can actually be enforced. If there is joint distribution of both the GPL component and the proprietary component, the developers of the former have significant leverage that they do not have if there is not, because the distributors must comply with the license to have the legal right to distribute the GPL component. No specious theories about derivative works required.

"Do you have examples of the former case?"

No. But as far as I know there is no legal dispute about the proposition that including substantive creative material from another source into a resulting product, whether literally or by translation, and without technical necessity creates a legally restricted derivative work. C++ templates and inline functions are usually raised as an example, although to some degree the use of both might be allowed on the grounds of technical necessity, i.e. to the degree necessary to make a compatible interface. cf. Baystate v. Bentley Systems (1996).

"And whether 110-years old decisions all make sense for software is an interesting question."

That is an issue Congress would have to address. The situation with software patents is similar. The latter are probably a counterproductive drag on the economy and the progress of science and the useful arts, but courts aren't generally in the business of making such determinations. That is what legislatures are for.

WordPress, themes, and derivative works

dlang — Sun, 01 Aug 2010 00:39:41 +0000

he's not saying that the GPL has a poor legal basis, just that the FSF definition of a derivitive work hoes beyond where it has a good legal basis.

all the GPL enforcement court cases that I am aware of has involved clear copying of the work without including the source.

I am not aware of any GPL enforcement court actions where a library was under the GPL, proper source for that library was provided, and the enforcement action was that because the library was linked to another program, that other program had to be released under the GPL.

I know this is stated frequently as a requirement, and I fully believe that the threats around this may have forced some companies to GPL their software, but just because threats have worked doesn't mean it has a solid legal basis.

Yes, this does mean that I question if there is really an effective legal difference between the GPL and the LGPL.

the idea that software A could be considered derived from library B one day (because it only works with library B), and then the next day someone releases library C with the same interface as library B changing the status of Software A to no longer be considered a derivative work of library B (because it now works with both library B and library C) seems like nonsense to me. The status of software A as a derivative of some other piece of software needs to be based on what the developers A did while they were developing the software, not anything that anyone else does.

arguing that dynamic linking is Ok, but static linking makes something a derived work smacks of the same silliness as people claiming that because a computer copies a binary from the hard drive to ram (or from the ram to the CPU cache/registers) to execute it, copyright law now allows them to control the use of the software.

I also don't think that loosing these edge cases of derived would necessarily be a big deal for the community. I think more damage would be done by people no longer trusting the claims than by the loss of the license coverage.

WordPress, themes, and derivative works

marcH — Sat, 31 Jul 2010 23:01:06 +0000

> You can, and get laughed out of court, unfortunately.

You meant: unfortunately *for the GPL*?

You are quite convincing about the theory. But in practice Justice is not as deterministic as a computers:
- judges are unreliable human beings with limited technical knowledge
- not everyone is rich and patient enough to actually go all the way to court
- US laws do not apply to the whole world
- etc.
For a (depressing) reality check look no further than software patents.

Even if you prove that the GPL has a poor legal basis, it is well-known that it is scaring many companies. So it would still serve its purpose anyway. Just like a number of other legal abuses (you do not fight guns with flowers)

> If you are making a binary distribution, it makes a _big_ difference whether protected elements of the include files are substantially included in the resulting binaries, or just referred to during the compilation process.

Whether this is the "right thing" or not, it sounds simple and consistent enough. Do you have examples of the former case?

> The Supreme Court set the basic precedent in this matter more than 110 years ago.

And whether 110-years old decisions all make sense for software is an interesting question.

WordPress, themes, and derivative works

butlerm — Sat, 31 Jul 2010 00:03:29 +0000

"The plugin does nothing by itself, so you can argue that it is irrelevant as a piece of work and that only the whole thing matters."

You can, and get laughed out of court, unfortunately. Legal arguments actually have to have a legal basis, not just be an exercise in idle speculation.

"Indeed it would look silly if #include "foo.h" was subject to different laws than "import foo", whatever these laws are"

It depends on whether you are making a source or binary distribution. If you are making a source distribution, you don't have to distribute foo in either case. If you are making a binary distribution, it makes a _big_ difference whether protected elements of the include files are substantially included in the resulting binaries, or just referred to during the compilation process. This is not some new thing. The Supreme Court set the basic precedent in this matter more than 110 years ago.

WordPress, themes, and derivative works

mpr22 — Fri, 30 Jul 2010 15:41:10 +0000

Is it circumvention of an "effective technical measure"?

WordPress, themes, and derivative works

marcH — Fri, 30 Jul 2010 10:03:00 +0000

> But who says the recipient doesn't get the library from someone else? The library author gives Mary a copy of his library, then the application author gives Mary a copy of the application.

That's circumvention, it's forbidden by the DMCA.

WordPress, themes, and derivative works

marcH — Fri, 30 Jul 2010 09:53:39 +0000

> whether the plugin _itself_

The plugin does nothing by itself, so you can argue that it is irrelevant as a piece of work and that only the whole thing matters.

> The general purpose of an "include" file is to serve as reference material so that a compiler, etc. can be compatible with provided technical interfaces. No copyright violation, even if such things as structure names and elements are copied verbatim.

Indeed it would look silly if #include "foo.h" was subject to different laws than "import foo", whatever these laws are. Laws and lawyers are never that inconsistent and always stick to some basic common sense. Look for instance at software patents. Oh, wait...

WordPress, themes, and derivative works

anselm — Fri, 30 Jul 2010 07:12:53 +0000

You're saying the derivative work issue is specific to GPL because without GPL the application author couldn't distribute his application without the permission of the library author anyway, because the application is no good without the library and he would need the permission of the library author to distribute the library.

No, I don't. I said that according to copyright law only the copyright holder gets to distribute their code, and that vendors of proprietary libraries may charge run-time fees in order to allow others to do it too. Application authors tend to take advantage of that sort of arrangement for the convenience of the users of their code. Whether that makes the application a "derived work" of the library is a non-issue in this case; the library is presumably sold in order to be incorporated in applications, and end users typically don't get to redistribute the code in question to yet other people.

With a GPLed library, permission to distribute is already part of the library's license, and the authors of the GPL are jumping through hoops to try to enforce specific licensing conditions on the distribution of code that uses that library, which is an entirely different ball-game from the proprietary case.

WordPress, themes, and derivative works

butlerm — Fri, 30 Jul 2010 06:40:35 +0000

"So a library can't have any licencing restrictions as to what the code that uses it will do?"

A library certainly can, under certain conditions. Notably a binding contract between the library developer and the end user. Forming that contract is a bit of a trick.

If you download a typical open source library from a web site somewhere, you typically have not clicked on a license agreement. If the web site provides you a legal copy of the software without requiring you to enter into a specific agreement, you now own that copy, and you are not bound by any use license.

The only reason why anyone actually needs to comply with the GPL is so that he/she can legally redistribute modified versions of the software. That requires a license because to do otherwise would violate the copyright of the original authors. No such license is required to use software in any manner that doesn't break copyright (or possibly patent) law, unless the software developer/distributors require you to enter into a licensing agreement before transferring a copy of the software to you.

Shrink wrap licenses are in legal limbo in many areas precisely because this does not happen at the point of purchase. A retail end user now _owns_ a copy of the software, and the First Sale doctrine means that the ability of the software developers to regulate further use has ceased, unless a shrinkwrap licensing agreement is counted as a valid contract between the end user and the original copyright holder no consideration.

If you _own_ a copy of software, or a book, or a CD, what legal principle requires you to enter into a further contract that takes away rights you already have by virtue of that ownership. That is the whole point of the First Sale doctrine, first established by the Supreme Court in 1908, and enshrined into statute in 1978. The software industry wants to take all that away with the pretense that opening shrinkwrap (or clicking yes on a post sale license agreement) constitutes entering into a valid contract. Where's the consideration?

The case for a typical open source license is worse. Where is the contract? A license is not a contract. A legitimate "license agreement" is a contract. A "license" grants you permission to do things you do not already have the right to do. It cannot take away rights you already have, which is why "use license" is an oxymoron.

WordPress, themes, and derivative works

vonbrand — Fri, 30 Jul 2010 01:50:45 +0000

It seems to me the derivative work issue is no more an issue with GPL-licensed stuff than with any other licensed stuff.

True, but in the case of propietary stuff you pay for the permission to redistribute the library (and perhaps also for the right to create a derivative work to be distributed with it). In the GPL case the only point that matters is the second one, which is very much irrelevant in the propietary case.

WordPress, themes, and derivative works

sfeam — Fri, 30 Jul 2010 00:26:57 +0000

You are confusing two things. It is certainly possible for a library to be licensed in such a way that its use is restricted. But this does not depend on the notion of a derived work. Use of the library itself is restricted, independent of what the calling code is used for.

But the GPL explicitly does not do this. Clause 0 says:
Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, [...]

WordPress, themes, and derivative works

tzafrir — Fri, 30 Jul 2010 00:14:43 +0000

There are all of those pesky libraries that will not allow me to use programs based on them for commercial usage (unless I get a different license, for which I pay separately). One that comes to mind off the top of my head is http://en.wikipedia.org/wiki/Integrated_Performance_Primi... .

But hey, it's impossible for a library to impose usage restrictions, right?

WordPress, themes, and derivative works

giraffedata — Fri, 30 Jul 2010 00:13:30 +0000

So a library can't have any licensing restrictions as to what the code that uses it will do?

I can't tell how that question relates to the post you replied to. Does it have something to do with the definition of derivative works? Or the purpose of copyright?

Taking the question by itself, though: I think it's possible to craft a copyright license for a library so people are restricted in how code they runs uses the library (to the extent you have to copy the library in order to use it, because you need permission from the author to copy it). It's not easy, since a condition on a copyright license must be met before the copying happens, but I think it's been done successfully.

WordPress, themes, and derivative works

sfeam — Fri, 30 Jul 2010 00:03:48 +0000

So a library can't have any licencing restrictions as to what the code that uses it will do?

Neither the GPL nor the LGPL attempts to restrict what a calling program is used for.

WordPress, themes, and derivative works

tzafrir — Thu, 29 Jul 2010 23:56:04 +0000

That's a typo here. I meant: "it's impossible to make any practical use of *a*.php without creating a work that is derived from both a.php and b.php".

WordPress, themes, and derivative works

tzafrir — Thu, 29 Jul 2010 23:53:49 +0000

So a library can't have any licencing restrictions as to what the code that uses it will do?

WordPress, themes, and derivative works

sfeam — Thu, 29 Jul 2010 23:14:37 +0000

it's impossible to make any practical use of b.php without creating a work that is derived from both a.php and b.php

Similarly it is impossible to make practical use of a shared library without creating an executable that calls into it. But in neither case does this by itself create a derived work. I know that the FSF implies otherwise in justifying the existence of the LGPL, but that doesn't make them correct.

WordPress, themes, and derivative works

giraffedata — Thu, 29 Jul 2010 23:13:18 +0000

The explanation of why it's a derivative work seemed ridiculous to me, too -- traditional (e.g. books, films) copyright arguments don't talk about include() statements and memory, and I don't think there is a large body of tested law specifically about software plugins and such. But I have to pay some deference to SFLC simply because they should know (better than me, anyway) and have a reputation better than plain crackpots. So I wonder what's going on there.

Do you know if the derivative work definition has ever been tested in court with software that simply links (after distribution) with other software? Or code that calls other code? Or is it all pure speculation at this point?

With regard to the idea that software that links is a derivative work, I like to go back to first principles: the reason for copyright is to prevent someone from using an author's own work to compete against the author, which would make writing unprofitable, so there would be no writing. But plugins don't compete with the base code. If anything, they cause the base code author to get paid more.

So I don't see any reason the law would give Wordpress authors control over themes.

WordPress, themes, and derivative works

giraffedata — Thu, 29 Jul 2010 22:53:25 +0000

You're saying the derivative work issue is specific to GPL because without GPL the application author couldn't distribute his application without the permission of the library author anyway, because the application is no good without the library and he would need the permission of the library author to distribute the library.

But who says the recipient doesn't get the library from someone else? The library author gives Mary a copy of his library, then the application author gives Mary a copy of the application.

It seems to me the derivative work issue is no more an issue with GPL-licensed stuff than with any other licensed stuff.

I agree with nye that people should keep clear in their minds what is copyright law and what is GPL. (Hint - if it stops you from doing something, it's not GPL. GPL only adds to what you can do). That prevents them from imagining that the author can control more than he really can.

WordPress, themes, and derivative works

giraffedata — Thu, 29 Jul 2010 22:44:10 +0000

So if I have a printer whose drivers don't allow me to do silly things, is it within my right to adapt them?
The provision I quoted applies to end users. It also prohibits distribution of those adaptations:

Not only that, in the case of adapting out the silliness in the printer driver, the law doesn't help the end user either. It says you can make adaptations needed to run the program, and was intended to address the perverse interpretations of copyright law that once existed that loading (and relocating, etc.) a program required permission from the copyright owner. As long as you can use the printer driver to do the things it was intended to do, I don't think any court would say it's an essential step in using the driver to remove silly restrictions from it.

WordPress, themes, and derivative works

butlerm — Thu, 29 Jul 2010 22:36:56 +0000

"However, it's impossible to make any practical use of b.php without creating a work that is derived from both a.php and b.php."

The dubiousness of that proposition aside, any such combination by an end user would be explicitly legal under 17 USC 117(a). That includes _static_ linking if necessary.

"The problem is that the combination of the licenses that cover a.php and b.php don't allow this derived work under either of them."

It doesn't matter whether the licenses allow it or not. No one needs any kind of license to use something they have obtained a legitimate copy of. The only obvious way to defeat the fair use rights Congress clearly intended end users to have would be to have those who receive copies of open source software enter into valid contracts specifying otherwise.

WordPress, themes, and derivative works

butlerm — Thu, 29 Jul 2010 22:29:23 +0000

"BTW: I really like your idea about adaptations. So if I have a printer whose drivers don't allow me to do silly things, is it within my right to adapt them? Distribute the resulting code? For profit?"

It helps if you actually read the law. The provision I quoted applies to end users. It also prohibits distribution of those adaptations:

"it is not an infringement for the owner of a copy of a computer program to make...another copy or adaptation of that computer program provided: (1) that such a new copy or adaptation is created as an essential step in the utilization of the computer program in conjunction with a machine...or (2) that such new copy or adaptation is for archival purposes only and that all archival copies are destroyed in the event that continued possession of the computer program should cease to be rightful. (b)...Adaptations so prepared may be transferred only with the authorization of the copyright owner." (17 USC 117(a),(b))

WordPress, themes, and derivative works

tzafrir — Thu, 29 Jul 2010 22:05:07 +0000

I didn't say it does. However, it's impossible to make any practical use of b.php without creating a work that is derived from both a.php and b.php .

The problem is that the combination of the licenses that cover a.php and b.php don't allow this derived work under either of them. This is very much not the case of two separate executables.

WordPress, themes, and derivative works

sfeam — Thu, 29 Jul 2010 21:07:17 +0000

Now someone gets a copy of my a.php and your b.php and runs a.php . In order to execute it, his system copies a.php into memory (this is a copy of my a.php) and then processes it to include b.php inside. That processed copy is derived from both a.php and b.php .

Maybe so, maybe no. The fact that both modules are loaded does not, by itself, make a.php a derived work of b.php. As to whether there now exists some third, separate work that is derived from both a and b, I'd say this is far from clear. Just having two executables running on your computer at the same time does not create a derived work, or so I would claim with some confidence. Is having two sets of php modules available at the same time a different case? I am dubious.

This is not to deny the possibility that a.php might indeed be a derived work for other reasons. But making use of other capabilities that may or may not be present on the system, be they other php modules or separately installed programs, is not a sufficient test for being derivative.

WordPress, themes, and derivative works

foom — Thu, 29 Jul 2010 21:04:11 +0000

Luckily the GPL doesn't forbid the end user from combining a work distributed under the GPL and a proprietary work, and running the result of that combination. So it doesn't matter.

He cannot distribute that combination, of course, but in the Wordpress case, nobody is distributing such combined works.

WordPress, themes, and derivative works

tzafrir — Thu, 29 Jul 2010 20:45:28 +0000

I write a.php that has the line: include b.php

You write b.php .

BTW: I really like your idea about adaptations. So if I have a printer whose drivers don't allow me to do silly things, is it within my right to adapt them? Distribute the resulting code? For profit?

WordPress, themes, and derivative works

smitty_one_each — Thu, 29 Jul 2010 19:41:11 +0000

Here is an idea which is at least testable: define 'derivative work' to mean the part which cannot be ported to another platform.
So you go to, oh, cherry.py, and make your theme work.
Inevitably, there would need to be some python shimming to de-conflict your namespaces, make up for missing functionality, and the like.
The part of your work that runs the same everywhere is called the 'theme'.

WordPress, themes, and derivative works

butlerm — Thu, 29 Jul 2010 18:40:04 +0000

"The SFLC analysis states that "the PHP elements, taken together, are clearly derivative of WordPress code," citing the fact that they are loaded into the WordPress PHP application with include(), combined in memory with the rest of the WordPress code, and executed by PHP as part of a single executable program."

This is some kind of joke, or rather the Software Freedom Law Center appears to be engaging in a combination of stupidity, opportunism, and wishful thinking. A derivative work becomes derivative by incorporating protected elements of another work. Whatever the end user does with a plugin has nothing to do with whether the plugin _itself_ is a derivative work. Not only that US law 17 USC 117(a) gives explicit permission for end users to create "adaptations" of copyrighted works as an essential step in running computer software "on a machine".

Those protected elements exclude technical interfaces of any kind, under the *scenes a faire* doctrine and the merger doctrine. The general purpose of an "include" file is to serve as reference material so that a compiler, etc. can be compatible with provided technical interfaces. No copyright violation, even if such things as structure names and elements are copied verbatim. See Bay State v. Bentley Systems (1996) and Gates Rubber v. Bando Chemical (1993).

So it would seem that the idea that a plugin that hasn't copied any technical interface unrelated code is a "derivative work" is entirely specious, fictional, and without any sort of legal foundation whatsoever. The SFLC website certainly contains no trace of an argument to the contrary. The common belief on this point is a combination of rumor and innuendo that such entities as the SFLC and the FSF propagate to an unwitting public, on no apparent basis other than pure opportunism.

WordPress, themes, and derivative works

njs — Thu, 29 Jul 2010 16:21:39 +0000

I've never seen a legal test for derivative works that made reference to whether some interface was declared "external" or "internal". So, citation needed, I guess.

WordPress, themes, and derivative works

hummassa — Thu, 29 Jul 2010 10:39:26 +0000

You are 100% correct.
The misunderstanding that "linking" (mashing in the same address space) a derivative work does is widespread. But it is a misunderstanding anyway.
People who pay attention to my comments -- if they exist -- know that I am very pro-FSF but that specific piece "linking a derivative works does" of the GPL is bollocks. I have analysed it thoroughly.

Now, if _the_ Pierce themes are derivative works of WP, that is one thing that I didn't analyse myself. They can be (especially if lots of non-trivial, can-be-done-differently-but-wasn't boilerplate code is involved). But I have a serious problem with the linking myth.

WordPress, themes, and derivative works

rhertzog — Thu, 29 Jul 2010 07:51:09 +0000

I doubt Thesis will end up listed on wordpress.org.

In this blog post, Mullenweg clearly said:

Even though graphics and CSS arent required to be GPL legally, the lack thereof is pretty limiting. Can you imagine WordPress without any CSS or javascript? So as before, we will only promote and host things on WordPress.org that are 100% GPL or compatible. To celebrate a few folks creating 100% GPL themes and providing support and other services around them, we have a new page listing GPL commercially supported themes.

WordPress, themes, and derivative works

aigarius — Thu, 29 Jul 2010 02:37:52 +0000

For GPL works the answer is quite simple - it depends on what the author of the program (like Wordpress) defines as an internal or external interface. If you are linking to an interface that is not external, then you are making your code part of the original program and thus creating a derivative work.