Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add license #15

Merged
merged 4 commits into from
Aug 18, 2021
Merged

Add license #15

merged 4 commits into from
Aug 18, 2021

Conversation

berezovskyi
Copy link
Member

Licensing generated code under EDL instead of EPL allows to provide the derivative work under Apache and LGPL licenses.

@berezovskyi berezovskyi requested a review from jamsden September 10, 2020 16:12
@berezovskyi
Copy link
Member Author

@jamsden can you request IBM to let you dual-license your work "under the terms of Apache License 2.0 and GNU Lesser General Public License v2.1 or (at your option) any later version". This will let us keep this code here and seamlessly push it to SST every once in a while as Manas suggested (but it was lost in the heat of the discussion).

@berezovskyi
Copy link
Member Author

@jamsden would be also good if your lawyers can check the license statement I wrote in this PR. Maybe we can ask Chet for help. If they disagree, I will have to ask Eclipse to allow license generated code also under LGPL, but this shall not be needed as EDL provides the necessary loophole.

@jamsden
Copy link
Member

jamsden commented Sep 10, 2020

I can contribute to oslc-op, following the requirements of the CLA we signed. I believe oslc-op established its IP management when it was established, and that all work products produced by the oscl-op would follow the IP for the project itself.

Let's see if we can keep the OSLC SysML server development at oslc-op and give the SST team time to figure out an organizational structure and IP management scheme for their reference implementation. Using the oslc-op allows us to leverage that existing organization and infrastructure so we can focus on the development work. OMG does not support this structure, so SST will have to come up with something. I would like us to stay out of that if possible so we can focus on OSLC.

Regarding the SysML specification contribution - the SysML OSLC PSM, we need to decide:

  1. what is going to be contributed - probably just the Swagger.io for the SysML OSLC REST API, but there may be other written content and diagrams for introductory material and to explain how the PSM maps to the PIM.
  2. how the oslc-op PSG as an organization can contribute work products to OMG and under what licensing - this is something we can take up with Chet.

Dealing with these cross-organizational issues will be beneficial because it will establish how SysML can be integrated with other things going forward, and not encourage it to be an island unto itself.

@berezovskyi
Copy link
Member Author

berezovskyi commented Sep 10, 2020 via email

@berezovskyi
Copy link
Member Author

@OASIS-OP-Admin hello, Chet! We need to collaborate with an OMG committee and they are releasing materials under LGPL. I was curious if OASIS can let OSLC OP dual-license this work under Apache and LGPL for making this collaboration seamless (ie to have the development under OASIS and do occasional code dumps to OMG), please? If yes, could you please check the proposed license statement under the Changes tab of this PR (I wrote it myself and it needs a lawyer to check it)?

@berezovskyi
Copy link
Member Author

@jadelkhoury @jamsden can we then make this repo public if you got all the legal approvals from your side? Under the terms approved by OASIS, that is.

@OASIS-OP-Admin
Copy link

@berezovskyi - I'm not clear on what kind of collaboration you envision. The Open Project Rules don't allow for work to be licensed under LGPL. The license choices are: Apache License v2.0; Eclipse Public License v1.0; Eclipse Public License 2.0; BSD-3-Clause License; CC-BY 2.0; CC-BY 4.0; MIT License, and CC-0.

See https://www.oasis-open.org/policies-guidelines/open-projects-process#repository-specification-licenses

@jadelkhoury
Copy link
Contributor

This implementation is not part of the contribution to OMG. Reference implementations are not.
The drive to license under LGPL seems to be driven by the group to want a more uniform licensing for all reference implementations. But they are fine with non-open source implementations, I am sure they can live with a non-LGPL open-source contribution.

@jadelkhoury jadelkhoury requested review from jadelkhoury and jamsden and removed request for jamsden and jadelkhoury September 10, 2020 20:18
@jadelkhoury
Copy link
Contributor

btw, I also produce license files under each of the project folders (standard genreation from LyoDesigner)

@berezovskyi
Copy link
Member Author

I did some digging and seems like Apache 2 is not compatible with LGPL 2.1 but is compatible with LGPL 3.0, so as long as they license their work under LGPL 3.0, they shall be able to take this code and relicense it under LGPL 3.0. I will remove mention of LGPL.

@berezovskyi
Copy link
Member Author

@jadelkhoury @jamsden just changed to only mention Apache License.

@jamsden shall we make this repo public once we merge this PR?

@berezovskyi
Copy link
Member Author

@OASIS-OP-Admin I know and I read the rules, they mentioned exceptions, which is why I cced you here. Let's skip LGPL, as Jad said it should be fine.

Actually, this repo has content that is dual-licensed under EPL 1.0 and EDL (essentially BSD-3-Clause). While this repo being a derivative work from that content (generated code, precisely speaking) can be licensed under Apache, with the implicit assumption that the original work is licensed under EDL, which allows relicensing, may we then dual-license this repo under EPL 1.0 and BSD-3-Clause as well to simplify things (i.e. avoid relicensing)?

@jamsden
Copy link
Member

jamsden commented Sep 11, 2020

Sure

@jadelkhoury
Copy link
Contributor

I still don't get it. Why are we introducing Apache, when we already have a license policy established under Eclipse Lyo.
Why are we spending time on this, when we will clearly not satisfy the SST needs anyway.

@berezovskyi
Copy link
Member Author

berezovskyi commented Sep 11, 2020 via email

@jadelkhoury
Copy link
Contributor

Here we generate the licenses. There is a bug that causes the files To be Generated at the root of the path (which makes them located under the model file itself). So I need to fix this LyoD bug.
https://github.com/oslc-op/sysml-oslc-server/tree/master/org.oasis.oslcop.sysml.oslc-server-model/license

But still, why we need to introduce Apache?

@berezovskyi
Copy link
Member Author

berezovskyi commented Sep 12, 2020 •
edited
Loading

That model is 100% copyright of the user, so I agree with you that the bug shall be fixed. But still, just because you put a license in the root folder (which is why I always try to delete those folders) does not mean you have a right to do so (right as a Lyo developer, but here it's tricky because you are both Lyo dev and LyoD user). We should only put a license notice on the generated Java code (i.e. in the top header of each generated file). EPL is a per-file license, BTW.

However, the adaptor itself (i.e. not only the generated code but configs, extra Java classes, handwritten Java code inside the comment blocks, template changes, seed data) needs to be licensed. Apache is the license which OSLC OP chose in its charter. Again, I just asked OASIS above to allow us to license the adaptor under the EPL+BSD(EDL).

@berezovskyi
Copy link
Member Author

Now that we are on this topic, we should not have the user block like this: https://github.com/oslc-op/sysml-oslc-server/blob/master/org.oasis.oslcop.sysml.oslc-server/src/main/java/org/oasis/oslcop/sysml/SysmlServerManager.java#L1. 'Copyright (c) 2011, 2012 IBM Corporation and others.' in that file is a notice and it is not legal to remove it. The user block shall be above the notice, so that it can be used like this:

// Start of user code Copyright
/*******************************************************************************
 * Copyright (c) 2020 OASIS Open.
 *
 *  All rights reserved. This program and the accompanying materials
 *  are made available under the terms of the Eclipse Public License v1.0
 *  and Eclipse Distribution License v. 1.0 which accompanies this distribution.
 *  
 *  The Eclipse Public License is available at http://www.eclipse.org/legal/epl-v10.html
 *  and the Eclipse Distribution License is available at
 *  http://www.eclipse.org/org/documents/edl-v10.php.
 *******************************************************************************/
// End of user code 
/*******************************************************************************
 * Copyright (c) 2011, 2012 IBM Corporation and others.
 *
 *  All rights reserved. This program and the accompanying materials
 *  are made available under the terms of the Eclipse Public License v1.0
 *  and Eclipse Distribution License v. 1.0 which accompanies this distribution.
 *  
 *  The Eclipse Public License is available at http://www.eclipse.org/legal/epl-v10.html
 *  and the Eclipse Distribution License is available at
 *  http://www.eclipse.org/org/documents/edl-v10.php.
 *  
 *  Contributors:
 *  
 *	   Sam Padgett	       - initial API and implementation
 *     Michael Fiedler     - adapted for OSLC4J
 *     Jad El-khoury        - initial implementation of code generator (https://bugs.eclipse.org/bugs/show_bug.cgi?id=422448)
 *     Matthieu Helleboid   - Support for multiple Service Providers.
 *     Anass Radouani       - Support for multiple Service Providers.
 *
 * This file is generated by org.eclipse.lyo.oslc4j.codegenerator
 *******************************************************************************/

@berezovskyi
Copy link
Member Author

@OASIS-OP-Admin I think we really need some legal advice here :)

