Re: [Wikitech-l] Must 3rd party skins and extensions be distributed under GPL?
On 26/07/10 16:33, Andre Engels wrote: > I think that is disingenuous. If one considers a skin or extension to > be a derived work, that is not because it uses function and class > names from the original product, but because they do not have any > meaning without the original code. The product, people would argue, is > not "extension" but "mediawiki+extension", which clearly _is_ a > derivative of mediawiki. Yes, it is certainly derivative in that sense. It's just not derivative in the sense of being a derived work under copyright law. > Line numbers are even less creative than function or class names, but > if someone took a series of instructions like > > * Take Mediawiki version 11.0 > * In such-and-such-file replace lines so-and-so to so-and-so by (my own code) > * same with several other files/lines > > I would argue that what you have is a derived work from MediaWiki. > Whether the same holds for extensions and skins, I would not argue > from either side, not knowing enough about either the code or the > legal side of the matter, but I think your rejection is too easy. Those instructions do not contain any of the creative work that went into making MediaWiki. Thus the copyright holder has no right to restrict the distribution of those instructions. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] collab.wikimedia db error in many tools
collab.wikimedia db error in many tools. like luxo's tool, vvv;s sulutil. In Luxo's tool, http://toolserver.org/~luxo/contributions/contributions.php?user=Devunt or sulutil. http://toolserver.org/~vvv/sulutil.php?user=Devunt How can we fix this problem? I don't know why this problem occurred. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] collab.wikimedia db error in many tools
Hello, > collab.wikimedia db error in many tools. > like luxo's tool, vvv;s sulutil. Thats so sad. It is really depressing, that even after I explained you on IRC (when you were reporting toolserver issue on #wikimedia-tech) that private wikis are not supposed to be exposed to toolserver users, you keep spamming non-related mailing lists. > How can we fix this problem? I don't know why this problem occurred. No. Domas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Toolserver-l] collab.wikimedia db error in many tools
Hello, At Monday 26 July 2010 11:56:09 DaB. wrote: > collab.wikimedia db error in many tools. > > > How can we fix this problem? I don't know why this problem occurred. This is a (new?) non-public wiki for which we have no view. I have no idea from where these tools get information about this wiki, because it is not listed in our toolserver-db. Sincerly, DaB. -- Userpage: [[:w:de:User:DaB.]] — PGP: 2B255885 signature.asc Description: This is a digitally signed message part. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] InstantCommons serving up non-free files
This is a sorta-technical sorta-copyright issue. InstantCommons is great stuff, it spreads free content with correct attribution in a marvellous manner. But Commons contains a certain number of non-free files, specifically Wikimedia logos and so forth. I just noticed (on a wiki using InstantCommons) that these are served up through it just the same. Is there any relatively simple way to stop this happening? (Including not caring.) - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] InstantCommons serving up non-free files
On Mon, Jul 26, 2010 at 12:24 PM, David Gerard wrote: > But Commons contains a certain number of non-free files, specifically > Wikimedia logos and so forth. I just noticed (on a wiki using > InstantCommons) that these are served up through it just the same. > > Is there any relatively simple way to stop this happening? (Including > not caring.) > Either not caring, or moving the Wikimedia logos to meta and configuring meta as a second foreign file repo to the Wikimedia projects. I think both options have been proposed before. Bryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Commons-l] InstantCommons serving up non-free files
On 26 July 2010 11:48, Bryan Tong Minh wrote: > On Mon, Jul 26, 2010 at 12:24 PM, David Gerard wrote: >> But Commons contains a certain number of non-free files, specifically >> Wikimedia logos and so forth. I just noticed (on a wiki using >> InstantCommons) that these are served up through it just the same. >> Is there any relatively simple way to stop this happening? (Including >> not caring.) > Either not caring, or moving the Wikimedia logos to meta and > configuring meta as a second foreign file repo to the Wikimedia > projects. I think both options have been proposed before. The second sounds like way too much faff (and has been consistently rejected on "don't be silly" grounds). I suppose some categories could be determined to indicate "don't InstantCommons." Not caring is probably the best option unless it become some sort of active problem. - d. ___ 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 Sun, Jul 25, 2010 at 10:22 PM, Tim Starling wrote: > In my opinion, MediaWiki extensions are not derivative works unless > they copy substantial portions of core MediaWiki code. If an extension > merely uses the interface MediaWiki presents, then it is not a > derivative work, and the authors of MediaWiki have no right to place > conditions on its distribution. Do you know of lawyers who agree with you, as far as American law goes? (I haven't heard anything either way about other legal systems.) > To adopt an interpretation of copyright law which claims that merely > calling code constitutes a copyright violation of the code which is > called would, in my opinion, be a terrible stance for a free software > advocate to take. For instance, it would bring into question the > legality of all open source code which runs on top of the Windows > native API, such as 7-zip, not to mention Wine and Mono. No one says that, though. They say that plugins or extensions are derivative works, not that ordinary programs that incidentally call the system libraries of their particular platform are derivative works. Something intimately tied to Windows, like a Windows shell extension or driver that doesn't make sense outside of a very Windows-specific context, might qualify as a derivative work according to this opinion, but not an ordinary program. A cross-platform program like 7-Zip even less so. No one claims that reimplementing an API makes something a derivative work, either. The merger doctrine would prohibit that -- the API duplication in Wine/Mono is necessary for the purely functional purpose of compatibility with Windows/.NET code. Baystate v. Bentley is a district court case that rules on this issue explicitly, saying that a program that implemented support for a proprietary data format did not infringe copyright of the official program, because any API duplication was purely functional in nature: http://scholar.google.com/scholar_case?case=8753348956544433&hl=en&as_sdt=2&as_vis=1&oi=scholarr > The two legal theories which would allow the use of an interface are: > > * A function name or class name are not creative enough or substantial > enough to be eligible for copyright. As far as I know, everyone agrees with that. > * A function name or class name is a small excerpt from a work, used > for the purposes of precisely referring to a larger part of the work. > Such reproduction of an excerpt is fair use. This is the same legal > theory which allows us to reproduce things like chapter titles and > character names in Wikipedia articles about copyright novels. Fair use is never an absolute thing. It depends very much on the particulars of the case. I don't think it would be possible to argue that *all* plugins and extensions fall under fair use -- they might all win on the amount and substantiality criterion, and maybe nature of the copied work; but purpose and character, and effect on the work's value (the two most important criteria), would depend on the circumstances. > When I agree to the GPL, and when I consent to allow my work to be > distributed under the GPL, I'm agreeing to the actual text of the > license. I'm not agreeing to every piece of nonsense that has ever > come out of Eben Moglen's mouth. I'm not even agreeing to the "How to > Apply These Terms to Your New Programs" section, which is explicitly > outside of the license itself. > > There is no way the GPL can restrict code which is not licensed under > the GPL, and is not derivative (in the sense of copyright law) of any > GPL work. The meaning of the GPL is uncontested here: it only restricts derivative works. In GPLv3 it uses clearer (more international) terminology, saying that it restricts only "modified versions", where "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 question is, under United States copyright law, does an extension or plugin constitute a derivative work? The professional opinion of the lawyers employed by the FSF and SFLC (and possibly others) is that some extensions and plugins are derivative works, depending on how tightly coupled they are with the underlying work. The SFLC did a detailed analysis of Wordpress themes, which I excerpt here: """ . . . The PHP elements, taken together, are clearly derivative of WordPress code. The template is loaded via the include() function. Its contents are combined with the WordPress code in memory to be processed by PHP along with (and completely indistinguishable from) the rest of WordPress. The PHP code consists largely of calls to WordPress functions and sparse, minimal logic to control which WordPress functions are accessed and how many times they will be called. They are derivative of WordPress because every part of them is determined by the content of the WordPress functions they call. As works of authorship, they are designed only to be combine
Re: [Wikitech-l] InstantCommons serving up non-free files
On Mon, Jul 26, 2010 at 6:24 AM, David Gerard wrote: > This is a sorta-technical sorta-copyright issue. InstantCommons is > great stuff, it spreads free content with correct attribution in a > marvellous manner. > > But Commons contains a certain number of non-free files, specifically > Wikimedia logos and so forth. I just noticed (on a wiki using > InstantCommons) that these are served up through it just the same. > > Is there any relatively simple way to stop this happening? (Including > not caring.) Probably. I think not caring is the best bet, though. It's up to reusers to ensure that they comply with copyright law. Maybe they'll be using the logos for fair use -- I don't see why we should worry about that any more than we worry about InstantCommons users reusing CC-BY-SA images without linking to their licenses. ___ 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 Mon, Jul 26, 2010 at 02:22, Tim Starling wrote: > On 23/07/10 10:57, Andrew Fitzgerald 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. >> >> Article: >> http://markjaquith.wordpress.com/2010/07/17/why-wordpress-themes-are-derivative-of-wordpress/ > > In my opinion, MediaWiki extensions are not derivative works unless > they copy substantial portions of core MediaWiki code. If an extension > merely uses the interface MediaWiki presents, then it is not a > derivative work, and the authors of MediaWiki have no right to place > conditions on its distribution. That's contrary to the FSF's opinion, as mentioned by citing their FAQ in a previous posting. The Why-CLISP-is-under-GPL document is also very informative in this regard (hosted at http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/doc/Why-CLISP-is-under-GPL) It's also very analogous to MediaWiki's situation since CLISP was only using the GNU readline *optionally*, and as anyone who's used a readline C API can tell you that must have been a very miniscule part and disposable part of CLISP, which isn't the case with MediaWiki extensions. The opinion of the FSF's legal team in that case was that explicitly coding for a GPL'd API (as all MediaWiki extensions do) means that your program must be under the GPL too. Here's the main gist of the discussion: The FSF position would be that this is still one program, which has only been disguised as two. The reason it is still one program is that the one part clearly shows the intention for incorporation of the other part. I say this based on discussions I had with our lawyer long ago. The issue first arose when NeXT proposed to distribute a modified GCC in two parts and let the user link them. Jobs asked me whether this was lawful. It seemed to me at the time that it was, following reasoning like what you are using; but since the result was very undesirable for free software, I said I would have to ask the lawyer. What the lawyer said surprised me; he said that judges would consider such schemes to be "subterfuges" and would be very harsh toward them. He said a judge would ask whether it is "really" one program, rather than how it is labeled. So I went back to Jobs and said we believed his plan was not allowed by the GPL. The direct result of this is that we now have an Objective C front end. They had wanted to distribute the Objective C parser as a separate proprietary package to link with the GCC back end, but since I didn't agree this was allowed, they made it free. So I don't think the GPL actually requires a correction for this. But perhaps it would be a good idea to add a note explaining this. > To adopt an interpretation of copyright law which claims that merely > calling code constitutes a copyright violation of the code which is > called would, in my opinion, be a terrible stance for a free software > advocate to take. Opinions differ on that, but that stance has pretty much been what the GPL was all about from day 1. Whether that's bad is up for debate, GPL advocates would dispute that, saying that the end result is a lot more free software from parties that just release their software under the GPL so that they can take advantage of GPL libraries and programs. > For instance, it would bring into question the legality of all open > source code which runs on top of the Windows native API, such as > 7-zip, not to mention Wine and Mono. That's different, for the reasons Aryeh Gregor explains. > The two legal theories which would allow the use of an interface are: > > * A function name or class name are not creative enough or substantial > enough to be eligible for copyright. > > * A function name or class name is a small excerpt from a work, used > for the purposes of precisely referring to a larger part of the work. > Such reproduction of an excerpt is fair use. This is the same legal > theory which allows us to reproduce things like chapter titles and > character names in Wikipedia articles about copyright novels. > > Aryeh Gregor wrote: >> 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: > > When I agree to the GPL, and when I consent to allow my work to be > distributed under the GPL, I'm agreeing to the actual text of the > license. I'm not agreeing to every piece of nonsense that has ever > come out of Eben Moglen's mouth. I'm not even agreeing to the "How to > Apply These Terms to Your New Programs" section, which is explicitly > outside of the license itself. > > There is no way the GPL can restric
Re: [Wikitech-l] Must 3rd party skins and extensions be distributed under GPL?
There would seem to be good points on both sides, so until it gets tested in court, I don't think we'll really have an answer. The issue is also discussed, though without a clear conclusion, in Wikipedia's article on the GPL [1]. Personally, I don't really like the FSF position (at least not to the extreme they push it). Everyone agrees that copying code is generally derivative but counting nearly all form of code interaction as also derivative feels unnatural. In this circumstance -- and irrespective of what the law actually says -- it would seem more natural if software were treated more like a physical object subject to first sale doctrine and similar principles. For example, it seems more natural (to me at least) to say that an end-user should have arbitrary authority to modify and combine legally obtained software, but not be allowed to distribute copies of the modified software. To give an analogy, car companies do not have the authority to restrict after-market modifications to the chassis of a car, and there is a booming industry of people providing after-market mods. So why should software copyright holders get to control the skins used in conjunction with their software? That said, a lot of the copyleft movement has operated on the assumption that copyright holders have nearly arbitrary freedom to impose restrictions on the users of their works. And maybe that is true. For the most part it hasn't been directly tested. I don't know whether the FSF is right about the reach of the GPL with respect to APIs and linked code, but personally, it feels like just another piece of evidence that copyright law needs to be updated to deal with the realities of the digital age. If there is a decision to be made (and I'm not sure there is), I would personally argue that we should take steps to make sure that authors are informed about the FSF position on the GPL, but not try to enforce it ourselves (except possibly for the extensions and skins actually deployed by Wikimedia). I don't see much benefit for Wikimedia in taking a hard line with third-party software contributors over the licensing of their extensions. [1] http://en.wikipedia.org/wiki/GPL -Robert Rohde ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Commons-l] InstantCommons serving up non-free files
On Mon, Jul 26, 2010 at 4:09 AM, David Gerard wrote: > On 26 July 2010 11:48, Bryan Tong Minh wrote: >> On Mon, Jul 26, 2010 at 12:24 PM, David Gerard wrote: > >>> But Commons contains a certain number of non-free files, specifically >>> Wikimedia logos and so forth. I just noticed (on a wiki using >>> InstantCommons) that these are served up through it just the same. >>> Is there any relatively simple way to stop this happening? (Including >>> not caring.) > >> Either not caring, or moving the Wikimedia logos to meta and >> configuring meta as a second foreign file repo to the Wikimedia >> projects. I think both options have been proposed before. > > > The second sounds like way too much faff (and has been consistently > rejected on "don't be silly" grounds). Personally, I'd rather we did move the 5500 Wikimedia-only images to Meta. Making Commons 100% free content would be clearer to reusers and make more general sense than having a site that is 99.92% free content. Of course, such a move would take considerable effort for relatively small gain, and thus far few people have been interested in doing this (i.e. most people think it is "silly"). -Robert Rohde ___ 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 26 July 2010 18:47, Robert Rohde wrote: > If there is a decision to be made (and I'm not sure there is), I would > personally argue that we should take steps to make sure that authors > are informed about the FSF position on the GPL, but not try to enforce > it ourselves (except possibly for the extensions and skins actually > deployed by Wikimedia). I don't see much benefit for Wikimedia in > taking a hard line with third-party software contributors over the > licensing of their extensions. There isn't really. One, it would probably take Automattic actually attempting to enforce their copyright on WordPress as they view it, and winning - or achieving a quick settlement and GPL release of the theme code the second a real lawyer reads the GPL, as has happened in every GPL enforcement case to date. Perhaps PHP will be treated differently to C. But until that occurs, if it occurs, no answer exists and one cannot be discussed into existence, or Slashdot would have solved all problems by now. Two, each developer holds the copyright on their small piece of the code and can enforce it without asking anyone else - as has been reasonably well tested by every GPL enforcement case to date - and Tim's opinion or wikitech-l consensus doesn't actually stop them. You could ostracise developers who go against the group interpretation of what the GPL should mean, of course, if you feel that's appropriate. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Commons-l] InstantCommons serving up non-free files
When there is a need and consensus to move all logo´s to Meta I would be happy to do so... -- Huib "Abigor" Laurens Tech team www.wikiweet.nl - www.llamadawiki.nl - www.forgotten-beauty.com - www.wickedway.nl - www.huiblaurens.nl - www.wikiweet.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Commons-l] InstantCommons serving up non-free files
On Mon, Jul 26, 2010 at 2:17 PM, Huib Laurens wrote: > When there is a need and consensus to move all logo´s to Meta I would be > happy to do so... Don't worry about doing it yourself, I'm sure we could get a sysadmin to import the images through the server. They might even be able to do it in a way that would preserve the file history. -- Casey Brown Cbrown1023 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Commons-l] InstantCommons serving up non-free files
Hi Casey. I was thinking about a bot that also imports the history, but on the server is much beter offcourse. -- Huib "Abigor" Laurens Tech team www.wikiweet.nl - www.llamadawiki.nl - www.forgotten-beauty.com - www.wickedway.nl - www.huiblaurens.nl - www.wikiweet.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Commons-l] InstantCommons serving up non-free files
On Mon, Jul 26, 2010 at 4:09 AM, David Gerard wrote: > The second sounds like way too much faff (and has been consistently > rejected on "don't be silly" grounds). I suppose some categories could > be determined to indicate "don't InstantCommons." Not caring is > probably the best option unless it become some sort of active problem. > Possible, but not currently. -Chad ___ 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
The code in trunk now has all the basic features. I encourage people to test it by setting $wgExperimentalCategorySort = true;, applying the patch in maintenance/archives/patch-categorylinks-better-collation.sql, and running maintenance/updateCollation.php. Note that: * The code is not stable or well-tested. It needs preliminary testing right now; testing it on a production site is probably a bad idea. * The entire architecture will probably be changed significantly in the near future based on feedback. * To reverse the changes, you need to disable the config option, manually reverse the SQL patch, and then run refreshLinks.php. When things change, I'll probably include instructions in my commit messages for how best to convert your schema to the new version, but it will not be done automatically as long as the feature is unstable. Obviously, once this is enabled by default everything will be automatic. Things that currently work: * Uppercase and lowercase letters are sorted identically. (This is my proof-of-concept collation function, it just uppercases everything.) * Categories, files, and other pages all page separately, and you get the first 200 of each independent of the others. * When you specify the same custom sort key for multiple pages, they'll sort amongst themselves according to what their default sort key would have been, not more or less randomly as it used to be. But probably there are bugs and such. I've made a wiki page to track my work: http://www.mediawiki.org/wiki/User:Simetrical/Collation I don't have any further changes planned until I get feedback on my approach from Tim, other than fixing specific problems people point out to me (please do!). ___ 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 26/07/10 23:58, Aryeh Gregor wrote: > If that were so, then you could evade the GPL completely by > distributing modified source code in the form of the original > unmodified source code plus a small program to patch it (not diff > files, since those will contain the contents of removed lines). Along > with an unmodified binary, together with a program to patch it just > before runtime. Do you think this is correct? That would sure break > the idea of copyleft to pieces. Yes, that's correct. > Such a work might not "contain" any of the creative work that went > into making the original software, if you construe "contain" in a very > literal sense. The law does have a preference for the literal. > But it is completely dependent on the original > creativity. Without the creativity of the original author, the > modified work could not meaningfully exist -- it is an extension of > the original work, not something independent. I don't think that argument is particularly convincing. A review of a movie is completely dependent on the creative content of the movie, that doesn't mean the copyright holders of the movie have the right to restrict the distribution of the review. > This is what makes it a > derivative work in the view of the lawyers employed by the FSF and > SFLC, inter alia. (I wonder what Wikimedia's counsel thinks.) The FSF and SFLC have agendas. They make implausible arguments and justify them by the ends they achieve. I'll believe their interpretation when it's upheld in court. -- Tim Starling ___ 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 Mon, Jul 26, 2010 at 7:54 PM, Tim Starling wrote: > The law does have a preference for the literal. Except that it doesn't say that a derivative work must contain parts of the base work, or even be similar to it. It says that a derivative work is just "a work based upon one or more preexisting works". It goes on to say, "A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a 'derivative work'." Would you say that a set of patches (in any form) is not "a work consisting of editorial revisions . . . or other modifications which, as a whole, represent an original work of authorship"? > I don't think that argument is particularly convincing. A review of a > movie is completely dependent on the creative content of the movie, > that doesn't mean the copyright holders of the movie have the right to > restrict the distribution of the review. Reviews might be derivative works, but if so, they're permitted under fair use. Indeed, reviews are one of the standard examples of fair use (although the standard application is when they actually copy parts of the work they're reviewing). > The FSF and SFLC have agendas. They make implausible arguments and > justify them by the ends they achieve. I'll believe their > interpretation when it's upheld in court. The interpretation of a lawyer with an agenda is unreliable, but not so unreliable that laymen can second-guess them. At most, a layman can suspend judgment in the absence of unbiased expert opinion, not draw his own conclusions. ___ 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 27 July 2010 00:54, Tim Starling wrote: > The FSF and SFLC have agendas. They make implausible arguments and > justify them by the ends they achieve. I'll believe their > interpretation when it's upheld in court. So far, in GPL enforcement, they're batting 1.000. So I can certainly understand your scepticism ... er. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Code Review: new eyes
I'm new to the Mediawiki codebase, but after going to Wikimania, I've been impressed with the need for more eyes on Code Review. Since I'm still learning my way around, I won't be able to approve any code (e.g. mark it “ok”) but I can offer feedback where it might be helpful. Right now, I'm focusing on Core, LiquidThreads and the Usability Initiative extensions. If you have an extension that you'd like feedback on, let me know and I'll have a look. I do not pretend to have Tim's expertise, so this is not a substitute for his review, but it could be a way to get some preliminary feedback as well as helping me to become more familiar with various parts of MediaWiki and its components and extensions. Your friendly code gnome, Mark. -- http://hexmode.com/ Embrace Ignorance. Just don't get too attached. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
