Re: [Wikitech-l] Architectural revisions to improve category sorting
Hi! No doubt Domas will complain anyway, but without developers adding new features, I figure his volunteer DBA work would get very boring. I don't complain about well designed features, especially if they don't scan millions of rows to return 0 ;-) Domas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Architectural revisions to improve category sorting
This looks like a very important feature, and a hard one to get right. You guys are real world heros :-) -- -- ℱin del ℳensaje. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: [Foundation-l] Discussion Questions for Potentially-Objectionable Content
Aryeh Gregor wrote: On Thu, Jul 22, 2010 at 4:02 PM, David Gerard dger...@gmail.com wrote: This is a perennial proposal. It's an idea I like, as it puts control in the hands of the viewer rather than third parties. All it requires is someone to code something that passes muster as being unlikely to melt the servers. cc to wikitech-l - how feasible is something that allows users to stop display of arbitrary image categories and/or subcategories? It's entirely feasible. I even have an outline written up: http://www.mediawiki.org/wiki/User:Simetrical/Censorship Maybe if I have time left after category sorting this summer, Wikimedia could have me do this. You would need to reparse on edit (which changes categories) all pages including the image. Even if the image comes from commons or another ForeignRepo. Not as easy, I think, but this is a long wanted proposal, see bug 8298/9616. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Must 3rd party skins and extensions be distributed under GPL?
On Thu, Jul 22, 2010 at 8:57 PM, Andrew Fitzgerald andrewfitz.swiftlytilt...@gmail.com wrote: Saw an article mentioned on Slashdot about Wordpress themes and plugins being required to be disributed under the GPL because they are derivative of Wordpress. Is this also true for Mediawiki extensions and skins? It seems like the arguements for why Wordpress themes and plugins also apply to MW. The FSF's position on the issue is that plugins, extensions, and things like that, which link to/call code from a GPL program, must themselves be licensed GPL-compatibly: If a program released under the GPL uses plug-ins, what are the requirements for the licenses of a plug-in? It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them. If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed. If the program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case. http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins This is C-oriented, but the application to MediaWiki is fairly clear. Extensions will invariably make function calls back and forth to core code, and share data structures (= objects). This conventional understanding is reflected in MediaWiki's README file, which has stated that extensions must be GPL (citing the above FAQ) for over four years http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/README?r1=11468r2=11770: Derivative works and later versions of the code must be free software licensed under the same or a compatible license. This includes extensions that use MediaWiki functions or variables; see http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins for details. http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/README?view=markup However, we don't actually enforce this against extensions, even ones hosted on mediawiki.org. (I'd be in favor, but most developers seem to be against.) Another question is JavaScript: stuff that people put in Common.js or whatnot is probably a derivative work by the FSF's standard, but on Wikipedia it's licensed as CC-BY-SA 3.0, which is not GPL-compatible. None of this has actually been tested in court, as far as I know. On Thu, Jul 22, 2010 at 9:19 PM, Q overlo...@gmail.com wrote: So, IMO, generally no in the case of extensions, and depends on the case of skins. People probably forget that the GPL doesn't dictate what are classified as derivitive works. No, United States copyright law does. The FSF's lawyers believe that if an extension or plug-in is written that integrates with an existing code base as is designed for that purpose, then it would typically be a derivative work under United States law. Note that the GPLv3 doesn't use the term derivative work, and instead defines its own term, modify: To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a “modified version” of the earlier work or a work “based on” the earlier work. http://www.gnu.org/licenses/gpl-3.0.html This more explicitly ties the question to local copyright law. The FSF believes that under United States law, the copyright holder for a computer program has the exclusive right to produce new code that is designed to link to the computer program, and thus the GPL restricts that. I'm not aware of any organizations whose lawyers have explicitly disputed this. So strictly speaking by their own definition, shouldn't WordPress be licensed under the PHP license? No, because the PHP license is permissive, not copyleft. If the PHP license required that all derivative works be released under it, then it might be required, yes. (However, this case is possibly fuzzier because independent reimplementations like Hiphop are possible based on the public documentation for PHP. Similarly, most Linux kernel developers maintain that drivers written for Linux must be released under the GPL -- but this presumably doesn't apply if BSD clones the driver interface, and the driver is written for BSD, and thus happens to work on Linux too. IANAL, and the FSF FAQ doesn't cover this case, so I dunno how this works.) On Fri, Jul 23, 2010 at 2:10 AM, Robert Leverington rob...@rhl.me.uk wrote: In the past it has been concluded that extensions do not need to be licensed under the GPL, and I think that is the
[Wikitech-l] Experience Team - Insert Template
Dear all, The improvements to the page editing interface by the experience team are great. I especially like the new insert link. I was wondering, whether it is possible to have something similar for templates, maybe with following functionalities: - suggestions for templates are listed while typing - short descriptions from the template page are shown - when a template is chosen, the user is asked for its parameters With that the users would not need to remember all templates, their syntax to use, and their number of parameters. Does anyone know whether that exists already or is planned? If not, how could that be implemented? Regards, Benedikt -- Karlsruhe Institute of Technology (KIT) Institute of Applied Informatics and Formal Description Methods (AIFB) Benedikt Kämpgen Research Associate Kaiserstraße 12 Building 11.40 76131 Karlsruhe, Germany Phone: +49 721 608-7946 Fax: +49 721 608-6580 Email: benedikt.kaemp...@kit.edu Web: http://www.kit.edu/ KIT - University of the State of Baden-Wuerttemberg and National Research Center of the Helmholtz Association ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: [Foundation-l] Discussion Questions for Potentially-Objectionable Content
Aryeh Gregor wrote: On Fri, Jul 23, 2010 at 8:00 AM, Platonides platoni...@gmail.com wrote: You would need to reparse on edit (which changes categories) all pages including the image. Even if the image comes from commons or another ForeignRepo. Not as easy, I think, but this is a long wanted proposal, see bug 8298/9616. Ouch. You're right, I hadn't thought of that. The categories for each image can't be stored in the parsed text, that will mean updates don't propagate until the next reparse. Okay, so how about this instead: when generating the page, the server retrieves all categories for all images on the page, then checks against site and user preferences to see if any need to be censored, and if so, stick a list into the head. That should work fine -- Even if you remove censoring ability from anonymous users, you still need to purge from squid cache all pages that include the images when category changes. it should be okay to retrieve the categories (local and foreign) for each image on the page on every page load, right? There are some large galleries. For instance contains 746 files each with 4-5 categories. That's nearly 3000 categories being retrieved. However, the image loading would have to be revised somehow, to not delay the loading of uncensored images . . . as usual, IE is the problem here. Aside from older IE versions, we could use attribute selectors, img[src=http://..], assuming we can get the src easily on the server side for each image. Getting the urls for each image should be no problem for us. Note that we can ban from src beginning with the thumb folder, we don't need the actual thumb url. I find going that way over-verbose, though. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Disabling magic linking for plaintext URLs
Aryeh Gregor wrote: On Fri, Jul 23, 2010 at 12:41 PM, Alex Kozak ako...@creativecommons.org wrote: Ah, ok my apologies. Maybe you could add a note describing some of the things that would break to http://www.mediawiki.org/wiki/Manual:$wgUrlProtocols? I've corrected some inaccuracies on that page. I'm not even going to *try* to predict what would break if you removed things like 'http:' from the array -- link parsing would break throughout the software. I don't see anything obvious breaking. Of course, external links stop working, both plain and in [], also magic external images, and the captcha won't detect it as addition of urls. But all of that seems expected behavior on removing http from $wgUrlProtocols. You mentioned Special:LinkSearch and wfParseUrl(), but LinkSearch has nothing to search if you don't allow external links, and wfParseUrl() is only used inside the parser (precisely to work with the previously matched external urls). ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Must 3rd party skins and extensions be distributed under GPL?
Aryeh Gregor wrote: This is C-oriented, but the application to MediaWiki is fairly clear. Extensions will invariably make function calls back and forth to core code, and share data structures (= objects). This conventional understanding is reflected in MediaWiki's README file, which has stated that extensions must be GPL (citing the above FAQ) for over four years http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/README?r1=11468r2=11770: It's fuzzier for skins, though. It can be almost a php interface, very similar to the mentioned borderline case. However, we don't actually enforce this against extensions, even ones hosted on mediawiki.org. (I'd be in favor, but most developers seem to be against.) I think that's because they are more liberal licenses, like MIT*. Do we have any code that isn't GPL-compatible? *To which extent they can do that is debatable. Maybe they can only license under that license *some* pieces of their code. Another question is JavaScript: stuff that people put in Common.js or whatnot is probably a derivative work by the FSF's standard, but on Wikipedia it's licensed as CC-BY-SA 3.0, which is not GPL-compatible We should probably change on wmf the editnotice on .js pages to require it to be colicensed as GPL. Specially since user space javascript sometimes goes into mediawiki. Andrew Fitzgerald wrote: So strictly speaking by their own definition, shouldn't WordPress be licensed under the PHP license? I consider that completely unrelated. PHP is a platform, similarly as how you can use a non-GPL program on a GPL kernel. Or write a document on a GPL text editor without it being automatically open source. Aryeh wrote: Similarly, most Linux kernel developers maintain that drivers written for Linux must be released under the GPL -- but this presumably doesn't apply if BSD clones the driver interface, and the driver is written for BSD, and thus happens to work on Linux too. IANAL, and the FSF FAQ doesn't cover this case, so I dunno how this works. It wouldn't need to be under GPL. AFAIK, the case for that is that kernel drivers usually copy code from the GPL ones. Also note that since some version, they have apis not available for closed drivers. I think there are some interesting discussions about this on lkml archives. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
