[License-review] Sublicensing

Engel Nyst engel.nyst at gmail.com
Sun Sep 14 15:40:48 UTC 2014


On 09/12/2014 11:48 AM, Jim Wright wrote:
> I'm not sure why the fact that *some* FOSS licenses are always
> directly from the original copyright holder (because that is clearly
> stated in the license terms) necessarily dictates that this is the
> case for *all* FOSS licenses.  MIT, by example, expressly states that
> sublicensing is permitted (sublicensing being defined as a new
> license issued by a licensee rather than the original copyright
> holder).  Others are silent on the issue and commonly interpreted to
> permit it.

BSD is silent on the issue, and many licensors interpret it strongly as
*not* permitting it, others don't care about a difference or don't
realize there is a difference.

On 09/12/2014 11:48 AM, Jim Wright wrote:
> While a downstream recipient may be unable to avoid the conditions of
> the license if that's how it's drafted, the existence of conditions
> or pass-through terms in a license does not mean that permitted
> sublicenses must otherwise duplicate the entire set of terms and
> rights of the original license.  (In a commercial licensing context,
> sublicenses of more limited sets of rights are often expressly
> contemplated, this is commonplace and I don't think the point is
> controversial...)

Lets say A makes a software work, which consists of three long files
implementing some complex algorithms. A licenses it as BSD, and
distributes it.

B takes the three files, doesn't modify them, adds a file interacting
with them, and distributes them together in a proprietary package. Lets
assume they're all written in python or javascript, and B distributes
them in source form.

C downloads B's package and accepts the license agreement. It says the
user accepts they can't make derivative works, distribute, in original
or modified form.

One day, C opens and reads A's BSD-licensed files from their machine,
and remembers their friend D is interested in those algorithms. C gives
D a copy of the BSD files.

(1) Did C do something wrong *under copyright law*?

(2) Did C break the agreement with B?

(3) D copies one of A's files on their machine, makes modifications,
complies with BSD and distributes the result publicly. Does D infringe
copyright?

(4) Does D break the agreement with B?

On 09/12/2014 11:48 AM, Jim Wright wrote:
> So if it's the case that sublicensing is permitted at least in some
> cases, why is that a good thing rather than a bad thing?  Well, it
> seems to me to be what allows the mechanics of copyleft license
> compatibility to work at a fundamental level - if I cannot sublicense
> a copy of an MIT licensed header file to a subsequent recipient under
> the GPLv2, I don't know how I can include that header file in a GPLv2
> licensed c file and then distribute the compiled object file and
> corresponding source, because the recipient of the combined module
> needs to get "each and every part" under the GPLv2.

This doesn't seem accurate. You can include a MIT file easily without
any 'sublicensing'. Please see GPLv2 section 2 paragraphs 2-3:

> 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.

> Thus, it is not the intent of this section to claim rights or contest
> your rights to work written entirely by you; rather, the intent is to
> exercise the right to control the distribution of derivative or
> collective works based on the Program.

If I include an independently developed MIT/BSD component in a GPLv2
work, then GPLv2 doesn't apply to it when I distribute them as
separated works.

GPLv2 applies to it in the sense that it *only accepts inclusion* if
the licenses of the included works give *similar permissions* and don't
impose restrictions not present in GPLv2.

MIT gives similar permissions and doesn't impose more restrictions. So
one can include works under MIT. But GPLv2 doesn't impose a new license
*instead of* MIT on works authored entirely by other licensors.

In this sense, in my reading, GPLv2 doesn't "relicense" / "sublicense"
included works.

I can copy all components of a GPLv2 work or only some; they're all free
and open source works. When I distribute, I have to comply with the
licenses of the works I'm using. If I only copy, modify and reshare
those licensed BSD/MIT, I only need to comply with their respective
licenses. I can license my new work as BSD/MIT, too.

It seems strange to say that the copyright holder of a GPLv2 work would
try to ask me to license as GPLv2; since I *only* do this when I work
*without* any material authored by them.

I think it's just common sense that I can always use those works under
their license.

Now, if we talk about a single (source or binary) file, it's not
meaningful or practical to seriously chase fragments to extract "MIT
bits"; they're likely no longer identifiable, and it's simply irrelevant
for most practical purposes. More importantly, the work with both MIT
and GPLv2 copyrighted material is (likely) a single *modified* work.[1]
I can continue to copy, modify and distribute this work, as long as I'm
in compliance with *both licenses*.

I can do that easily, there's nothing problematic here: deal with it
like any GPLv2 work, and keep MIT notices in place. The GPLv2 compliance
of my new work implies to be licensed as GPLv2, have source code for all
components, have installations scripts, *not* have any part that imposes
restrictions beyond those in GPLv2, among others. MIT compliance
requires I keep MIT notices.

Consider this simple practical case: if I ever want and analyze the code
enough to conclude that I modified it so much that there's no trace of
MIT copyrightable code anymore, *then* I can no longer comply with MIT
and remove the MIT notices. This depends on the copyrightable material
that comes from the MIT licensor, it's not up to the GPLv2 or other
licensors at all. My point is the practice and common sense
understanding says MIT continues to apply - to the same copyrightable
material it came with. It cannot be 'erased', no one has the right to,
as long as copyright applies.


Please compare these with your theory. If 'sublicensing' was something
substantial, if FLOSS licenses were 'erased', many other common cases
would be affected, not just the (less relevant) case of a single file.
Cases that range from juxtaposed files to combinations of packages, in
both source and binary form, seem to me affected. The answers for C and
D in the hypothesis above could change? I just don't understand what the
results would be.


[1] for simplicity, I assume here the works are always derivative.

-- 
  "Excuse me, Professor Lessig, may I ask you to sign this CLA, so we can
*legally* have your permission to remix and distribute your CC-licensed
works?"
  ~ Permission culture, take two.



More information about the License-review mailing list