@OASIS-OP-Admin
Copy link

@berezovskyi - Let me repeat how I understand your request to make sure I can express it correctly to Jamie, as I'll need to pose the question to him.

The OSLC OP wishes to develop code as one of its work products and occasionally ship copies of that code, or parts of it, to a working group at OMG (Eclipse Lyo). Code produced by the OP is covered by the Apache license as described in the LICENSE.md file. However, Lyo uses GPL v2.1.

You are asking whether the OP can add the GPL license to this code when it is copied over to Lyo so that they receive it with the dual licenses.

Have I got that right?

Thanks.

@berezovskyi
Copy link
Member Author

berezovskyi commented Sep 14, 2020 •
edited
Loading

Thanks @OASIS-OP-Admin!

OSLC OP wishes to develop code as one of its work products and occasionally ship copies of that code, or parts of it, to a working group at OMG

Yes

to a working group at OMG (Eclipse Lyo)

No, Eclipse Lyo is a project that I and Jim lead together under the Eclipse Foundation. Eclipse Lyo code is used in our OASIS OSLC work, not the other way around.

Code produced by the OP is covered by the Apache license as described in the LICENSE.md file.

Not yet. This discussion is squarely about this question. We would like to offer it under EPL 1.0 or BSD-3-Simple (dual-license).

However, Lyo uses GPL v2.1.

No, Lyo uses EPL 1.0 or EDL (essentially a BSD-3-Simple). The choice of license lies with the user (dual-licensing).

You are asking whether the OP can add the GPL license to this code when it is copied over to Lyo so that they receive it with the dual licenses

No.

  1. Lyo code is reused in this project as a generated code. It constitutes original work (in my opinion, ofc need to run by legal). The original work is licensed by the Eclipse Foundation and contributors under EPL 1.0 or EDL (essentially a BSD-3-Simple).
  2. The derivative work (this whole repository, which includes the full source of the generated code, i.e. the original work) needs to be licensed. For now I put it under Apache 2.0 license (this assumes that we license original work under EDL which allows relicensing as one of its provisions, again needs to be confirmed by Jamie). If it were licensed under EPL-1.0+BSD-3-Simple it would make it simple for people who have a rather vague understanding of original and derivative works, as you can see from Jad's comments who is one of the Eclipse Lyo leads himself. This license shall also allow contributing the code to an LGPL (let's assume 3.0) licensed repository at OMG. I looked up that BSD-3-Simple or Apache 2.0 shall be compatible with LGPL 3.0.

Questions to Jamie:

  1. Can we dual-license this repo under EPL-1.0+BSD-3-Simple, please?
  2. Will EPL-1.0+BSD-3-Simple be possible to contribute to an LGPL 3.0 licensed repository?
  3. If either 1 or 2 is not possible, can we dual-license this repository under Apache-2.0+LGPL-3.0, please?

Please note that LGPL is a rather liberal license compared to GPL. EDL is the Eclipse Distribution License and is word-for-word identical (see under The Eclipse Distribution License is an OSI Approved Open Source License by means of the New BSD License.) to BSD-3-Simple except for the copyright holder, ofc. LGPL 3.0 is the one being discussed here and not LGPL 2.1 - I am aware of its patent termination clauses that make it incompatible with EPL or Apache.

Thanks in advance 🙏

