Hacker News new | comments | show | ask | jobs | submit login

The exact analogy in FSF terms which you were careful to avoid is - An executable created by a GPL compiler will have to be GPL licensed. This is where your analogy breaks down because this is explicitly not the case.

Depends on the FSF tool. For many years the output of Bison (FSF's yacc clone) would propagate a GPL onto your entire program is you used it.

gcc uses a special library (outside of the C library) called libgcc with some builtin functions (I don't recall what's left there these days -- floating point stuff, 64-bit long long support on non-64 bit platforms?)

That library -- per definition part of GCC -- had to be explicitly made exempt from gcc's GPL license: http://www.gnu.org/licenses/gcc-exception.html otherwise yes, all your compiled code would have to be distributed using GPL.

For a long while RMS blocked adding plugins to gcc because he though that would allow proprietary vendors to violate the spirit of GPL.

I'd expect other languages that compile to binary code to fare even worse here -- gcc is better at separating its helper library -- but I'm not sure what other compilers than gcc are GPL'ed.

If I remember correctly, the GPLv3 license prohibits creating DRM'd content. Or more insidiously, a GPLv3-licensed compiler (e.g. recent GCC) cannot be used to produce an executable that contains DRM code without being in violation of the license, despite the fact that the executable itself is not covered under the GPL.

Someone please correct me if I'm wrong. I'm not willing to wade into the sea of legalese that is the GPLv3 right now just to verify this.

As far as I recall, the GPLv3 has two different anti-DRM restrictions, neither of which does what you say it does. The first restriction is that if you include GPLv3 code in certain kinds of consumer hardware and it accepts firmware updates, you must give the end users any keys that are required to install and run their own modified version of that code. The second restriction is intended to exempt any DRM system based around GPLv3 code from anti-circumvention laws. There's no restriction on compiler output that I'm aware of.

From my understanding, you can create as much "DRM" code as you want, but you must provide the cryptographic key along with the source. This extends to the platform that the code runs on; for example, "Tivo" can't distribute a GPL3 binary in their set-top boxes, lock it down using a cryptographic signature, and fail to distribute the signing key.

It would be impractical for the GPL to determine what counts as DRM and what does not; so they merely require "free modification of the Software".

What about GPL-licensed javascript code used in a web app? (Or in, say, a desktop application that uses a WebView for part of its interface, in which it uses the GPL-licensed javascript).

There may be some content or code from Apple that gets baked into your iBooks to enable some functionality or other. Maybe bits of Apple-developed javascript that get stuck in to mediate between the HTML and the iBooks application.

You're correct. The iBooks Author app embeds Apple code, both HTML, and Javascript, in the form of easy to use Widgets that enable the functions that make the book more than just text, such as photo galleries, embedded movies, etc.

Thus an iBook produced with the app is a derivative work that includes within it Apple copyrighted code.

Apple's ability to restrict the use of such derivative works is the very same ability the GPL relies on.

>you were careful to avoid

Don't attribute to others derogatory actions as an argument technique.

>This is where your analogy breaks down because this is explicitly not the case.

The existence of software that does not fit my analogy does not change the fact that there are many situations where the analogy still holds. In fact, the GPL itself is an example of the analogy holding- the GPL prohibits certain kinds of commercial use of creations derived by the thing protected by GPL, just as the Author app does.

Ah I see where our difference in opinion originates from - you look at the book outputted by the tool as a derived work. I must admit I never conceived of this possibility, and I am still trying to digest it. I wonder how many authors who use Apple's product will realise that after two years of hard work to create a manuscript, just by hitting publish the outputted object will not wholly belong to them.

The generated book contains Apple's code. It's definitely a derivative work.

That said, a person would be foolish to write the entire book using this. Write your text and create your graphics in your editors of choice, import them into this tool to create a nice layout for the iBookstore, then import them into another tool to create a nice layout for Kindle or whatever. You might have to do that anyway -- I've yet to see a tool that will generate a nicely-formatted ebook in both MOBI (Kindle) and ePub formats. Conversion tools like Calibre work if all you care about is reading the text, but the output often looks like ass if the original eBook used anything other than the most basic formatting (that said, a lot of commercially-produced eBooks look like ass anyway, so maybe that's not such a big deal).

No, I do not think it would be a derivative work, at least not in the way the term is normally used.

For an anology, consider MS Word. When I create a document using MS Word and save it in one of Words native formats, this file includes all sorts of information generated by MS code and includes MS specific formatting information. That does not, in any traditional meaning of the word, mean that my essay is a derivative work of MS Word.

Many of the people who have created GPL (not LGPL) libraries would disagree. Strongly.

These files don't just contain "formatting information". They contain actual executable code created by Apple. Apple's claim lies on the distribution of their code, not your content per se. They can put any restrictions on the distribution of their code that they want, whether we like it or not (and I don't particularly like it myself). They're not claiming ownership of your essay. They're claiming ownership over the code they wrote, which their system uses to display it. Not the same thing.

Suppose I create a Javascript library. I own the copyright, yes? No one can use it without my permission, yes? Now suppose I say in the license "Anyone can use this for free, but you have to include a link to my website". There are tons of libraries and code snippets with this restriction.

What you, and others, are claiming is that this type of license has no legal effect. That's clearly wrong.

Let's not confuse the two issues of whether it's a good idea for Apple to do this (it isn't) and whether they're legally allowed to do it (they clearly are).

> That does not, in any traditional meaning of the word, mean that my essay is a derivative work of MS Word.

But a derivative work of the base template (normal.dot?), yes. If the template was released as NC-SA, then the resulting document is NC-SA.

However, these textbooks are more than just formatted text. They're interactive; they are essentially a specialized website of sorts. You can include your own HTML and JS based 'widgets' and presumably use Apple's HTML/JS based widgets. The inclusion of Apple source code embedded in the book I believe would technically make the book a derivative in the way the term is normally used.

Whether I personally believe in my gut if it is right that these books be deemed derivatives is a separate issue.. ;)

It's a derived work in the same way that linking to stdlib from your program makes it a derived work. Which is to say, no, it's not reasonable to call books you wrote with this tool to be considered a derived work.

Reasonable or not, that is in fact what they are from a purely legal perspective. There is usually legalese involved with the licensing of the stdlib such that it explicitly disclaims derivative creation in this case.

This is not an uncommon thing to see. IIRC, the gcc compilers have an explicit exception clause that says that programs compiled with gcc (e.g., the output) are not affected by the GNU GPL. A compiler usually does more than just transforms code from a higher-level language to a lower-level language. It can reorganize the code (-O2, -O3, -O4); it can inject standard or custom implementations of common behaviours that the user didn't explicitly write.

From a very real and very strict standpoint, a compiler/code generator does create a derivative work (and there's at least one code generator I've used in the past few years that holds this to be true explicitly; gSOAP) that is a combination of your copyrighted code and the code by the compiler writer (and possibly others involved).

How can it be qualified as derivative work ? If you consider it this way, then everything in your life is a derivative work of something else. Writing a patent on paper is a derivate work of the paper manufacturer ? Painting a picture would be a derivative work of the brushes and paint ?

There is no ground for any of this.

Coming soon to a packet of pens near you - an EULA/shrinkwrap license ... any works created with this pen can only be sold, or used in a business setting, after purchase from the EvilBic shop with all profits going to EvilBic Inc..

Applications are open for YC Winter 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact