Re: [webkit-dev] WebKit licensing and LGPLv3

2007-07-25 Thread Allan Sandfeld Jensen
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

2007-07-25 Thread Benjamin Hawkes-Lewis

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

2007-07-25 Thread Donald C. Kirker

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

2007-07-25 Thread Lars Knoll
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

2007-07-25 Thread Lars Knoll
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

2007-07-25 Thread Maciej Stachowiak


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

2007-07-25 Thread Amit Gupta

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

2007-07-25 Thread Adam Roben

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


Re: [webkit-dev] WebKit licensing and LGPLv3

2007-07-25 Thread Christopher Brichford


On Jul 24, 2007, at 4:51 PM, Maciej Stachowiak wrote:



Hi Everyone,

With the release of GPLv3 and LGPLv3, I'd like to take a moment to  
discuss WebKit licensing. LGPLv3 includes some restrictions beyond  
the previous version that make it difficult to accept for many key  
contributors and users of WebKit, including Apple. Given this, we'd  
like to keep the project at LGPL 2.1, to make sure it can be used  
in all the ways it is used today.


To that end we'd like to do two things:

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.




Sounds good to me.  I'd prefer BSD-style licensing whenever possible.


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).




Does not matter to me as long as I can continue to use the version of  
the LGPL I am using today.



Chris

___
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

2007-07-25 Thread Nagy Tamás
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

2007-07-25 Thread Maciej Stachowiak


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