Re: [License-discuss] [Non-DoD Source] Re: US Army Research Laboratory Open Source License proposal

[Richard Eckart de Castilho]

Hi Cem,

> On 25.07.2016, at 18:41, Karan, Cem F CIV USARMY RDECOM ARL (US) 
>  wrote:
> 
> OK at this point I want to start another discussion about the license 
> (attached once again, with the minor correction of stripping out the word 
> 'Apache', which I'd left in earlier).  Is the license compatible with Apache 
> 2.0 and the licenses that Apache 2.0 is compatible with?  If not, why not?

This list is IMHO not the right place to ask whether your license would be
compatible with the Apache License 2.0. You should post that question on
the legal-discuss list of Apache (legal-disc...@apache.org). 

Mind there have been requests to Apache from USG-affiliated people requesting
the Apache license to be changed - these have been discussed but rejected. Your
approach to create a new license seems kind of novel in that respect.

When it comes to compatibility, the question is what you actually mean by that.
I see multiple questions:

- Is there any conflict between the terms in your license and the Apache 
license?

- If there are conflicts, are they one-way? I.e. can at least a work under your
  license include code under the Apache license or vice versa?

Finally there is a policy question. If your desire is that Apache (or parties
following the Apache-view of third-party license management) should be able to
make used of code under your license, then you should check out this page:

  http://www.apache.org/legal/resolved.html#category-a 

If you can get Apache to add your license to that list under "considered to be 
similar", that should be a strong blessing.

If you bring up the topic with Apache, I would recommend you state your
expectations/wishes regarding license compatibility and policy separately
trying to avoid the two aspects to be mingled up in the discussion.

Best,

-- Richard
___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] [Non-DoD Source] Re: US Army Research Laboratory Open Source License proposal

[Richard Eckart de Castilho]

Hi Cem,

