[License-review] Sublicensing

Lawrence Rosen lrosen at rosenlaw.com
Tue Sep 16 01:40:11 UTC 2014


Jim Wright noted:

> As to the direct question on the UPL, suffice it to that the 

> ability to sublicense does not violate OSD 7 (or any other 

> part of the definition), and by way of example, both the 

> MIT license and the Academic Free License (Larry's own

> creation) expressly permit it.

 

My AFL 3.0 license actually says a little bit more to limit the discretion
of intermediary distributors:

 

"1(c): to distribute or communicate copies of the Original Work and
Derivative Works to the public, under any license of your choice that does
not contradict the terms and conditions, including Licensor's reserved
rights and remedies, in this Academic Free License;" [emphasis in original]

 

Also read section 6, which requires the retention of the licensor's
attribution notices even in copies and derivative works. At the time I
thought that would be all it would take to limit the discretion of
distributors of "universally permissive" works to hide them away inside
proprietary works. With those limitations, go ahead and sublicense. Just
make sure you honor my reserved rights and remedies and don't contradict the
terms and conditions.

 

Now that I see your license, I regret allowing sublicensing. Life is full of
such regrets. :-)

 

/Larry

 

 

-----Original Message-----
From: Jim Wright [mailto:jim.wright at oracle.com] 
Sent: Monday, September 15, 2014 5:58 PM
To: Engel Nyst
Cc: License submissions for OSI review; Lawrence Rosen
Subject: Re: [License-review] Sublicensing

 

