Re: [webkit-dev] WebKit licensing and LGPLv3
On Wednesday 25 July 2007 01:51, Maciej Stachowiak wrote: 1) We will continue to accept only code that's licensed under a BSD- style (no advertising clause) license, or LGPL 2.1, or other compatible license. We don't want to accept code that's LGPL 3 only, as that would make the whole project LGPL 3. I think continuing to require LGPL 2 or later would be the most sane and most compatible. 2) We'd like to change the copyright notices from their current mix of LGPL 2 or any later version and LGPL 2.1 or any later version to just LGPL 2.1, to make this clear. This one is maybe more debatable, so I'd like to know if anyone objects. It would prevent incorporating WebKit code into LGPL 3 projects, and would require sign-off from all copyright holders to ever change to a different LGPL version in the future (in case the FSF came out with a version 3.1 or 4 that solved some of the problems with v3). I object. I would like to reserve the right to integrate WebKit with LGPL 3 projects like future KDE libs. Though since we are talking LGPL the linking-issues are not that problematic, it would still make it easier if the project continued to include the or later clause. Regards `Allan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Project Goals
Would it not be worth making an explicit goal of accessibility, or at least explicitly bracketing it under usability? -- Benjamin Hawkes-Lewis On 7/25/07, Maciej Stachowiak [EMAIL PROTECTED] wrote: I sent this a while ago with not much comment. Any thoughts? Should I post this on webkit.org somewhere? - Maciej On May 10, 2007, at 3:34 PM, Maciej Stachowiak wrote: Hi Everyone, I recently watched a video on the topic of preventing poisonous people from hurting an open source project. One of the practices it recommends for a large open source project is to have a mission statement, so it's clear to everyone what is and isn't in scope for the project. I'm not too fond of the name mission statement (it sounds a little corporate) but I do think it's important to write down our goals as a project. Ultimately I'd like to put this on the WebKit site, but I wanted to throw out some ideas for discussion. I'd like to hear if anyone thinks I have missed any project goals, if any of these are worded badly, or if it is worth calling out more non-goals. WebKit Project Goals WebKit is an open source Web content engine for browsers and other applications. We value real-world web compatibility, standards compliance, stability, performance, security, portability, usability and relative ease of understanding and modifying the code (hackability). Web Content Engine - The project's primary focus is content deployed on the World Wide Web, using standards-based technologies such as HTML, CSS, JavaScript and the DOM. However, we also want to make it possible to embed WebKit in other applications, and to use it as a general-purpose display and interaction engine. Open Source - WebKit should remain freely usable for both open source and proprietary applications. To that end, we use BSD-style and LGPL licenses. Compatibility - For users browsing the web, compatibility with their existing sites is essential. We strive to maintain and improve compatibility with existing web content, sometimes even at the expense of standards. We use regression testing to maintain our compatibility gains. Standards Compliance - WebKit aims for compliance with relevant web standards, and support for new standards In addition to improving compliance, we participate in the web standards community to bring new technologies into standards, and to make sure new standards are pratical to implement in our engine. We use regression testing to maintain our standards compliance gains. Stability - The main WebKit code base should always maintain a high degree of stability. This means that crashes, hangs and regressions should be dealt with promptly, rather than letting them pile up. Performance - Maintaining and improving speed and memory use is an important goal. We never consider performance good enough, but strive to constantly improve. As web content becomes richer and more complex, and as web browsers run on more limited devices, performance gains continue to have value even if normal browsing seems fast enough. Security - Protecting users from security violations is critical. We fix security issues promptly to protect users and maintain their trust. Portability - The WebKit project seeks to address a variety of needs. We want to make it reasonable to port WebKit to a variety of desktop, mobile, embedded and other platforms. We will provide the infrastructure to do this with tight platform integration, reusing native platform services where appropriate and providing friendly embedding APIs. Usability - To the extent that WebKit features affect the user experience, we want them to work in accordance with good human interface design principles, and to mesh well with platform-native HI conventions. Hackability - To make rapid progress possible, we try to keep the code relatively easy to understand, even though web technologies are often complex. We try to use straightforward algorithms and data structures when possible, we try to write clear, maintainable code, and we continue to improve names and code structure to aid understanding. When tricky rocket science code is truly needed to solve some problem, we try to keep it bottled up behind clean interfaces. Non-Goals WebKit is an engine, not a browser. We do not plan to develop or host a full-featured web browser based on WebKit. Others are welcome to do so, of course. WebKit is an engineering project not a science project. For new features to be adopted into WebKit, we strongly prefer for the technology or at least the use case for it to be proven. WebKit is not a bundle of maximally general and reusable code - we build some general-purpose parts, but only to the degree needed to be a good web content engine. WebKit is not the solution to every problem. We focus on web content, not complete solutions to every imaginable technology need. ___ webkit-dev
Re: [webkit-dev] WebKit licensing and LGPLv3
Hi Maciej, Maciej Stachowiak wrote: 1) We will continue to accept only code that's licensed under a BSD-style (no advertising clause) license, or LGPL 2.1, or other compatible license. We don't want to accept code that's LGPL 3 only, as that would make the whole project LGPL 3. As I understand it, yes (standard IANAL disclaimer here). I have no objects with this. 2) We'd like to change the copyright notices from their current mix of LGPL 2 or any later version and LGPL 2.1 or any later version to just LGPL 2.1, to make this clear. This one is maybe more debatable, so I'd like to know if anyone objects. It would prevent incorporating WebKit code into LGPL 3 projects, and would require sign-off from all copyright holders to ever change to a different LGPL version in the future (in case the FSF came out with a version 3.1 or 4 that solved some of the problems with v3). I think sticking with LGPL 2 or any later version might be best for now. The reason I say this is it puts fewer limits on what GPL projects WebKit, or parts of WebKit (I suppose), can be incorporated into. Personally, I am not a big fan of (L)GPL v3 (although, I have not really followed it since the first draft), but I still think that it is good to be as less restrictive as possible, in certain senses. -Donald Kirker ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit licensing and LGPLv3
On Wednesday 25 July 2007, Allan Sandfeld Jensen wrote: On Wednesday 25 July 2007 01:51, Maciej Stachowiak wrote: 1) We will continue to accept only code that's licensed under a BSD- style (no advertising clause) license, or LGPL 2.1, or other compatible license. We don't want to accept code that's LGPL 3 only, as that would make the whole project LGPL 3. I think continuing to require LGPL 2 or later would be the most sane and most compatible. Accepting LGPL 3 only code is not something we should do, as it would lead to more restrict licensing terms than we currently have. 2) We'd like to change the copyright notices from their current mix of LGPL 2 or any later version and LGPL 2.1 or any later version to just LGPL 2.1, to make this clear. This one is maybe more debatable, so I'd like to know if anyone objects. It would prevent incorporating WebKit code into LGPL 3 projects, and would require sign-off from all copyright holders to ever change to a different LGPL version in the future (in case the FSF came out with a version 3.1 or 4 that solved some of the problems with v3). I object. I would like to reserve the right to integrate WebKit with LGPL 3 projects like future KDE libs. Though since we are talking LGPL the linking-issues are not that problematic, it would still make it easier if the project continued to include the or later clause. I have to agree with Allan. Restricting it to 2.1 only might give open source projects (KDE being one of them) problems in the future. I don't see a need to change the license to become more restrictive than it has been in the past. As a sidenote, since we're already talking about licensing: I don't quite see the benefits of having a mix of BSD and LGPL licenses. LGPL is more restrictive, so that one applies to the project as a whole anyways. Wouldn't it be easier to just have one license (LGPL 2.1 or later) for the complete code base? Cheers, Lars ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Project Goals
On Wednesday 25 July 2007, Maciej Stachowiak wrote: I sent this a while ago with not much comment. Any thoughts? Should I post this on webkit.org somewhere? I like both the goals and non-goals. Please put it onto webkit.org. Cheers, Lars - Maciej On May 10, 2007, at 3:34 PM, Maciej Stachowiak wrote: Hi Everyone, I recently watched a video on the topic of preventing poisonous people from hurting an open source project. One of the practices it recommends for a large open source project is to have a mission statement, so it's clear to everyone what is and isn't in scope for the project. I'm not too fond of the name mission statement (it sounds a little corporate) but I do think it's important to write down our goals as a project. Ultimately I'd like to put this on the WebKit site, but I wanted to throw out some ideas for discussion. I'd like to hear if anyone thinks I have missed any project goals, if any of these are worded badly, or if it is worth calling out more non-goals. WebKit Project Goals WebKit is an open source Web content engine for browsers and other applications. We value real-world web compatibility, standards compliance, stability, performance, security, portability, usability and relative ease of understanding and modifying the code (hackability). Web Content Engine - The project's primary focus is content deployed on the World Wide Web, using standards-based technologies such as HTML, CSS, JavaScript and the DOM. However, we also want to make it possible to embed WebKit in other applications, and to use it as a general-purpose display and interaction engine. Open Source - WebKit should remain freely usable for both open source and proprietary applications. To that end, we use BSD-style and LGPL licenses. Compatibility - For users browsing the web, compatibility with their existing sites is essential. We strive to maintain and improve compatibility with existing web content, sometimes even at the expense of standards. We use regression testing to maintain our compatibility gains. Standards Compliance - WebKit aims for compliance with relevant web standards, and support for new standards In addition to improving compliance, we participate in the web standards community to bring new technologies into standards, and to make sure new standards are pratical to implement in our engine. We use regression testing to maintain our standards compliance gains. Stability - The main WebKit code base should always maintain a high degree of stability. This means that crashes, hangs and regressions should be dealt with promptly, rather than letting them pile up. Performance - Maintaining and improving speed and memory use is an important goal. We never consider performance good enough, but strive to constantly improve. As web content becomes richer and more complex, and as web browsers run on more limited devices, performance gains continue to have value even if normal browsing seems fast enough. Security - Protecting users from security violations is critical. We fix security issues promptly to protect users and maintain their trust. Portability - The WebKit project seeks to address a variety of needs. We want to make it reasonable to port WebKit to a variety of desktop, mobile, embedded and other platforms. We will provide the infrastructure to do this with tight platform integration, reusing native platform services where appropriate and providing friendly embedding APIs. Usability - To the extent that WebKit features affect the user experience, we want them to work in accordance with good human interface design principles, and to mesh well with platform-native HI conventions. Hackability - To make rapid progress possible, we try to keep the code relatively easy to understand, even though web technologies are often complex. We try to use straightforward algorithms and data structures when possible, we try to write clear, maintainable code, and we continue to improve names and code structure to aid understanding. When tricky rocket science code is truly needed to solve some problem, we try to keep it bottled up behind clean interfaces. Non-Goals WebKit is an engine, not a browser. We do not plan to develop or host a full-featured web browser based on WebKit. Others are welcome to do so, of course. WebKit is an engineering project not a science project. For new features to be adopted into WebKit, we strongly prefer for the technology or at least the use case for it to be proven. WebKit is not a bundle of maximally general and reusable code - we build some general-purpose parts, but only to the degree needed to be a good web content engine. WebKit is not the solution to every problem. We focus on web content, not complete solutions to every imaginable technology need.
Re: [webkit-dev] WebKit licensing and LGPLv3
Hi Allan, I've forwarded your comments and those of others internally at Apple. I won't do #2 for moment. I'd still appreciate any other input on this point. Regards, Maciej On Jul 24, 2007, at 11:05 PM, Allan Sandfeld Jensen wrote: On Wednesday 25 July 2007 01:51, Maciej Stachowiak wrote: 1) We will continue to accept only code that's licensed under a BSD- style (no advertising clause) license, or LGPL 2.1, or other compatible license. We don't want to accept code that's LGPL 3 only, as that would make the whole project LGPL 3. I think continuing to require LGPL 2 or later would be the most sane and most compatible. 2) We'd like to change the copyright notices from their current mix of LGPL 2 or any later version and LGPL 2.1 or any later version to just LGPL 2.1, to make this clear. This one is maybe more debatable, so I'd like to know if anyone objects. It would prevent incorporating WebKit code into LGPL 3 projects, and would require sign-off from all copyright holders to ever change to a different LGPL version in the future (in case the FSF came out with a version 3.1 or 4 that solved some of the problems with v3). I object. I would like to reserve the right to integrate WebKit with LGPL 3 projects like future KDE libs. Though since we are talking LGPL the linking-issues are not that problematic, it would still make it easier if the project continued to include the or later clause. Regards `Allan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Debug the webkit on windows platform
Hello Has anyone debug webkit on the Window platform, I am able to build and run ./run-webkit --debug, but wanted to know if i need to set the breakpoint and do step by step debugging to uderstand the code, how can i proceeds. I hope it should be able to link with VS 2005 to debug webkit. but i am not able to get it how. Please help me if anyone knows Thanks in Advance -- Regards Amit ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Debug the webkit on windows platform
On Jul 25, 2007, at 5:32 AM, Amit Gupta wrote: Hello Has anyone debug webkit on the Window platform, I am able to build and run ./run-webkit --debug, but wanted to know if i need to set the breakpoint and do step by step debugging to uderstand the code, how can i proceeds. I hope it should be able to link with VS 2005 to debug webkit. but i am not able to get it how. You can find some information on debugging WebKit on Windows at http://webkit.org/building/debug.html . It would be great if someone could beef up the information on that page for Windows. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] The Application Data Folder for Visual C++ Express could not be created
Hi all! I still trying to compile webkit under Windows XP. I have done everything as mentioned on the web page. But if I try build it, I get a popup window with the following message: The Application Data Folder for Visual C++ Express could not be created I also tried to run Visual C++ from cygwin like this: $ /cygdrive/c/Program Files/Microsoft Visual Studio 8/Common7/IDE/VCExpress.exe , and I also got the same error message. If I run Visual C++ from a 'normal' command promt like this: c:\Program Files\Microsoft Visual Studio 8\Common7\IDE\VCExpress.exe , it starts without any error message. Any ideas about what am I doing wrong? Thanx, Tamas 2800 állásból Te is találsz megfelelőt! Mérnöki, értékesítői, asszisztensi, pénzügyi és IT állások a Jobline.hu-n! www.jobline.hu http://ad.adverticum.net/b/cl,1,6022,186603,243027/click.prm ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Javascript collector
On Jul 25, 2007, at 1:02 PM, Patrick Hanna wrote: I am running into a segmentation fault in Collector::collectOnMainThreadOnly on the line that reads: cellBlock(cell)-collectOnMainThreadOnly.set(cellOffset(cell)); I believe that the reason is because the address passed in as 'value' is the address of a stack variable. This address comes from PluginsFunc::callAsFunction. PluginBase is created on the stack and the constructor for DOMObject calls Collector::collectOnMainThreadOnly with 'this' as the parameter. My question is, should Collector::collectOnMainThreadOnly work with stack pointers? If it is supposed to work, when does the CollectorBlock for the stack object get created? Specificy, CollectorBlock::collectOnMainThreadOnly is the structure that I'm running in to problems with. That's definitely a bug. It's illegal to create JSObject subclasses on the stack at all, as this will break garbage collection. Please file it. I think it's only through luck that it's not crashing for others (and maybe it is, but we just don't know it yet.) Two possible solutions: 1) make refresh() a static member function of PluginBase, since it only touches static data members anyway. Then you won't need to instantiate a PluginBase object. 2) Have PluginFuncs look at the this object, which should be a Plugins, which inherits from PluginBase and thus should have the refresh method. Do you have steps to consistently reproduce this bug? Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
