Bugzilla – Full Text Bug Listing
| Summary: | Migrate to new license (SUA) for Indigo | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Community | Reporter: | David Williams <david_williams> | ||||
| Component: | Cross-Project | Assignee: | David Williams <david_williams> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | a.gurov, ahunter.eclipse, hmalphettes, john.arthorne, kim.moir, michael.wenz, sbouchet, steffen.pingel, tjwatson | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | 336090, 336091, 345021, 346568, 346814 | ||||||
| Bug Blocks: | 340554 | ||||||
| Attachments: |
|
||||||
|
Description
David Williams
Ok, I add to the fun... :-) I already changed to the new license for the modeling.gmp.graphiti project, but by exchanging the files manually inside our projects. That is because we use a Buckminster build on hudson.eclipse.org and there is no Buckminster using PDE 3.7 build available. Are there any plans to make a new Buckminster version available that supports this license-by-reference feature? I know that would be quite early, but well there's this eat-you-own-dogfood-thing... ;-) Definitely not a real issue for me, just a question. Michael David, I think you can safely ignore the error message. >license-feature="org.eclipse.license"
>license-feature-version="1.0.0.qualifier"
It is very good and all, but still it is incompatible with 3.6, right?
Branching the whole project for 3.7 just because of something this minor looks really amusing to me. So, is there any way to use this interesting feature at low costs? If not, then, as they say, "one old friend is better than a two new ones", meaning that the stable and compatible solution is still better despite being deprecated.
P.S.
So, could anyone point me on how to befriend this fine feature with 3.6 (because actually I really liked the whole idea of reducing the amount of copied license files)? :)
(In reply to comment #3) > Branching the whole project for 3.7 just because of something this minor looks > really amusing to me. So, is there any way to use this interesting feature at > low costs? If not, then, as they say, "one old friend is better than a two new > ones", meaning that the stable and compatible solution is still better despite > being deprecated. The license substitution support is only in PDE 3.7/Indigo. So, to make use of it, you must use a *builder* that is based on 3.7. This does not imply anything about the dependencies of the software being built. I.e., you could use PDE from Indigo to build software that is based on the Helios version of the platform. The license substitution support is purely a build-time concept, with no dependencies at install-time or run-time. By "stable and compatible solution", I assume you mean updating all license files by hand or using David's tool. That is certainly a viable option, especially if you only have a small number of features in your project. To be clear, nothing was deprecated here - license features are a new concept that can be used as a way of authoring and managing feature license info, but you are not compelled to use them. For a small project or plugin the concept of license features would be too heavy weight. [repeating much of what John said, since I'd already typed it in.] (In reply to comment #3) > >license-feature="org.eclipse.license" > >license-feature-version="1.0.0.qualifier" > > It is very good and all, but still it is incompatible with 3.6, right? > Sort of. You can put these attributes in your feature.xml file, and they will show as "unrecognized attribute" in a 3.6 IDE. (There's preferences to change from error, to warning, to ignore ... but, this applies to all unrecognized attributes, of course). But sort of not. These attributes are only used at "build time" so, it is conceivable someone could build with a 3.7 based PDE builder, and then deliver to 3.6 clients. Once built, the licenses and properties, etc., look as they did before .. they are just "pulled in" during the build, instead of always being there as part of the project in your SCM. So ... won't work for everyone ... but some people might want to do that. But, let me extra clear ... a "new license" is not required for anything "in a maintenance release". We are finished with our last overall Helios maintenance release ... but of course any project is free to have their own ... but if you do ... I suggest you might want to use the "old" license in the original release just so it still "matches" all the other licenses you'd be installing with ... in which case, why bother migrating to a new license support style. But ... each project is free to decide _how_ to implement ... all we ask for Indigo is that we all use the same one, so users have an easier time of it. I knew this would be fun :) Thanks for answers. I have something about 10 features with license files, so it will definitely be more fun to update license files just once but not ten times in a row. And PDE build do actually remove these incompatible attributes at build time, but 3.7 is still at the stage where it could be used for running builds at most but not for the plug-in development (at least JDT works way more funny than in 3.6). :) Then, it seems like features in Subversive are already up to date regarding license files matter, so I've decided to wait a little before introducing the license feature into the Subversive project. P.S. Thanks again for such a detailed answers! I just ran my tool to check license consistency, based on the Indigo M7 repository. Below is the summary for M6 (complete details attached): Summary: ======================= Features with conforming license: 127 Features with different license: 623 Features with no license: 1 Features with extra licenses: 0 ======================= Features with no license: ======================= org.eclipse.jwt.feature.feature.group 1.0.0.v20100719-0900-7N--FJdMh0gj33jLjjgg Created attachment 194188 [details]
License consistency details for Indigo M6
Summary for M7: Summary: ======================= Features with conforming license: 320 Features with different license: 453 Features with no license: 1 Features with extra licenses: 0 ======================= I'll attach an updated full listing after RC1 declares tomorrow. Not perfect, but better than where we were a few weeks ago. I suggest if a projects sees any of their features in the RC4 report as still using 2010 licenses, that you open a bug on yourself to fix it at some point, especially if the feature is changing anyway, in maintenance. Just as well get caught up! ... we will continue to measure and flag the deviants. But, thanks for the great improvements! Indigo will have a much better appearance to most users now without so many variations. http://build.eclipse.org/indigo/simrel/reports/licenseConsistency.html # Repository ('repoURLToTest'): file:///home/data/httpd/download.eclipse.org/releases/staging # License Consistency Summary: ======================= # Features with conforming (2011) license: 629 # Features with old (2010) license: 195 # Features with different license: 3 # Features with no license: 0 # Features with extra licenses: 0 # ======================= # Details: ======================= # Features with no license: ======================= # Features with different license: ======================= # org.eclipse.riena.build.feature.core.sdk.feature.group # org.eclipse.riena.build.feature.samples.sdk.feature.group # org.eclipse.riena.build.feature.sdk.feature.group # |