> On 25.07.2016, at 18:41, Karan, Cem F CIV USARMY RDECOM ARL (US) 
>  wrote:
> 
> OK at this point I want to start another discussion about the license 
> (attached once again, with the minor correction of stripping out the word 
> 'Apache', which I'd left in earlier).  Is the license compatible with Apache 
> 2.0 and the licenses that Apache 2.0 is compatible with?  If not, why not?

This list is IMHO not the right place to ask whether your license would be
compatible with the Apache License 2.0. You should post that question on
the legal-discuss list of Apache (legal-disc...@apache.org). 

Mind there have been requests to Apache from USG-affiliated people requesting
the Apache license to be changed - these have been discussed but rejected. Your
approach to create a new license seems kind of novel in that respect.

When it comes to compatibility, the question is what you actually mean by that.
I see multiple questions:

- Is there any conflict between the terms in your license and the Apache 
license?

- If there are conflicts, are they one-way? I.e. can at least a work under your
  license include code under the Apache license or vice versa?

Finally there is a policy question. If your desire is that Apache (or parties
following the Apache-view of third-party license management) should be able to
make used of code under your license, then you should check out this page:

  http://www.apache.org/legal/resolved.html#category-a 

If you can get Apache to add your license to that list under "considered to be 
similar", that should be a strong blessing.

If you bring up the topic with Apache, I would recommend you state your
expectations/wishes regarding license compatibility and policy separately
trying to avoid the two aspects to be mingled up in the discussion.

Best,

-- Richard
___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

[License-discuss] Option to fall back from GPL to ASL

[Richard Eckart de Castilho]

Hi all,

I am relatively new here, yet this seems to be the most appropriate venue to 
ask a question that has been nagging me for a while now.

I'm involved in a project that consists of multiple modules, most are ASL 
licensed, but some are GPL licensed.

The reason why we use GPL for a few modules is that these modules have make use 
of GPLed libraries - and our understand is that due to the reciprocal 
licensing, that means our code must be GPL-licensed as well. 

However, we actually would prefer if all our code was basically under the ASL 
because that makes it much easier for us to refactor stuff and move code 
between modules if necessary.

So part of this situation is covered by a contributor license agreement which 
says that everything that goes into the GPLed modules is essentially covered by 
ASL terms and conditions.

However, the CLA we get isn't handed down to the users of our modules. So 
they essentially only see the GPL license on some modules.

So why does this bother us?

Lets say we have module FOO which depends on the library BAR which is GPL - so 
we release FOO under GPL.

The vendors of BAR also offer a commercial license for BAR. If somebody buys 
that license, we want them to be able to use FOO under the commercial-friendly 
ASL terms without having to give them any extra permission. Right now, those 
people would still face the GPL label on FOO even though they removed it for 
themselves from BAR by buying a license.

I wonder if it was valid to add a statement like

This software is provided under the terms of the GPL *as long as mandated by 
the reciprocal terms of libraries used by this software*. Any code removed from 
this software falls back to ASL unless it continues to depend on GPL code. 
Likewise, all code automatically becomes ASL if it no longer depends on GPL 
code, e.g. through alternative license agreements with the vendors of the 
respective code.

Or if anybody has faced a similar situation, it would be great to hear how you 
have resolved it.

Cheers,

-- Richard
___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Category B licenses at Apache

[Richard Eckart de Castilho]

Hi Larry,

On 17.08.2015, at 21:20, Lawrence Rosen lro...@rosenlaw.com wrote:

 snip
 
 But then that Policy makes the following strange explanation for Category B 
 and its enforcement conditions at ASF: By including only the object/binary 
 form, there is less exposed surface area of the third-party work from which a 
 work might be derived; this addresses the second guiding principle of this 
 policy.
  
 That object/binary form requirement and the reference to exposed surface 
 area in the Policy are nonsense. I repeat three statements I made here 
 previously:
  
 ·   The binary and source forms of a work are, from a copyright 
 perspective, the exact same work subject to the exact same FOSS license. Stop 
 wasting time trying to distinguish them legally.
 ·   Apache is committed to FOSS. For that reason, we should always 
 publish source code. Binaries are a convenience for our customers published 
 by our projects, but never without source code.
 ·   Our failure, or our customer's failure, to make that source code 
 available (including of course any ALv2 code) and copies of all relevant 
 licenses, is a probable breach of license and possible copyright 
 infringement. All modern technology companies understand that about FOSS and 
 copyright law.
  
 The second guiding principle referred to in the current Apache Policy is 
 this:
 2.  The license must not place restrictions on the distribution of 
 independent works that simply use or contain the covered work.
 This accurately and precisely refers to independent works and not 
 derivative works.  Reciprocity has nothing to do with independent works. 
 Every FOSS license (except perhaps under the GPL static linking doctrine) 
 satisfies this second guiding principle. See OSD.
 
 snip

What you call nonsense makes a lot of sense from the point of view of a 
software developer.

The problem with reciprocal licenses in the lines of EPL and MPL is not so much 
in being used as:

a) a *library* or as
b) a clearly *separate piece of code* (that resides in a repository outside the 
ASF)

but rather in *accepting patches* for at least two reasons:

1) it is tedious to *maintain per-line license* information in a source file
2) it seriously *limits the ability to perform refactoring* of code

Of course, 1 and 2 become somewhat irrelevant if a project under license X that
accepts patches under EPL/MPL simply states that all source files are licensed 
under EPL/MPL and *contain parts licensed under X*. 

But then *X becomes irrelevant* because it is hard to impossible to tell which
parts of the project are actually licensed under X and which parts are under 
EPL/MPL.

Thus, if the developers of the project wish that their project remains under
license X, accepting *patches* under EPL/MPL is simple *not desirable*.

Cheers,

-- Richard

___
License-discuss mailing list
License-discuss@opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: [License-discuss] Is what's made with Open Source, Open Source?

[Richard Eckart de Castilho]

