Re: [License-discuss] Is what's made with Open Source, Open Source?
On 10/06/2015 12:33, Gareth Edwards wrote: The big thing everyone wants to know (and no-one seems to be able to answer), is are the apps made with Rapid also Open Source, i.e. are app creators obliged to share the code and files for apps they've made using Rapid with the rest of the Rapid community? Hello, This post might seem a bit long - I'm just throwing a few ideas up into the air here with the usual disclaimers and hoping others will comment and correct me where I'm wrong. I had a quick look at Rapid - sounds interesting and something that I would certainly find useful for, ahem, /rapid/ development and prototyping and for building admin interfaces for backends :) To answer your question in brief - not typically. There would be two ways of looking at the question of whether the apps made wth Rapid [are] also Open Source: 1.the licensing terms of Rapid require app developers to release any applications created with it under a specified licence (e.g. GPLv3); or 2.apps built on Rapid are derivative works of Rapid itself and therefore remain within the GPLv3 Regarding point one, the GPLv3 doesn't allow for this. If it did, for example, documents made with LibreOffice would themselves be licensed under the GPLv3. Technically I think it would be possible for such a licence to still be compatible with the Open Source Definition, although I can't name a licence like that off the top of my head. With respect to point two, you'd need to show that the apps built using Rapid are actually derived works. From the viewpoint of the Free Software Foundation, they would probably see that as the apps are completely dependent on Rapid, perhaps moreso than a software library, the apps would therefore form derivative works and be licensed under the GPL. I don't know how successful that argument would be in court, and especially here as the apps are not seen as modifications or improvements to Rapid but instead apps in their own right which are merely interpreted by/linked to Rapid. Another thing to note is that the GPL only really takes effect on distribution or propagation of software. Therefore, even if apps were somehow required to be licensed under the GPLv3 or were otherwise considered derivative works, app creators wouldn't actually be obliged to share the code and files with others where they were merely developing the apps for their own use. It's only where the developer wants to give (or make available) the app to other people/entities where that developer would be required to release the source code for that app. TL;DR - if you really want to make sure that the apps created with Rapid are themselves open source then you'd probably want some form of custom OSD-compatible software licence. Regards, Max ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Is what's made with Open Source, Open Source?
On 11/06/2015 20:47, co...@ccil.org wrote: I think it would require that the recipient explicitly accept the license as a requirement to getting LibreOffice (or whatever), which would make it not Open Source. Possibly, and I would have thought that it would require more than a mere copyright licence could grant - I just used it as a relatively crude hypothetical example and I'm glad the GPL doesn't work that way! On 11/06/2015 20:47, co...@ccil.org wrote: With respect to point two, you'd need to show that the apps built using Rapid are actually derived works. From the viewpoint of the Free Software Foundation, they would probably see that as the apps are completely dependent on Rapid, perhaps moreso than a software library, the apps would therefore form derivative works and be licensed under the GPL. Almost certainly not. Before open-source Java systems existed, the FSF discouraged people from writing free Java apps, but didn't deny that an app released under a free license was free. See http://www.gnu.org/philosophy/java-trap.en.html; there is no longer a Java trap, of course. To be clear, I'm of the mindset that Rapid's current licence does not require apps developed with it to themselves be licensed under an open source licence, and I give the possiblity it being a derivative work as just that - a possiblity. I do maintain that it's a possibility due to the longstanding debate and uncertainty over whether dynamic linking is sufficient to create a derivative work under the terms of the GPLv3, and say if an app developer wanted to make an app using Rapid and release the app solely under a proprietary licence, this is something that developer ought to give some thought to. On 11/06/2015 20:53, Gareth Edwards wrote: Over on my Reddit post (http://redd.it/39gpcy) there's a reply that as Rapid is a server platform it doesn't get distributed like a typical desktop application so GPLv3 doesn't apply, and AGPLv3 should be used instead. Giving AGPL a quick read this makes sense to me, but not having heard of it before I wondered whether AGPL was sound and/or a better choice? The AGPL might well be preferable to the GPL in this scenario, as (and I quote from the AGPLv3 itself) if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge. Therefore distribution of the program itself isn't the sole 'trigger' but also where an end-user actually uses the app then they would have a right to the source code under the same terms. ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] International Licenses
Presumably the European Union Public Licence was discussed during that meeting (and I note it here for those who haven't yet come across it). https://joinup.ec.europa.eu/software/page/eupl/licence-eupl Whilst I make no comment as to the content of the licence, it boasts official translations and compatibility with 22 European languages and therefore IMHO is a good yardstick to consider/compare other international multilingual licences by. Max On 5 Jun 2015 02:53, Mike Milinkovich m...@opensource.org wrote: At our last face-to-face meeting, the OSI Board discussed the topic of FLOSS licenses targeted at specific languages and jurisdictions. As you can imagine, with the interest in reducing license proliferation, the conversation was quite lively. However, if we want open source to be a truly worldwide movement, it seems unreasonable to insist that English be the only language allowed. As a result, we would like to propose the following: A new category of open source licenses would be created for those targeting specific languages and jurisdictions. The normal public license review process would be used to debate the merits of the license. However, we would add a criteria targeted at preventing code under the class of licenses from being orphaned. (This may, for example, be addressed in candidate licenses by explicitly allowing re-licensing under other well-known licenses.) A certified English translation must accompany the license. We require a certified English language translation of the license in order to conduct the license review process, which uses open discussion between many people who share English as a second language regardless of their first language. Submitters can meet this requirement by accompanying the translation with an affidavit from the translator on which the translator has sworn, in the presence of a commissioner authorized to administer oaths in the place where the affidavit is sworn, that the contents of the translation are a true translation and representation of the contents of the original document. The affidavit must include the date of the translation and the full name and contact details of the translator. When you offer your license(s) to the review process, you should be aware that change to the license is probable and be prepared to iterate. Certified translations will not be essential for every iteration but the final iteration must be accompanied by a certified translation. We would appreciate your thoughts and comments. ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Strong and weak copyleft
Interesting - I always thought that the distinction between strong and weak copyleft was in respect of how the code is linked. Are there any/many examples however of weak copyleft given that definition? I would have thought that weak copyleft under that definition would be largely ineffective, as it would be easy enough to hide any modifications to third-party copyleft code in other proprietary source files with function calls. Therefore, ought the definition of weak copyleft extend to include any code additionally referred to in the third party source file? Also, ought then the distinction not be on how individual source files are licenced, but instead the subdivisions (e.g. functions) within the source files? This has probably already been considered and dealt with before - I'm just being verbose and thinking out loud in my lunch break. -- Maximilian On 07/04/2015 19:40, Simon Phipps wrote: It looks like you may consider LGPL to be a weak copyleft license; my apologies if you don't! But if you do... I do not believe the LGPL to be a weak copyleft license. Strong copyleft implies that the scope of the required reciprocity is the source needed to create the distributed binary, while weak copyleft implies that scope to be the altered source file alone. The LGPL requirements, like those of the GPL, are scoped at the distributed binary, but there is a restriction to what constitutes the distributed binary. Thus I refer to LGPL as scope-limited strong copyleft and discourage clients from regarding it as weak copyleft. Treating LGPL as weak copyleft is a dangerous thing to do as, in the absence of conditions to make the limitation of scope apply, LGPL has all the same consequences as GPL. S. On Tue, Apr 7, 2015 at 7:29 PM, Ben Tilly bti...@gmail.com wrote: I believe that the legal key is distribution of the licensed code, not linking to it. The LGPL defines a Combined Work and has requirements on what is required when you distribute a combined work together. The intent is clearly that if you distribute the combined work together and DO NOT meet those conditions, then you had no permission to distribute the LGPLed code. And this has force because while the proprietary half of a combined work is not a derived work, you still need permission to distribute some else's copyrighted code and that permission was contingent on what you did with your application. The GPL defines a covered work to be, either the unmodified Program or a work based on the Program. Later in the license a distinction is drawn between that and mere aggregation. The intent is that distributing your program + the covered GPLed code it depends on creates a work and you need GPL permission to have distributed the covered GPLed code. (Whether a judge will agree with this interpretation is another question, but I'm pretty sure that the license drafters intended a judge to understand it this way.) With that said, the LGPL gives a lot of license flexibility for your part of the combined work but says you must allow reverse engineering. Which by default is allowed in many places, but is something that many proprietary licenses take away. By contrast the GPL offers no real alternative but to license the code you own under the GPL. Therefore LGPLed code keeps itself copylefted but does not encourage developers to GPL their own code. While GPLed code pushes people who want to use that code to have to GPL the code that they wrote. On Tue, Apr 7, 2015 at 10:23 AM, Lawrence Rosen lro...@rosenlaw.com wrote: Patrice-Emmanuel Schmitz referred me to this thought-provoking link: https://joinup.ec.europa.eu/community/eupl/news/meaning-%E2%80%9Ccopyleft%E2%80%9D-eupl Can anyone here precisely identify the language in the GPL licenses that makes it strong rather than weak copyleft? And can anyone here identify anything in copyright law or cases that allow this distinction in the meaning of derivative work? /Larry ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Undistributable binaries and network services
On 13/03/2015 00:07, ChanMaxthon wrote: Sometimes licenses conflict, producing a non-distributable mess of licenses for a piece of code. Using my such code internally is not that much of a problem but what if I used such piece of code in a web application? My project involves transcoding video files on the cloud, hard dubbing the subtitles and emitting multiple formats. The service used a version of libav that is linked in a non-distributable fashion. Will that cause me any trouble? Sent from my iPhone ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss I would have thought that the answer to your question depends on exactly how each software component is licensed, and I'll assume here that the components your project uses are licensed under typical open source licences. As you won't be distributing the software, just running it, the fact that it is linked in a way which is not distributable should not matter as you're merely distributing the output of the software and not the software itself. So it's quite likely that it would be fine. If on the other hand you're linking with something licensed under the AGPL then you would be obliged to make the source code available to users of your web application. Whilst this provision should not conflict with the fact that your build of the software is linked in a way which you say cannot be distributed, you would need to release the (complete) source. If anyone else can add to this please do, as I have a feeling I'm missing something out here... -- Maximilian ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Reverse Engineering and Open Source Licenses
On 11/03/2015 01:07, John Cowan wrote: No, of course not. But when I buy the book, the first-sale right is exhausted; when I buy proprietary software, it is not, and I have no right to resell. The difference is that the book is purchased whereas the proprietary software is only licensed. Just to add here that in the European Union, following the Usedsoft v Oracle decision (case C-128/11), the right of the developer/copyright owner to control distribution is indeed exhausted after first sale and proprietary licensed software *can* be resold despite any clause in the licence to the contrary. Of course, this requires that the licence is not for a fixed time period and that any DRM controls would not be interferred with in the process, but hey it's a start! -- Maximilian ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