Obviously I don't think all of this is as clear as you would make it, but in
any event we do not need to solve for the broader questions about how
copyleft does, does not, should, or should not work.  As to the direct
question on the UPL, suffice it to that the ability to sublicense does not
violate OSD 7 (or any other part of the definition), and by way of example,
both the MIT license and the Academic Free License (Larry's own creation)
expressly permit it.  

 

Regards,

  Jim

 

> On Sep 15, 2014, at 4:58 PM, Engel Nyst < <mailto:engel.nyst at gmail.com>
engel.nyst at gmail.com> wrote:

> 

> Jim,

> Your argument on strong copyleft seems entirely backwards.

> 

> Disclaimer: the following is personal opinion. I think I have 

> statistically contributed more to permissive software projects, and I 

> license share-alike in writing. I don't make comparative statements of 

> value on free/open licenses, by personal policy. However it is fair to 

> say that I have a preference for strong copyleft.

> 

> Regarding these statements:

> 

>> On 09/12/2014 11:48 AM, Jim Wright wrote:

>> I understand the perspective that as long as you're distributing the 

>> source and notices to everything, few will complain, but that doesn't 

>> mean no one will - and beyond that, if we foster an environment where 

>> copyleft requirements are not subject to strict compliance as long as 

>> all the source is released, maybe that's ok, but it seems to me this 

>> may cultivate a culture which weakens the strength of how copyleft 

>> licenses are interpreted and implemented generally, which will bleed 

>> over into commercial use as well to the extent it hasn't already. And 

>> if you're a fan of strong copyleft, this might not be a preferred 

>> outcome.

> 

>> On 09/12/2014 03:20 PM, Jim Wright wrote:

>> the reason *I* want to expressly permit this is to be crystal clear 

>> that the license facilitates use in both (i) strong copyleft code 

>> (potentially requiring licensing originally UPLed code under the 

>> copyleft terms)

> 

> I use in the following 'copyleft' in the sense of strong copyleft, 

> copyleft to the extent of copyright in a work, or close to that extent.

> 

> Copyleft exists to counteract copyright, it's a tool to restore the 

> liberty of the public to deal in works of authorship, as if copyright 

> exclusivity wouldn't be there, except strictly in the measure 

> necessary to keep it that way to any recipient of works based on them. 

> To put this in perspective, I think of it in the context where 

> copyright law is, in a sense, in flux: courts interpretations change 

> what was understood and relied upon before their new decisions, and 

> the direction seems to be that copyright and related rights will be 

> more expansive. It has happened before. It has happened in 2014.

> 

> If, in 2020, copyright will restrict *more* the freedom of people to 

> deal with works of authorship, than it does in 2014, then copyleft 

> will need to at least contemplate addressing it, in its implementation 

> and/or its interpretation.

> 

> *If* copyright can and will destroy the common sense understanding in 

> dealing with unmodified copies of BSD/MIT/AL2.0 works, by some future 

> court decision, then copyleft may contemplate addressing it, in its 

> implementation and/or its interpretation.

> 

> But it's not the other way around.

> 

> To use copyleft to argue that copyright law 'must' be more invasive 

> than it is, that it 'must' be interpreted to erase FLOSS licenses on 

> *unmodified copies*, is entirely backwards. That's simply *not* common 

> sense, not what GPLv2 strictly *says*, not the way people usually work 

> in free and open software projects, and not helpful to anyone except a 

> traditional proprietary middleman.

> 

> Copyleft to the extent of copyright needs to guarantee that each and 

> every recipient has all rights to use every part of the covered works, 

> without proprietary restrictions, no matter if the parts are 

> derivative at their turn or not. While I don't think GPLv2 or A/GPLv3 

> texts are ideal implementations of this concept, none of them relies 

> on 'sublicensing' / 'relicensing'.

> 

> On the other hand, I subscribe to the view of other commentators in 

> this discussion, that the argument for sublicensing in FLOSS licensing 

> or that all non-copyleft FLOSS licenses can be 'erased', is only to 

> the advantage of a traditional distributor of others' works. I note 

> proprietary licensing doesn't need it either. You don't need to 

> 'sublicense' in order to make proprietary derivatives of a permissive 

> work. Only some assumption of the traditional publisher that they 'must'

> claim to be the ONLY licensor for authors' works to subsequent 

> recipients, seems to me implied here.

> 

> Copyleft has no need for that. On the contrary. Most free and open 

> source projects, copyleft or not, work on this basis: each author 

> gives a license to the other authors and everyone else in the world, a 

> license which gives them all legal rights to copy, modify, build upon, 

> transform and adapt the work, use it in other works or have it used by 

> them, as long as the recipients fulfill its conditions.

> 

> Perhaps it's only me, but I don't see anything right now, in my layman 

> understanding of copyright law, that could possibly 'stop' the flow of 

> rights from BSD or MIT or AL2.0 or MPL2.0 licensors on an *unmodified

> copy* of their work[1] to all recipients, purely under copyright. None 

> can be exactly 'erased'. That seems correct about most or all 

> currently approved OSI licenses.

> 

> In this context, you're proposing a license which claims to be 'clear'

> that... it's not clear. That it can get to people and not mean what it 

> says. That it depends on something else, some other license, external 

> to the software and copyright in the software, *by design*, which 

> other license will 'really be' the license people get. For unmodified 

> copies in source form, even.

> 

> For OSI approval, I think this doesn't pass OSD 7.

> 

> Arguably, it doesn't pass the other criteria either, since the rights 

> it seems to give don't depend on it.

> 

> 

> In the larger context, my concern is what can happen, is that some 

> interpretation of this odd concept of sublicensing is steered along a 

> way that may, one day, try to make cases like C and specially D[2] 

> into copyright infringement cases. Or throw more doubt on people's 

> rights to use an *unmodified copy* of a free and open work, a copy 

> licensed sufficiently clear for them to read and know their rights.

> 

> If copyright can really go there, copyleft may be able to cope with 

> it, but I don't think this is an academic question, and I don't see 

> how is it a good thing in the first place.

> 

> 

> [1] assuming everything else is equal, i.e. source code available, no 

> proprietary parts in a binary, no calls to otherwise-licensed code, etc.

> 

> [2] C and D from the hypo in a previous email, which I copy below for

> convenience:

> 

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

> 

> 

> --

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20140915/52f14c0d/attachment.html>


More information about the License-review mailing list