UPD: My bad, it is MIT that explicitly allows sublicensing but I believe BSD-3 license is equivalent in this regard.

@OASIS-OP-Admin
Copy link

OASIS-OP-Admin commented Sep 14, 2020 via email

@berezovskyi
Copy link
Member Author

@OASIS-OP-Admin did you have a chance to talk to Jamie regarding this? Thank you in advance!

@berezovskyi
Copy link
Member Author

@OASIS-OP-Admin checking on Jamie's reply status

@chet-ensign
Copy link

@berezovskyi - I had a conversation with Jamie about this. It is not so simple.

  • First, each repo gets one license. We don't assign two or more.
  • Second, the bigger problem: all the contributions to the content of repo are made under the terms of that one license. We can't apply a second license after the fact and say 'oh, and we make everyone's contributions available under these new terms as well.' Kind of like developing a spec under Non-Assertion mode and then going back later and saying 'oh, we decided this ought to be RAND instead.' Can't do it.

What you could do would be to create a second repository licensed under the other terms you want to use, and recontribute/reconstruct the content there and make that available to your other party. Clumsy, yes, but it does accomplish the goals.

@berezovskyi
Copy link
Member Author

berezovskyi commented Oct 21, 2020 via email

@chet-ensign
Copy link

This whole issue of licenses can get thorny when you are combining code from other projects. If you have code in your repo under their license, why should they have a problem with using yours under your license?

If you want to switch it to BSD-3, you will still need to reconstruct the repo under the new license. Is there a reason why Apache is unsuitable?

@berezovskyi
Copy link
Member Author

I asked to continue the discussion over the phone but for the record: I have now fully dropped the OMG licensing needs (actually OMG has none wrt reference impl, it's the SST). What we are talking about is the code from the Eclipse Lyo project (aka the official OSLC SDK), which has been checked into this repo as generated code and the code/config done by Jad and Jim in this repo that fully falls under the OP licensing regime. The latter may be Apache if you insist or BSD, but the former MUST be either EPL v1.0 or EDL (essentially a BSD-3). We may also take advantage of BSD-3/EDL license to relicense the generated code under the terms of Apache but I have only heard about this and never done it in practice so Jamie would have to sign off on that.

@chet-ensign
Copy link

chet-ensign commented Oct 22, 2020 via email

@berezovskyi
Copy link
Member Author

@chet-ensign any progress regarding this? Can we apply BSD-3-Simple?

@jadelkhoury
Copy link
Contributor

@chet-ensign @berezovskyi Any update on this? Did you get to setup this meeting?

@berezovskyi
Copy link
Member Author

We had a meeting but I didn't hear from Jamie.

Jad, could you perhaps show the new generated copyright header with just BSD on it?

@chet-ensign could you please follow up with Jamie?

@jadelkhoury
Copy link
Contributor

@berezovskyi I have now pushed the latest license headers on all files.

@berezovskyi berezovskyi mentioned this pull request Jan 14, 2021
Closed
@berezovskyi
Copy link
Member Author

Hi @scott1979rn, are you working with OASIS Open?

cc @OASIS-OP-Admin @chet-ensign

@chet-ensign
Copy link

chet-ensign commented Mar 15, 2021 via email

@berezovskyi
Copy link
Member Author

@chet-ensign, thank you! @img is Ian M. Green with IBM, it's all right. Is Jamie going to find time soon to approve our licenses?

@chet-ensign
Copy link

chet-ensign commented Mar 15, 2021 via email

@berezovskyi berezovskyi merged commit 424af56 into master Aug 18, 2021
@berezovskyi
Copy link
Member Author

Merging the PR to add Apache license because it's the chosen license of the OSLC OP as per email discussion with Chet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@scott1979rn scott1979rn scott1979rn approved these changes

@jamsden jamsden Awaiting requested review from jamsden

Assignees

@OASIS-OP-Admin OASIS-OP-Admin

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
6 participants
@berezovskyi @jamsden @OASIS-OP-Admin @jadelkhoury @chet-ensign @scott1979rn