[License-discuss] Source-attribution licenses and Javascript compatibility

Sat May 28 18:38:51 UTC 2016

Andi McClure wrote:

> The zlib license refers to "source distributions". The BSD license refers to "redistributions of source code". Neither license defines "source code". Without a definition, how do I (or someone who uses my project) know whether cases #2 and #3 are "source distributions"? Cases #2 and #3 are literally distributing Javascript source, although it is no longer the source to the original program.

These areas of technical confusion perhaps explain why the U.S. copyright law does not distinguish between source and other forms of the same software. There are procedures for registering a copyright with either the source code or (for proprietary software) parts of the binary only. As far as the Library of Congress is concerned, both forms are the same original work protected by the exact same copyright.

What is important for open source is that the source code be available for downstream modification and security validation. Otherwise the FOSS license needn't distinguish. Many open source licenses identify "source code" without defining it clearly. Here, though, is one definition:

3) Grant of Source Code License. The term "Source Code" means the preferred form of the Original Work for making modifications to it and all available documentation describing how to modify the Original Work. Licensor agrees to provide a machine-readable copy of the Source Code of the Original Work along with each copy of the Original Work that Licensor distributes. Licensor reserves the right to satisfy this obligation by placing a machine-readable copy of the Source Code in an information repository reasonably calculated to permit inexpensive and convenient access by You for as long as Licensor continues to distribute the Original Work.

OSL 3.0 <https://opensource.org/licenses/osl-3.0>  § 3. 

/Larry

From: Andi McClure [mailto:andi.m.mcclure at gmail.com] 
Sent: Thursday, May 19, 2016 7:06 PM
To: license-discuss at opensource.org
Subject: [License-discuss] Source-attribution licenses and Javascript compatibility

I am working on some projects (a programming language, a game library) for which I wish to use a "source attribution" license-- for example, the zlib license, or the 2-clause BSD license if I could somehow delete the second clause. I want people redistributing or reusing source code from my project to keep attribution along with the source; however, I do not want to put conditions on people who are only distributing executable versions to be run by end users.

However it is ambiguous to me what "source" and "executable" mean when dealing with interpreted languages, or in particular when dealing with Javascript, which has developed an entire tools ecosystem around "minifying". Consider these scenarios:

1. A developer has taken a Javascript library I wrote and embedded it into a web app they wrote using a <script src> tag. (The .js source file is vended from their web server, but never made directly visible to the end user.)

2. A developer has used node.js, uglify.js and webpack to "compile" a Javascript library I wrote, along with their own code and other libraries, into a single large .js file. The code is dense, not human readable and is basically obfuscated.

3. A developer has used a transpiler like Emscripten to compile a C library I wrote into dense, non-human-readable Javascript code.

4. A developer has written a program in Lua, an interpreted language. They distribute this as a .exe containing an embedded Lua interpreter. They pack all the Lua code their program uses, including a Lua library I wrote, into a .zip file and distribute this .zip along with their .exe (possibly literally packed into the binary of the exe itself).

These are all real, non-hypothetical ways of using open source code (I have done all of them myself) and I do not think I know how to apply the zlib license to any of these.

The zlib license refers to "source distributions". The BSD license refers to "redistributions of source code". Neither license defines "source code". Without a definition, how do I (or someone who uses my project) know whether cases #2 and #3 are "source distributions"? Cases #2 and #3 are literally distributing Javascript source, although it is no longer the source to the original program.

The Apache and MPL licenses *do* define "source code" (both say something like "the form of the work preferred for making modifications"). Both of these licenses are more restrictive than I want to use, but the definition at least means the license is unambiguous, and clearly with these licenses cases #2 and #3 are not "source distributions". If I had a license which excused attribution in the case of #2 and #3, but required attribution in the case of #1 and #4, I think I would feel satisifed since I assume in cases #1 and #4 one could satisfy the license by simply leaving comments in the source files (#2 and #3 are awkward this way because the javascript-packing process naturally strips comments).

Is there a existing source-attribution license which fits my needs here?

Would it be sufficient to use the zlib license and then outside the license include a clarifying paragraph like:

    "For purposes of the above license, 'source' is defined as the preferred form for making modifications to the code. In other words, minified Javascript which is not intended to be modified does not count as a 'source distribution'."

…and if I included such a clarifying paragraph outside the license, would I break the magical spell of OSI compliance which zlib normally has?

Alternately, would it make sense to introduce a new license for this purpose? It seems like the javascript ecosystem is really hurting for an appropriate license, and this is a real need which should be filled at some point. My impression from my brief experiences with modern javascript development is many of the people using webpack are not bothering to fill their license requirements (ie using MIT licensed libraries but not surfacing license information anywhere).

- Andi McClure
http://emilylang.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20160528/93757a3a/attachment.html>