First: I am not a lawyer just an interested bystander with an opinion and a 
problem to keep his mouth shut.

So Rapid applications are basically complex configuration files.

Let's say you create a specification for this type configuration files and 
Rapid is the reference implementation.

Let's say somebody creates a new implementation of that specification, the 
Rapid applications run on the new implementation without modification, and the 
new implementation is completely free of GPL (that is the Rapid applications 
have no direct dependency on GPLed code)...

... then I would fathom that applications created with Rapid would not be 
touched by the reciprocal clauses in the GPL very much in the same way that 
documents created with a word processor would not be touched by it.

My 0.5 cents.

Btw. I think that restricting what you can so with the output of a build tools 
such as Rapid may well restrict its adoption - in case you care about that.

Cheers,

-- Richard

On 11.06.2015, at 21:53, Gareth Edwards gareth.edwa...@rapid-is.co.uk wrote:

 Hey many thanks Max,
 
 This is all really helpful - as you can imagine I'm trying to understand this 
 as fully as I can...
 
 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 Open Office document is a good example: I write an essay in Open Office 
 and is the essay Open Source? Of course not, the words in the text are all my 
 own. However the font is not, and, erm, neither are the other building 
 blocks which Open Office is using to show me my essay. The essay can exist 
 entirely independently of Open Office, and I can do things like print it, and 
 still have what makes my essay, my essay, and retain it after it's creation 
 without any further requirement for Open Office.
 
 And this is where Rapid apps get tricky. The debate (I think) is can a Rapid 
 app exist, like my essay, independently of the Rapid platform used to make 
 it? (like FileZilla can exist outside of the mysys compiler) And the answer 
 is, no it can't. What users generate with Rapid are just definition files of 
 properties and what Rapid controls (html snippets) are on pages and what 
 Rapid actions (JavaScript and pre-compiled server-side code) get called when. 
 The app has to constantly refer back to the platform resources to generate 
 the pages and execute the actions. I assume this is linking, or even 
 derivation? Is it enough to ensure Rapid apps are Open Source?
 
 Not that ensuring Rapid apps are Open Source is necessarily the end goal - I 
 just need to be sure if it's yay or nay.
 
 Isn't software interesting?
 
 Thanks for your time and help so far.
 
 Best regards,
 
 Gareth
 
 
 Gareth Edwards
 Rapid Information Systems Ltd.
 http://www.rapid-is.co.uk
 gareth.edwa...@rapid-is.co.uk
 Office : 02081239508
 Mobile : 07818830430
 
 On 11/06/15 19:36, Maximilian wrote:
 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 

Re: [License-discuss] Proposal: Apache Third Party License Policy

[Richard Eckart de Castilho]

On 27.05.2015, at 20:17, Lawrence Rosen lro...@rosenlaw.com wrote:

 If we amended the proposal to leave out the GPL licenses, would that calm 
 your concerns?
  
 I'd really hate to do that at Apache for that set of generous FOSS licenses, 
 but fear is fear Apache didn't cause this fear of infection and Apache 
 can't cure it. There is a group of attorneys that is drafting an appropriate 
 exception that would allow at least some GPL software to be aggregated with 
 Apache software.
  
 But are ALL other OSI-approved licenses OK with you?

I'd personally not be inclined to make a blanket statement on all OSI-approved 
licenses - the list is quite longish.

For example, it is my understanding that the following clause from the LGPL 
also represents a reciprocal licensing term that we do not wish our downstream 
users to be affected by:

 6. As an exception to the Sections above, you may also combine or link a 
 work that uses the Library with the Library to produce a work containing 
 portions of the Library, and distribute that work under terms of your choice, 
 provided that the terms permit modification of the work for the customer's 
 own use and reverse engineering for debugging such modifications.


Actually, I wonder how this licensing term goes along with the OSI rule 9. 
License Must Not Restrict Other Software.

Cheers,

-- Richard
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss