On Mar 5, 2013, at 6:22 PM, Tyler Romeo <tylerro...@gmail.com> wrote:
> I would just like to note that while it may be "silly" or "useless" to > insert licenses into minified JavaScript, it is nonetheless *legally > required* to do so, regardless of the technical aspect of it. And it is not > a question of whether we want to support some labeling program that reads > JavaScript licenses; both the GPL and CC licenses have requirements that > when you convey source code or binaries through any medium that the license > be prominently displayed. I strongly doubt that a company is going to sue > the WMF for something like this, but even so it's not a good idea to > specifically ignore legal requirements for a third-party software. > Sure, but it depends on your definition of "prominently displayed". First off, I agree our javascript files should have license headers in form of a code comment on top of the files (like we do for PHP files). But only to clarify their license, not because it is required. Because we already have a general LICENSE in our distribution, which if I recall correctly explicitly states that unless otherwise indicated, all is under said license. We don't have a license header in our release notes, in jpg, png, svg, sql files etc. A good example (to make it more complicated) is our README where we mention certain PNG file (cc icons) and JS files (sajax) are from a different author and license. We don't alter their PNGs and JS files, instead we mention it elsewhere (whether it belongs in README is another question). However I don't think it makes sense in any way for this to be sent to the browser. A few examples. ## Media in wiki pages We don't display the license or attribution of images inside the article near to the image. You go the the image descriptions page (by clicking the image) and there it is. ## Content of wiki pages We do display the license on the bottom of every page (which is about the wiki content, not the software). But not the authors. You go to the History page of the current article and find a list of contributors there. Note that the user doesn't click on the content here, but on the "History" tab. ## Server-side code in the software Any program code in our software that is not sent to the client. But its result is sent to the client. Everything you see on the wiki is the result of executing that server-side code. And if you consider HTML to be part of what you "see", then there's actually a significant amount of server-side code being sent to the client, because that is literally or abstractly (Html.php) explicitly written in the code. ## Client-side code in the software Any program code in our software that is sent to the client (css, javascript). These are commonly combined and minified, which means HTTP headers are not an option (unless you'd implement offsets or delimiters correlating to the content). ## Media in the software Any interface images and icons in our software. These are commonly embedded as base64 encoded data, which means HTTP headers are not a feasible method for delivery of information. ## Media in print A photograph used in a magazine or print. It might have the license/attribution over top of the image or closely to it, but it isn't uncommon for there to be a dedicated page for it. That then refers back to the images (by page number, position and/or by title) to disclose the license and attribution. If you'd look at any single spread (e.g. open it on page 3, you see page 3 and 4) you wouldn't have a complete legal picture. The same if you take out a page and "access" it directly. And even more so if you were to take scissors and take out an individual photo, in which case you'd lose the info even if it was printed right next to it. ## Conclusion So let's take the extremes and sum them up: * A page can contain multiple pieces of content from different sources (software interface, wiki page content, wiki media embedded) that can all be from different authors under different licenses (some might even be non-free, e.g. when embedding fair use, though lets avoid that can of worms for now). * Our wiki text source does not have license headers. Instead the platform on which they are primarily displayed (accessing html pages) has a footer. When accessing it from the API you're circumventing the main portal and are expected as a consumer to "check out" the primary access point to find out the license and author. * Like wise, accessing a multi-media file[1][2] directly does not give you attribution or license information in the file itself or in its headers, not even a link to it. I presume the rationale here is similar to the "Media in print" example. One might argue that because it is accessible over a separate http request it needs to be standalone, but I'm not sure thats justifiable. It is an implementation detail of how the web works. You can't require everything to be in the same web request (imagine MediaWiki ajax loading of article contents, the footer would be there always and you'd be loading the actual content over a separate request). You could also consider an individual page of a book to be a separate "request", again see the "Media in print" section above. * We certainly aren't going to embed the GFDL legal text in every http request… So given all that, whilst not having a clue whether all that is legal – I'm assuming so since that's practically how every website in the world operates (both free and non-free websites) – I think it is acceptable for our program code to follow similar guidelines as multimedia and text (since code is text). So it ought to be legal for our software to deliver individual bits and pieces to the browser that are not a complete package with license and all (like pages in a book). Instead one is expected to know about the colophon page. If you are in a position where you're legally required to have permission to do what you're about to do (e.g. copy our javascript), you go back up the chain and access the complete package. Find the "Powered by MediaWiki" button on the bottom of the page the code was bundled with (the "colophon"). Then, after looking up MediaWiki's license, go and find that code again in the original MediaWiki book and find the helloWorld.js in all its glory on page 42. Not sure how well that analogy flies, -- Krinkle [1] https://upload.wikimedia.org/wikipedia/commons/thumb/e/eb/Baantjegracht_Dokkum_2010.jpg/160px-Baantjegracht_Dokkum_2010.jpg [2] https://upload.wikimedia.org/wikipedia/commons/e/eb/Baantjegracht_Dokkum_2010.jpg _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
