Web Browser Licensing
Ken Vermette <[email protected]> Mon, 6 Jul 2015 16:52:12 -0400
| Newsgroups | gmane.comp.kde.licensing |
|---|---|
| Message-ID | <CAFtcy6xfXFaBAUH=Ou1HynQjZZmc52_HeHetUNPr61s-NkEzDQ@mail.gmail.com> |
--===============2512037017696190548== Content-Type: multipart/alternative; boundary=047d7b33906b73b5d4051a3b14f5 --047d7b33906b73b5d4051a3b14f5 Content-Type: text/plain; charset=UTF-8 Hello! I have a question on licensing for a project I'm currently working on; The project is a web-browser with strong KDE integration, and an extension-oriented design encouraging third-party extension development. I've been told that I should follow the KDE licensing policies now, in case later this would be put for consideration as an official KDE project. The browser is almost entirely based on extensions, and I'd like to encourage a rich and robust extension ecosystem. My question comes with ensuring that 3rd party developers who might make extensions for the browser are not restricted in the licensing they choose. The most permissive licences allowed in the KDE licensing policy are MIT, BSD, and LGPL; I'm uninterested in MIT and BSD, which leaves LGPL. My issue comes in an LGPL/GNU statement which considers a plugin which extends a class provided by a GPL/LGPL application as a derivative work; this technical detail concerns me because it muddies the waters of how an implementation can be done, and I'd like developing extensions for this browser to be absolutely safe. This isn't helped by the fact that ECMA now has an "extends" keyword. The Mozilla Public Licence is similar to the LGPL, only it allows for unrestricted linking. There are also projects which have what's called a "linking exception" where the project allows its GPL/LGPL code to be linked, specifically without imposing any licence restrictions. If this were an option, I would be interested in GPL. So, I guess I'd like to ask what might be reccomended to both comply with the KDE licensing policy, while also ensuring any potential extension developers are unencumbered in their choice of licence; 1. Could I use the MPL and still potentially have this project become official? 2. Could I use the GPL or LGPL with a link exception? 3. Could I dual-licence the project somehow? MPL/GPL? 4. Something I haven't considered? Thank you. If there are any questions I'll be happy to answer. - Ken Vermette --047d7b33906b73b5d4051a3b14f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div>Hello! I have a question on licensing for a proj= ect I'm currently working on;<br><br></div>The project is a web-browser= with strong KDE integration, and an extension-oriented design encouraging = third-party extension development. I've been told that I should follow = the KDE licensing policies now, in case later this would be put for conside= ration as an official KDE project.<br><br></div><div>The browser is almost = entirely based on extensions, and I'd like to encourage a rich and robu= st extension ecosystem. My question comes with ensuring that 3rd party deve= lopers who might make extensions for the browser are not restricted in the = licensing they choose.<br><br>The most permissive licences allowed in the K= DE licensing policy are MIT, BSD, and LGPL; I'm uninterested in MIT and= BSD, which leaves LGPL. My issue comes in an LGPL/GNU statement which cons= iders a plugin which extends a class provided by a GPL/LGPL application as = a derivative work; this technical detail concerns me because it muddies the= waters of how an implementation can be done, and I'd like developing e= xtensions for this browser to be absolutely safe. This isn't helped by = the fact that ECMA now has an "extends" keyword. The Mozilla Publ= ic Licence is similar to the LGPL, only it allows for unrestricted linking.= <br><br>There are also projects which have what's called a "linki= ng exception" where the project allows its GPL/LGPL code to be linked,= specifically without imposing any licence restrictions. If this were an op= tion, I would be interested in GPL.<br><br></div><div>So, I guess I'd l= ike to ask what might be reccomended to both comply with the KDE licensing = policy, while also ensuring any potential extension developers are unencumb= ered in their choice of licence; <br><ol><li>Could I use the MPL and still = potentially have this project become official? </li><li>Could I use the GPL= or LGPL with a link exception? </li><li>Could I dual-licence the project s= omehow? MPL/GPL?<br></li><li>Something I haven't considered?</li></ol><= p>Thank you. If there are any questions I'll be happy to answer.<br>=C2= =A0- Ken Vermette<br></p></div></div> --047d7b33906b73b5d4051a3b14f5-- --===============2512037017696190548== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KS2RlLWxpY2Vu c2luZyBtYWlsaW5nIGxpc3QKS2RlLWxpY2Vuc2luZ0BrZGUub3JnCmh0dHBzOi8vbWFpbC5rZGUu b3JnL21haWxtYW4vbGlzdGluZm8va2RlLWxpY2Vuc2luZwo= --===============2512037017696190548==--